3 ms·
The joy of writing and designing multiplayer games is the constant tension between cleverly hiding latency and trying to keep the view of the game somewhat cohe
by meheleventyone 6y ago
The joy of writing and designing multiplayer games is the constant tension between cleverly hiding latency and trying to keep the view of the game somewhat coherent between players.
Probably the most relatable example is “peekers advantage”. A static player looking at a corner will always be at a disadvantage to someone coming round it if there is client side simulation of the local player. This is caused by the moving player getting round the corner and seeing the static player before the server is even aware of it (as they are locally ‘ahead’), the static player won’t see them until the movement makes it through the server to them. As such the advantage gets bigger as the round trip time between the players increases.
For the static player this manifests as seeing someone coming round the corner and having them dead to rights. Clicking the fire button, seeing the shot hit (in their local ‘ahead’ view) and then getting shot and killed by the moving player. Fast FPS games with short time-to-kill weapons are particularly affected by this which is why competitive games try to reduce the time the server spends sitting on updates by running at high tick rates.
If both players have a fast connection to the server (20-40ms) and the server is running at 60Hz (~16ms tick) peekers advantage still exists but is much less exploitable (~56ms best case). Versus the bad case where both players have a slow connection to the server (100-150ms) and the server is running at 10Hz (100ms tick) so best case becomes 300ms and the moving player enjoys an enormous advantage.
- Kuinox 6y ago56ms is huge in a competitive game, reaction time are around 200ms.
- meheleventyone 6y agoYup which is one of the reasons competitive games host physical events and companies like Network Next exist to try to improve the packet routing situation. But at some point you can't beat the physics involved.
- Kuinox 6y agoDo you known if 10ms change a lot comparing to 0ms aka LAN ?
- meheleventyone 6y agoI haven't done any experiments but at those low figures it's likely imperceptible to people but I think it's important from a perception of fairness to have each participant with the same low latency. Like if one team averaged 10ms and another averaged 20ms that might not be a compelling competitive difference but just from a perception of fairness not having it is important.
- totetsu 6y agoJust make the corners see through.
- meheleventyone 6y agoAll walls are now tagged WONT.
- kd5bjo 6y ago> A static player looking at a corner will always be at a disadvantage to [a moving one]. ... The static player won’t see them until the movement makes it through the server to them. Do you mean that an accelerating player has an advantage? If all the remote players are being simulated locally, I’d expect that to be just as good at predicting straight-line motion as for stationary players— The hard part is predicting player input, not kinematics.
- meheleventyone 6y agoI'm skipping out local simulation of remote players as a potential mitigation strategy to illustrate the core concept which is caused purely by latency and local client simulation of the controlled player. Naive extrapolation can cause issues, for example players appearing briefly from behind corners on other peoples machines that they actually stopped behind. How you might locally simulate depends a lot on the game simulation. Is it deterministic or not? Are more complex things happening like rigidbodies being simulated in a distributed manner that still need to collide reasonably and so on.