How can I keep two racing players synchronised?

Question

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.

Answer 1

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.

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?

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.

Answer 2

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.

Answer 3

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.