Ok... NOW I'm sad.

Originally Posted by Zwillinger GG, I would tell you that "I am killing you with my mind", but I couldn't find an emoticon to properly express my sentiment.

Originally Posted by Captain_Photon NOTE: The Incarnate System is basically farming for IOs on a larger scale, and with more obtrusive lore.

Good in a bad way: they also laid off legal.

You're thinking the seconds2frames is made while the game runs, of course that's inefficient. You've got to pretreat the data. Is it still inefficient ? I think it's the least-size representation, since the seconds get rounded to frames anyway. And least-size is always the most efficient (given everything else being equal). In truth I can't see what you mean by making the power activation period explicitly supported in the primary event loop, except what I'm doing: expressing the delays & time in general expressed in event loops, that is, frames (which is the end-product of a loop).

It *will* have all of these, in some form or another of course. The values each power has of these "power attributes" is supposed to be part of the data used by the engine. True, the Mids database doesn't have all of these. (stacking and near ground at least). I didn't think of suppression up to now, but that would take registering the last supressing effect's occurence.

Well, even if it's not the same engline but the same results, it has the same "complexity", but As Codewalker said, there is no need simulating when making the engine, implementing existing designs is far easier than making up a new engine with new designs or a one-shot simulator of each power.

Ranging from 2 minutes to a week-end, depends on what that humanly means :S Looks like a coma-separated... thing, each thing between comas is a token meaning... function names, operators and parameters ? You would need to set up a grammar in Yacc or Bison (heh !) and make your hearts desire come true.

First implementation: A "check toggle" clause for effects (next to the "onHit", etc, a "if X power toggled on"). Or, given this could be used for other powersets, just make a new "attribute" that's set by the toggle (it's just not a "vital" attribute of entities, it's here only for certain powersets).

But there is something you can use already, the "mode" variable every entity has. Like "disableAll" etc. These are just bits in a bitfield right ? It can be set/deset as part of effects too.

Obviously, you pass messages to the UI. And this is done as part of the powers. So be it, also set these "flags" or attribute. Use the decay (inverse to regen, used for Fury & domination) mechanism already implemented to reset this attribute to 0 (no combo) (with infinite decay every T seconds) and use specific values to test for equality with subsequent powers.

Or you can use modes or a mode-like system. A special bitfield for use by powersets, like the dual blade, dual pistols, or street fighting, Titan Weapon, Staff Fighting (notice these are all offensive powersets, so mutually exclusive on one single toon). Fiery Embrace is an exception, but it's a single power, it could manage with only one bit of the new bitfield. Each new power could use specific bitmasks to apply to the new bitfield, given the effect. This has to be done for these 5 or 6 power sets, and you have to code the method to parse these commands, but it's not goint to take 10 hours.

The second, obviously it's the simplest to implement and not quite inefficient. Why reinvent the wheel ? "Fury" is built as part of the melee powersets (all of them), just that the fury stat is not used (nor shown) to other ATs. You forgot Domination, that works the same way.


You already did that. And listing them would be technically beginning to implement the engine.

What makes you think there is a 30/sec animation loop ? I think there is no animation loop at all, it's just animation notices sent to the client, and eventually rooting notices to the the movement enging. If there was animation "synchronisation", it would never desync the Flares animation from floating text (which are also noticies to the graphics engine to render. Maybe a max of 3 of them / entity / frame + a total in case of overflow, in order to keep vitals in sync) or at least it would try to reanimate when at point blank. Which I've not seen the game doing even in very bad server lag situations. (like Nova'ing the hell out of towers in the last cimerora mish. I did see reanimating powers in traffic lag when duplicate packets were received.) If there is synchronisation, it's because the animation notifications is part of the combat engine's responsibility, because it knows the power launching, and thus, their animations.

That should be done only when it's both more efficient server-wise and if it's compliant with the present behaviour.

So what's difficult in doing that ? Here you *specifically* need script1 calling script2 and each needs to be different for it not to loop. Of course the better way would be designing a "chain" target zone, next to single-target, PBSphere, and targeted sphere, and that's more difficult because you have to change the data. But that's only a handful of powers. And I did specify that you could take twice as much time to do something better instead of just reimplementing the game.

That requires either a new mechanic, or pretreating the powers. I wouln't like the additional complexity of adding the possibilty of a single effect affecting only a select numbers of target, I would do the 0-range sphere pseudopet technique, even if its displeases me. But hey, I'm not perfect.

[/quote]Do you directly implement exactly how our game engine deals with buffs that buff themselves? Or do you fudge, again by hand, Combat Training: Offense?[/quote]You mean things like resistible resistance debuffs ? Hell, I would straightly implement it without trying to fix it. It's part of the compliance. Buffs are always Irresistible and/or "Ignores Enhancement & buffs" to try to diminish these effects, even for resistance (doesn't take +dam into account)

