[glob2-devel] "Optimum behaviour for network desyncs"

[Bradley Arsenault]

Heres my give on what should happen upon a desync, its fairly complex,
allot of work, but I'm sure one the developers could bundle up and do
it:

1) A desync occurs.
2) Screen fades out, like when pause is on, message says "Games
desynced". It has a progresss bar underneath, progressing through the
following steps. *important* cancel button.
3) System dumps full game memory
4) System zips the "glob2.world-desynchronization.dump.txt"
5) System sens this zipped file to yog, along with any applicable
system information (like gcc -v on unix)
6) Yog logs this information from all of the users
7) Each player, except the game host (the one who created the game)
contacts the host, and resyncs from them (this could be as simple as
feeding the output of save from the host to the input of load in the
children, provided endian-correctness)
8) The game has been magically resynced, so the game continues
9) If it desyncs 3 times in one game, the game is not allowed to proceed.

Steps 3-6 are the most important, steps 2 and 7-9 are mainly for end
users who probably would be quite angry/confused at the window
dissapearing for no apparent reason, and if they are as techie enough
to have run it on the console, the might be further concerned with the
words "Dump full game memory" and "World desynchronisation".

This system has the added advantage that every desync gets recorded
and can be examined, and that the dumps from every player in the game
are garunteed to be accurrate. Several of us often forget to save our
desync dumps after a crash, most notably appleboy, who just loads up
the save game and we all restart.

Steps 3-6 are most important for now, and they are easiest. Steps 2 &
7-9 are more difficult, but are going to become increasingly important
as we approach a 1.0 release.