a good thing too since the game was totally non-deterministic, and therefore has to transmit combat results, etc, not just moves and input. since the title was non-deterministic, prediction methods were not an option - and would have been unacceptable due to the accuracy required by the simulation - IE no being denied a kill due to inaccurate prediction methods.
So this is a slight derail, but metamorph seems to have gotten a lot of good info, and might also find it useful. Would you mind expanding on what you were doing that was non-deterministic?
the whole game was made as random as possible as a single player game first. then co-op multi-player was added. since the random number generators on each pc were seed with a value derived from the time the game was launched on that pc (down to the millisecond), you couldn't just say "target x fires" and then rely on the same results from all "dice rolls" on all pc's to take care of the rest. likewise, since you couldn't know what random number a given node would generate next, it was pretty much impossible to predict changes. as a result, all non-deterministic stuff (IE dice rolls) were handled by the server, and the results passed to the client for application to the clients copy of the simulation. IE projectile "i" has exploded and done x points of damage to target y. I was able to get the steady state pack size down to just 34 bytes, and the worst case was about 250? bytes. the game ran in lock step synchronization, with a proprietary protocol so robust you could disconnect the phone line / cable / etc, plug it back in, and the game would keep right on going.
by contrast, the typical approach is to seed all pseudo-random number generators with the same value, and make sure that each node executes the same flow control code path and therefore the same calls to the random function. as a result, you only need to track and transmit actions (input), not results (dice rolls). also, since future random events on remote nodes can be pre-determined (since the server's dice will return the same result, given the same seed and same number of calls), that leaves only changes in player input (i was going straight, now i suddenly side step left) as possible mis-predictions when lag times get long.
the down side to non-deterministic is that if each node is seeded with the same value each time you play, you get the same exact game each time you play it the same way. to avoid this, have the server generate a "random" seed value based on server launch time, etc, then send that to all clients to seed their random number generators, and then start the game. this way you get different results each play through, even with identical play. after lag, predictability is probably the next worst thing. a random seed shared between nodes can help avoid this - while keeping things deterministic to aid in lag prediction.
