0
\$\begingroup\$

Please note: Although this question involves a link to the Source Engine, its really a generic question about client-server interactions in multi-player games, and I think can be answered by anyone with such experience.

So I just started reading this article on multiplayer networking and only got through the first paragraph before I already had a slew of questions. Most of these questions can all be addressed if I simply could get help understanding the diagram at the top of the page:

enter image description here

Here is my understanding of the first paragraph, regarding snapshots:

A snapshot is something sampled on the server and broadcasted out to all connected clients. Ideally, in a perfect world with zero latency, clients could send updates to the server, and the server could broadcast each and every update back out to all the other clients. However this is not a perfect world, latency does exist and is both chaotic and unpredictable; and so by servers sending these snapshot "heartbeats" out at regular frequencies, all clients can receive updates at the same rate, consistently. Yes? No? Kinda/sorta?

Assuming I'm more or less correct about the underlying purpose of snapshots, then I'm trying to understand what is happening in that diagram above:

  • The client is currently at Tick=115, but the server is at Tick=130, but why?! Why is the client behind?
  • Why does the client "buffer snapshots for 100ms"? What's going on there? Is that just the time it takes (roughly) to process a snapshot from the server?
  • Why is the server simulating the world (and what does that even mean?!) at 33Hz but only sending out snapshots at 20 Hz?

I know these are a lot of tiny/small questions but think they can be addressed with a single answer explaining what is happening in the diagram. Thanks in advance!

\$\endgroup\$
4
  • 1
    \$\begingroup\$ The rate at which the simulation occurs is fixed. The packet rate varies per client (see cl_updaterate below) and adjusts depending on network conditions. The client tick is behind the server tick because the server state is authoritative: the client can project world state beyond the last received tick, but client tick 115 occurs when the client receives and processes the packet containing server tick 115 (unless it has already received a later packet, since this is UDP). \$\endgroup\$
    – Justin
    Commented Mar 1, 2017 at 18:58
  • \$\begingroup\$ Ahhh thanks @Justin (+1), so in the diagram above, the client is currently processing Snapshot @ Tick = 115 (sent by the server), right? \$\endgroup\$
    – smeeb
    Commented Mar 1, 2017 at 19:04
  • \$\begingroup\$ Correct; 120 and 125 are in flight. The client input is buffered to smooth out data rates and because the server can basically apply the command as though it was received instantly (tick history or back-projection). \$\endgroup\$
    – Justin
    Commented Mar 1, 2017 at 19:08
  • \$\begingroup\$ Disclaimer: I haven't worked with Source engine; this is just my interpretation of this page combined with Gaffer on Games stuff. \$\endgroup\$
    – Justin
    Commented Mar 1, 2017 at 19:11

1 Answer 1

Reset to default
1
\$\begingroup\$

The client is currently at Tick=115, but the server is at Tick=130, but why?! Why is the client behind?

Because the client has to wait until it has information from the server in order to process it. So in this case you can assume that the client has a ping of 15ms because that is the difference between the two. The client can't process past tick 115 because that's the last snapshot it got from the server.

IE: the client will always be behind the server according to the amount of latency.


Why does the client "buffer snapshots for 100ms"? What's going on there? Is that just the time it takes (roughly) to process a snapshot from the server?

It's not necessarily the time it takes to process a snapshot, it's more like how an audio streaming service like Pandora works. What would happen if your computer could only play audio as it received it and didn't buffer? The moment your connection had any kind of lag the music would cut out. What do you think happens to an online game if you don't buffer? The same thing.

It's to make sure you have a smooth and responsive gameplay experience and it's invisible to the user because EVERYONE has it and it's planned for. The reason network latency (ping) is bad is because not everyone has it and you can't completely account for it due to how much it varies.


Why is the server simulating the world (and what does that even mean?!) at 33Hz but only sending out snapshots at 20 Hz?

The server is simulating the world because all "decision-making" has to happen server side for integrity reasons. If you let the client have any influence on the outcome of events then it makes it trivial for players to cheat.

It's sending them out at a lower rate because sending every single "tick" is both too much data and would result in the same problem as with no buffer. The client doesn't need 33hz, it processes at that rate because it wants to process them as fast as the server generates them.

Think of it like the refresh rate of a monitor, you have a 144hz monitor but your game is only running at 90fps. Your GPU is sending less but your monitor is still refreshing 144 times per second, because you want each frame to display as quickly as possible. You don't need 144 frames to be smooth, same idea.

\$\endgroup\$

You must log in to answer this question.

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