I'm currently researching regarding a design for an online (realtime) mobile multiplayer game.

As such, i'm taking into consideration that latencies (lag) is going to be high (perhaps higher than PC/consoles).

I'd like to know if there are ways to overcome this or minimize the issues of high latency?

The model i'll be using is peer-to-peer (using Photon cloud to broadcast messages to all other players).

How do i deal with a scenario where a message about a local object's state at time t will only get to other players at *t + HUGE_LAG* ?

  • \$\begingroup\$ Good question, I'm also interested in this one. Though, I think that the high latencies only apply to mobile networks, as in, a phone capable of and connected to WiFi will have it's latencies greatly reduced. \$\endgroup\$ Commented Jul 2, 2013 at 7:35
  • 1
    \$\begingroup\$ Quick tip here: With TCP, you're going to see stutters on 3G/Wifi both, because TCP interprets packet loss as "I'm using too much bandwith". This can cause latency spikes of several seconds (as well as increased latency after the first spike, as TCP is throttling its output). I recommend you go with UDP. \$\endgroup\$
    – Nuoji
    Commented Aug 7, 2013 at 22:23
  • 1
    \$\begingroup\$ Actually your model is a client-server architecture with your mobile devices being the clients and Photon Cloud being the server. It would be peer to peer, if your clients would communicate directly with each other without having Photon Cloud in between to broadcast the messages. \$\endgroup\$
    – Kaiserludi
    Commented Oct 2, 2013 at 13:27

2 Answers 2


Part of this is a Technical solution, the other part is a Design solution.

Peer to peer for this sort of thing has some fun drawbacks, especially as you're left with an interesting question of which client is authoritative, especially with lots of players. You can round robin between clients (this is actually useful for anti-cheating), but as everyone's talking to everyone else with different pings, things can get pretty weird.

It's a lot easier to use a server, have the server be authoritative, and have the clients just respond to, and send information to the server. The downside is that you're introducing extra latency on every action, on top of your normal lag.

It really depends on what kind of game you're making.

You're forced into using a asynchronous networking paradigm given the lag, synchronous paradigms (like lockstep) fair badly in high lag situations. This kind of networking is typically used in FPS/Driving and low latency input type situations, and you can easily find a lot of supporting information by looking at how those kind of games deal with their latency hiding. Even if your game isn't one of the above, you're going to want to steal how they do their latency hiding.

One of the more common techniques is to have two game worlds per client. One is the client world, which the user of the game sees. The other is the real world, which is as accurate as you can be given the networking data that you have. The trick is to make the client world always lerp towards the real world. Decision making usually happens on real data, although you can use client data if you want, but that can get weird fast.

This obviously means that not all clients will have the same data at the same time. At various intervals you're going to want to do a "sync up" between clients (i.e.: send as much of the full game state as you can). Sort of similar to how you get keyframes within video compression playback. You generate the intermediate frames using temporal deltas, but each keyframe is authoritative.

Designing for high latency is just as important as the technical side. Some things are just not possible. It also depends on how bad we're talking about. If you're at around 300ms, you can still get away with some FPS paradigms. If you're over 1 second, forget it, you won't be able to do any sort of on-the-fly targeting, or hit detection.

Games like WoW hide their latency quite well by using a few neat tricks

  • Players don't collide with other players. This means it doesn't really matter how accurate your player data is, as it makes no difference to the simulation
  • Minimal number of dynamic objects that impact determinism
    By limiting the amount of items that are in the world that can possibly impact position/movement, you have far less data to send, and far less objects to lerp/simulate
  • No hitscan targeting, because it will be hideously inaccurate and feel unfair.

The key is to make the game feel responsive, without actually being responsive. Having the client act immediately, while waiting on the result from the server/other clients and designing for that kind of interaction is why you don't notice the high latency in games like WoW.


I've written at length about this topic here: http://www.gabrielgambetta.com/fpm1.html. It's not exactly your case (this is for an authoritative server and dumb clients, vs your peer-to-peer architecture) but I guess the entity interpolation and server (in htis case, peer) reconciliation may apply.


You must log in to answer this question.

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