I'd pass the hot potatoe here, I only signed for a combat/vitals engine, the state of the enhancements is modified by another engine and taken to combat engine as input when the entity is a player (Enhancements could be carried to the pseudopets by way of buffs, because an enhancement is a power-restricted buffs, power that spawns the pseudopets).

Yes but you can't change what's an engine and what's a data. When you had issue 7 (or the one when city of villain came out) you could have inserted the Demon Summoning Powerset without changing the engine (well, maybe the graphical one), but you could not do the same for the Dual Blade or the Bio Armor/Nature Affinity one because it's using all new mechanisms. Once you have put the Nature Affinity in the game (engine + data) you don't need to modify the engine to make Bio armor work, just list a set of powers, that is data, that the engine interprets.

Conclusion:Hey hey hey ! we nearly went over all the mechanics of the combat in the game in a single post ! And you still think this would take 1000 hours ? Okay, I'll give you the time we are spending discussing this

1. Because there's evidence for it in a number of places including Arcanatime, and the way the game engine attempts to synchronize rooting between the server and the client. I suspected its existence long before, when I first discussed predictable bits with BaB.

2. Because pohsyb confirmed the existence of that system when I discussed game clocking with him.

If anything, my estimate actually went up. You seem to be dismissing anything that isn't "hard" as taking essentially no time, when the problem isn't complexity, its thoroughness. For example:

That's just a postfix expression. But you're focused on the grammar, and not on all the systems that grammar implies have to exist. Its referencing entity properties set by other mechanics, all of which would require more code. There's no possible way to make the expression system work in a week end.

To you its just tokens. But its actually an example of the number of moving parts in the game engine you can't trivially simplify.

There are dozens of attributes with half a dozen aspects, plus over a hundred mechanically different ways to affect them. That's hundreds of hours just to create a complete attribmod calculator. If you spent 24 hours a day for four weekends I would bet anything you would not be finished with that, and that's maybe 15% of a working combat game engine.

It took me two weekends worth of work to write the code to simulate enough attack calculations to generate my attack set metrics for I24 beta ranged set metrics, and I hadn't finished adding the tohit tracking for fast snipe. That would be about 0.5% of a working combat engine.

Honestly, I recommend you to spend just a single weekend writing as much of an attribmod calculator as you can. Not even an engine, just a calculator that can be given a set of attribmods and will calculate what the attribute values are for the entity that has them for the full duration of those attribmods, moment by moment. That's like at most 1/6th of a full combat engine. If you think you can write a full combat engine in four weekends, you should be able to do this in one without missing the NFL late game.

Just try it for even one hour and see how far you get. I can only assume you are dramatically underestimating the time necessary because you have no reference to compare to.

I actually miswrote that. I meant: What makes you think the 1/30 sec loop is the animation one ? Is it exclusively animation ? I think it's the combat/vitals loop, and the 1/8 sec loop the positionning loop, and animation is just a by-product of the power part of combat.

