[Network Gaming 2] The Dictator's Statecraft: How Dedicated Servers Rule the World

0. The Old-Timers Who Outplayed Time:

If you're an old-timer like me, there's a good chance you played early MMORPGs like Lineage, The Kingdom of the Winds, or Ultima Online.

I was never a hardcore Lineage player, but back then there was a technique called the Ebony Wand control. You'd target an opponent with the Ebony Wand to stagger them, then use that tiny delay to close in and buy yourself a window to start swinging your sword. It was the signature move of the notorious PKers.

In The Kingdom of the Winds, there was "one-tile spacing" and "two-tile spacing": landing your special attacks on a monster before it could close the gap. On your own screen, it looked as if you'd skipped across space. To other players watching, it looked even more extreme.

In this post, I'll lump these techniques together and call them "tick control." The difference between players who could pull it off and those who couldn't wasn't just fast hands. It was whether you understood, in your gut, when the server calculates the world.

In the previous post, we watched the democracy of Lockstep collapse and the dictator known as the Dedicated Server take power. The conclusion was simple:

"All your client calculations are fake."

The real coordinates live only on the server.

But this dictatorship had one fatal weakness. The dictator is slow. Every ruling requires a full round trip to the server.

This post is about all the lies and tricks game developers deployed to hide that slowness. And the traces of those tricks are still preserved, coated in a thick layer of nostalgia, in the strange phenomena we experienced in Korean PC bangs as the world shifted from analog to digital.

1. The Tick: The Dictator's Heartbeat

The dictator doesn't see the world as a continuous flow. At fixed intervals, it freezes the world, gathers every input that arrived in between, and rules on all of them at once. Each of these ruling cycles is called a tick.

At 10 ticks per second, the server calculates the world once every 0.1 seconds. If, within that 0.1 seconds, you fire the Ebony Wand and frantically click to move at the same time, those inputs sit in the server's waiting room until the next tick.

As I understand it, on the next tick the server resolves the hit, the target's stagger, and your movement all together. Because you were already spam-clicking to move, you end up glued to your target the instant they're staggered.

That's what tick control really is. The veterans didn't know jargon like ticks or input latency, but they learned by feel what works inside that 0.1-second window. They didn't know the theory, but they were dancing to the beat of the dictator's heart.

Then add ping on top:

• The time for your input to reach the server
• The time the server waits for the next tick
• The time for the result to come back to your screen

Stack those three together and the gap between pressing a key and the server accepting it as "fact" grows larger than you'd think. In the dial-up era, a few hundred milliseconds was nothing.

The problem is that humans are extremely sensitive to this gap. If your character moves 0.3 seconds after you press a key, the game gets branded as "laggy." The dictator was fair, but painfully sluggish.

2. Client-Side Prediction: Move Before You're Allowed To

In 1996, John Carmack of id Software was fighting exactly this sluggishness. Quake used a pure server-authoritative model, and modem players suffered through a half-beat delay every time they pressed a key. The solution he introduced in QuakeWorld was simple, yet bold.

"Don't wait for the server's permission. Let the client move first."

This is client-side prediction. When I press the key to move forward, the client doesn't wait for the server's reply. It predicts, "the server will probably calculate it like this," and moves my character immediately, while sending the input to the server at the same time. Most of the time, the server's calculation and the client's prediction match, and the player never feels the lag.

Wait, didn't the previous post say all client calculations are fake? Correct. They're still fake. They're just a temporary fake shown until the dictator hands down its ruling. When the real verdict arrives, the client must obey it, no questions asked.

Rubber-Banding: The Dictator's Correction Notice

So what happens when the prediction is wrong? You're running hard through heavy lag, and suddenly your character gets yanked several steps backward. We've all been there. This is commonly called rubber-banding.

It isn't a bug. It's the dictator's correction notice. The client predicted, "I made it over there," but the server ruled, "No, you hit a wall," or, "Your input never arrived." The client snaps back to the position the server confirmed, then replays all the inputs the server hasn't acknowledged yet on top of it. This process is called server reconciliation.

In that rubber-band moment, we were literally watching the fake world being overwritten by the real one.

3. Interpolation: Other Players Always Live in the Past

Prediction solved the problem for my own character. But what about other players? I have no way to predict someone else's inputs. All I can do is receive the position data the server sends, known as snapshots.

The problem is that these snapshots arrive in bursts, once per tick. If you plot the received coordinates as-is, other characters teleport one step at a time in a choppy stutter. Drop a single packet and they jump several tiles at once. That image of other players sliding and teleporting across the field on a laggy day? That's exactly this.

