How RuneScape Ran a Multiplayer RPG Over 56k Dial-Up

An Engineering Marvel Born of Necessity

The internet of 2004 was nothing like today. A 56k dial-up modem topped out at roughly 7KB per second under ideal conditions — and that's before accounting for high latency and unstable connections. Yet RuneScape, a browser-based massively multiplayer RPG, somehow managed to pack thousands of players into a single persistent world under exactly these constraints.

According to an in-depth Reddit discussion, much of RuneScape's early success came down to its ruthlessly efficient network communication design. The thread's central insight can be summed up in one sentence: almost nothing was wasted. Every packet was compressed to the minimum possible byte count, and every piece of information was packed to its limit.

Even Encryption Wasn't Allowed to Bloat the Data

Nothing illustrates this network optimization philosophy better than how RuneScape handled encryption.

Encryption typically introduces overhead — ciphertext is often larger than plaintext. But RuneScape's designers made a clever trade-off: they used a 1-to-1 byte substitution cipher. The encrypted data was exactly the same size as the unencrypted data — zero expansion.

In an era where bandwidth was measured in bytes, this mattered enormously. When your entire gaming experience depended on a phone line that could drop at any moment, every extra byte was a luxury you couldn't afford. That restraint — refusing to let even encryption grow the data — was a quintessential product of the engineering constraints of the time. It wasn't that they didn't want to do things more "by the book"; there simply was no room.

The Spaghetti Code Debate

An interesting twist in the discussion: many veteran players pointed out that RuneScape was notorious for its "spaghetti code" — especially in versions predating 2007. So someone quipped that calling RuneScape "efficiently written" felt almost like a joke.

This sparked a fascinating debate about the relationship between code quality and runtime performance — one worth every engineer's attention.

Efficiency and Maintainability Are Two Different Dimensions

A consensus emerged among commenters: "spaghetti" describes how code is organized, not how efficiently it runs.

Code that is structurally chaotic and difficult to read can still be extremely performant at runtime. The problem isn't that it runs slowly — it's that building new features on top of it becomes painfully difficult and slow. As one commenter put it perfectly:

"Spaghetti code can still run efficiently — it's just very inefficient to work with."

Another added: "It works fine until it breaks, and when it does, you're done for."

Does Efficiency Have to Come at the Cost of Readability?

Here's where the most valuable disagreement in the thread emerged.

One camp argued that more efficient code tends to naturally trend toward spaghetti — that readability is usually the price of performance, especially with the tools available decades ago.

But another camp pushed back hard, calling this a long-standing "myth." Real performance, they argued, comes first from good design — design that doesn't strangle performance — and then from avoiding performance traps: poor algorithms, heavy scripting in hot loops, excessive memory allocation, and bad memory access patterns. "The idea that fast code has to be unreadable was never true."

A more balanced voice ultimately bridged the two sides: it's a spectrum. 99.9% of performance comes from good design, but there's always "that last drop" you can only squeeze out with more complex code. The classic example: Quake's famous Fast Inverse Square Root algorithm — that mysterious magic number and cryptic bit manipulation, written purely for extreme performance and nearly impossible to read at face value.

RuneScape's Bizarre Side Effects

This code — built for efficiency and rapid iteration — also produced some gloriously absurd gameplay bugs that veteran players still talk about today:

• Poison didn't work on cows — because the damage check and the cow's "moo" animation happened in the same server tick, and they cancelled each other out.
• Certain enemies only dropped proper loot after you used a ball of wool on a kitten.
• Desert environmental damage was accidentally negated — because a completely unrelated quest was added that checked every player's position every 15 seconds, which overrode the desert damage logic.

These absurd chain reactions are textbook symptoms of tightly coupled systems — a change in one place producing completely unrelated behavior somewhere else. They're the most vivid footnote imaginable to what "spaghetti code" actually means in practice.

What This Means for Game Developers Today

RuneScape's story remains worth revisiting 20 years later because it distills a timeless software engineering trade-off.

Under extreme resource constraints, engineers were forced into radical optimization choices — 1-to-1 substitution encryption, zero-waste communication protocols. Those choices made the product possible, while also planting the seeds of future maintenance nightmares. Today, with near-unlimited bandwidth and compute, it's easy to lose that byte-level discipline entirely.

But that debate about code quality reminds us: performance and maintainability are not inherently at odds. Truly excellent engineering starts with good architecture, then precisely extracts performance where it's genuinely needed — rather than using chaos as an excuse for efficiency.

RuneScape's ability to run a multiplayer online game over 56k dial-up wasn't built on disorder. It was built on a profound respect for every single byte, under the most extreme constraints imaginable.