4
\$\begingroup\$

In watching the GDC talk about Overwatch netcode, it mentions that the client is always ahead of the server, that the "current tick" on the server is behind that of the client.

From their explanation this makes sense. If the client is ahead of the server, then by the time the client messages arrive at the server, the server will have caught up and can handle them when it wants them.

But how does this get setup to begin with? The client connects to the server, the server starts a game... does the client jump ahead of it's own accord? (Server says "game is starting, I'm at tick 0", and the client is like "okay, well, based on my ping I'm going to be tick 20 then")

  • If the server is in charge of what's going on in the game, how does the client even know what's going on in that future tick? I would assume constant extrapolation of game events from the last server update would be bad. Having the client in the past to allow it to interpolate between server updates would make a lot more sense to me.

  • Or am I wrong in assuming that client and server tick times need to remain in sync, and it is instead more loosely based on server updates and the number of client events that happened since that update was received, rather than the client actually caring about what tick they're on compared to the server?

It's the time/tick synchronization, despite one or the other having to be in the past, that I can't wrap my head around...

\$\endgroup\$
1
  • \$\begingroup\$ Haven’t watched this talk, but it sounds like some form of rollback netcode. My understanding of rollback is that the game actually does extrapolate events based on the last server update. If you have a ping of a few tens of milliseconds, the difference between the client’s “guess” as to what will happen and what actually does happen will rarely differ enough to disrupt gameplay or be visually jarring. \$\endgroup\$ – Fluffy the Togekiss Nov 6 '20 at 6:26
3
+200
\$\begingroup\$

But how does this get setup to begin with? The client connects to the server, the server starts a game... does the client jump ahead of it's own accord? (Server says "game is starting, I'm at tick 0", and the client is like "okay, well, based on my ping I'm going to be tick 20 then")

No. Once the connection is established, the client just starts running, and starts sending messages (input) to the server immediately. But the messages take time to reach the server (network latency). And by the time the first message arrives at the server, the client is already 10 ticks ahead (let's say), "predicting" what's happening based on its own state of the game world. The client is not in the future, the client just runs its own simulation in real time; it's the server that's always late (because of the time it takes for them to exchange messages).

If the server is in charge of what's going on in the game, how does the client even know what's going on in that future tick?

It doesn't. It maintains its own state of the game world, and it tries to predict what is going on based on that. Here "predict" just means "run the game based on my own state and hope that the server will eventually come up with the same answers." For this to work the behavior of the game needs to be made as deterministic as possible (see the talk for details). Again, for the client, this is not a future tick, it's the current tick; the client just doesn't have the most up-to-date state of the world. E.g. it may not know yet that someone fired a gun at you a couple of milliseconds ago.

The server computes the same kinds of updates as the input arrives, and then sends the results back. That takes time to arrive as well. To the client, that's now some 20+ ticks ago (roundtrip time). The client maintains the past state (and past inputs), and if the state obtained from the server is different, it will throw away everything after it, and re-predict from that point on, all the way up to the current frame.

At least, that's a general/conceptual overview; in the talk you'll see that in practice there are some subtleties that need to be taken into account.

Having the client in the past to allow it to interpolate between server updates would make a lot more sense to me.

Well, the problem is that the game needs to feel responsive. In this type of game, when a player clicks a button to shoot, or whatever, you can't wait for the input to get to the server, be processed, and then to come back. So it's a compromise - the input feels very responsive, but when an occasional misprediction happens, the client does extrapolate from a past state, and just replaces whatever was on the screen with the new thing. Luckily, this usually isn't very noticeable.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ +1 As an example, I have worked on an Android app which behaves as described. The device (because it's a battery-limited handheld) performs some rough rendering so that the user is happy while waiting 10+ seconds for the (high-quality) server rendering to download. 15 year old very profitable app. \$\endgroup\$ – Vorac Nov 10 '20 at 3:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.