Multiplayer Game Development: Networking and Synchronization
Multiplayer games connect players across the globe in shared real-time experiences. Building them requires solving problems that single-player games never encounter: latency, packet loss, cheating, and state synchronization across dozens or hundreds of clients. This guide covers the architectural patterns, synchronization strategies, matchmaking systems, and networking libraries that power modern multiplayer games, drawing on GDC networking talks and official engine documentation.
Network Architectures
The choice of network architecture determines how your game handles authority, cheating, and server costs.
Authoritative Server Architecture
In authoritative server architecture, the server is the single source of truth for game state. Clients send inputs (key presses, mouse clicks) to the server; the server validates these inputs, simulates the game, and broadcasts authoritative state back to all clients. Because clients cannot directly modify game state, cheating is severely limited — a hacked client cannot teleport, give itself health, or see through walls because the server ignores invalid inputs. The cost is increased latency: every action must round-trip to the server before the client sees the result. This is mitigated by client-side prediction (discussed below). The Source Engine (Counter-Strike, Team Fortress 2) uses authoritative server architecture, as documented by Valve’s networking model presentations at GDC 2008 and 2012.
Peer-to-Peer (P2P) Architecture
In P2P architecture, each player’s machine communicates directly with others. There is no central authority, so each client must validate others — typically through a lockstep simulation or by having one peer act as a “host” that other peers trust. P2P is simpler to implement and cheaper to run (no server costs) but is vulnerable to cheating if any client is compromised. P2P works well for cooperative games with small groups and trust-based matchmaking. The Portal 2 co-op mode uses P2P networking, and fighting games like Guilty Gear Strive use P2P with rollback netcode for low-latency 1v1 matches.
Relay and Dedicated Server Hybrid
Many modern games use a hybrid approach: matchmaking and lobby management go through inexpensive relay servers, while gameplay runs on dedicated game servers for competitive integrity. This is the model used by Valorant, Overwatch, and Apex Legends. Relay servers handle authentication, party management, and game session creation; once a session is formed, players connect to a dedicated game server in the closest geographic region.
Lag Compensation Techniques
Network latency typically ranges from 20 ms (same city) to 200 ms (intercontinental). Lag compensation hides this delay so players perceive responsive gameplay.
Client-Side Prediction
Client-side prediction lets the local player see their actions immediately rather than waiting for server confirmation. When the player presses “move right,” the client immediately moves the character right on screen and sends the input to the server. When the server’s authoritative state arrives, the client reconciles — if the server’s position differs from the predicted position, the client smoothly corrects. Implementation requires storing a history of past inputs and being able to roll forward from a server snapshot. The Source Engine’s prediction system, described in Valve’s multiplayer networking documentation, stores 200 ms of input history and reconciles by comparing server snapshots with client-predicted positions at the same timestamp.
Server Reconciliation
Server reconciliation corrects the client’s predicted state when the server’s authoritative state differs. The server sends snapshots at regular intervals (typically 20–30 Hz) containing position, rotation, and state for all relevant entities. The client receives a snapshot, compares it with its own predicted state at that snapshot’s time, and applies an interpolation correction. The correction should be smoothed over 50–100 ms to avoid visual snapping. The GDC 2017 talk “Overwatch Gameplay Architecture and Netcode” (Blizzard) detailed how Overwatch’s reconciliation system handles corrections differently for different entity types — player characters snap less aggressively than projectiles because positional error is more noticeable on characters.
Entity Interpolation
Other players’ positions are interpolated between received snapshots. When the client receives snapshot at time T, it has the previous snapshot at time T-50ms. It renders entities at time T-50ms + (renderTime × interpolationFactor), smoothly moving between the two positions. This introduces a small, consistent delay (render delay) of 50–100 ms but produces buttery-smooth movement. Entity interpolation is why, in high-latency conditions, other players’ movement appears smooth while your own (predicted locally) remains responsive.
Rollback Netcode
Fighting games and other latency-sensitive genres use rollback netcode. The client simulates the game forward assuming no inputs from the remote player (using the last received input). When the remote player’s input finally arrives, if it differs from what was assumed, the client rolls back the simulation to the correct frame and re-simulates forward. The rollback is invisible if it completes within a single frame (16.6 ms). GGPO (Good Game Peace Out) is the most established rollback implementation, integrated into Street Fighter III: 3rd Strike Online Edition and Skullgirls. The GGPO documentation (Poncle, 2013) describes the save state and re-simulation approach.
Matchmaking Systems
Elo and TrueSkill
Elo rating (developed for chess) adjusts player ratings after each match: winners gain points from losers, with the amount determined by the expected win probability. TrueSkill (Microsoft Research, 2005) extends Elo with a confidence measurement — after fewer games, the system is less certain of a player’s skill and adjusts ratings more aggressively. Xbox Live’s TrueSkill implementation uses a Gaussian distribution of skill with mean and standard deviation. Matchmaking systems typically aim for matches where both players have a 45–55% win probability.
Party Matchmaking
Parties complicate matchmaking: should a party of three skilled players and one beginner be matched based on the highest skill, average skill, or party-specific rating? The Apex Legends matchmaking system, documented in Respawn’s GDC 2022 talk, uses a weighted average that skews toward the highest-skilled player to prevent boosting. Party members must be within a configurable skill range (typically 2–3 standard deviations on the skill curve) before matchmaking proceeds.
Synchronization Strategies
State Synchronization
The entire game state is serialized and sent to clients. This is simple to implement but bandwidth-intensive. The Unreal Engine replication system uses state synchronization for Actor properties: mark a property as Replicated, and the engine automatically sends changes to all relevant clients. State sync works well for games with moderate entity counts (under 200).
Input Synchronization
Only player inputs are sent to the server. The server runs the game simulation and broadcasts the resulting state. This is more bandwidth-efficient because input data is compact (a few bytes per frame) compared to full state snapshots. RTS games like StarCraft II use input synchronization with deterministic lockstep — every client runs the identical simulation, ensuring all players see the same result from the same inputs.
Deterministic Lockstep
Lockstep requires identical game logic on all clients, including deterministic floating-point behavior. Every client sends its inputs for a specific frame; when all clients have acknowledged the same frame, the simulation advances. Ticks are synchronized across all peers. Lockstep is bandwidth-efficient but ties simulation speed to the slowest client. The OpenDraft documentation (popular for StarCraft II custom games) explains how lockstep coordinate systems and deterministic math avoid desyncs.
Networking Libraries
Mirror
Mirror is the most popular open-source networking library for Unity, maintaining the API patterns of the deprecated UNet system. It supports authoritative server architecture, NetworkTransform for automatic position sync, and NetworkBehaviour for RPCs and Commands. The Mirror documentation provides extensive code examples for common patterns: player spawning, health synchronization, and scene management.
Photon
Photon (Photon Cloud, Quantum) offers cloud-hosted multiplayer infrastructure. Photon PUN (Photon Unity Networking) handles matchmaking, room management, and real-time messaging without requiring dedicated server management. Quantum is a deterministic lockstep engine for Unity that runs game logic in a custom C# interpreter. Photon’s pricing scales with concurrent users, making it suitable for indies who want to avoid server operations.
Steamworks
Steamworks provides networking integrated with Steam’s matchmaking, friend lists, and lobbies. The Steam Networking API (SDR) routes connections through Valve’s backbone for optimal routing. Steamworks integration is essential for PC games launching on Steam due to its deep platform integration.
For networking protocol details, see Multiplayer Networking. For engine-specific implementation, consult Unity Guide.
Frequently Asked Questions
Q: What is the difference between latency, ping, and jitter? A: Latency is the time for data to travel from client to server (one-way). Ping is round-trip time (RTT) including server processing. Jitter is the variance in latency between packets — high jitter causes more noticeable stuttering than consistent high latency.
Q: How many players can a single server instance support? A: For real-time action games, 16–64 players on a single 64-tick server is typical. For turn-based or strategy games, 128–256 players. For MMORPGs, 1000+ players per server shard with aggressive interest management and level-of-detail for entity updates.
Q: How do I prevent cheating in my multiplayer game? A: Use authoritative server architecture (clients send inputs, server validates). Validate inputs server-side — reject impossible movement speeds, health changes, or inventory modifications. Use server-side hit detection for critical actions. Client-side anti-cheat (EAC, BattlEye) adds additional protection but is not sufficient alone.
Q: What tick rate should my server run at? A: 30 Hz for slow-paced games (strategy, RPG). 60 Hz for fast-paced action (shooters, fighting games). 128 Hz for competitive esports titles (CS:GO, Valorant). Higher tick rates improve precision but increase bandwidth and CPU cost linearly.
Q: How do I handle network disconnects gracefully? A: Implement client-side buffering: cache the last 3–5 seconds of inputs and re-send on reconnect. Server-side: maintain session state for 10–30 seconds after disconnect, allowing reconnection. Display clear messaging — “Connection Lost. Reconnecting…” — with a timeout that leads to graceful return to menu.
For a comprehensive overview, read our article on 2D Game Development Guide.
For a comprehensive overview, read our article on 3D Game Development Guide.