Real-time Game

A real-time multiplayer game has many players interacting in a shared world — moving, shooting, colliding — where everyone must see a consistent view with the lowest possible latency. It pushes Real-time Updates to its extreme: not "updates within a second," but tens of updates per second, where 100ms of lag is noticeable and cheating must be impossible. The design centers on an authoritative server and clever state synchronization.

1. Requirements

Functional:

• Players join a game session and send inputs (move, act).
• All players see the shared world state update in real time.
• The server resolves interactions (hits, collisions) authoritatively.

Non-functional:

• Ultra-low latency — tens of ms; updates many times per second.
• Consistent world — all players agree on what happened (who got hit).
• Cheat-resistant — clients can't be trusted to report their own outcomes.
• Scale — many concurrent sessions; each session has a bounded player count.

2. Transport: UDP, not TCP

Unlike most designs in this track, a fast game usually uses UDP, not TCP. TCP's guaranteed in-order delivery means a single lost packet blocks everything behind it (head-of-line blocking) while it retransmits — fatal when you need the latest position and stale data is worthless. UDP sends fire-and-forget: a dropped position update is simply superseded by the next one. The game layers its own lightweight reliability only on the few messages that truly need it (e.g. "you died"). This transport choice is a key talking point — it's the opposite of the TCP/WebSocket default elsewhere.

3. The authoritative server

The single most important principle: the server is authoritative over game state. Clients send inputs ("I pressed forward," "I fired"), not outcomes ("I killed player B"). The server simulates the world, resolves all interactions, and tells clients the result:

client → inputs → authoritative server (simulates world, resolves hits/collisions)
server → authoritative state snapshots → all clients in the session

This is what makes the game cheat-resistant: a hacked client can lie about its input but can't fabricate outcomes, because the server decides. Never trust the client for anything that affects other players.

4. The game loop and tick rate

The server runs a simulation loop at a fixed tick rate (e.g. 30–60 Hz): each tick, gather inputs received since the last tick, advance the world one step, resolve interactions, and broadcast the new state. Players are grouped into sessions/rooms, each simulated by one server process (or a region of a world), so a session's state is local to one authority — no distributed consensus on game state. Scale by running many independent sessions across many servers.

5. Hiding latency on the client

Network latency is unavoidable, so clients use tricks to feel instant while staying consistent with the server:

• Client-side prediction: the client immediately applies your own input locally (you move the instant you press a key) and later reconciles with the server's authoritative state, correcting if they diverge.
• Interpolation: render other players slightly in the past, smoothly interpolating between received snapshots, so their movement looks fluid despite arriving in discrete, occasionally-dropped updates.
• Reconciliation: when the server's truth contradicts the client's prediction, the client snaps/eases to the authoritative state.

These make a laggy network feel responsive without surrendering the server's authority.

6. Reducing bandwidth

Broadcasting full world state to everyone many times per second is expensive, so:

• Delta compression: send only what changed since the last snapshot, not the whole world.
• Area of interest: send a player only the state near them, not the entire map — most of the world is irrelevant to any one player.

7. Deep dives

• Matchmaking: a separate service groups players into sessions before handing them to a game server — not on the hot path.
• Lag compensation: for hit detection, the server may rewind to where targets were at the shooter's timestamp, so high-ping players can still land shots fairly.
• Persistence: the fast loop is in memory; durable progress (stats, inventory) is written out of band to a database, not per tick.
• Region/edge: place game servers near players to cut round-trip latency; it dominates the experience.

What to emphasise

Lead with UDP + authoritative server, then client-side prediction:

"Latency is everything, so I'd use UDP rather than TCP — a lost packet shouldn't block the latest position behind retransmits; the next update just supersedes it. The server is authoritative: clients send inputs, not outcomes, and the server simulates the world on a fixed tick rate, resolves all interactions, and broadcasts state — which is what makes it cheat-resistant, since a client can't fabricate kills. To feel instant despite latency, clients predict their own actions locally and reconcile with the server's truth, and interpolate other players from recent snapshots. Players are grouped into sessions each owned by one server, so I scale by running many independent sessions, and I cut bandwidth with delta compression and area-of-interest filtering."

Next up: AI Chat Service — streaming LLM responses at scale.