The current "accepted best definition" of a game universe for persistent worlds is "sandbox." This means a malleable environment with lots of toys which players can then use to make whatever they want to out of the environment--as much as the game allows, at any rate. The ideal of the designer, then, is to provide a wide array of toys that suit the sort of environment that they intend. There are however many ways to do this, and they all have to do with how the virtual world in question handles data storage. While all virtual worlds must offer a modicum of persistence, there are lots of different levels of persistence to consider, and they all have radically different impact on the overall design.

For the purposes of discussion, one can break persistence into three levels: persistence of the world proper, persistence of avatars and their possessions, and lastly, persistence of items that are not avatars. Properly ordered, the world encompasses the objects that encompass the characters. The very earliest muds had persistence of the world, but lacked persistence of the other two. AberMUDs, for example, were originally scavenger style games wherein the entire world “reset” periodically. There was, therefore, no real way to make a mark on the world within the game’s context. Many of the player-vs-player combat muds do not offer character persistence either: avatars are persisted only in the sense that some of their career statistics for kills might be saved, but essential elements of the avatar such as acquired skills have to be relearned at the start of each match.

The key thread here is that these are session-based games. All that is required for a game to cease being session-based and become a true persistent world is persistence of characters. Note that persistence of the “second layer” (objects that are not characters) is not in fact required; in fact, few games do this, and those that do are termed muds that save world state. World state muds are generally limited to those that allow users to build in the world while the game is running.

In the diagram, you can see that even though there are three layers defined, what we really have is a spectrum, and one on multiple axes at that. It is easy to find examples of muds that make player’s corpses persistent, whilst leaving other types of objects as ephemeral; this because of player outcry when the mud crashes before they have recovered their items from the corpse. You can find many examples of muds wherein the code simply does not offer high degrees of user modifiability of the world, obviating the need for persistence of many elements; and examples of muds where user-created content is commonplace, requiring a high degree of persistence. Likewise, it is easy to find examples of muds which offer the technology sufficient for persisting absolutely everything in the virtual world, but which choose not to do so in order to simplify either database maintenance or the process of approving changes to the world as being fitting with the world’s theme. Some mud codebases, such as LP, rank high on both scales even though in practice they are most often used in a manner consistent with muds of the Diku codebase which is low on the scale. Early LPs did not properly persist characters, in fact![1]