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

Type 1: Card/Runner Weak‑Interaction Servers – Because player interaction is minimal, these games use simple HTTP servers, RSA/DH for login key exchange, RC4 for request encryption, and a single MySQL or MongoDB instance with optional Redis caching. Clients poll the server every few seconds for notifications.

These architectures are sufficient for simple card or endless‑runner games where logic is straightforward and real‑time player‑to‑player combat is unnecessary.

Type 2: First‑Generation Game Servers (1978) – The first MUD, MUD1 , was written by Roy Trubshaw and later expanded on ARPANET. Its open‑source descendants, such as MudOS (1991), were built in C, used a single‑threaded non‑blocking socket model, and introduced the LPC scripting language for world definition. Players connected via Telnet, and user data was stored in flat files loaded into memory.

Type 3: Second‑Generation Game Servers (2003) – With the rise of graphical MMORPGs, the monolithic MUDOS model became a bottleneck. Data was moved from files to databases, DB proxies were introduced to reduce load, and a dedicated gateway (Gate/Session) handled network connections while backend game servers focused on game logic. This three‑tier model (gateway → game server → DB) became the de‑facto standard.

Dynamic load balancing and service splitting continued to evolve, leading to more granular architectures.

Type 4: Third‑Generation Game Servers (2007 onward) – Seamless‑world MMOs introduced node servers that each manage a region of the map, overseen by a NodeMaster and a World layer for continent‑level coordination. Players crossing region borders are served by multiple nodes until they fully transition. Dynamic load balancing is achieved either by moving node boundaries or by a grid‑based scheme that migrates whole grid cells between nodes.

Although this architecture can support many more concurrent users, ultimate limits are still bound by network bandwidth and client rendering capabilities.

Type 5: Battle.net‑Style Servers – Designed for fast‑paced, small‑team games (typically ≤8 players). A matchmaking service creates or joins matches, selects a host, and uses P2P connections aided by STUN/relay servers. To ensure fairness, clients compute game results locally and submit them to the server, which resolves discrepancies via voting and logs suspicious behavior.

Type 7: Casual Game Servers – Similar to Battle.net in using a full‑zone architecture, but adds dedicated room servers and separates basic user data from per‑game data. Token‑based read/write locks ensure consistency when the same account plays multiple games simultaneously.

Type 8: Modern Action MMOs – Combine action‑game responsiveness with RPG‑style towns and dungeons. A hybrid backend consists of an RPG server for persistent world state and a separate instance server for small‑scale, real‑time action instances (typically ≤8 players), delivering both longevity and fast combat.

Overall, the article demonstrates how game server architectures have continuously split and specialized from the original MUDOS model to meet the scaling, latency, and gameplay demands of successive generations of online games.

Welcome to ArchDigest – your daily source for heavyweight architecture articles covering high‑availability, high‑performance, big data, machine learning, and more.