3 ms·

They missed one key bit on CS's network model(which is what made it so great) is that they would actually re-wind the gamestate to do hitchecks so you could hav

They missed one key bit on CS's network model(which is what made it so great) is that they would actually re-wind the gamestate to do hitchecks so you could have a latency of 200ms+ and have a reasonable experience. Also the common term for resolving these types of things on the client is called "dead-reckoning". You've always got a diverging states from latency so you're continuously trying to reconcile this on the client. Simple Newtonian physics based games(Subspace, etc) are famous for being latency tolerant since the simulation is incredibly deterministic and are based on the players extrapolating where things will be in X time rather than twitch responses(which is also why fighting games are so hard without using a solution like Counter-Strike). You could play SubSpace on a 500ms dial-up connection and still be competitive without needing to lead for lag.

Jare 11y ago
A quick note, I think dead reckoning is not about correcting for latency. It is a conscious decision on the server to send less precise (cheaper), incremental data to the client most of the time. The client extrapolates from this imprecise data to still provide a fluid and continuous motion. The server performs the same extrapolation, and precisely tracks the error accumulated by the client to decide when to send a more expensive and precise packet that corrects the divergence.
- vvanders 11y ago
  That's the traditional term, but it has specific meaning in game network programming. For instance we never send back the "error accumulated" to the server. Instead the server usually sends a PVS(potentially visible set) that the client handles displaying in a meaningful way(and reconciling and discrepancies). This PVS set is usually absolute values but at a discrete snapshot in time(of which the client can never be certain due to latency and there not being a single global clock). The client is basically guessing where the simulation is going and then smoothly handling(normally interpolation over your usual time-slice) differences from the server snapshot. That PVS is why you'll see map hacks where people can see through walls and whatnot. The server is doing less expensive checks(not doing a ray cast per-client to client which is n^2) and the cheat takes advantage of that data in memory.
zubspace 11y ago
There's something I always wondered about the gamestate rewind thing: Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bullet)? What about slow moving projectiles or physically accurate bullets? Can the server spawn the projectile 200ms in the past at the time you pressed the button? But then other clients would receive the information about 400ms later after the initial keypress, which does not seem right...
- vvanders 11y ago
  The projectile issue actually is much better. Since as a player you're trying to shoot the projectile to "predict" where it will intersect you're actually playing to the strength of latency and dead reckoning(that's the SubSpace case above). You want to segregate your action into twitch(reactionary: hitscan, parry, etc) and predictive(slow projectile, > 250ms ttl, etc) and only rewind/replay for the twitch case. There's also the case that when you rewind and do confirm a gamestate change you need to gracefully handle resolving it on all clients. That's why you'd see people warp back around corners when shot in Counter-Strike. Their player movement speed slowed after being hit and the server reconciles it and then the clients interpolate the result.
- clevernickname 11y ago
  In Source Engine games, there is no lag compensation for projectiles. The lower your ping, the faster the projectile is spawned on the server. You can see this very clearly when playing on high ping: you click mouse1, you hear the rocket fire, but the rocket doesn't appear for a good fraction of a second. Since TF2 is very heavily based around projectiles (Soldier's rockets, Demo's pills and stickies, etc) many competitive players play with their cl_interp (determines how many ticks worth of game state are delayed before being displayed, interpolated, to the player) set lower than default (which is 2 ticks at 66 ticks per second by default). This results in jerky movement if packets are lost, but it ensures that they see threats as soon as possible so that they can fire their projectiles with minimal (real time) delay. I think it might also have some effect on client side input buffering; not sure, but that would be an even bigger reason for projectile users to want low interp.
nhaehnle 11y ago
The article does mention it, though without going into detail - it's called lag compensation.

Jare 11y ago

A quick note, I think dead reckoning is not about correcting for latency. It is a conscious decision on the server to send less precise (cheaper), incremental data to the client most of the time. The client extrapolates from this imprecise data to still provide a fluid and continuous motion. The server performs the same extrapolation, and precisely tracks the error accumulated by the client to decide when to send a more expensive and precise packet that corrects the divergence.

vvanders 11y ago
That's the traditional term, but it has specific meaning in game network programming. For instance we never send back the "error accumulated" to the server. Instead the server usually sends a PVS(potentially visible set) that the client handles displaying in a meaningful way(and reconciling and discrepancies). This PVS set is usually absolute values but at a discrete snapshot in time(of which the client can never be certain due to latency and there not being a single global clock). The client is basically guessing where the simulation is going and then smoothly handling(normally interpolation over your usual time-slice) differences from the server snapshot. That PVS is why you'll see map hacks where people can see through walls and whatnot. The server is doing less expensive checks(not doing a ray cast per-client to client which is n^2) and the cheat takes advantage of that data in memory.

zubspace 11y ago

There's something I always wondered about the gamestate rewind thing: Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bullet)? What about slow moving projectiles or physically accurate bullets? Can the server spawn the projectile 200ms in the past at the time you pressed the button? But then other clients would receive the information about 400ms later after the initial keypress, which does not seem right...

vvanders 11y ago
The projectile issue actually is much better. Since as a player you're trying to shoot the projectile to "predict" where it will intersect you're actually playing to the strength of latency and dead reckoning(that's the SubSpace case above). You want to segregate your action into twitch(reactionary: hitscan, parry, etc) and predictive(slow projectile, > 250ms ttl, etc) and only rewind/replay for the twitch case. There's also the case that when you rewind and do confirm a gamestate change you need to gracefully handle resolving it on all clients. That's why you'd see people warp back around corners when shot in Counter-Strike. Their player movement speed slowed after being hit and the server reconciles it and then the clients interpolate the result.
clevernickname 11y ago
In Source Engine games, there is no lag compensation for projectiles. The lower your ping, the faster the projectile is spawned on the server. You can see this very clearly when playing on high ping: you click mouse1, you hear the rocket fire, but the rocket doesn't appear for a good fraction of a second. Since TF2 is very heavily based around projectiles (Soldier's rockets, Demo's pills and stickies, etc) many competitive players play with their cl_interp (determines how many ticks worth of game state are delayed before being displayed, interpolated, to the player) set lower than default (which is 2 ticks at 66 ticks per second by default). This results in jerky movement if packets are lost, but it ensures that they see threats as soon as possible so that they can fire their projectiles with minimal (real time) delay. I think it might also have some effect on client side input buffering; not sure, but that would be an even bigger reason for projectile users to want low interp.

nhaehnle 11y ago

The article does mention it, though without going into detail - it's called lag compensation.