How Game Server Architectures Evolved: From Simple HTTP to Seamless MMOs

Mobile, web and PC games share the same core; the difference lies in game type. Below is a detailed breakdown of server architectures.

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

These games use simple HTTP servers because player interaction is minimal. Login can employ asymmetric encryption (RSA, DH) to generate a per‑session key, after which HTTP requests are RC4‑encrypted. Game data is stored in a single MySQL or MongoDB instance with optional Redis caching. Clients poll the server every 15 seconds for notifications, extending the interval when idle.

Type 2: First‑generation game server (1978)

The first MUD, MUD1 , was created in 1978 and spread via ARPANET. Its open‑source descendants, such as MudOS (1991), were written in C, used a single‑threaded non‑blocking socket model, and employed the LPC scripting language to define rooms, NPCs, and quests. Players connected via Telnet, and user data was kept in files loaded into memory, with periodic disk writes.

Type 3: Second‑generation game server (2003)

As games became fully graphical, file‑based storage proved insufficient, prompting a shift to databases (MySQL, etc.) and the replacement of LPC with Python or Lua scripts. Single‑threaded logic became a bottleneck, leading to world partitioning, database front‑end proxies (DB Proxy), and the introduction of a gateway (Gate) to handle session routing.

Type 4: Third‑generation game server (2007)

Seamless world maps required dividing the world into zones managed by Node servers, overseen by a NodeMaster and a World manager. Players crossing zone boundaries are served by multiple nodes until fully transferred. Dynamic load balancing adjusts node boundaries based on hotspot detection, either by moving zones between nodes or by a grid‑based redistribution.

Type 5: Battle.net game servers

These servers use a global architecture with matchmaking, host selection, and P2P connections aided by STUN. When direct P2P fails, a forward server relays traffic. Result integrity is ensured via a voting mechanism where clients compute outcomes independently and the server reconciles discrepancies.

Type 6: Casual game servers

Similar to Battle.net, they employ a full‑zone architecture with dedicated room and game servers. User data is split into base data and per‑game data, with token‑based read/write access to handle concurrent sessions across devices.

Object movement: Managing player transitions between nodes.

Data broadcasting: Nodes tag users for targeted broadcasts via an Object Master.

Object messaging: Direct messages to users via the Object service.

Friend chat: Handled through the Object Master.

Type 7: Modern action online games

Combining action combat with RPG town and dungeon mechanics, these games run a main RPG server plus separate dungeon servers, keeping sub‑instances small (≤8 players) for low latency and high responsiveness.

After many architectural shifts, developers must decide whether to continue traditional methods or adopt newer, more modular approaches, considering scalability, development cost, and future challenges.

Source: Wei Yixiao URL: http://www.skywind.me/blog/archives/1265