Ok, so the only hard part is thoroughness, you say ? My thoughts exactly. But most of the thoroughness is already made by datamining efforts done by the Titan Network with City of Data or the Mids. Essentially, my estimation is that when you get to implement every player power, you've got all the mechanics, and then you just need the bulk of the data, that is not the combat engine, actually, it's the NPC data, the powers each have and what each power does. But I also think what remaining out of our reach is the "which powers has every NPC" database, because we can already have the real numbers of NPC powers.

It's an example of what, actually ? When does this get involved, and what does it do client-side ? I did throw grammar at it because I didn't know what that was. I do want to know when and what because that could help me understand the mechanics, not reinvent an emulating mechanism. I know you don't invent things, but I was as puzzled by this as much as if you did. I could have called that an "*** pull". If it's power-related and not in the City of Data database, it's useful. If you just applied that fancy representation just for the pleasure of finding me dumb-founded... well... I don't see the point.

ho ho ho, now you're getting interesting ! Okay, I take the bait. Though I don't have access to the database, so I'm going to make a dozen sample powers each from a different set, and that doesn't count, okay ? Also, I may cheat a little because I did code it a bit in my head so I have a headstart (heh). Language is C++ but no inheritance (so C code-efficiency but easier time writing the code).

I don't know the functions you implemented nor how you implemented, so I cannot judge. Even if I saw the code I couldn't even fathom the number of times you rewrote this or that.

Probably because all of the animation data is specified in terms of frames, and there are 30 frames in a second. That and discussions with a developer who worked primarily on the animation side of things.

30hz would be awfully inefficient for a combat loop just because of how much time you'd spend re-evaluating things that don't really change all that often, relatively speaking. The server DOES have to process animations, if for no other reason than to figure out how long to root a player, since the only place that information exists is on the flags of the animations themselves (the ones flagged CantMove). Not to mention the timing for things like weapon redraw.

I think it's been fairly well established by information posted by developers that there are two separate loops going that interact with each other periodically.

We have access to that, just haven't advertised it. Come to think of it I'm not really sure why the client would possibly need that data, but I guess I can't complain that it was included.

That's an RPN expression, which I alluded to earlier as they are used extensively throughout the combat system. From deciding whether or not to automatically grant you powers when you log in, to if you can access a particular power set or pick, or if certain effects of a power apply or not (think combo levels, Disintegrating, Dual Blades combos, and just about any other dynamic behavior a power can have).

City of Data pretties them up a bit before displaying them as conditionals -- it contains a parser that re-arranges them into algebraic notation. It also evaluates them in order to try to figure out if a certain effect is PVP or PVE-only, and whether or not to count it in the "average damage" total.

Incidentally, I did write that parser over a weekend, but it's a grossly simplified version. It implements all of the grammar I believe, but when evaluating most of the variables just dummies them out as zero or a predefined default.

The 8/sec loop determines when actions can start, the 30/sec loop specifies when events occur, and it keeps the server and the client synchronized.

The difference between what I'm calling an "action" and an "event" is: activating a power is an action. A regeneration tick is an event.


Nope. Every bit of data implies hundreds of lines of code to do something with that data.

Also, this assumes the person looking at the data knows what they are looking at.


That would be more definitive than debating it, because honestly there's not all that much to discuss without flat-out writing a spec for the engine. Only by looking at the data for real and writing code for real are you likely to appreciate the scope of what we're discussing. Or alternatively, your idea of the scope of what we're discussing is radically different than mine.

Depends on what you mean by "similar." What I was talking about was reproducing, in effect, every aspect of every power and every enhancement currently in the game. Its not necessary to do that in the same way as the game engine, but if you're not reproducing the CoH engine precisely, you're just making a different game, which was not what I was talking about.

