I'm not sure if "game state" is the correct term, as my searching shows me a lot of results that are not relevant to my question. When I say "game state", I'm talking about the internal state of the game being played: what units are spawned, where they are located and headed, what players are playing, what their current scores are, etc. Everything that would get wiped out if you were to start a "new game".
I'm curious how other people or other games handle the issues of client and servers appearing to need access to more than one copy of the game state.
For example, the client's job is to accept game state updates from the server, and render them. However, the server updates are usually much slower than the client render speed, so the client needs two copies of the state information in order to interpolate between the two and make everything appear to be moving smoothly. I'm not sure how you would accomplish this without having the client hold two copies of the game state, copying the current to the previous whenever the server sends an update.
Likewise, the server needs to make decisions on the current game state, and apply changes. However, if it only has one copy of the game state, then any changes it has already made will influence future decisions. If two players shoot at each other at the same time, and the server processes one shot before the other and writes the result to the same game state, it'll see the second player as now being dead and unable to shoot. If it had two different game states, "current" and "next", any new changes (such as player death) would be written to the "next" state, and since they are both still alive in the "current" state, each shot would get processed and both players would end up dead, as expected.
However, having multiple game states creates a lot of other problems:
- Each copy of the game state could be very large, with many players playing, and hundreds or thousands of units moving around the game world. This would be a lot of data to be copying around just to keep multiple game states synchronized.
- While having two separate game states fixes the server problem of two entities killing each other at the same time, it presents new problems when an entity is newly-spawned. You might spawn an object into the world, and then want to immediately have it perform an action, or have other entities start to interact with it. Problem is, that new entity doesn't exist in the "current" game state, it only exists in the "next" game state. The server would have to wait until the next cycle, when the "next" state became the new "current" state, before the new entity was available for interaction.
I'm leaning towards just having a single state for the server, just for simplicity, but I don't see how to avoid keeping two copies for the client. How do other games handle this?