One problem I encountered in my first game was with processing simple interactions between various game entities. For instance, if I'm processing movement/changes to each entity each frame, I might get the following: Code: Process Entity A Process Entity B Checks current state of C and uses information to make changes to A Process Entity C State changes, meaning that B should not have applied changes to A Undo changes to A So in the above case, it would have made sense to process in the order CBA instead of ABC. But there's no way to predict in advance what the optimal processing order might be, especially as the number of entities grows. I realize that the problem with my method is that each entity not only needs to know information about others in order to decide what to do each frame, but it also needs to know what other entities are affected by any changes to itself. This caused numerous problems that were difficult to track down. So I'm wondering how to handle things this time around. An easy solution would seem to be to record the current state of each entity at the beginning of every frame, then process all the entities using the recorded state. Code: Frame 0: ... Record state of A1, B1, C1 Frame 1: Process Entity A Process Entity B Checks state of C1, raises flags that A needs to be aware of Process Entity C State changes, raises flags for B not to make any more changes to A Record state of A2, B2, C2 Frame 2: Process Entity A Checks B2, which has flags that A needs to be changed Checks C2, which has flags that A needs to ignore B No changes made Process Entity B Checks state of C2, does nothing Process Entity C Does nothing Record state of A3, B3 C3 This seems like it would be simpler and cause fewer problems down the road. I like that Entity B and C don't need to know that A is affected by them at all, and that any changes to A will happen during A's own processing cycle. I do suspect that going this route would make it important for me to process events faster than the graphical framerate, perhaps run this physics loop 1000 time a second and use the last recorded states of A, B to do the drawing at whatever framerate is needed. Does this make sense? Is there a better way to handle such things? I'm sure this is a basic problem that pops up in simulations of all sorts, but I haven't found any good resources online for how to deal with such things (pointers to such would be greatly appreciated). Thanks, ::ken::
I'm not sure what your talking about to be honest, is this a physics thing? Or are you talking about passing messages between your entities? Could you give a more solid example of what your problem is?
Does it really make a difference? Instead of considering everything happens simultaneously, make everything happen everthing almost simultaneously : what A did is done, if B comes later in the update chain, it will afect the NEXT update of A. Unless you're doing complicated physics stuff, this should be good enough. I do it that way in Wild West Wendy. If two characters try to walk into the same square, the first one wins, the second one waits.
I'm also not totally sure what you mean. But usually my entities have member variables with can be changed externally, but any physical action that needs to be taken, is only taken from within that entities own process. Ie. Weapon's Process Finds collision between player and laser shot Weapon subtracts 20 from player's life stat. Weapon destroys itself. Player's Process Checks it's own life, it is found to below zero. Player destroys itself. Is this what you mean?
I think you're looking for trouble. Unless you're running some super-realistic physical simlulation, it's not going to matter. AFAIK, the standard practice is just to run through all the entities, update them, and not worry about "who got there first". These are small errors that won't make the slightest difference in the experience. If you are doing a super-realistic physical simulation, it's impossible to exactly determine information that you're trying to figure out. Computers are discreet machines that can only go so far. You'll run out of bits before you run into problems with your simulation. My advice: don't waste your, or the computer's, time going for a more complex method than linear processing. If it's just a game, it's definately not worth it!
In my experience, this kind of problem shows up most in physics. Perhaps you have one character pushing another character into a wall. In which order do you process the collisions? If you do it like Process Char 1 <-> Char 2 Process Char 1 <-> Wall Process Char 2 <-> Wall you may still get characters being pushed into each other, or into the wall, if you do the collision another way. Another way is to calculate and accumulate the forces being applied on each character in one character update loop, then loop over them all again and apply the forces, causing the actual movement. Sure, some wall intersection may occur, but I don't know a better way. Any other ideas? Or have I missed the point of the question?
I used to just add physics events to a queue on each object and then apply all the changes in that order after all the physics processing was done. I suppose it could be generalized to handle all object state changes though. Now I use Torque2D and don't worry about it anymore.
You may want to try this link:http://www.gamasutra.com/features/20030829/vanderbeek_01.shtml It goes into dependency issues among various game entities. A very good read but not the stuff I need to deal with for now.