Getting a Smooth Multiplayer Gameplay

As we wrote in our latest  entries our main goal is to get a smooth multiplayer gameplay. This means that we have to guarantee the perfect sync between server and remote players. In an ideal world, we would have to implement the following algorithm:

1.      The server  calculates the maximum client latency and send it back to the client.

2.      Once received the Go command from the server, the client  will wait for the maximum latency minus his own latency (plus a fixed security buffer).

3.      Every client will keep this gap  for the rest of the game by mantaining, clients and server,  the same tick duration.

So, let’s end this post… everything is OK ;-)

…but latency is variable and changes every time for uncontrollable reasons (network congestion, router processor time, etc…). So, if we can’t control something, don’t waste time about it, just try to deal with this.  We know that some movements are going to arrive late at some rate, that’s for sure. We have previously  explained (lasts posts) how we made an algorithm to get back movements and replay real movements sent by the server. This is our seatbelt and it always be there because, above all,  we want to have an stable game. Anyway, we can’t control the changing latency but we can try to mitigate his variation:

 Take for example a distant race… If the leader accelerates, the persecutors tend to do the same whereas if he slows down  the followers tend to also slow down. They tend  to maintain the  distance. At the end, they are keeping the same distance by adding or removing some distance.

If we think in terms of our game there are some parallelisms. The gap  between the end of the client tick and the server tick should keep stable and close to the maximum latency out the remote players (plus an additional buffer).

How to do this? Consider the following guidelines:

1. The server should inform every client about the  advance time that his movements have arrived related the end server tick. That’s an absolute measurement than shows us if we are in danger of arriving late or too soon. For every client, we will write down if the distance has increased or decreased related to the last tick. Send back to the client the info about their relative increase/decrease related to last tick. Once the client has this info, he has to compensate the variation by adding or reducing milliseconds to the server tick, in order to maintain always the same gap.

2. We can use some tricks for reduce the variability of the client tick game. A good practice is to  adjust  this delay by multiplying by a constant (between 0 and 1) because latency variability may compensate by himself. There are no mandatory strategies to handle this. Just try yourself what adjusts better to your scenario.

As a result of this combined approach, we finally got a smooth and interactive gameplay!