The first decision in any multiplayer game: how are clients connected? Peer-to-peer, client-server, and — the standard for competitive games — the authoritative server that owns the truth.
There are two fundamental topologies. In peer-to-peer, players connect directly and share simulation, which is cheap (no server to run) but hard to keep consistent and trivial to cheat. In client-server, all players connect to a central server that coordinates the game; it costs money to host but gives you one place to enforce rules. Nearly all modern online games are client-server for exactly that control.
PEER-TO-PEER (P2P) CLIENT-SERVER
players connect directly all clients connect to a central SERVER
no server to run (cheap) you host + pay for servers
who's "right" on conflict? the SERVER decides -> one source of truth
easy to cheat (no referee) server can validate + hide info
NAT/connectivity pain server has a public IP -> reachable
scales poorly (N² links) scales per-server; shard for more players
Modern online games are almost all CLIENT-SERVER for control + anti-cheat.
P2P survives in some co-op / fighting games (lockstep, next topics).The cornerstone of competitive netcode: the server is authoritative — it runs the real simulation and its state is the truth, while clients only send inputs and render what the server tells them. A client cannot teleport, shoot through walls, or give itself health, because the server ignores anything its own simulation does not permit. This trust model is why authoritative servers dominate any game where cheating matters.
AUTHORITATIVE SERVER: the server runs the REAL game; its state is TRUTH.
client -> sends only INPUTS ("I pressed forward + fire") (never state)
server -> simulates, validates, and sends back the RESULTING STATE
client -> RENDERS that state (and predicts locally, next lessons)
"never trust the client":
client claims "I'm at (500,10) with 100 hp" -> IGNORED.
server computes position from validated inputs + its own physics.
-> a hacked client can't teleport, shoot through walls, or grant itself health,
because the server simply won't simulate it. The foundation of anti-cheat.A different model, used by many RTS and fighting games, is deterministic lockstep: instead of sending state, every peer sends only inputs, and each runs the identical simulation in lockstep, so they stay in sync from the same inputs. It sends tiny amounts of data (just inputs) and suits thousands of units, but it requires perfect determinism and waits for the slowest player’s input each turn. Knowing it exists explains why some genres network so differently.
LOCKSTEP (deterministic): every peer runs the SAME simulation; they exchange
only INPUTS and advance in lock-step.
✓ tiny bandwidth (only inputs) -> great for RTS with 1000s of units
✓ no state to replicate; every machine computes the identical world
- requires PERFECT determinism (same float math, order, RNG seed everywhere)
-> one divergence and games desync
- must WAIT for the slowest player's input each turn -> input delay
- a mid-game join must replay/copy the whole simulation
Used by: RTS (StarCraft, AoE), many fighting games (rollback lockstep).
Authoritative server (previous topic) is the other dominant model.The choice follows the genre. Fast, competitive action games (shooters, MOBAs) use an authoritative server with client prediction — the model this course focuses on. RTS and fighting games often use deterministic lockstep (increasingly rollback-based). Casual co-op may accept simple client-server or even P2P. Picking correctly up front shapes everything, because the netcode model is very hard to change later.
Match the model to the game:
fast competitive action -> AUTHORITATIVE SERVER + client prediction
(FPS, MOBA, battle royale) (this course's focus)
RTS / many-unit strategy -> DETERMINISTIC LOCKSTEP (inputs only)
fighting games -> ROLLBACK lockstep (predict + rollback locally)
casual co-op / small -> simple client-server, sometimes P2P
The netcode model is a FOUNDATIONAL choice — extremely hard to swap later.
Decide by: how competitive, how many entities, latency tolerance, budget.