Counter-Strike: Global Offensive - Page 609

Re: the whole interpolation, server tick rate and how good everything 'feels' debate:

I study CS and am working on multiplayer games myself so I kinda can't tell anymore what's common knowledge for people and what isn't. If what I say here is something everybody knows already then please excuse me for the repetition, I don't want to come across as a smartass. :p

So getting a fast action-based multiplayer game to work across the internet is always super mega tricky for the simple fact that the internet is, in reality, too slow for what human reflexes can do. Say you have a ping of 70 (which is a good average, I personally have a good connection here in Germany which means I generally get ~20 ping but there's also people from other countries further away from the Valve servers with much higher ping). That means it takes data 70ms to travel from your game (client) to the server. If you see someone else on your screen, let's assume they also have a 70 ping, it takes 70ms for their input to reach the server and then the server forwards their movement and actions to you which is another 70ms. That's 140ms. Of course, all clients (you and your opponent) as well as the server, are just computers and they aren't infinitely fast either. A server running at 64 tick 'updates' the game 64 times a second. This creates a 'window', jitter in other words. Say you hit the fire button to shoot at someone, your PC probably doesn't take very long to send out that info to the server, so let's ignore possible lag there, but it will take 70ms to reach the server. But it will only affect the state of the game whenever that server reaches its nearest tick. It's (pseudo-)random. Sometimes your info will hit right before the server 'ticks' and it'll be great, sometimes it's the worst case where your data hits the server just as it updated and now it's in a queue waiting to be applied to the actual game. For a 64 tick server, the worst case is another ~16ms if you're unlucky. If we switch perspective to the opponent that you were shooting at, he can only see the shot when the data arrives at his computer. So that's the total of 86 plus the 70 ping of the opponent, since it still takes a bit of time for your PC to handle the new data and render a new frame to the screen we can safely assume 160ms of delay there.

160ms is not responsive whatsoever in a game that's as fast as CSGO. As you can probably assume, 120 ticks doesn't change the situation that much for people with average-bad ping. The better the ping, the more higher server tick rate helps. But the point is, raw data transfer over the internet like that is just way slow and not suitable for fast gameplay. So 90% of the work that the programmers for these games do in the multiplayer department is to implement hacks that make the game feel better than what it really is, this is where client-side interpolation and prediction comes in, which are more complicated ways of faking less latency than there really is. So with interp, if you want to move forward by hitting W it's unacceptable to have there always be a delay of up to one tenth of a second or more before your player actually starts moving, that feels absolutely horrible, so the client will just move itself directly rightaway. If the server then later says that you couldn't have gone there because something else happened that you as a client didn't know about at the time (or because you're hacking lol), then it'll overwrite the local client position with whatever the server sent you (in fact it will blend over from your current position into the actual one). This is what creates rubber-banding and warping when there are connection problems.

Aaaanyways, not quite sure why I decided to write that up, and again I hope that I didn't make myself look stupid because it's the most obvious thing ever. If so, please ignore. Maybe there are people out there, however, who don't know what ping is or how a client-server game roughly works. Also note that there's no way to confirm the specifics of how it all actually works, this is mostly my general knowledge of netcoding in combination with what I can safely assume to be the case with CSGO.

But latency isn't the only issue with CSGO's gunplay. It's a complicated topic with a lot of contributing areas where there could be improvements. That was just the basics of latency under the assumption that everything else works. But servers can hiccup (even 128 tick) and there's more issues, such as paket loss. Or take hitboxes for example. They are obviously misplaced in certain animation clips, everybody knows/sees it when Ts plant the bomb/CTs defuse. The visual model does not line up with the actual hitbox so hitting these semi-crouching players can be tricky. Jumping hitboxes also seem glitchy. Since I practice and warm-up against knive-only bots that rush you on aim_map, I even noticed a big hitbox issue when I look down on them from one of the balconies (and they are rushing up at me on the ramp). I will miss hits that are on their visual model heads and then get headshots that are completely offset. Maybe I should capture these on video because, contrary to the latency issues which are simply a limitation of technology, these hitbox misalignments are not. This is on a local vs bots 128 tick game with 300-400 fps and <0.6ms var so there shouldn't be any instability from lag. They're just lazy and badly tested as far as I can tell and, in extreme cases, gamebreaking.