The Secret Behind Old MMO 10,000-Player Wars

The gate is packed.

Skill effects stack. Nameplates, health bars, and damage numbers pour across the screen. A rider pushes in from the left. Someone drops and revives. The national channel fills with “gather,” “push,” “left side.” The frame rate falls into single digits. The characters still move. Skills still fire. The fight still resolves.

Anyone who played a large-scale PvP game more than a decade ago has seen this. How did the server handle it? Thousands of players moving, attacking, dying, chatting. If the server calculated every view, every angle, every effect, every player’s screen, no machine of that era could carry it.

It did not calculate every view.

Old MMOs survived massive battles by splitting the world, filtering messages, and trusting the player’s computer to draw the picture. The server acted as referee and broadcaster. It decided who hit whom, who died, who got the reward. Then it told the right people the right amount of information. The client turned that into motion, light, and noise.

Raw power was not the answer. They survived by refusing to simulate everything, send everything, or draw everything.

One shard, many machines

Start with a word that gets blurred in old forum arguments: shard.

A shard is a server. In practice, it is often a cluster of servers pretending to be one world. Giant Interactive’s 2007 prospectus for Zheng Tu described multiple servers working together to carry a single shard. The same document said a shard could support up to 40,000 players. A later technical cooperation piece from 2009 claimed 43,000 concurrent users on one shard.

That number did not mean 43,000 people stood on one map. It meant the whole world: ten kingdoms, many maps, dungeons, cities, chat channels, auctions, mail. The work was divided.

A player grinding monsters in Zhao did not need every position and skill message from a player in Qi. The two kingdoms might use the same city map, the same terrain files, the same building models. The live characters, monsters, drops, and combat states could be maintained separately.

When a player crossed from one map to another, responsibility moved. The old scene server stopped handling that character. The new scene server took over its position and state. Both sides had to agree on who owned the character during the handoff. If they did not, the character might be attacked twice, or not at all.

This is the first layer of the answer: a world was not one machine. It was a group of machines with a shared world model and separate local responsibilities.

The server keeps rules. The client draws.

A common mistake is to imagine the server rendering every player’s screen. It did not.

Models, textures, animations, and effects lived on the player’s computer. The server kept the authoritative state: who was where, who was alive, what buffs were active, which actions were legal. Ryzom’s developers once published a network design that separated local static resources from dynamic properties. Terrain and buildings were local. Position, facing, and animation state were synchronized.

Suppose player A uses a skill on player B. Twenty people stand nearby. All twenty can watch the same attack from different camera angles. The damage result does not need to be recalculated twenty times.

The server checks the request. Is A alive? Does A have the skill? Does A have enough resource? Is B still in range? If the request passes, the server applies the game rules, updates the relevant states, and decides who needs to know what changed.

The client can play a wind-up animation before the server responds. That animation does not prove the attack landed. The client says, “I want to attack.” The server says, “Let me check.” Only then does the state change.

The server is the judge. The client is the projector.

What one attack actually costs

Take the same example. A attacks B.

The client sends a request: character A wants to use skill S on character B. The server identifies the connection, checks A’s state, checks the skill, checks range, checks line of sight if the game uses it. If everything passes, the server calculates hit or miss, damage, resource cost, status effects, and death if health reaches zero.

Then it must synchronize the result.

Not every result goes to every client in the same form. B needs to know health changed. A needs to know the skill connected and what it cost. Nearby observers may need to see an animation, a hit reaction, a floating damage number. They may not need the exact combat log.

A death is different. If B dies, nearby players need to know. A corpse that still looks alive changes how people choose targets and judge the fight. A normal hit is less urgent. A displacement is different again. If B blinks or charges, the new position affects distance and collision for everyone nearby.

So the server splits the event. The rule result is one thing. The presentation message is another. The audience is a third.

When the crowd is already there

Area-of-interest systems help when players are spread out. They do less when everyone is stacked on the same gate.

Tencent’s 2018 Mobile Game Technical Review Standard and Practice Cases includes a chapter on Yulong Zai Tian Mobile. On printed page 159, it describes skill synchronization in a crowded scene.

The rules are specific:

• Death effects broadcast to viewers in range.

• Non-death effects go to the attacker and the victim.

• Other observers get health by querying when needed.

