Explore How Online Game Servers Keep Many Players in Sync

Picture forty players in an online game, spread across three continents, all looking at the same capture point. One is on fibre in Frankfurt, one is on hotel wifi in Singapore, one is on a phone in a moving car. Their connections differ by hundreds of milliseconds, and yet each of them needs to see roughly the same thing at roughly the same time, or the game stops making sense.

Keeping that shared world consistent is the central job of a game server. I have spent a fair amount of my career running servers that do this, and the techniques are more interesting, and more pragmatic, than most players assume.

Why the server is the single source of truth

The first decision in any multiplayer design is who decides what really happened. Most competitive online games use an authoritative server: clients send their inputs, such as "move forward" or "fire", and the server runs the actual simulation and tells everyone the result.

The alternative, letting each client simulate its own character and report its position, is simpler and feels very responsive, but it hands the truth to the players' machines. That makes cheating trivial, since a modified client can simply claim to be somewhere else, and it makes disagreements impossible to settle. An authoritative server costs more to run, but it is the only model where the game can be fair.

The tick: a heartbeat for the game world

The server does not simulate continuously. It advances the world in fixed steps called ticks. On each tick it reads the inputs that arrived, moves every entity, resolves collisions and hits, and then sends updates out to players.

The tick rate is how many times per second this happens. Casual and strategy games may run at 10 to 20 ticks per second. Fast shooters commonly run at 60, and some competitive servers go to 128. A higher rate makes the game feel tighter and reduces disagreements about who shot first, but it multiplies CPU and bandwidth costs. A server running 128 ticks for 10 players can cost more than one running 20 ticks for 100 players, which is why tick rate is as much a budget decision as a design one.

Sending only what changed

Sending the full state of a big world to every player on every tick would swamp most connections. Servers keep it lean in a few ways.

• Delta compression. The server remembers what each client last acknowledged and sends only the differences since then.
• Interest management. A player gets updates only for things near them or relevant to them. Someone on the far side of the map does not need your footsteps.
• Quantisation. Positions and angles are packed into fewer bits. A rotation does not need a 64-bit float to look right on screen.
• Priority. Nearby enemies get updated every tick; a distant flag might update once a second.

Together these can cut bandwidth by an order of magnitude, which is the difference between a game that runs on mobile data and one that does not.

Hiding the delay on the client

Even with a perfect server, every update is already slightly old by the time it arrives. If the client simply drew whatever it last received, other players would jump around in steps of one tick, and your own character would feel sluggish.

So clients do two things. For your own character, they use prediction: they apply your input immediately and assume the server will agree, then quietly correct if it does not. For everyone else, they use interpolation: they deliberately display other players a little in the past, smoothly blending between two known snapshots rather than guessing ahead. That small built-in delay, often around 100 milliseconds, is what makes movement look fluid. The trickier question of what happens when two players act at nearly the same instant is covered in how netcode decides who wins in fast online game matches.

Transport: why games avoid plain TCP for movement

Most web traffic runs over TCP, which guarantees every packet arrives in order. For a game that is a mixed blessing. If one position update is lost, TCP holds back every later update until the lost one is resent. By then it is stale anyway.

Games therefore send fast-changing state over UDP or a UDP-like channel, where a lost packet is simply skipped because the next one carries newer information. Reliable messages such as chat, purchases or "match over" still go through a reliable path. In browsers, WebRTC data channels and WebTransport provide this mix, as we describe in how browser technology brings online game worlds to any screen.

Where "just add more servers" falls short

When sync problems appear, a common response is to throw hardware at them: bigger machines, more regions, higher tick rates. Sometimes that helps. Often it does not, and it is worth understanding why.

Most desync is caused by the network between players and servers, not the servers themselves. A faster machine cannot shorten the distance from Jakarta to a server in Virginia. More regions help only if the matchmaker actually keeps players in nearby regions, which conflicts with finding matches quickly at quiet times. And a higher tick rate increases the amount of data every player must receive, which can make things worse for those on weak connections.

The real fixes are usually in design: better interpolation, sensible lag compensation, smarter matchmaking, and honest limits on how far apart players can be. Hardware is the last lever, not the first.

Shards, instances and very large worlds

One server process can comfortably simulate somewhere between a few dozen and a few hundred active players, depending on the game. Larger worlds are split. Instances give each group its own copy of a dungeon or match. Shards run parallel copies of the whole world. Spatial partitioning splits one world into regions handled by different servers, handing players across the boundary as they move.

Each approach trades some consistency for scale, and each needs careful engineering at the boundaries. When an online game platform needs to bring up hundreds of these processes during a busy evening, the infrastructure side becomes its own challenge, which we look at in how online game platforms scale their servers on busy nights.

Synchronisation is never perfect. It is a careful balance of fairness, responsiveness, bandwidth and cost, tuned for each game. When it works, players never think about it at all, and that is the goal. Browse more of our Games coverage.