Mobile Multiplayer Engineering

We specialize in building real-time multiplayer for mobile games. This is not just WebSocket and sending coordinates — it's managing 50–200 ms latency, compensating for packet loss, synchronizing physics, and dealing with unstable 4G. Mobile clients lose packets more often than desktops: switching from WiFi to LTE, OS backgrounding — a naive implementation breaks in early tests. 5% packet loss is common on mobile networks, and an extra 100 ms of latency creates an unacceptable experience. Our team, with over a decade in mobile gaming and 20+ shipped multiplayer titles, provides a turnkey solution from architecture to deployment. We deliver up to 40% bandwidth savings via delta compression — a typical saving of $2,000–$5,000 per month for a mid-size game. This article covers key technical decisions: authoritative server, client prediction, lag compensation, and mobile optimizations.

Core Challenges in Mobile Multiplayer

The first mistake is trusting the client. The client sends "I moved here" and the server applies it without verification. Within a week, cheaters teleport across the map. The correct architecture: authoritative server. The client sends input (pressed buttons, movement vector), the server simulates physics and broadcasts resulting states. The client runs the same calculations locally — this is client-side prediction. When the server response arrives, the client reconciles — rolls back to the last confirmed state and replays the buffer of unconfirmed inputs. As noted in Unity Netcode documentation, this approach is mandatory for competitive games.

How Does Client-Side Prediction Improve Mobile Multiplayer?

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 snapshots to all clients (not every tick — delta compression is applied).
4. Client receives snapshot, compares with predicted state, and corrects.

Delta compression is critical: instead of a full world state (300 bytes), only changes are sent (10–30 bytes). At 20 Hz for 10 players, the difference is 60 KB/s vs 6 KB/s — a 90% reduction. Client-side prediction reduces perceived latency by 3x compared to waiting for server confirmation.

UDP vs TCP for Mobile Real-Time

TCP guarantees delivery and ordering via retransmission on loss. In a real-time game, a lost packet with a player's position 200 ms ago is not needed — the current position is needed. TCP will wait and resend outdated data while new data queues behind it, adding 100–400 ms to visible latency on poor channels. UDP — fire and forget. Loss is handled at the application layer: positional updates don't need reliability (new packet overwrites old), while important events (damage, death) need acknowledgement — implemented via a simple ACK scheme over UDP. For mobile, raw UDP is accessible via System.Net.Sockets.UdpClient in Unity or NWConnection with .udp parameter on iOS. Android uses DatagramSocket through Java/Kotlin. Photon Realtime uses its own protocol over UDP with built-in reliable delivery for critical messages. LiteNetLib is an open-source alternative. In latency tests, UDP reduces average lag by 30–40% compared to TCP for real-time positional data.

Lag Compensation and Interpolation

On the client, other players' objects do not move directly according to snapshots — that causes jitter on unstable connections. Interpolation: the client stores a buffer of the last 2–3 snapshots and renders the state with a 50–100 ms delay, interpolating between them. Movement becomes smooth at the cost of artificial latency. Lag compensation on the server: when player A shoots at player B, the server "rewinds" the world state back by RTT/2 and checks collision where B was from A's perspective. Without this, hitting a fast opponent at high ping is physically impossible.

Mobile Platform Specifics

iOS background mode (after 5–10 seconds UIApplicationWillResignActiveNotification) breaks the socket. Use BGTaskScheduler for background reconnect or graceful disconnect with session persistence on the server. Android: WakeLock and WifiLock to keep the connection during a match. Without WifiLock.WIFI_MODE_FULL_HIGH_PERF, the WiFi module enters power-saving mode and adds 30–80 ms to latency. Network switching from WiFi to mobile — ConnectivityManager.NetworkCallback on Android, NWPathMonitor on iOS. On network change, fast reconnect without losing the game session.

Stack and Tools

What's Included in the Work

• Architectural documentation: protocol selection, synchronization scheme, error handling.
• Server code: authoritative server, lag compensation, delta compression.
• Client integration: client prediction, interpolation, reconnect logic.
• Testing on real devices: 10+ models, different OS versions.
• Deployment: server infrastructure setup, monitoring.
• Team training: code review, documentation, 1-month support.

Real-Time Multiplayer Development Stages

Requirements audit (genre, player count, platforms) → framework selection → prototype with basic position synchronization → implement client prediction and reconciliation → lag compensation on server → load testing → polish for mobile constraints. Prototype with basic multiplayer for 2-4 players: 3-4 weeks. Full real-time system for 10-20 players with lag compensation and mobile optimization: 2-4 months. Cost is calculated individually, but typical prototypes start at $5,000–$10,000 and full systems range from $20,000 to $50,000.

Contact us for a project assessment. Order a prototype in 3-4 weeks — we will advise on architecture and propose the optimal solution. Get a consultation from an engineer specializing in mobile real-time systems with 10+ years of experience and 20+ shipped titles.

Our company: 10+ years in mobile multiplayer, 20+ shipped titles, 5+ years on the market. We have helped over 50 studios deliver responsive multiplayer experiences.