It should be clear now that for any instance involving data in mud design, there are basically two paradigms for handling the data. One of them is dynamic, flexible, and powerful; the other is simplistic but much easier to use. In understanding these two systems, it helps to understand how muds tend to be architected generally. And to do that, it helps to have a lot of diagrams!

A mud is essentially a server that responds to input from a client, and then makes changes to a database it is holding in memory. It also saves aspects of this database to disk in order to persist elements that are worth persisting. It may also have another, different, database, wherein templates for objects and rooms and other such materials for the environment are stored. We can term these two databases the persistence database[1] and the template database.[2] Calling these databases doesn’t mean to imply that they are actually transactional databases, SQL, Oracle, or anything of the sort. Often they are merely aggregations of text files.

Generally, the server saves data to the persistence database periodically (and maintains a copy in memory for speed, in most cases, though there are some fully disk-based systems). It reads from the persistence database anytime it needs to access data that it does not have in memory—server boot, for example, and perhaps also when individuals log in, items are retrieved from storage, etc. It only reads the template database once, however, at server boot, and uses the information in this database to create objects in the likeness of the templates from then on.

Some mud designs, notably the ones which use aggregated maps and an object-oriented system, conflate the two databases. There is no template database; instead, everything goes into the persistence database. Every object in the game must therefore be a unique creation or be a copy or modified copy of something else in the persistence database. This is, of course, an object-oriented approach—but it’s a memory hog. And even these systems usually have a set of object primitives that you can use basically as templates in the creation of new objects.

For the purposes of discussion, it helps to not conflate these two databases even if your architecture actually does, just so that the relationship between them and other components of your server is clear.

Now, it should be evident that any client-server relationship implies that there’s a part of the server that does nothing but talk to the client. This is often called a packet handler, a nanny, or the network layer. Either way, it’s a very basic component of a mud. So basic, that in fact it’s one of the most similar bits of code from mud to mud. It’s also one of the least understood, generally.

You can think of this network layer as being part of the core engine of a mud. It’s not the only part, however. There’s also a large part of the game code which is similarly generic in that it cares not what the mud visible to the players looks like. It’s the guts of the mud, what handles simple concepts like “here” and “now.” It’s what determines not just the shape of objects, but the fact that there are objects at all. This part of a mud is generally called the driver.

In many muds, the principal role of the driver is to serve as a script execution engine. It isn’t about defining the physics of a given world—rather, it is about defining the rules by which physics can be written. It provides a language and a framework in which the game’s laws of nature can be crafted. Drivers therefore tend to be pretty heavy-duty code, obscure and difficult for most to manage, replete with technical mumbo-jumbo such as compiler theory, interpreted language parsing, memory management, and garbage collection. Few hobbyist programmers mess around with drivers.

Above the driver comes a layer that is far more amenable to modification. This is the portion of the mud that defines the laws of nature: things like what a character is like, what an avatar looks like, what “looking” means. The commonest term for this is mudlib, a term from the LPMud codebase. LPs are the muds with the clearest line between driver and mudlib, and hence make a handy reference point. In the MOO world, LambdaCore is a good example of a mudlib. Writing new mudlibs is hard, and they are few and far between. They provide an interface for the mud designer to craft their own mud on top of the base.

Some mudlibs are written in C++ or C. Some are written in whatever language the driver supports as an embedded scripting language. Drivers themselves are almost never written in the embedded script language for speed and security reasons. What lies above a mudlib can be entirely written in the script language, and indeed may be best done that way. After all, what is above the mudlib is the skin of the mud: the face it presents to the world. And this is the part that you want to be most easily mutable.

The line between driver and mudlib, and the line between mudlib and game-specific code, exist for a very good reason. By replacing a mudlib without having to rewrite the driver, you gain the ability to radically alter the capabilities of a mud with a minimum of fuss. A well-designed mud will allow you to replace niceties such as how time works, what the data structure is for an avatar, and so on, with relative ease. Even Diku muds, which have no formal split, have code files segmented such that making this sort of change is relatively trivial. And of course, the difference between a mudlib and what goes above it is even more critical. Countless muds have been written with a package that supplies essentially a complete driver and mudlib—these many muds are all as different from one another as fingerprints, because ultimately, it’s the data and the custom code above a mudlib that really make it appear different to a user.