Game Development Reference
In-Depth Information
To reduce the lag that gamers can feel, we design the client-server communication
to be asynchronous because waiting for the new game state from the server can take
a long time due to network latency. Since we try to keep running the game locally
while we wait for the server, we need to adjust the client when we do finally get
an authoritative update from the server. Adjusting the client can be tricky, though.
First of all, by the time we get a response from the server, the state it sends us will
be in the past. To deal with this, we'll need to keep track of all player input since the
last time we got an official server update, rewind the game to the newly received
authoritative game state, and then replay any more recent input on top of that. The
result will be our latest guess of what the server thinks the game state should be at
the current time, which will likely be slightly different than what we've actually been
showing the player. We could just snap the current game state to our ideal game
state, but that would make the game seem jittery since things might spontaneously
teleport. Instead, if the differences between states are small enough, clients should
interpolate between their current state and their projected ideal state. If we drift too
far away, we can snap back to the server state, but otherwise we'll lag a few frames
in order to ensure smoothness. Snapping happens most often with complex physics
interactions or when players collide.
Ideally, we'd like to just send players' inputs to the clients because they're smaller
than the full game state (so they take up fewer network packets). This might be
the only sane way to handle MMO games with potentially thousands of players.
However, this can cause drifting over time due to floating point rounding error, so
it may not be accurate enough to be the only solution for intense action games like
first-person shooters. As a compromise, inputs can be sent frequently and the full
game state sent only periodically; then clients can use the inputs to predict how the
game should progress.
Of course, not all physics is driven by user input. If your game has gameplay-
affecting nature-driven physics such as wind or avalanches, you may need to have
the server simulate the physics without client prediction, and clients will just have to
deal with some latency. On the other hand, you can simulate some physics entirely
on the client. For example, it doesn't really matter if the clouds in the sky are in
exactly the same position on each client since they're typically just decorative.
The game state tracked by the server usually includes, at a minimum, the position
and velocity of all movable actors, a unique identifier for the version of the state,
and a timestamp. The server does not need to send a full scene export to every client
since that would be too expensive. However, the server does need to simulate the
full scene in order to accurately update the game state.
