From MUD to Modern MMOs: How Game Server Architecture Evolved

Mobile, web, and PC game servers are essentially the same; the difference lies in the game type.

Type 1: Card, runner and other weak‑interaction servers

Because interaction is weak, players do not need real‑time face‑to‑face PvP; they simply update offline data, calculate rankings, and trade items, so a simple HTTP server is often sufficient.

During login, asymmetric encryption (RSA, DH) can be used. The server generates a hash‑based key from the client UID, timestamp, and its private key, sends it to the client, and both sides communicate over HTTP encrypted with RC4 using that key. The server can recompute the key on each request, eliminating the need to store it.

Each match requests level data, submits results for validation, and stores rewards. A single MySQL or MongoDB instance can serve as the database, with optional Redis caching. For notifications, the client polls the server every 15 seconds, gradually extending the interval if no messages are pending.

This architecture easily supports a strategy or card‑runner game, offering fast development and simple debugging via a browser.

Type 2: First‑generation game server (1978)

In 1978, Roy Trubshaw at the University of Essex created the world’s first MUD program, MUD1, which later spread via ARPANET and inspired many derivatives, including the open‑source MudOS (1991), the ancestor of many online games.

MudOS was written in C and used a single‑threaded non‑blocking socket model to serve all players. The world was organized into “rooms” linked by north, south, east, and west exits, and scripted with the LPC language, allowing advanced players (wizards) to extend the world.

Players connected via Telnet over TCP, issuing text commands such as “go east” or “look a mu”. User data were stored in files and loaded into memory on login; changes were periodically flushed to disk. A single MudOS instance could handle about 4 000 concurrent users.

Type 3: Second‑generation game server (2003)

After 2000, games became fully graphical, increasing file I/O and user‑data load, which strained the original MUDOS architecture. Data were moved from flat files to databases, and servers began to be rewritten in C with scripting in Python or Lua.

To alleviate single‑server bottlenecks, the world was split into multiple servers, and a DB proxy was introduced to cache and translate high‑level operations before reaching the database.

Network gateways (Gate/Session/LinkSvr) were added to centralize client connections, forwarding traffic to backend game servers.

While this model improved scalability, each additional layer increased state‑machine complexity and development difficulty.

Type 4: Third‑generation game server

Since 2007, seamless world maps (e.g., World of Warcraft) became standard for large MMOs. The world is divided into zones managed by Node servers, overseen by a NodeMaster, with a higher‑level World service handling continent‑scale management.

Players at zone borders are served by two Nodes simultaneously until they fully migrate. To reduce cross‑zone traffic, an Object (OBJ) server layer was introduced, handling player‑specific logic, while Gate servers focus solely on network forwarding.

Object movement between Nodes

Data broadcasting via tags

Object‑to‑object messaging

Friend chat routed through OBJ/OBJ‑MASTER

Dynamic load balancing later allowed Nodes to adjust zone boundaries or to migrate fixed‑size grid cells between Nodes.

Grid‑based balancing splits the map into equal cells that can be reassigned to less‑loaded Nodes in real time.

Type 5: Battle.net style server

Battle.net uses a matchmaking server to create or join games, selects a host player, and connects others via P2P (often star topology). STUN assists NAT traversal; if P2P fails, a forwarder relays traffic.

Voice data is mixed on the host and redistributed. Because game state is computed mainly on clients, servers employ a voting mechanism to resolve discrepancies and record suspicious users.

Type 7: Casual game server

Similar to Battle.net but with dedicated game servers and room servers. User data are split into core profile data and per‑game data, with token‑based read/write control to prevent concurrent write conflicts.

Type 8: Modern action‑RPG hybrid server

Action games merged with RPG elements, offering town hubs and instanced dungeons for groups of up to eight players, combining real‑time combat with RPG progression.

In summary, most game server types stem from the progressive decomposition of the original MUDOS architecture into distributed components, forming the second‑, third‑, and later generations described above.

Source: Zhihu, author Wei Yixiao.