Networked Multiplayer

Practical reference for wiring up a multiplayer game: where authority lives, how clients stay in sync, how to spend bandwidth wisely, and how to keep cheaters from rewriting the rules.

Picking a topology

Match the network model to how the game is actually played:

• Twitch / ranked PvP (fighting games, shooters, racing) -> run an authoritative dedicated server. Players never talk directly; the server owns the truth.
• Drop-in co-op or friendly lobbies -> use a listen server, where one player's machine doubles as host. Cheap and quick to stand up.
• Turn-by-turn play (card games, async strategy) -> a plain client-server loop is plenty; no tight timing budget.
• Persistent worlds at scale (MMO) -> spread load across sharded / distributed servers, each owning a region or instance.

How the three common hosting styles stack up:

The pattern: spend money to buy latency and trust. P2P flips that — it costs almost nothing but gives up both.

Keeping clients in sync

Two opposite philosophies, plus the blend almost everyone ships:

Hiding the latency

Even on a dedicated server, the round trip is real. Four techniques paper over it:

• Client-side prediction — the local player moves the instant a key is pressed, guessing what the server will confirm, so input feels immediate.
• Entity interpolation — remote characters are rendered a beat in the past, blending between received snapshots so they glide instead of teleporting.
• Server reconciliation — when a prediction turns out wrong, the client quietly snaps back and re-simulates from the authoritative state.
• Lag compensation — for hit registration the server rolls the world back to what the shooter saw at fire time, so well-aimed shots count despite ping.

A concrete flow: a player with 90 ms ping fires. Locally the shot leaves instantly (prediction). The server receives it, rewinds enemies ~90 ms (lag compensation), checks the hit against that older snapshot, then broadcasts the result; everyone else sees the victim react a frame late but smoothly (interpolation).

Spending bandwidth wisely

You will run out of bytes before you run out of things to send. Trim aggressively:

Tune send frequency to how fast each value matters:

Authority and anti-cheat

The bedrock rule: the client is an attacker's playground, so it gets no say over outcomes. Treat every inbound packet as a claim the server must prove.

When a client reports "my rocket killed them," the server independently asks:

1. Did a projectile with that trajectory actually intersect the target?
2. Was the firing player in a state allowed to shoot (alive, not stunned, weapon ready)?
3. Is the timestamp physically plausible, or is it impossibly fast?

Common exploits map cleanly onto server-side checks:

That last row is the strongest lever: an exploit is impossible if the cheating client was never handed the information in the first place.

Matchmaking trade-offs

Four goals that constantly pull against each other:

Tightening any one usually loosens another — perfect skill matching, for instance, means longer queues or worse pings.

Pitfalls to avoid

Bottom line: a client's word is only ever a request, never a fact. The server is the one and only source of truth.