What Every Programmer Needs To Know About Game Networking
Source: https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/ Author: Glenn Fiedler | Date: 2010-02-24 | Series: Networking for Game Programmers
Introduction
Multiplayer games appear to share one consistent virtual world, but underneath it is an illusion: each player sees an approximation unique to their point of view and place in time.
Peer-to-Peer Lockstep
Early games networked peer-to-peer in a fully connected mesh. This model still lives in RTS games. The game is abstracted into turns and command messages; each machine runs the same commands from a common initial state (see also: "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond").
Limitations:
- Determinism: Extremely hard to keep every turn identical across machines (pathing differences → desync).
- Latency equals worst peer: Must wait for all players' commands before simulating a turn. RTS hides delay with audio/cosmetic feedback.
- Late join difficult: All players must start from the same initial state; capturing a mid-game deterministic checkpoint is hard.
RTS still use this because game state (thousands of units) is too large to exchange; only commands that evolve state are sent.
Client/Server
Doom used peer-to-peer lockstep designed for LAN; over modem Internet it was unplayable (wait for most lagged peer's inputs every frame).
Quake (1996) switched to client/server: game exists on the server; clients are dumb terminals showing an approximation. Pure model: client sends inputs; server updates character and replies with nearby state; client interpolates. Quality depends on client–server link, not worst peer; players can join mid-game; average bandwidth per player drops.
Carmack later noted original Quake targeted <200ms; most modem users had 300+ms and felt terrible lag.
Client-Side Prediction
Modern FPS removes lag on your own actions via client-side prediction (QuakeWorld). Client runs a subset of movement code locally so forward/fire feel instant. Server remains authoritative ("The Server Is The Man" — Tim Sweeney / Unreal Networking Architecture) to prevent cheating (client cannot simply report "here is my position").
When client and server disagree, server correction is in the past (e.g. 100ms each way → 200ms old relative to predicted time). Applying it verbatim would yank the player back and undo prediction.
Solution: circular buffer of past character state and input on the client. On correction: discard buffered state older than the correction; rewind to corrected state; replay stored inputs to present predicted time while holding the rest of the world fixed.
If client and server simulation match for the same inputs, corrections are rare. Corrections mainly happen for external effects (rocket hit, bump into enemy) or cheating attempts.