• Non-movement skills, once the crowd passes a threshold, go to only some receivers, including the victim.

• Movement skills still broadcast to viewers in range.

The reasons are practical.

Death must spread because it changes the battlefield. Movement must spread because position changes distance. A normal hit can be trimmed because a bystander does not always need every point of health in real time.

Back to A hitting B. A and B need the result. The crowd may need only a slice. If B dies, the slice gets wider. If B is merely scratched, the slice can be narrow.

The server is still in the same crowded scene. It is still handling the same fight. It has simply changed who receives which message.

Movement without a message per frame

If the server sent every position for every character, the network would drown. Clients fill the gaps.

The client receives two positions with timestamps. It draws the character between them. This is interpolation. Valve’s article on client-server synchronization in game protocol design explains the idea. If a character is at position 0 at one moment and position 1 one hundred milliseconds later, the client can draw 0.2, 0.4, 0.6, 0.8 without the server sending those intermediate points.

The cost is slight delay. The player sees a version of the past, smoothed into motion.

For the player’s own character, delay feels worse. The client can move the character immediately using known rules, then wait for the server to confirm or correct. This is prediction. Prediction guesses what will happen. Interpolation fills in what has already happened.

When prediction and server state disagree, the client corrects. The character may snap back. Network jitter makes the snap worse. The player notices. The server did not send every frame. The client guessed, and sometimes guessed wrong.

How the server finds the right people

Even after the client handles drawing, the server must decide who gets each update.

The common tool is AOI: area of interest. The server filters objects by location. People far away from a change do not receive it.

One implementation divides the map into a grid. To find characters near A, the server looks up A’s cell, finds the cells that overlap the query radius, and checks the characters inside. It does not scan the whole world.

The grid only works if cell size and query radius match. A large skill may cross many cells. A large object may need boundary handling. The number of cells to check changes with the range.

When a character enters another player’s view, the client needs enough information to draw it. After that, only changes need to be sent. When the character leaves view, the client removes it.

This explains why charging into a crowd can feel worse than standing in one. The first moment brings a burst of new objects, new nameplates, new models, new effects. Average traffic over a long fight does not describe that spike.

The grid reduces search. It does not make a dense crowd free. Two thousand players in one small area still occupy the nearby cells. The candidate list is still long.

The bandwidth bill

A rough calculation shows why receiver count matters.

Let N be concurrent players. Let each player produce f state records per second. Let each record go to K observers on average. Let each encoded record be b bytes. The total outbound payload for that record type is approximately:

N × f × K × b

Take N = 10,000, f = 10, K = 50, b = 40. The total is about 200 MB/s, or 1.6 Gbit/s. Per client, that is about 20 kB/s for this record type.

Now send every record to all other 9,999 players. The same assumptions produce nearly 40 GB/s.

The difference is the audience.

This simplified math ignores monsters, chat, protocol headers, retransmissions, and new objects entering view. Real traffic adds all of that. Different properties update at different rates. A distant character can receive fewer updates. A cosmetic change can wait. A position update cannot wait forever.

Ryzom’s developer notes describe distance, property changes, and send budgets working together. The real total is a sum of many update rules, not one average. The point still stands: a server survives by choosing receivers.

Batching, compression, and one result with many animations

Once the receiver list is smaller, the server can still reduce packet overhead.

Tencent’s handbook, printed page 158, mentions aggregation and compression. Messages wait until they reach a size or time threshold, then go out together. Urgent messages keep a direct path.

Aggregation solves fragmentation. Ten small messages each pay header and queue costs. One larger message spreads those costs. Compression uses repeated content to reduce bytes. The two are not the same. An aggregated message is still split into packets by the transport protocol.

Waiting adds delay. Compression costs CPU. A critical state change and a cosmetic detail should not share the same schedule. That is why the handbook keeps a real-time channel.

Page 159 adds another layer: one server skill result can support multiple client-side animation segments. A continuous attack animation can play out on the client. Whether the server resolves each segment depends on the skill rules. A flashy sword arc does not automatically become an equal number of server calculations.

The animation can be rich. The server result can be one event.

The client can also draw less

Network load is only one side. The player’s computer has limits too.

