3
\$\begingroup\$

Say there are two clients connected to an authoritative game server, using input + state synchronization strategy. Client 1’s has a round-trip latency of 100ms and client 2 with 400ms latency. For now just imagine each player controls a ball that can collide and bounch off each other.

  1. Client 1 executes command at t = 100 ms, proceeds with prediction for next 100ms (however many steps depending on timestep and framerate)
  2. Client 2 also executes command at t = 100ms, proceeds with prediction for the next 400ms (or capped at some max prediction timestep)
  3. Server receives client 1’s commands for the next t = 100ms + dt, simulates up to t = 100ms + dt
  4. Say server’s simulation is now at t = 500ms, and client 2’s command for t = 100ms just arrived. In this case I can think of two things to do:

    a. Rewind simulation back t = 100ms and re-simulate back to t = 500ms, if client 1 was affected by client 2’s command (such as collision) send correction to client 1. The results are that:

    • To client 2, everything looks fine

    • To client 1, his movement constantly rewinds bottlenecked by client 2 as long as client 2 is affecting client 1

    b. Simulate client 2’s command as if it was executed at t = 500

    • To client 1, everything looks fine
    • To client 2, his motion is constantly corrected (either jerky or the interpolation creates strange movements)

With this method you can really only have smooth gameplay for one person. Are there better methods for smoothing out the gameplay for all players? I understand that for FPS you can easily compensate for the the bullet latency because you don't actually see the bullet. But in the case where physics collision can occur between players this becomes troublesome.

Another idea that I have is spawning of a lava pit that is instant death for players. Lava pit spawning done using client side predication can instant kill the player and sync the state later, resulting in smooth gameplay for the client. But if the other player is lagging it will appear as if he is still standing in the pit (or with full prediction will kill him but he’s not actually dead). How do games handle cases like this?

\$\endgroup\$

2 Answers 2

2
\$\begingroup\$

After much research and readings I think I can answer my own question.

This is not really a solvable problem. All clients are seeing other client’s commands x time from the past, and there are no solutions to synchronize real time behavior if one client intends to directly affect another player without corrections. The best thing you can do is do your best to apply corrections as smoothly as possible so the gameplay still feels responsive. In addition do your best to mitigate the network latency through proper matchmaking and latency/network congestion optimizations.

If you require your simulation to be consistent across all clients, then clients cannot execute a command until server has authorized the command. This means that server has to receive commands from all clients for a certain time/tick before the simulation can proceed. This ensures correct and smooth simulation for all clients but bottlenecked by the slowest client. In RTS games like Starcraft all commands have input latency of about 200ms, so if the network latency is less than that you can effectively hide network latency and produce more or less accurate simulation for all players.

200ms lag in RTS games seems to be acceptable by players but not for FPS games which inputs needs instantaneous responses. And this is done through client side prediction. If player 1 shoots player 2, from player 1’s perspective he is actually aiming at the target sometime from the past. The server rewinds the simulation based on client predictions checks for hits. This kind of lag hiding is acceptable because you don’t actually see the bullet. For weapons where you actually see the ammo, like rockets/grenades/flamethrower they are not lag compensated and require server authorization before they can execute on the client. However the perceived lag affect can often be hidden through animation. For example, client side shows a grenade throw motion when a button is pressed, but grenade actually disappears and reappears when the server responds with grenade’s location. The throwing motion itself is enough to hide the appear/disappear latency.

So in conclusion to address this problem you have to decide what’s more important in your game when compensating for lag: accurate simulation for all clients but induce lag for all clients, or try and hide lag through client side predictions and do your best to hide corrections. If your game requires aggressive physics interaction between players then then this is a really hard problem to try and hide the latency.

If anyone has a better answer or known good models please let me know! Thanks!

\$\endgroup\$
0
\$\begingroup\$

We had the same problem in our game.

Finally we decided we don't use any client side prediction, but we tried to minimize latency as low as possible.

Now if I play on a server on same continent, ping is about 30 ms, then the feeling is responsive enough.

\$\endgroup\$

You must log in to answer this question.

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