Consider everything that happens when I activate an attack. Do I have something targeted. Is that thing a valid target for the power. Do I have enough endurance to activate the attack. Am I currently rooted. Does the attack require the target to be near the ground. Does the attack autohit that type of target. What is my base tohit verses that target. What are my net tohit buffs and debuffs. What's the highest net defense of the target applicable to the attack's attack types. What's the accuracy of the attack. What's my net tohit. Does my tohit roll fall below the tohit threshold. What are the attack's effects. For each effect, does it affect the caster or the target. Does the effect have target conditionals. Is the target within the outer radius limit of the effect. Is the target outside the inner radius limit of the effect. What attribute does it affect. What aspect of that attribute does it affect. Are there combat modifiers (level differences) in play. Is the effect immune to combat modifiers. What kind of effect is it: is it a Magnitude or Duration effect. What's its scale value. Is it an expression based magnitude effect. What does its magnitude expression evaluate to. What is its effect modifier at this level for the caster's archetype. Does the effect have a chance to occur. Does the effect have a duration. Should we resolve the effect immediately or should it be delayed. Does it have a period. Does the target have resistances to this effect. Is the effect unresistable. Does caster strength affect the effect. Is the attack itself immune to such strength. Does the effect create an entity. Does the effect grant a power. Does the target currently have an effect identical to this one cast by the same caster? Does the effect stack from the same caster. Does the target currently have an effect identical to this one cast by any caster. Does the effect have a stacking limit. Is the current number of identical effects under the stacking limit.

None of these things are things you can handwave away, and still have a game that functions like City of Heroes.

Okay so the action loop is filling the event loop's data ? Action's loop is processing the "launch power"s and the event loop the "Do X points of damage"s ? (notwithstanding all the other things in the event)

[quote]Nope. Every bit of data implies hundreds of lines of code to do something with that data.[quote]NO NO NO NO and NO for god's sake ! What kind of project manager believes that ?
Once you've implemented something able to decode the data behind, let's say, the Nemesis Staff, it's far easier to do the Force Field.Force Bolt ! But you can't directly do Smite then, except if you've done Shadow Punch ! You have a baseline of minimal data to process and then all the data can be processed by the engine ! It's not because you've got 1000 powers and that it takes 1000 lines to implement Brawl at first that it's going to require 1000x1000 to implement everything ! Gosh !

Of course. In my mind I assumed the person has access to the Mids representation of the data, or the way the Titan Network produce this data from the most obscure representation. Anyway it's the same data.

True, true. Benchmarking But actually, we have been writing the tech specs nonetheless, at least it's table of content.

More or less. Critically, the 30/sec loop also calculates when animations start and stop, because that has to be in sync with the client that does animations. At launch, there were all sorts of odd glitches where the player would activate a power and the character would just stand there. That's because the server told the client "do this" and the client said "can't, still doing that" and then the client said "done, now what" and the server said "forget it, I'm already moving on to the next thing." The server has to know what the client is doing, which is why the server, among other things, has to now what is happening at every 30th of a second, because the client works on that clock.

This interplay generates the server side lag we call "Arcanatime." But even if you didn't want to reproduce this behavior, I'm not sure there's any significantly easier way to reproduce all of the events in the game engine as they occur. It actually took me a couple of days of thought and experimentation to come up with the design for a reasonable scheduler that would properly process everything that happens in City of Heroes.


Assuming I'm an idiot will only cause me to conclude you're one. Because every *other* programmer in this thread that has worked on something larger than "Hello World!" I'm pretty sure understood what I meant, which was that every data element in the power schema represents a data field which is processed by the game engine, each in a completely different way. Especially within the context of everything else I've said in the thread.

On top of that, many fields are themselves indirectly processed, like the Expression fields which themselves require an entire scripting engine just to process. And parsing the grammar of the Expression fields is exactly zero percent of the problem. The real problem is writing the code to properly evaluate all of the indirect references to the game. Which *itself* requires entity tracking code to allow for those indirect references to go somewhere. AttributeRequires as a single field could end up taking ten times more code than fully processing all of the damage-type attribute fields because of that.

(Since Abs and Cur modifiers on those attributes actually point to Health, they can all be processed with an iterated loop of code, but they cannot be processed with the same code as all other attributes with their own separate attribute values directly. Doing crazy pointer magic to make all of the attributes work with a single processing loop would save some coding time, but probably add significant debugging time to the process.)

