tain.totalcodex.net

I was thinking about this last night and my curiosity is piqued. What gets sent across the wire during a network game to keep everyone playing the same game, in sync? I know there's some randomness in the game, like the exact amount of health each unit has at the start, how much damage a blow strikes (if it lands at all), duds, etc. It just seems crazy that even back in the 28.8 days of TFL, we were able to have realtime gameplay. Maybe it's not a short answer but if someone has a simple way to explain it I'd love to hear!

First I was thinking that the game clients are just sharing enough information for everyone's copy to "play" the game in sync, with any random parts synced at the beginning, like seeds for random numbers, exact unit healths, etc. This seems prone to error, though. I don't quite get it.

Thal

The inputs to the game simulation are, roughly speaking:
1. the game files - all players have this data already
2. the game setup (which map, which game type, list of players, random seed, etc.)
3. the player commands (move, attack, stop, taunt, etc.)

Only 2, 3 need to be sent across the wire. The game setup info is sent once at the start, after that it's just the player commands, which require very little bandwidth. For example a move command is simply a list of numbers to identify the selected units, and a coordinate for the move location.

How does synchronization work? The game simulation is designed to be deterministic, meaning that given the same inputs, the result will be the same every time. As long as all of the players in a game receive the same inputs in the same order, they will always be "in sync" by construction. Since Myth uses the TCP protocol for networking, all the magic to make sure that packets arrive in the right order is handled by the network, not by the game.

While there isn't any data explicitly sent for synchronization purposes (although TCP will do some implicitly), the host will periodically send a copy of its random seed. If it doesn't match what the client has, then they have gone Out Of Sync. Once OOS has been detected, the game has no mechanism for "correcting" or "re-synchronizing".

Cool, thanks for the explanation!

One extra detail that's sort of interesting... because of latency, a client is always slightly "out of sync" on what it sees vs. the host (i.e. the game has progressed some number of milliseconds from what a client sees). Thus it's possible to issue commands that are actually "invalid" by the time they get to the server. Ex. I click to move a unit but that unit has already been killed on the server's frame.

For this reason, there's logic for the host to reject commands from clients that appear to be invalid. More interestingly, clients cannot/do not ever apply even their own actions to their copy of the world state since that action might get rejected by the server which would cause the two to go out of sync. Instead, client commands *only* get sent to the host, which decides what to do with them. The clients are effectively watching a film/replay streamed from the host in terms of what they are actually seeing on-screen.

In high latency situations it's possible to see some of this "in action". These days latencies and reliability of packets are good enough that it's mostly not an issue, but I just find it interesting in general as well