Codebase

Related to the idea of genre is that of codebases. To explain how the two are connected requires a short introduction to some principles of virtual world server architecture.

Codebases came about because much of the work that needs to be done to create a virtual world can be re-used when creating other virtual worlds. How much, exactly, depends on the codebase. Codebases are mainly associated with the third age of virtual worlds, although the codebase principle was used as early as MUD1 and there are ongoing attempts to create similar solutions for graphical virtual worlds (Asheron’s Call was designed with this idea in mind ¹).

The most basic part of the software that runs a virtual world is its driver. This has all the usual routines that appear in any sophisticated interpreter, handling things like memory management, parsing, and data structures. Coupled with these are more operating systems-like material such as input/output queuing, time-outs, packet handling, and so on. The result is that the driver can make two foundation concepts available to higher levels of the program: the existence of entities from which the virtual world is to be constructed (for example, objects) and the association of input/output with some of those entities (for example, players).

Above this layer comes what (for historical reasons) is known as the mudlib ². The mudlib defines the physics of a virtual world, which will include things such as mass/weight, timers, movement, and communication, along with higher concepts such as (in a game context) magic and combat mechanisms.

The layer above the mudlib is the world definition. Using the model set up by the physics, world-specific concepts are added. New functionality is associated with these objects that is also consequent on the physics (although not necessarily defined directly by it). The world definition is fully descriptive: It can be used to create multiple incarnations of the world.

Finally, there is the particular instantiation of the world. Actual data items define this individual world, differentiating it from all the worlds that could possibly be defined.

Here’s an example to show how this all hangs together. Suppose we have a world in which (among many other things) a silver key opens a silver casket. The driver defines the concepts of: discrete objects; actions that manipulate such objects; actors (that is, players) that can affect such actions. The mudlib defines the concept of objects that can contain other objects and the conditions under which this can occur. The world defines the concept of caskets and keys, and how using the right one of the latter on one of the former can cause that casket to open. The world instantiation includes an explicit representation for object32 (a silver casket) and object19 (a silver key); the state of a silver casket in the instantiated world depends on whether anyone has opened or closed it with a silver key.

Okay, so these are the various parts of the server:

• Driver

• Mudlib (physics)

• World model

• Instantiation

All codebases must implement these layers, but they don’t have to do it all the same way. Typically, they use a combination of three techniques:

• Hard-code them using a real programming language such as C or C++.

• Soft-code them using a scripting language such as LPC or MUF (Multi-User Forth—used by MUCKs), which is interpreted by the hard code.

• Store them explicitly as data in files that are meaningful to the hard code, the soft code, or both.

How exactly they do this depends on the particular codebase.

Everything that is hard-coded constitutes the engine. For MUSHes and MOOs, the engine is just the driver; for LPMUDs it’s the driver and the mudlib; for DikuMUDs it’s the driver, the mudlib, and the world definition. The advantages of having an engine with higher-level functionality are ease of use and run-time efficiency; the disadvantages are inflexibility and a lack of expressiveness.

Everything that is stored to data files is the database (which may, or may not, be a third-party database with a formal query language and so on). This can be a little confusing, as there can be up to three completely different databases that make up the database:

• Scripting language code

• Templates

• Instantiations

Any or all of these could be used statically (for initialization only) or dynamically (consulted each use, on-the-fly).

Let’s look at these different database forms a little more closely.

A scripting language database consists of the script files that the virtual world needs. For MUSHes, these scripts themselves define the mudlib, the world model, and the world’s instantiation; for LPMUDs, they just define the world model.

A template database contains definitions for objects, from which a world can be constructed. With this kind of set-up, it’s possible to do things like change the behavior of one of the virtual world’s denizens by tinkering with the template from which it was stamped out—you don’t have to change/recompile any code. DikuMUDs use a template database.

An instantiation database (more widely known as a runtime database) stores the state of the instantiated world, specifically those values that persist across server shutdowns and which can’t be generated from either a scripting database or a template database. A good example is player character data, which is usually stowed in a database while the player is not present in the virtual world. Worlds that run continuously will periodically store their entire state in an instantiation database, so they can effect recovery in the event of catastrophic machine failure.

Note that it’s possible for a codebase to incorporate these three databases into one. The object-oriented implementation of MOOs, for example, means that dumping all the data objects (that is, creating a runtime database) automatically dumps all templates and scripts as well, because they are defined as such objects.

Table 1.1 summarizes these differences for a number of codebase families (and, for comparison, some individual virtual worlds). Each component level is described as being code (executed by the computer hardware), script (executed by the code ³), or data (non-executable).

Table 1.1 Codebase Differences

What does any of this have to do with genre?

Well, the way codebases are implemented has an impact on the virtual worlds that they themselves implement. Hard-coded functionality is less flexible but more powerful; soft-coded functionality is quicker to write but slower to run.

Thus, if you wanted a virtual world with a lot of action delivering an intense experience, you’d go for something that favored code (for example, a DikuMUD); if you wanted a virtual world where spontaneity and creativity were important, you’d go for something that favored scripting (for example, a MOO); if you wanted a codebase that had a detailed physics but in a nonstandard setting, you’d go for something that employed code for the mudlib and a scripting language for the world model (for example, an LPMUD).

Very generally, the major codebases ⁴ used for (textual) virtual worlds conform to the following stereotypes:

• DikuMUDs: Adventure-oriented, with a heavy emphasis on combat against computer-controlled foes. They are exciting experiences, but the worlds themselves tend not to change much over time. They mostly have a Fantasy setting, with Science Fiction in distant second place.

• LPMUDs: Also adventure-oriented, but with less emphasis on combat. They are often extended over time. Again, they’re mainly Fantasy, but across a wider range; there are numerous Science Fiction, Horror, and mythological worlds, too.

• MUCKs: Socially oriented, heavily focused on role-playing. These are usually based on some specific work of Fantasy, Science Fiction, or Horror. Those that aren’t often involve original, anthropomorphic animals (furries).

• MUSHes: Socially oriented, mostly focused on role-playing, but occasionally non-gaming in nature. MUSHes tend to have a Science Fiction setting based on books, comics, or movies, with Fantasy some distance behind.

• MOOs: The least games-oriented codebase, responsible for more non-game worlds than all the other codebases put together. Those games it does produce are usually original (rather than derivative) Fantasy that are geared for role-play rather than adventure.

These stereotypes are reinforced by the historical heritages of each codebase. Although it’s possible (for example) to program an exact replica of a MOO in LPC, people who wanted to write a “MOO-like” virtual world would probably just go for a MOO codebase instead. What’s more, people just starting up an LPMUD would probably take someone else’s mudlib as a starting point. Thus, the theme or genre connotations associated with a codebase will tend to be perpetuated as that codebase evolves, meaning that when new versions appear they will usually be refined for their preferred genres ⁵.

Codebases are a common way of categorizing free, text-based virtual worlds (of which there are several thousand); they are not, however, a lot of use in most other circumstances. Almost all graphical virtual worlds, for example, have their own, proprietary codebase. Other means of usefully distinguishing between the different natures of virtual worlds are therefore also commonly employed.