At this point, I'm really interested to see what sort of code you generate, to represent your understanding of the actual problem being discussed.

<----- Evolutionary pressure

Recoded and implemented a Learning (Artificial Intelligence) framework. In a team I'm currently working on... something... I guess I could say multi-sensors calibration and in particular, Kinect handling in an existing framework, the thing is enormous but I'm still green in this project. I didn't do real-time game development, I've had real-time courses though, and the server is NOT real time (else it would never "lag" (I'm talking about cimerora/hami lag))EDIT: forgot to tackel the networking code. I did do the master part of an I2C communication system as part of amateur robotics system back in school. I also pretty well remember the practical sessions with linux virtual machines.

Sure I'm not a multi-decade code veteran here, I didn't code in Basic or Fortran, nor on Amiga or Amstrad, but that doesn't mean I don't have a brain and can't learn or work, or that what I was taught was crap. Doesn't mean I know it all either. I actually want to appear stupid and get told things harshly than people saying nothing and letting me in the wrong. Actually, I've come to see this little explanation as tutoring on the game's mechanisms, making notes here and there that could see better use than in the dark corners of a single brain. Also, I'd like some people to come to term with their assumptions that there is only the harsh way to an implementation.

Wait, the client shouldn't do anything, it's a client, it sends request and gets updates, everything happens server-side, well, nearly everything, at least everything combat(and animation)-wise are decided on the server-side and just user input is forwarded by the client (things like respec or real powers for instance use data on the client side plus eventually some constant data received from the server ages ago, like the chosen powersets and currently slotted enhancements). Since you would know some lower bounds to some effects you can program the client to actually don't forward things the player can't do anyway, but ultimately the server has the hand and say 'it's ok'. If it was like you said, if the server kept in sync with the client, how could you have powers showing ready when they are not ? How could I animate Haste (though only the excitation/shrugging, not the pompoms) when I activated it when it wasn't server-ready ? I believe the client does not sync the "animation", the rooting for sure (because it defines what the player is able to do) but not the "play flare animation" part. Animation is fluff, feedback, rooting is an effect, even if it's "animation rooting", isn't this why some powers don't root anymore (non-offensive PBAoEs anyone ?) Or am I missing something

This kind of delay always happens when you have numerical systems (instead of analogical), time sampling tends to create delays if not resonnance, at least if you don't compensate for it, which is computationally expensive.

What's actually the most unnerving in network play ? movement lag. Power lag, everybody can do with it, but jumping a fraction of a second too late and your down the hole instead of on the other side. So movement has a special treatment in network games, everytime. Since you have the network lag, it's no use doing it 120 times a second, that's why the Entity placement engine is on this 1/8 timer, and power launching is the duty of the placement engine because line of sight is one of the requirements. But the combat/effect timer can be as fast as you want, basically, because you have events based on time, and in a second it doesn't matter if you loop 2 or 6 times because you'll have to do as much processing (well, not to maintain every timers) but you'll have as many messages to send.

Sorry, didn't mean that you were an idiot, I meant that reading what you said made me think you were an idiot, and I can misread, or read too literally. You could have seen from the answer I took your "data" was the power data, not the entity data, the memory that represented the actual state of the entity. But I did have the first misjudgment so I do understand why you just passed over that =) Also, I'm handicapped, because English is not my mother tongue.

[/quote]On top of that, many fields are themselves indirectly processed, like the Expression fields which themselves require an entire scripting engine just to process. And parsing the grammar of the Expression fields is exactly zero percent of the problem. The real problem is writing the code to properly evaluate all of the indirect references to the game. Which *itself* requires entity tracking code to allow for those indirect references to go somewhere. AttributeRequires as a single field could end up taking ten times more code than fully processing all of the damage-type attribute fields because of that.[/quote]What's this "expression field" you're waving around ? never heard of that. That's the list of power effects ? Codewalker already said it was done, and I'm not one to let done work spoil.

That's still only 2 things to do differently, and since you've got functions, with parameters you can code pretty much any number of cases in your functions. It doesn't reduce the complexity though, I agree. It has to be somewhere. But you don't have to code a function for every existing combination of effect. What's the parser for then ?

EDIT: As I lied down to sleep, I understood your point about damagetype attributes and health now. That does shake my already-laid coding plan, but I'll make up a workaround this night I think, else tomorrw, else, with an ugly hack.

That could sort things out. But do we agree I just have to produce a library that handles entities and all their attributes (inspired from the attribute window plus every hidden attribute/fields I need for the implementation) and "example" functions that apply all power effects that I can think of and translate it into calls to that library ? Then the next stage would be executing said function when parsing the matching power's effects part.

May I ask why the NPC data was always kept hidden in the back-end of things? I've often wanted to be able to, say, look at how much resistance various enemies have, or exactly what the various powers of the Awakened are doing behind the scenes as they charge up and flash text at me, and it's always been a bit frustrating to know that it's in CoD, just hard to find.

Because you have an in-game tool to do exactly that, it's the power analyzer (MK3 to hit any mob). Once it has hit you have the hit entity's real numbers (attributes), and so this data would have come to nullify the need for this power.

That's not the why. The existence of that tool vastly post-dates the decision to hide almost all entity information from the players, including that for their own characters. Power Analyzers were essentially hacked in with Real Numbers, which was the first serious foray into giving the players in-game numerical information.

The actual answer to the question is that the original game designers believed as a matter of game design philosophy that it was harmful for players to understand the game mechanics, because it was felt that this would lead them to focus on game mechanics themselves instead of playing the game as presented. They wanted us to enjoy the game for its qualitative features instead of its quantitative ones.

Personally, I think this was terribly misguided. Access to how something works does not primarily drive whether people focus on it. People who want to focus on those things will do so, and people who don't want to will not do so, whether the information is easy to access or not. Yes, there are some middle-ground folks who might swing one way or the other depending on what the game provides, but I suspect very much that they average out overall.

Unfortunately for this game's original devs, its designers were either very bad at math, or at least very bad at interpreting how the things math told them would translate into functional play. Because the players were largely disallowed from knowing the math or the numbers to plug into it, they could not detect this or show it except qualitatively, at run-time. That made it very hard to convince the devs of real performance issues, for either over-performing or under-performing things.

Actually, I feel the really difficult things to simulate would be things other than the combat engine. I think we know enough about that engine to logically recreate a functionally similar entity. But even a combat-centric game like CoH has huge amount of extra systems that also need to work right, and I think that the potential for difficulty is way higher for those other systems. I personally have no idea what the difference is between Pet AI and mob AI, and the coding that goes into that (except that you are responsible for mobs dealing twice as much damage through AI tweaks).

Don't take this the wrong way; again it's not an insult to your capabilities. But there is one thing you can never learn by studies and can never be taught to you and that is how to do estimates.

Do this experiment: at random select 10 libraries/classes/whatever code files you are familiar with in one of those projects. Without opening them, guess how many lines of codes they have. Write it down. Then open them and count them. How many did you get right?

I am looking at a very simple piece of code right now, does nearly nothing. Its 112 lines of code. There is no optimization that can be done to it, it’s rather sleek code. Best I can do is making it hard to read by bumping code lines on top of each other and deleting comments. This just makes it harder to work with later, though.

The point is, you can have a perfectly clear idea of how to approach a coding task, you likely have what it takes to do so, but without enough years of experience you are nearly certainly going to understate how long it will take you.

Again: not doubting your ability to do the job we are talking about, I am doubting your ability to do the estimate on how long it will take you and how many lines of codes you will end up with.

Heck, after 16 years of coding for a living, I still often understate it! I made a habit of just padding it upwards because I KNOW I am getting it wrong.

BTW: I am not singling you out. I asked you because I am already familiar with Arcanaville's background. You will notice I also still asked her about her 3k hour estimate (for a MyBrute project) despite knowing that, though.

Oh one last thing: real time game development does not mean things won’t lag. "Real time game development" simply means the loops are aware of how long they take, and advance things appropriately. If a loop gets overloaded for any reason and is delayed, there will be lag, but time will not come to a halt. CoH server is real time in that sense. If something overloads and a loop hangs for 2 seconds instead of 0.125, you still will see 2 seconds pass in the recharge timer of all powers (for example) or enemies move 2 seconds worth of distance based off their last active speed, etc etc. [It also may mean the game is not turn based but that's not what I mean here.]

The intricacies of real-time system programming, mostly.

Dual box sometime. Then ask how its possible to see what you're seeing and still have a sane game.

Effects can have a Requirement in order to take effect, for example TargetType = player (for PvP effects) or source.kMeter > 0 (stalker hidden). These are entered into the power data as postfix expressions. It takes an integrated script processing engine to understand what "source.kMeter > 0" means, and it implies you either have to translate that into another concept on the fly programmatically, or you have to add entity tracking code that knows what kMeter's value is on the source of the power at the time its activated. Even the magnitude of the power is sometimes an expression: (source.TeamSize(30) * 0.03 + 0.07 >= rand()) * @StdResult -> the Assassin's strike non-hidden PvE critical.

If you don't know these things even exist, I'm not sure how you can be so certain about your estimates for how long it would take to reproduce all of the combat engine's behavior.

Technically, there's only one thing to do:

I never said anything about combinations of effects. If you think I mean combinations when I say the engine does hundreds of things, you don't understand what the game engine does. It does hundreds of discrete, singular, computationally different things. Magnitude resistance is different from Duration resistance: they require different code because the formulas are totally different. MaxMax buffs are totally different from Strength buffs. Zero duration effects are handled differently from non-zero duration effects. Extend stacking is different from conventional stacking. Cur is different from Abs. (Base) Defense is a special case of Attack type in the attack/defense type summation code. There are hundreds of different things in the engine, not dozens of things in hundreds of combinations. Hundreds of different things that require completely different code because they cannot be procedurally summarized.

Exploits. If everyone can read the data easily, things like Hamiddon would have been defeated on day one.

CoD can show it if they wanted, but they would likely get in trouble with the devs, who would either attempt to take them down or obfuscate data in the client further.

The difficult parts of making a real MMO engine are all the optimizations involved in making working map servers, real time network code and event queues, etc. Things I have no current interest in doing. Replicating the game engine would be, for me, an intellectual challenge to see how well I actually understand it. And part of the reason for the large time estimate is that I'm pretty certain there are interesting problems in the way the engine does things that I won't really understand fully into I try to implement that in code. In a real project, debugging and reimplementing code to account for problems represents a large fraction of the total time. The time to program something is not identical to the amount of time it takes to type the final source code.

I know I spent a couple of weeks, off and on, just musing to myself how the game engine must work for unresistable resistance debuffs to work they way they do and for Combat Training: Offensive's accuracy buff to work as it does. When I posted my results on ranged damage metrics in the beta fast snipe thread a legitimate question was whether I had properly accounted for sonic blast buffing its own DoT with -Res - which I had not, because my calculator (deliberately, due to time constraints) did not deal with effect over time specifically in that manner. But that has a very significant impact on Sonic's numbers.

Having written damage calculators, damage mitigation simulators, and other discrete calculators gives me a particular perspective on this topic. The sheer amount of stuff the game engine does is enormous compared to the amount of time it takes to account for each effect.


Also, it was only on average about 28% more damage except in some degenerate cases.

By mutual agreement, most of the people (I'm aware of) that were capable of seeing that data elected to show player data and not critter data, due to the potential for critter data to be used for exploitive purposes or to spoil the intent of certain content. For example, before I told the players what the LRSF towers did, I tested them myself to prove that knowledge was capable of being determined in-game by a player, and even so I left one thing out until the devs granted me permission to mention it - the momentary intangible buff that allowed Recluse to break toggle debuffs.