Re: networked games

[Stan Shebs <shebs at shebs dot cnchost dot com>]

Jim Kingdon wrote:
> 
> OK, Derek and I tried to play a network game tonight and this is what
> we found:
> 
> * Without the sequential play option, having the two xconq's get out
>   of sync was swift (turn 5 or so I think).
> 
> * With sequential play, we would last maybe 20 or 40 turns.  Then they
>   would get out of sync.  I believe this happened at the end of a turn
>   both times.

Well, at least it hasn't regressed. :-)

The chief suspect is plan execution.  I don't know if you're running
the all-out-save-after-every-run_game, but if you do, and diff the
results, the usual first sign of trouble is that in one game, the
unit is ready to move, and in the other it is in reserve or something,
as if one program got to do a tiny bit more work than the other.

> * In either case, we couldn't see any way to recover (and we've tried
>   a few things.  Even something basic like restoring a saved game
>   seems broken for networked play, unless I'm missing something).

I haven't spent much time on this, so not too surprising.  It would
be the simplest way to recover though.

> The quickest and dirtiest way to get networked games playable would
> seem to be something like:
> 
> (1) if the games get out of sync, then have the master download the
>     entire state to the out of sync xconq(s).

This would work, but would be very slow.

> (2) Derek had in mind something in which the xconq's somehow have a
>     way of knowing which commands they missed, and recovering.  I sort
>     of wonder whether this is making assumptions about why the games
>     got out of sync (do you need to undo partially done commands for
>     example?).  But since he is more likely than I to get around to
>     implementing one of these....

Very hard.  The whole reason for running kernels in sync is that
there are so many random bits of data running around.  It would
be easier if some of the junk was stripped out of the kernel. :-)

As I think about it, you could have different sort of checksums,
perhaps detect bogosity in a single unit's state, and re-download
that only.  I think that's how the action games' "dead reckoning"
works - games will compute their own rocket trajectories, but server
updates with accurate positions can override.  It's a different
viewpoint, basically assuming that games are always a little out of
sync, and using the server to clean up the worst discrepancies.

> (3) even fixing restoring from a saved game would help, because then
>     you wouldn't have to start over at the very beginning.

Yep.  This is probably pretty close to working, just need to reconstruct
the connections using saved player data.  A little messy, because you
have to decide whether to use the data in the saved game, or allow the
players to use different hosts.

Stan