Hello Cthulhu!

New MUD Book

© Christopher R. Jones, 2003. All rights reserved.


While the software will be developed using C++ and in an object oriented way, actual MUD objects will be represented as a limited number of "templatized" objects. This cuts down on overall memory usage in large MUDs (you can point to the stereotype object instead of having to create a new reference for each item in the game), as well as the total number of objects and hierarchies that need to be created.

There are a number of goals the developer should keep in mind when designing and programming the MUD. In rough order, these are:
  1. MUD concept,
  2. bandwidth utilization,
  3. processing time,
  4. memory footprint,
  5. and persistence.

MUD concept

What kind of multi-user game is being developed? In addition to deciding on a setting, technical design decisions need to be made; depending on what the game is like, and how it is implemented, some design decisions are going to be easier to make (even if not easier to implement). The following are game architecture concepts, in rough order of difficulty to implement.
Moving toward using multimedia, tile, or 3D elements requires more media assets to be created. The greatest development expense in a commerical game relates to the creation of those elements, rather than the actual game code.

This document will examine the creation of a simple multi-user on-line tile-based MUD. A minimal tile-set will be developed as part of the MUD.

Bandwidth utilization

The less bandwidth used, the more users can be connected to the game at one time. While all communication will occur over the Internet, several approaches present themselves as possible solutions:
This game will communicate in near-real time between clients and the server. To minimize bandwidth utilization, the following restrictions will be placed on the protocol:
Messages types will be enumerated later in development and tokenized where possible. All objects in the game will have unique IDs, so a typical message may (syntactically) look like:
<message type> <actor> <target>
Messages may be stacked or concatenated to reduce the total number of transmissions sent. Connections between the client and server will be performed with TCP (to limit out of sequence packets) and will use a single established connection for the duration of the session. Finally, clients will be throttled so that they may send no more than two individual transmissions per second to the server, and no stacked message should exceed 1000 bytes (to accomodate a 1500 MTU).

Processing Time

Massively multi-player games need to process transactions from hundreds or thousands of players at a time. To accomplish this, the systems are designed with a few key features:
Server software should be designed to minimize processing time and push as much appearance processing on the client as possible.

Memory Footprint

Memory isn't as expensive as it once was, but as long as the application is being deployed to a 32-bit PC platform, there is an upper limit of 4 GB. Using a UNIX-like operating system can reduce the total space needed by the operating system, but there are still limits, especially if the database and MUD server must be hosted on the same physical machine.

Minimizing memory utilization by intelligent creation of object instances (ie, only when a PC is nearby, or when a scripted activity is taking place) is a useful strategy at the cost of additional complexity.

In short, the developer shouldn't waste memory and should clean up after himself. Minimizing instance data is key, as is using templates.


This was partially discussed in Processing Time. Strategies for persisting world data include:
The strategy used will be to persist only player characters. Initial world state (locations and numbers of mobs, items, etc.) will be loaded from static data (data that is not modified by in-game activities).

Data may be stored in:
It's imperative that MUD data be able to be manipulated outside the system. Some requirements include:
Flat text files, ISAM, and DBM files can only be manipulated with custom programs. Memory-mapped data files likewise require a custom program, and may not function properly outside the MUD itself (depending on how it was designed). Relational databases allow scripts to be written in SQL and SQL clients to directly view and manipulate the system data, as well as making it very easy to add and remove columns (fields) as code changes. Object and XML databases require a lot more overhead, are generally more expensive, but also can preserve a natural object structure without a lot of additional development time to map the objects to tables.

This system will use a relational database to persist data, as the template structure described above closely matches the table/row/column data model.


The MUD must provide implementations for a large number of requirements, in detail, as well as a few broader requirements. From the broad, high level requirements, the detailed requirements will be derived and enumerated.

The high level requirements include:

Support for multiple users

Communication between users
Providing multple, interesting locations