In mobile multiplayer, latency is a gameplay problem
Players do not experience your network architecture. They experience whether the game felt fair. That makes latency a design problem, not only an infrastructure one.
- Games
- Engineering
- Mobile
Real-time multiplayer on mobile is a trust problem wearing a gameplay costume. The fun is in the moment-to-moment feel. The difficulty is making that feel survive a real network — a phone on a train, switching between towers, on a mid-range device that is also busy rendering the game.
The most useful shift I have found is to stop treating latency as an infrastructure problem to be minimised, and start treating it as a design constraint to be designed around.
Players do not see packets. They see unfairness.
A player never thinks "my round-trip time is 180 milliseconds". They think:
- I hit him. It didn't count.
- I was already behind the wall.
- The other player teleported.
Every one of those is a disagreement between two devices about what just happened. The core job of a competitive multiplayer system is to resolve those disagreements in a way that feels fair to the people involved — not to eliminate them, which is impossible over a real network.
Design decisions that are really network decisions
Who has authority? Somebody has to be the source of truth for each piece of state. Whether that is a server, a host player or a split by object type determines what cheating is possible and how disagreements are settled. Networking frameworks such as Photon give you tools for this, but the choice of who decides is yours.
What does the local player see immediately? Showing the result of your own input instantly (prediction) makes the game feel responsive. The cost is occasional correction when the authority disagrees. How visible those corrections are is a design choice.
What happens to other players between updates? Interpolating between known positions looks smooth but shows the past. Extrapolating shows the present but guesses wrong. Different game modes can tolerate different trade-offs.
What counts as a hit? The "whose view wins" question is where fairness lives. There is no neutral answer, only a choice about which player's experience to favour, and it should be made deliberately.
Session flow is part of the same problem
On mobile, disconnection is not an edge case. Calls come in, apps get backgrounded, signal drops. Matchmaking, reconnection and what happens to a player who vanishes mid-match are core gameplay systems, not error handling. A game that punishes a two-second signal drop as harshly as a rage-quit will feel unfair even if every frame renders perfectly.
The takeaway
Put the network in the design document, not only the technical one. For each game mode, write down who has authority, what the player sees immediately, how corrections appear and what happens on disconnect. Those four answers decide whether the game feels fair, and fairness is what makes people come back.