As this quickly gets tangled, the easy way to think of it is the three tiers of storage: world, objects, and avatars. It is then easy to trace the evolution of mud codebases as they gradually move from persisting only the world, to persisting the world and also avatars, then also persisting some objects, and lastly, saving what we term world state, which is all data in the virtual environment.

The first thing worth noting here is that some of the earliest muds did not provide persistence of the avatars. Today this is taken for granted, but some of the earliest muds were in fact often little more than session-based scavenger hunts. You can see the remnants of this style of design in the requirement that you bring treasure in an AberMUD to the “well” at the center of the map. This design was likely inspired by the original Zork, wherein you scored points by placing found treasures in the trophy case in the little white house. The world itself is drawn from a static database, and therefore could technically be said to not persist at all, but merely be recreated anew at every time the server boots. In other words, the world data is instantiated from a template.

As avatar persistence became more important, we came to muds like the (extremely large) family of DikuMUDs.[1] In these muds, avatar advancement and development is the sole point of the activity—they are goal-oriented experiences based around achieving arbitrary levels and slaying monsters. This also requires the storage of specific other items, those carried by avatars as they go about their business: the part of the profile termed “equipment.” The world is still drawn from a static template database, as are in fact the monsters and swords and other items, but now text flat files are maintained of characters (the avatar’s tangible attributes and profile). The profile eventually expanded, in some muds, to cover objects that were not actually part of the avatar in any way, such as the avatar’s corpse, or specific objects located in special rooms termed lockers, or rooms tied to the avatar (instances of what we’d call player housing). Given time, dynamic elements would be added to Diku-derived muds in that online map building tools, commonly termed OLC, would be added to the stock code distributions. However, Dikus had already been leapfrogged by that time by two other codebases: LP and MUSH.

In LP and MUSH systems, the world is no longer a static database. Instead, it is a dynamic entity; rooms in these systems are actually code objects and can be modified on the fly; this can be termed an aggregated world as opposed to a template-driven world. For various reasons, MUSHes tend to be used as social spaces whereas the commonest use of an LP is to attempt to emulate the play mechanics on a Diku. However, in both cases the ability to build is generally restricted: even though the code architecture allows free creation of objects, new object classes, and new rooms on the fly, only certain players are given permission to do so. Hence, they offer a less dynamic environment than more evolved codebases.

Said more evolved codebase is called MOO, for “mud, object-oriented.” MOOs allow any user whatsoever to write code objects, and there code objects make up the map, the objects, and yes, even the avatars in the space—on a MOO, any user can actually write a new player class that redefines the nature of the tangible attributes of an avatar.[2] Absolutely everything is persisted to the database.

This is obviously the sine qua non of virtual spaces: complete freedom to rewrite the digital space at any time, with every action persisting until changed. But it also reveals the key problems of world-state muds: database bloat and content approval. With the ongoing additions of new objects that all must be persisted, the amount of data persisted continues to increase[3]—and worse, all the code there means that likely every object must be covered by an update loop in order to keep cycling through the code that it may be executing. This leads to lag, which is the slang term for slowdowns in the virtual space. On many MOOs, you are greeted by a message giving you the current loop time for the mud! Flexibility comes at a price, and many muds back away from full world-state simply to minimize lag and save hard drive space and memory footprint.

The other problem is whether all that content is worth it at all. If you are running an environment that you hope to make themed or fictionally consistent, allowing free content creation by any user is disastrous. The cost of vetting every piece of user building quickly grows prohibitive. Hence many muds back away from user building in order to maintain creative control; Ultima Online opted to allow building only with fairly large and complex pieces so that the designers could be ensured of a somewhat reasonable aesthetic in the world. It did, however, persist every single rabbit and sword left on the ground and scrap of cloth forgotten at the bottom of some chest—arguably, for no good reason at all.

Muds which have this high degree of persistence actually permit the rules of the environment to be rewritten on the fly; the only codebase to make this clear is LPMuds, where there is a division by convention between the mudlib or core game rules (which are dynamic) and the game objects (which are also dynamic).

All of the above history should make it clear that there are solid reasons to choose not to make what one would expect is a “true” persistent world. Well after the development of MOO, many codebases continue to be created which offer quite a great deal less flexibility. Similarly, Diku-derived muds, with their simplistic template-based system, are more popular for budding builders than the more complex object-oriented systems. One should not be snobbish about these differences in architecture, but instead should evaluate the options based on what one seeks to provide in the space they plan to run. Then design accordingly.