So developers pulled out another trick: interpolation. The client doesn't display snapshots the moment they arrive. Instead, it deliberately plays them back with a slight delay, smoothly connecting the dots between two snapshots. It draws a line between where someone was 0.1 seconds ago and the position just received, then makes them walk along it.

Thanks to this, the screen became smooth. But there's a chilling truth hidden here. The other players you see are always a picture of the past.

• Thanks to prediction, I'm living slightly in the future.
• Thanks to interpolation, everyone else is living in the past.

Different timelines coexist on the very same screen.

In the previous post, I said Lockstep created parallel universes. The dedicated server eliminated parallel universes, but in their place it created a universe of tangled time. And in the next section, that time gap leads to some deeply unfair deaths.

4. Lag Compensation: The Dictator's Retroactive Verdict

What happens when you fire a gun in a universe of tangled time?

The enemy on my screen is an enemy from the past. I aim precisely at that past enemy's head and pull the trigger. But in the server's ledger, that enemy has already moved several steps to the side. Judged by the server's present, my bullet slices through thin air. A game where you clearly hit but don't land the shot. Nobody would play that.

So in the Half-Life and Counter-Strike era, Valve made an even bolder move. When the server judges a shot, it rewinds time.

The server keeps a short history of every player's past positions. When my shot input arrives, it calculates, "Given this player's ping and interpolation delay, this is what the world looked like on their screen at the moment they fired." It rewinds every player to that moment, checks whether the shot hit, then returns to the present. This is lag compensation.

It's as if the dictator turned the clock back to the moment of the testimony and issued a retroactive verdict. From the shooter's point of view, it's fair. The problem is the person who got shot.

Anyone who has played an FPS knows the feeling of ducking completely behind a wall and dropping dead a beat later. On my screen I was already safe, but on my opponent's past screen I was still out in the open. The dictator ruled based on my opponent's past, and I died in a moment that had already passed.

For similar reasons, we get peeker's advantage: the player who swings around a corner first has the upper hand, because their movement reaches the opponent's screen with a delay. The effort to shrink that delay eventually turned into a tick rate arms race, but let's save that for the next post.

5. MMO Dictatorships Operate at a Different Scale: Zones and AOI

Everything so far applies to FPS games and MMORPGs alike. But MMORPGs face a hell of their own that FPS games never have to deal with: sheer headcount.

An FPS match has around ten players at most. Tell the other nine about one player's movement, and you're done. That's roughly 90 updates per tick.

MMORPGs are different. Imagine 1,000 players gathered in a single town. To tell everyone about everyone else's movement, you'd need to send 1,000 × 999, roughly a million updates per tick. Double the player count and the cost quadruples.

This isn't a server performance problem. It's an arithmetic problem. No matter how good a server you buy, you can't beat this math.

So the MMORPG dictator changed how it governs, using two forms of divide and rule.

• Zone partitioning: Split the world into regions and manage each one separately. The loading screens between towns and hunting grounds, the same hunting ground split into "Channel 1" and "Channel 2," the servers you picked on the selection screen, like Lineage's "Deporoju" or "Kenrauhel." All of these existed to divide players into numbers the dictator could handle at once.
• Area of Interest (AOI): Even within the same region, you only receive updates about entities within a certain range around you. There's no need to tell me what someone on the far side of town is doing. Whatever lies outside my view is treated, at least as far as my client is concerned, as if it doesn't exist.

No matter how much you shrink the workload with zones and AOI, an MMORPG server still has to process a huge number of entities every single tick.

Part of why Lineage's skill system was relatively simple was the era itself, but a bigger reason was likely that the servers simply couldn't handle complex attack and hit calculations. Above all, the servers of Lineage's heyday had less computing power than today's smartphones. So they likely had no choice but to push the tick rate as low as possible and keep hit detection simple. I'm not an NC developer, so this may not be fact, but that's what the era was like.

I've actually built MMORPG servers on top of Photon Fusion and FishNet. So if you ask me, "Could you build Lineage's massive mob-style siege wars with netcode libraries like these?" my answer is:

"Yes, but it gets very expensive."

The reason is generality. These libraries have to handle both FPS games and MMORPGs, so they ship with the requirements of the most demanding genre baked in as the default. Every networked object records its state every tick and carries a history for prediction and resimulation. In a ten-player FPS match, that cost is nothing. In a siege war with hundreds of players crammed onto one screen, it gets multiplied by the headcount.

