Mobile Game Real-Time Multiplayer Development

Real-Time Multiplayer Development for Mobile Games

Real-time multiplayer in mobile games isn't just WebSocket and sending coordinates. It's managing 50-200 ms latency, compensating for packet loss, synchronizing physics, and working with unreliable 4G. Mobile clients lose packets more often than desktop: WiFi→LTE switch, tunnels, background mode—all break naive implementations within first tests.

Architecture: Authoritative Server and Client Prediction

First mistake—trusting the client. Client sends "I moved here", server applies. Week later, cheaters teleport across map.

Correct architecture: authoritative server. Client sends input (pressed buttons, movement vector), server simulates physics, broadcasts resulting states. Client applies same computations locally—client-side prediction. When server response arrives, client compares: if deviation exceeds threshold, apply reconciliation—rollback to last confirmed state and replay buffered unconfirmed inputs.

In Unity via Netcode for GameObjects or Mirror, but architectural pattern is identical. Each game tick (typically 20-60 Hz for mobile):

1. Client sends InputPayload { tick, moveDirection, shootPressed }
2. Server applies input, computes StatePayload { tick, position, health, ... }
3. Server broadcasts snapshot to all clients (usually not every tick—delta compression)
4. Client receives snapshot, compares with predicted state, corrects

Delta compression is critical for mobile: instead of full world state (300 bytes), send only changes (10-30 bytes). At 20 Hz for 10 players: full state = 60 KB/s vs delta = 6 KB/s.

Transport Layer: UDP vs TCP

TCP guarantees delivery and packet order via retransmit on loss. In real-time games, a lost packet with player position from 200 ms ago is useless—we need current position. TCP waits and retransmits stale data while new packets queue. This adds 100-400 ms visible latency on poor channels.

UDP—send and forget. Losses handled at application level: position updates don't need reliability (newer packet overwrites older), critical events (damage, death) need confirmation—implemented via simple ACK scheme over UDP.

On mobile platforms, raw UDP available via System.Net.Sockets.UdpClient in Unity or NWConnection with .udp on iOS. Android uses DatagramSocket via Java/Kotlin.

In practice: Photon Realtime uses proprietary protocol over UDP with built-in reliable delivery for critical messages. LiteNetLib—open-source alternative with similar capabilities.

Lag Compensation and Interpolation

On client, other players' objects don't move directly by snapshots—causes jitter on unstable connection. Interpolation: client stores buffer of last 2-3 snapshots and renders state with 50-100 ms delay, interpolating between them. Motion becomes smooth at cost of artificial delay.

Lag compensation on server: when player A shoots player B, server "rewinds" world state RTT/2 back and checks collision where B was from A's perspective. Without this, hitting fast opponent at high ping is physically impossible.

Mobile-Specific Concerns

iOS background mode (within 5-10 sec UIApplicationWillResignActiveNotification) breaks socket. Need BGTaskScheduler for background reconnect or graceful disconnect with session save on server.

Android: WakeLock and WifiLock to maintain connection during match. Without WifiLock.WIFI_MODE_FULL_HIGH_PERF, WiFi module enters power-saving mode and adds 30-80 ms to latency.

WiFi→mobile switch—ConnectivityManager.NetworkCallback on Android, NWPathMonitor on iOS. On network change—fast reconnect without losing game session.

Stack and Tools

Timeline

Requirements audit (genre, player count, platforms) → framework selection → basic sync prototype → client prediction and reconciliation → server lag compensation → load testing → mobile optimization.

Basic 2-4 player prototype: 3-4 weeks. Full real-time system for 10-20 players with lag compensation and mobile optimization: 2-4 months. Cost calculated individually.