Design a multiplayer game server

A client never says 'I am at this position'. It says 'I pressed forward and fired'. The server applies those inputs to its own copy of the world with the same rules every time. A modified client can lie about its inputs, but it cannot lie about where it is or whether a shot hit.

The server runs a fixed tick, 30 times a second, so each tick has 33 ms. In every tick it reads the inputs that arrived, advances the physics, resolves hits and sends snapshots. If a tick takes more than 33 ms the world slows down for everyone, so we budget 10 ms of CPU and keep the work per match on one core, with no locks between matches.

Use UDP. In a fast game an old position is worth nothing, and TCP would hold back new data behind a lost packet. With UDP the game adds its own small layer: sequence numbers on every packet, and a separate reliable channel for rare events such as 'you were eliminated'.

Cut the bandwidth. Sending all 63 other players in full every tick costs 63 × 24 B + 40 B = 1,552 B a packet, or about 46.6 KB/s per player. Three things shrink it:

• Quantize. Send positions as 16-bit whole numbers instead of 32-bit floats. For a map 650 m wide, 16 bits gives about 1 cm of precision.
• Delta compress. Send only what changed since the last snapshot the client acknowledged. The client's acknowledgement says which one that was. If it has not acknowledged for a while, the server falls back to an older baseline.
• Interest management. Send only the entities a player could care about, such as those within 100 m or in line of sight. Cheaters also lose a way to see through walls, because hidden players are never sent.

With these, a packet carries about 16 entities × 8 B + 40 B = 168 B, so about 5 KB/s per player. That is 9 times less, and it makes 640,000 players about 26 Gbit/s across the fleet instead of 240.

Three techniques work together.

Client-side prediction. The client applies its own inputs to its own copy of the world at once, and keeps a list of the inputs the server has not yet confirmed. Each snapshot says 'I have processed your inputs up to number N'. The client resets to the server's state, then replays its inputs after N. Usually the result matches the prediction and nothing visible happens. When the server disagreed, for example because another player bumped you, the client blends smoothly to the corrected position.

Interpolation. Other players are not predictable, so draw them slightly in the past. With snapshots 33 ms apart, a client draws other players about 100 ms behind the latest one, which is about three snapshots. It then always has two snapshots to blend between, and one lost packet does not cause a stutter. The price is that you see opponents as they were 100 ms ago.

Lag compensation. If a shooter sees a target 100 ms in the past, a shot at what they see would miss when judged against the target's true position now. So the server keeps a history of each player's position for about the last 200 ms. When a fire input arrives, the server works out what the shooter saw: the shot's travel time of about 40 ms (half of an 80 ms round trip) plus the 100 ms interpolation delay, so roughly 140 ms. It rewinds the targets to that moment, tests the hit, and then returns to the present.

The cost is fairness for the victim. A target who ran behind cover 100 ms ago may be hit after they believe they were safe. To limit the damage, cap the rewind at 200 ms, so a very laggy player cannot shoot into the distant past, and treat players above that ping as playing at a disadvantage.

Anti-cheat basics. The server validates every input: speed limits, rates of fire, and legal actions. It never sends hidden entities. It rate-limits packets and checks the join token. For aim assistance and similar cheats, it keeps statistics, such as accuracy and reaction time, and flags outliers for review. Client-side detection is a separate and endless contest. The authoritative server is the part that always works.

The matchmaker keeps tickets in memory, grouped by region and game mode, ordered by rating. It looks for 64 tickets inside a rating band. A new ticket starts with a tight band, say plus or minus 100 points. For every 10 seconds of waiting, the band widens by 50 points, up to a limit such as 500, and the region set can widen too. Short waits then give fair matches, and long waits give some match instead of none. Parties queue as one ticket with the average rating.

Allocation. Each region has a fleet of game machines. Each machine sends a heartbeat that says how many match slots it has free. The allocator picks a machine with room and starts the match there, passing the player list and a join token for each player. Keep a spare pool of warm machines, since starting a machine takes minutes, and scale the fleet by the 11 matches a second and the time of day. When deploying a new version, mark old machines as draining: they take no new matches and finish the ones they have.

Joining. The token says which match and which player a connection belongs to. The relay checks it, and a stolen address alone is useless. The relay also hides the real server addresses from players, which blunts attacks aimed at a single server.

Reconnects. When a player's packets stop, the server keeps their character for 60 seconds, idle or run by a simple bot, and does not release the slot. The lobby records which match each player is in, so a restarted app is offered 'rejoin'. The same token reconnects to the same server, which sends a full snapshot, not a delta, since the client has no baseline.

Results. A match lasts 15 minutes and its state lives in memory. At the end, the server writes the result and new ratings in one transaction, keyed by the match ID, and only then shuts down. A retry writes nothing twice. If a server crashes mid-match, the match is voided and nobody's rating changes, which is rare and acceptable. Saving state every few seconds just to survive that would cost more than it saves.