The character controller (KCC, Kinematic Character Controller) is a prime example. It's a multipurpose controller built to support any genre: slopes, stairs, wall sliding, jumping, knockback. So the collision checks and corrections that run every time a character moves are fairly heavy. Turn on prediction, and the client re-runs several ticks' worth of that work every time the server's correction notice arrives. I was paying, hundreds of times over, for features the game I was building didn't even need.

A general-purpose engine lets you build anything, but in exchange, whatever you build carries a certain amount of dead weight. Maybe what an MMORPG needs isn't a dictator who can do everything, but one who does only what it has to.

In large siege wars, when players crowd together, you've probably seen characters suddenly "pop" into existence late, or taken hits from enemies you couldn't see. That happens when AOI processing falls behind or the server can't push out all the updates. It's no exaggeration to say that the real skill in MMORPG server architecture comes down to how well you carve up the world.

6. Getting Kicked for Speed Hacks: The Dictator's Checkpoint

Client-side prediction hid the lag, but it also opened a door. If the client moves first and reports to the server afterward, what happens when the client falsifies its report?

Many people will remember the speed hacks of the Lineage era, commonly called "accelerators" in Korea. These programs manipulated the PC's sense of time itself to boost movement and attack speed. The client dutifully reports, "I moved this far in one second," but that second has been doctored.

It wasn't a famous game, but in one I used to play called Yeongungmun, there was a strange button-like gadget attached next to the monitors at the PC bang. Mash it, and your character actually moved faster. Only after I learned to program did it click. It was probably a macro device that repeated inputs rapidly, and since the server never checked the interval between movement packets, every single one it sent was accepted as valid movement.

And as everyone remembers, if you used a speed hack, you got kicked. That's the dictator's checkpoint. The server doesn't just look at the result of the client's inputs; it also verifies the interval and timing at which they arrive. If it decides, "This character's movement speed can't cover this distance in 0.5 seconds," or, "These inputs are arriving too densely," it cuts the connection without mercy.

This is the true power of the server-authoritative model. The dictator may be slow, but it tolerates no lies about what happens inside its own ledger. When it comes to coordinates and time, the client cannot fool the dictator.

But one question remains. What about the lies told outside the dictator's ledger? Auto-hunting macros that look like perfectly normal input to the server. Wallhacks that secretly peek at information the server already sent. No matter how carefully the dictator audits its ledger, it can't catch these. That's the central topic of the next post.

7. And Even the Dictator Falls

Let's recap. The dictator was slow, so developers stacked lie upon lie.

• My character lives in the future through prediction.
• Other characters live in the past through interpolation.
• Verdicts are handed down by rewinding the past through lag compensation.
• Too many subjects are divided and ruled through zones and AOI.
• Those who falsify the ledger are thrown out at the checkpoint.

All the things we lumped together as "lag": tick control, rubber-banding, teleporting players, unfair deaths behind walls, getting kicked for speed hacks. Every one of them was the sound of these lies creaking.

Yet despite all this sophisticated statecraft, the dictatorship still has a fundamental weakness it hasn't solved.

In the previous post, the horror of Lockstep was "Waiting for player..." One person disconnects and everyone freezes. So what is the horror of the dedicated server? Anyone who has played an MMORPG already knows.

"Connection to the server has been lost."

And a few hours later, the announcement: "The server will be rolled back to [date, time]." That hollow feeling as the item you worked so hard for vanished into thin air.

The dictator monopolizes all truth. Which means when the dictator falls, the truth falls with it. Lockstep crumbled at the betrayal of a single player. With a dedicated server, the death of a single machine stops the entire world.

In the next post, we'll look at where this dictatorship stands today: the 128-tick arms race, the hacks the dictator never managed to catch and the security software forcibly installed on our PCs, and where the bill for all of it is ultimately being sent.

References

• John Carmack, QuakeWorld development notes (.plan, 1996): the origin of client-side prediction
• Gabriel Gambetta, "Fast-Paced Multiplayer" series: prediction, reconciliation, interpolation, and lag compensation explained (gabrielgambetta.com)
• Valve Developer Community, "Source Multiplayer Networking"
• Yahn Bernier, "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization" (GDC 2001)
• Glenn Fiedler, "Snapshot Interpolation" and "State Synchronization" (Gaffer On Games)
• Riot Games, "VALORANT's 128-Tick Servers" (2020)