8
\$\begingroup\$

I'm trying to wrap my brain around the concept of creating a server/client multiplayer experience.

My problem is mainly related to timestep. Consider the following scenario:

A client connects to a server. The client sends his inputs to the server to indicate he wants to move. Server simulates the input and determines the position of that client in the game world.

Since the client and the server are both running on different timesteps, how do you accurately simulate so that all clients are in sync with the server? My server is currently set at at 30ms timestep. When I process client movements, there are potentially hundreds of requests waiting to be processed, yet no way to indicate how long it took between each one of the requests.

I'm really not grasping how to properly simulate on the server based on time, in order to have everything sync up.

Improve this question
\$\endgroup\$
2

1 Answer 1

Reset to default
3
\$\begingroup\$

Simply put, you need to send a time-stamp with each snapshot from the server, and with each input from the client.

On both ends you need a process to "fill in" any frames where packets are not received.

In my game (a fast-paced action game - yours may be different), on the server, I discard any "older" (out-of-order) input, and simply guess that if no new input packets arrive, the same buttons just keep being held down (there's a bit more stuff for making sure short button presses/releases are handled, but that's the basic premise).

On the client I keep a "lag buffer" (described in this article that Tetrad linked). I use a rolling average of arrival times to ensure that the lag buffer stays the right length - making the client game run a bit slower or faster to catch up. If snapshots don't arrive in time then I do extrapolation on the client. Otherwise I interpolate between snapshots in the buffer.

The client is also responsible for tracking the round-trip-time for inputs and using that for prediction (the server sends back the timestamp of the input that it used when calculating a given frame). It buffers inputs for that length of time, replaying them to take the player's position from the "old" position (in the snapshot from the server) to the predicted "present" position.

Basically the server just keeps running at a fixed frame rate. It is up to the clients stay synchronised with the server.

Of course, this is just a high-level overview. There's a lot of nitty-gritty details that you have to figure out when you implement it.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ If server receives 10 input commands from a client between one server time step. Server executes the 10 input commands. How do we know how long to simulate each input command? What if you only receive one input command, do you simulate the command over the entire timespan of the time step? \$\endgroup\$
    – jgallant
    Jan 13, 2013 at 1:33
  • 1
    \$\begingroup\$ @Jon Most "action" games send input as button up/down state each frame. The server then just uses the latest received state as the state for that update tick. Dropped, late and out-of-order packets are ignored. (At least at the basic level - you could, for example, add additional sequencing information so that a very brief up or down state is not ignored, even if dropped.) This is probably what you should do for all inputs that have associated timing. Command based actions (eg: "move here" in an RTS) don't generally have an associated duration - so you'd simply execute them in-order. \$\endgroup\$
    – Andrew Russell
    Jan 13, 2013 at 5:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .