How can I synchronize state in my Asteroids game with many networked players?

Question

Wondering how state synchronization works in games with lots of players like MMOs. It seems like a hard problem to solve and I am not aware if there are standard solutions. Specifically, synchronizing game clients (users playing game) with an array of centralized servers, and then broadcasting and merging the state with all the same connected clients. How it is done (and how efficiencies are implemented) typically, and what the structure of the game state is like.

To simplify this question, I am thinking in terms of a simple asteroids game:

You have n number of players, and the asteroids, players, and bullets are synchronized across clients. I am not familiar with how the game state should be modeled (if it's some quadtree thing you are sending around, or just a vector of patch/updates, etc.). There could be players all over the world, so latency is a factor.

Answer 1

Is it possible to save the game's current state to disk?

If yes (hint, the answer is always yes) then you have a means by which you can synchronize players. Even if it is horribly inefficient. But optimization is just a matter of working out which bits and bytes any given player doesn't need, either because:

• they already know (eg, what level is being played and it hasn't changed)
• they are the data source (eg a player doesn't need their own user name)
• they can't know (eg stealthed players in WoW are not sent to other players until detected otherwise someone could write an external program that could detect and display that information, bypassing the mechanic¹ )
• they don't need to know (eg. That other player on another level is irrelevant)

If no, you need to refactor.

1 _{The "stealth broken" / "hidden player detected" sound effect was actually an accident of this. When the client got told about the stealthed player, it spawned them an immediately applied all of their buffs, playing the associated sound effect for each one. This was fixed during development to only play the "entering stealth" sound to avoid eat-bleed, but the audible clue hasn't been planned and ended up being an elegant solution to an unknown problem.}