A 2010 update note for Zheng Tu 2 fixed issues where effects still appeared after effects were disabled, and where some summoned objects were not hidden in cinematic mode. Turning off effects reduces client drawing load. To reduce network traffic, the server must also send fewer messages.

For characters that are drawn, resources can be reused. Dozens of characters wearing the same equipment do not need dozens of copies of the same model and texture. If conditions allow, rendering can batch objects to reduce per-object submission costs.

Culling removes objects that do not need to be drawn. This matches the Yulong Zai Tian 2012 interview’s mentions of shared resources, batch rendering, and dynamic culling.

Differences in animation, material, and transparent effects limit batching. Nameplates, damage numbers, health bars, and translucent skill effects add cost. A screen with dozens of characters and heavy effects can be harder to draw than a screen with more characters and effects turned off.

A screenshot’s headcount does not tell you why the frame rate dropped.

Connections, chat, and the database

Reducing messages is not enough if the processes that send and receive them are saturated.

Tencent’s mobile handbook records a network entrance redesign. In the old architecture, scene services were bound to a small number of connection processes. In the improved design, the connection cluster was decoupled from the scene service, with an intermediate service forwarding messages.

The problem was receive and send capacity. A scene could still calculate combat, but its few connection processes were busy. Adding machines for other maps did not help those busy entrances. Separating the connection layer let more connection processes share the load.

Chat can be separated too. Chat cares about channels and membership, not damage resolution. Zheng Tu’s official controls distinguish regional, party, national, and guild channels. A party message routes to party members. It does not join every combat check.

World chat reaches many more receivers. That broadcast cost can be assigned to a dedicated service. Even then, a message to five people and a message to ten thousand people are different jobs.

The database cannot write every step.

Live character state can sit in memory. Moving from one coordinate to the next changes the running state. It does not require a database transaction for every displayed frame.

That memory state still needs to be saved so a character can log back in or recover after a failure. Tibia’s developers described loading character data from files at login. Databases and files can both handle persistence. The key is the save and recovery rule.

Walking position and property need different rules. Skipping a mid-step save may change where a character stands after a crash. A trade that deducts money but fails to deliver an item breaks player property.

Patrick Wyatt’s 2012 talk on reliable online game services used a gold transfer between players to discuss transactions and duplicate requests. A retried request must not create a second payment. High-frequency state can advance in memory. Durable saves follow business rules. Batch saves reduce cost. Unsaved changes still need a recovery plan.

Why the war still lags

Client drawing, network transport, and server resolution each have ceilings. Players feel lag as one thing. The cause can be in different places.

The camera stutters and the interface feels heavy: check client drawing and resource preparation. Culling, resource reuse, and effect reduction may help.

The world still moves, but actions take a long time to resolve: check network transport, queues, and server processing. Connection decoupling, send scheduling, and message batching may help.

Many players gather and everything slows together: check hotspot scene computation or concentrated broadcasts. Scene resource placement and reduced propagation may help.

A trade completes with uncertain state: check request retries, persistence, and recovery. Transaction rules and duplicate prevention matter.

When requests arrive faster than a scene can process them, unfinished work queues. The server can keep connections alive while skill results return later and later. A world that holds many players can still hit a local ceiling.

EVE’s developers said in 2010 that a single solar system’s work could not be split across multiple CPU cores. Adding nodes helped other systems and services. A busy system had its own limit.

Later, EVE used time dilation. Under load, game time slows. The server reduces the amount of game behavior it must advance per real second. By 2012, the developers reported the system running in live conditions.

Time dilation trades a slower battle rhythm for continued processing. The overall world can be large. A local battle can still reach its ceiling.

Back to the gate

The gate is still packed.

A attacks B. The server checks the request, resolves the hit, updates health, and handles death if health reaches zero. Nearby players receive what they need. Some receive less. The client plays the animation, draws the crowd, fills the gaps between positions, and hides what does not need to be shown.

The old MMO did not simulate every player’s view. It split the world into shards, scenes, and areas of interest. It sorted messages by type and audience. It let clients interpolate, predict, batch, compress, cull, and reuse. It kept the rules on the server and the picture on the player’s machine.

That is how a crowd of thousands could stand at the same gate. The server never saw the full picture. It saw the rules, the receivers, and the next necessary message. The rest was drawn locally, one computer at a time.