Evolution of Game Server Architectures: From Early MUDs to Modern Action MMOs

Although mobile, web, and PC games differ in platform, their core server requirements depend on game type; weak‑interaction titles such as card games or endless runners can run on simple HTTP servers, using RSA/DH for login, RC4 for request encryption, a single MySQL or MongoDB instance with optional Redis caching, and periodic client polling for notifications.

Type 2 describes the first generation of game servers (1978) exemplified by the MUD1 program and its C‑based successor MUDOS, which used a single‑threaded non‑blocking socket model, LPC scripting for world definition, telnet client connections, and file‑based user data, laying the groundwork for early MMORPGs.

Type 3 marks the second generation (around 2003) where increasing player counts and data volume forced a move from flat files to databases, replacement of LPC with Python or Lua scripts, and the introduction of a DB proxy layer and a dedicated gateway (Gate/Session/LinkSvr) to separate network handling from game logic.

Type 4 introduces the third generation (circa 2007) with seamless world maps; the world is partitioned into regions managed by Node servers under a NodeMaster, with a higher‑level World service, and dynamic load balancing achieved either by periodically reshaping node boundaries or by grid‑based migration of map cells.

Type 5 covers Battle.net‑style servers where small matches (typically ≤8 players) use a host‑centric P2P model, assisted by STUN/forwarding servers, and employ voting mechanisms to resolve divergent client calculations and deter cheating.

Type 6 discusses casual game servers that adopt a full‑zone architecture with separate room servers and token‑based read/write control to handle concurrent gameplay across multiple devices while preserving data consistency.

Type 7 describes modern action MMOs that blend RPG and action gameplay, using a hybrid architecture of an RPG backend plus dedicated instance servers for action‑heavy raids, enabling real‑time combat for small groups within a larger persistent world.

The article concludes that each architectural shift addresses scalability, latency, and development complexity, and that future server designs will continue to balance performance with maintainability as player expectations evolve.