I am working on a Unity mobile game, much like a multiplayer version of Temple Run. I'm seeing a fluctuating network latency (generally 200-500ms) because of the mobile platform.

The two player characters are shown as running along the same path and must do simple actions (jump, slide, powerup, etc.) to pass obstacles.

When a message comes late, the game assumes the remote player passed an obstacle. This usually works well, but in case a player is killed by an obstacle, I want the remote player to appear to die on the same obstacle/position as local player. Due to latency, the remote player appears to have crossed the obstacle before the message announcing their death even arrives.

How can I keep the players synchronised?

I tried moving the remote player back to the local players death position immediately as the death message arrives, it looks awkward visually and might raise other syncing issues.


3 Answers 3


Problem analysis

Real-time communication over a high-latency connection is obviously impossible.

You can of course attempt an illusion (as you're doing by making the remote player appear to have passed an obstacle when it's not yet known). When that illusion fails (as yours does when the remote player didn't actually pass the obstacle, but died instead) nothing can be done anymore.

the problem

In a case (such as here) where the illusion's failure looks really bad, it might be easier to accept the facts and just do your best to represent the situation as it actually is.

Potential solution

How about literally slowing down the other player if their decision is taking time to propagate?

a solution

Each player sees an image of the other, but that image slows down when approaching obstacles for which the decision message is still in the air. Only once the message is received do they appear to pass or fail the obstacle. After the obstacle, the image then speeds up again to catch up, slowing down again for the next one, if necessary.

On a low-latency connection, the decision arrives soon and the slowing down and speeding up will be negligible. On a high-latency connection, this will make the other player appear to be lagging behind, but ensures that the more important game state of "who has passed this obstacle" is consistent for both players.

  • \$\begingroup\$ Thanks for your reply. We have already tried the potential solution that you have proposed but did not find it feasible due to following reasons: 1.The first reason is high speed of my game. In order to cover a 200ms window I would have to slow down the remote player to 1/4th speed which causes a very unpleasant and visible visual anomaly specially in the case where the player where running side by side. 2.Since latency is fluctuating, It is really difficult to calculate speed reduction for the remote player which would guarantee that the message will arrive before it crosses the obstacle. \$\endgroup\$ Feb 7, 2014 at 18:00
  • 2
    \$\begingroup\$ @ZahaibJaved Often the only real solution is to hide the latency through animations. Rather than slowing down as they come up to the obstacle, consider stopping completely at the edge and performing a "getting ready to jump" animation that takes a full second to play. Once the "did they make it" packet comes through, perform the actual jump and lerp forwards to their real position. \$\endgroup\$ Feb 7, 2014 at 19:19
  • \$\begingroup\$ Sorry for the delayed reply. So the solution I implemented was in the start cutscene is played where all players can be seen. Local player is always on first position. After cutscene is finished. I just move all the all the remote player behind enough so they can have some time to receive the information that local player was died on specific obstacle or slide or jump correctly on the path. And in the end there is a straight path where I just sync players again. So that result is displayed correctly. \$\endgroup\$ May 23, 2014 at 7:44

To complement Anko's answer, you can change a bit your game design by adding the consequence of the failed obstacle after the failure, for instance, a failed jump results in landing in a puddle of mud which disqualifies the player. This way the other player notices the failure by seeing the other fall in the mud, while the player who fails sees it right away.

Here is a nice blog post about this issue (it's not that recent but it's quite interesting): Darrin West's Time Management and Synchronization.


Is it that important for the local player to know the exact position of the remote player's death? Let's say the remote player couldn't jump over one of your obstacles, and thus died.

The dead player would see their death immediately, and would continue from the location of the accident. Nothing magical here.

The local player (the one still alive and kicking) would see the remote player pass the obstacle successfully. A death notification would come in. The remote player would stumble on their feet, fall, and slowly fade away. The next time you know the remote player's position, the player would fade in to that exact position, running normally again. In such a setup, players would be aware of latency, but latency would be represented as a game element (stumbling down) rather than jerkily appearing and disappearing players.

If speed of the two players is constant, running trajectory is predefined, and the time it takes to recover from a fall is known, you could eliminate the fading/disappearing part completely. Imagine a remote player dying at one of the obstacles. Its local representation is still running when a notification comes in. The player is shown stumbling immediately. It takes time for them to get up and start running again. Actually, it takes as much time as if they were shown dying at the obstacle. Thus, when they are up and running again, both local and remote positions are synchronized.


You must log in to answer this question.

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