From MUD1 to Modern MMO: Evolution of Game Server Architectures

Type 1: Card, Runner and Other Low‑Interaction Services

Because these games have weak interaction, they can rely on simple HTTP servers: players exchange offline data, update leaderboards, and buy items. Login can use asymmetric encryption (RSA, DH) to generate a per‑session key, after which HTTP requests are encrypted with RC4. Game data is stored in a single MySQL or MongoDB instance, optionally cached with Redis. Notifications are handled by client polling that adapts its interval based on activity. This lightweight stack is sufficient for many card or endless‑runner titles.

Type 2: First‑Generation Game Server (1978)

In 1978 Roy Trubshaw at the University of Essex created the world’s first MUD, MUD1, which later spread via ARPANET. Its open‑source descendants, such as MudOS (1991), became the foundation for many early online games. MudOS was written in C, used a single‑threaded non‑blocking socket model, and updated all objects once per second. The game world was organized into rooms linked by cardinal directions, described with the LPC scripting language, allowing advanced players (wizards) to extend content. User data was kept in files loaded into memory, with periodic disk writes, supporting thousands of concurrent users.

Type 3: Second‑Generation Game Server (2003)

After 2000, games moved from text to full graphics, exposing new bottlenecks: frequent file I/O for user data and growing online populations. Data was migrated to databases, and servers were rewritten in C with scripting in Python or Lua. Single‑threaded logic soon became a performance limit, prompting world‑splitting architectures. Database front‑end proxies (DB Proxy) were introduced to cache and translate high‑level operations into concrete queries, reducing load on the database. To handle frequent scene changes and avoid state inconsistencies, a dedicated gateway service (Gate, Session, or LinkSvr) was added, centralizing client connections and routing traffic to backend game servers. Further decomposition led to multi‑layered models with separate services for chat, trading, web APIs, and sharded databases, offering high scalability but increasing system complexity and development cost.

These architectures have proven successful for large‑scale MMORPGs, but each additional layer multiplies state‑machine complexity, raising development and debugging costs. Teams must balance architectural sophistication with project timelines and expected player counts to ensure a viable return on investment.