A Spatial Representation of the Virtual World
The heart of a mud is the map: the world the mud represents. This serves as the stage upon which all action takes place. Unlike other forms of virtual communities, like web boards, live chat areas, and so on, muds rely on an attempt to represent virtual space. Elements are arranged in mimicry of geographical relationships. Sometimes, the actual spatiality of the world represented bears no resemblance to natural physics, but the portrayal is nonetheless spatial.
That said, there are still two principal methods of representing and codifying the virtual space within a mud. One of them is arguably better suited to a graphical medium, and the other better suited to text. These two approaches are really all about how the data that makes up the map is segmented. They can be described as a room-based model, in which the map is partitioned into sub-maps which have clear point-to-point exits leading to another “room” located elsewhere; and continuous maps, which do not have said “exit” points, but which instead allow movement from map to map anywhere along the continuous border of the two distinct spaces.
Room-based maps
Text muds were inspired by text adventures, which used a room-based model. In this model, a database entry defines a particular node. The node has exits on it, which are unidirectional connections to another node. Generally, the convention is that exits are reciprocated. These are not actually “exits” of course—the term itself presupposes spatiality when there is none. In fact, what they are is logical links between database entries. In other words, they are hypertext links.
In hypertext, there exists a database entry that is a block of text (and eventually, in more sophisticated systems like the modern World Wide Web, pictures and other elements as well). This entry has something very akin to footnotes that mark certain words as logical linkages to other database entries with different contents. This is a concept that is probably familiar to everyone today, but which was truly alien to most people just ten years ago. Perhaps the best way to explain room-based muds is to think of the Web today, wherein every page links to other pages, but exists as an independent entity. There is no concept of a “geography” of the Web—but only because the links are treated as logical links, rather than as spatial connections. In other words, if your links on your homepage were labeled “north” and “up” then you’d get the illusion of spatiality, at least on your own page. Once you get reciprocal connections from the page you linked to, you have a consistent illusion of spatiality. Taking the exit labeled “south” carries you to another node (whose index number in the database may have absolutely no relevance to its alleged geographical location) which has an exit labeled “north” capable of taking you back to the point where you originated. Presto, an illusion of space.
In hypertext authoring systems, such as Eastgate Systems’ Storyspace, the representation of the logical linkages and database entries is in fact termed a “map.” To the right is a screenshot of the Windows version of Storyspace, showing the logical linkages between boxes containing text. The boxes are called “writing spaces” in hypertext lingo, but in muds they are called rooms. You can see that in Storyspace the linkages are purely logical, and do not imply anything about geographical relationships. But in muds, everything is different—rooms mean a place. This is not a radical invention—it was foreseen by the inventors of hypertext in the late 40’s.1
The tricky thing about a room-based model, despite its insistence on being seen as a spatial representation, is that the nodes do not in fact exist in a location on an overall coordinate space, generally speaking (though there have been many, many text muds that have enforced building practices placing nodes in a known location on an in fact nonexistent coordinate grid). A few muds have enforced coordinate locations for their nodes, particularly those muds that have hybrid systems including coordinate-based wilderness spaces. By and large however, room-based models have no consistent scale. Since nodes can represent spaces of arbitrary size, and exits between nodes need not represent directions per se, room-based maps actually lend themselves towards non-Euclidean geometries. For example, while most muds derived from the Diku code base have hardcoded the available exits to cardinal directions, muds derived from the MUSH and MOO families prefer to have exits with descriptive tags that do not represent spatial relationships—or at least, not cardinal directions, but perhaps other conceptual relationships that are spatial in nature. Containment is a particularly popular metaphor; in Julian Dibbell’s book My Tiny Life he describes his “home base” room as a node located “inside” a television set. The link to the node originates in a virtual living room, but the label used on the exit does not suggest adjacency. This type of exit, and the type of exit that allows you to move “in” and “out” or “towards that building,” are termed contextual exits in the mud community. Interestingly (and getting back at our definition of a mud), even when non-Euclidean geometries are played with, the predominant assumption is that their purpose is spatial representation. Consider this mailing list post by mud designer and MUD-Dev mailing list maintainer J. C. Lawrence:
This is one of the reasons that I like contextual exits so much in addition to the base compass directions (where they apply). Just name something the character can see (or knows) is in some direction, and he will move in that direction. e.g. If he’s in a street and there’s a pub in one side and a store on the other, “pub” takes him one way, and “store” the other.
Further, it also makes it easier to add various forms of disorientation. The character is in a new area, is under a disorientation spell, or is carrying a large lodestone with him? He has no idea of compass directions and any attempt to navigate by compass direction will result in random motion (or at least arbitrary).
One of the implicit advantages of this is that it allows you to later extend your directional command matrix if you decide to make more interesting spaces (such as non-Euclidean) that need their own movement commands as different from the others. It also makes it very easy to extend to orientation support ala “forward”, “back”, “left”, “right”, etc, or say given orbital mechanics, “in”, “out” “retro”, etc.2
In practice of course, all room-based systems can be described via a map very similar to the Storyspace screenshot. Consider Figure 2, which is a picture of the original design notes for a portion of MUD1, laid out by Richard Bartle. As you can see, it looks in many ways similar to a holographic version of the Storyspace interface. This is the way in which players of room-based systems tend to map the spaces they inhabit, and it is an accurate representation. The nodes themselves are written as room names or identifying numbers, and lines are drawn between the nodes that represent the logical links between locations. But the nodes themselves have no size and do not truly abut one another. The link between nodes does not convey any particular sort of distance.
It is not uncommon to see, therefore, cases of map building on text muds wherein the map, when drawn on a rigid grid, folds over itself. On LegendMUD for example (which offers a convenient example because of its mimicry of real-world geography), it takes only six or so rooms to represent crossing the entire Pacific Ocean—yet it also takes six rooms to walk the length of the Abbey of St. Denis, and six to walk the length of the Isle of Dogs in London, and six more to travel from Spain to France. Similarly, you may well move one node to the east, move one south, and head west, but not find yourself on the street where you began, because nodes do not have fixed size on the grid.
Room-based systems are the mainstay of text muds, although several have attempted continuous maps instead. This is largely because the blocks of text in mud descriptions are generally database entries of one sort or another, and are associated with a particular index number—the number of the node. Thus you hear of builders on muds needing “100 room numbers” to build their area. What they mean is 100 unique database entries that create 100 nodes in a room-based system.
Typically nodes are collected in groups, usually authored by a single individual, all the nodes in a set themed together, with commonality in descriptions, creature population, etc. These collections of connected nodes are generally termed either zones or areas based on the nomenclature of the mud in question. This division is largely so that associated data that needs to be used in an area-wide fashion can be applied to all the rooms in the area. A prime example is the name of the geographical region the collection of nodes purports to depict. Thus it is that we hear of mud areas named “the forest of Haon-Dor” or “Midgaard.” The area in this case also has its own database of objects and characters that are found within the environment. In a more sophisticated system, it may be possible to subdivide the area as well—one nomenclature for this is “area” for the complete collection of nodes and “yell zone” or “zone” for the subdivision. A mud that has zones within areas can use them to set boundaries on whether certain events (such as yells, hence the term) are audible, essentially as a form of display culling; or can use them to curtail the automatic AI movement of creatures within the zone.
As a result of these practices, room-based systems usually break naturally into areas that are self-coherent, but the overall maps are rarely coherent across areas. Since authorship of the areas is generally by different people, and muds tend to accrete over time and without a strong central creative vision, mud worlds designed with a room-based model are rarely coherent fictional settings. Instead, they are an odd patchwork of radically different styles and themes. Since object and creature definitions for a given area are generally part and parcel of the area, a deer found in one area may vary wildly from a deer found in another area, even if they are on the same mud. This also leads to standard database procedures, such as resetting the state of creatures on the map, to often be done on a zone-wide basis.3
Another, subtler factor involved here is that zones are generally linked to one another with only a few exits. In other words, room-based models with zone-by-zone building often resemble large-scale versions of a node diagram themselves. The different areas generally only touch at specific single links between nodes that happen to cross area boundaries. These are generally referred to as the entrance to an area, of course. It is rare to find an example of building where even the most basic of geographical principles are observed; two areas featuring empty plains may well abut, but there’s liable to be no linkages between the plains proper, with the only access from one to the other being at the road.
So, nodes have no spatiality, merely relationships to linked nodes. The fact that a node system is used for the granularity of the world map does not, however, preclude spatiality and coordinate systems within a given node. There exist text muds that have made use of coordinate systems within each given mud room, thus allowing a series of spatial relationships between objects that are at the same node. Some mud “wilderness systems”4 are based on similar systems. In a system like that, the purpose of a node is really for culling information: deciding which data needs to be sent to which players. The output of the mud server to a given client is largely based on which node the player’s avatar object happens to be located in.
Since culling is a major concern in the display of graphical scenes, it should be no surprise that room-based systems are alive and well in graphical environments. The Realm, originally developed by Sierra and now run by Codemasters out of Yosemite Studios, for example, used carefully hand-drawn graphical backdrops for every room, but was still essentially a room-based system like any other mud. In a case like this, the pretty pictures substitute for the text description of the room, but everything else is substantially the same. In some of the earliest graphical incarnations such as Illusia,5 this was carried to the extreme that the graphical display was literally a static pre-rendered picture with no dynamic elements whatsoever. If you wanted to know whether another player was in the same space, you had to resort to the mud’s text output.
This was actually a step backward from the level achieved by Habitat back in 1985, which was arguably the first graphical mud, and which also used a room-based system with a side view like The Realm. Habitat was later renamed to WorldsAway and ran on CompuServe for quite some time. In Habitat there was accurate depiction of the characters in the room, and a delightful comics-derived convention was used to display player’s speech: the text bubble. This device, which serves to unify the words spoken by players and the pictures portraying the environment in a very direct manner, was ignored by other mud developers for over a decade, until resurrected by Ultima Online, albeit in substantially different form. Overall, however, it is instructive to put screenshots of BSX muds, Habitat, and The Realm side by side.
Other systems from the same time period as Illusia are more sophisticated. Lyra’s Underlight for example, used a room-based system in which the links between rooms were literally displayed as colored portals hanging on walls. However, each room was a full 3d environment in which other participants in the space could be seen as avatars.
The largest-scale use of a room-based system to date in a graphical environment is probably Verant’s EverQuest. In this mud, entire zones (and that is the term that they use) are essentially rooms, each with its own repop schedule and set of item database entries, etc. The room-based nature of the design is betrayed by the fact that travel from one zone to another must be done by traveling through small chokepoints. This delay is incurred in part so that the geometry of the next zone can be loaded into memory; arguably, it is a design error to allow people to see into the space occupied by the next zone, but then whip the rug out from under them when the zone loads with a significantly different landscape than what they had expected. EverQuest’s reliance on zones is so extreme that they only cull network traffic on a zone basis, which is less, for example, than almost any other 3d based game (in which line of sight and distance are used for culling) and less than what many text muds do with yell zones. Obviously, within each room or zone, the game makes use of a continuous map.
I’ve talked about “culling” here several times. In saying that, I mean the decision made by the server as to what information to send a player. When you are in an IRC channel, there is no culling taking place: everything spoken within the channel goes to you. However, the server is actually handling messages for many other channels simultaneously—it is selectively sending you only the messages that apply to you—that is, the ones for the channel in which you are participating. In other words, what defines an IRC channel is shared experience. The same is true of mud rooms—what defines them is shared experience. There are very real bottom-line consequences to defining the extent of this shared experience, as bandwidth usage rises exponentially depending on how many individuals you wish to have a shared experience together.
The great advantage to areas, zones, and room nodes, of course, is exactly what makes them less convincing at portraying coherent fictional spaces. They are extremely expandable, and it is easy to open a new area, and attach it into the larger map. Since there was no exit there previously, it literally does not matter what may have allegedly existed beyond the mountain range (or other artificial barrier) that served as metaphor for the lack of links in a particular cardinal direction. Thus it is easy to add continents, new areas, backfill into previously built areas, play tricks with areas that move, etc. A notable example of the latter exists on LegendMUD, wherein a traveling carnival moves around the world by the simple expedient of severing the old links between its nodes and the rest of the game, and adding new ones in the new location. A common trick is to make a “boat” move across an ocean by playing similar tricks, changing the links on a time schedule.
Continuous maps
The current trend in more cutting-edge mud development is to move away from room-based models in favor of continuous maps. This means that the assumption of spatiality includes the concept of a 2d or 3d space handled with a Cartesian coordinate system. Depending on the implementation, the dataset for the map may be sparse or dense—meaning, the map may actually have data for every point on the grid, or it may only have data for specific landmarks on the grid.
In general, the latter approach is taken by text-based environments, which essentially dynamically build up descriptions that look just like traditional mud rooms, based on the proximity, visibility, and notability of landmarks and features on the map. In other words, the text descriptions, which are generally of locations for which there is no data, build a description that interpolates data based on nearby landmarks. Movement is still done, generally speaking, in the same manner as it is in a room-based system—the intricacies of moving in an actual continuous space are handled transparently by the server. In fact, the designers of these environments tend to go to great lengths to get their systems to output textual descriptions that are well-written prose, which is quite a difficult task! Few muds have implementors with this level of technical ability, which may be why I do not know of any operating servers that have this level of continuous map. Many muds have implemented Cartesian grids within given rooms, however.
In the graphical world, continuous maps are common. A key difference between room-based graphical systems and continuous systems is the lack of a nodal structure to the map. Perhaps one of the best examples of proto-continuous systems is Meridian 59. At first blush this system is extremely similar to EverQuest, with zones that are independent of one another and a significant delay when crossing a zone boundary as the new zone’s data is cached in. The key difference is conceptual: Meridian 59 was seen as a continuous world by its designers, and therefore any point along the boundary between two zones allowed passage from one zone to the next. In addition, you could actually see the geometry of the landscape in the next zone. The result was a continuous map, but with seams in it where the map was evidently stitched together.
Both Ultima Online and Asheron’s Call use seamless maps, involving some tricky technology to provide server mirroring along the boundaries of separate zones. Zones in this model are something else entirely—an arbitrary chunk of map handled by a given server process (meaning, a given copy of the server program running on a computer). When you physically move on the map from a location handled by one server to a location handled by another, you and all your belongings are copied over to the other server process transparently and instantly. Since zones in both cases divide not along geographical lines but are purely conventions in order to distribute load on a given server process, this means wide-open landscapes and seamless plains. There are frequently artifacts where the mirroring of actions from one server to another is imperfect, but by and large the illusion is good, and the act of moving from one server to another is actually transparent. Asheron’s Call goes UO one better by dynamically shrinking and enlarging the size of the map portion controlled by a given server based on the load on a server process: as a process gets overloaded, it hands off portions of the map (and the players sitting on those portions of the map) to other server processes. This is a very scaleable solution generally termed dynamic load balancing.
Even within continuous map designs, there are multiple ways to go, of course. The basic implementation of a continuous map has a low density of grid points, meaning that it is essentially a grid mosaic of individual spaces. This is generally referred to as a tile-based system. In such a system, every object within the world, including a player, occupies a grid square. This leads to a very clear “gridding” of the world, as if it were put together on a chessboard. It also means that in most cases, buildings and the like are aligned on rigid X and Y axes. In a more advanced 3d environment, the coordinate mesh becomes finer, allowing higher granularity in movement. However, this also complicates problems such as object collision and walking from point to point (particularly if done as part of a pathfinding routine in the server software). Because of this, the abstraction of a low-resolution grid underlying the continuous map is still useful in many ways. One of the most obvious is that the tile set for a particular terrain type can be re-used endlessly everywhere. Examples of tile-based virtual worlds have included Legends of Kesmai, Ultima Online, and Dark Sun Online; of these, only Ultima Online used a continuous map, as opposed to a room-based model. The others were however continuous within the room.
Completely implied by any of these systems is a world map that is a seamless whole. The downside is that it is much more difficult to add new geography into a continuous map system than into a segmented or nodal system. Think of the map in a room-based system as being best represented by Tinkertoys—it is easy to add a new connection point somewhere, even in a direction that is not on the 2d plane (or indeed even into a 4th dimension or some such other non-Euclidean direction) or to remove even a node in the center, and by judicious rearranging of connection points, preserve the overall integrity of the map. However, the best analogue for a continuous map model is a piece of cloth. With some fictional difficulty, you can justify sewing more cloth onto the edges to make the coordinate plane larger, but it is impossible to justify the removal of a square of cloth from out of the center of the map. Likewise, it is impossible to add more detail (by adding greater resolution to the coordinate system) to a region within the existing map that you want to expand upon or revisit—your grid size is fixed.
One partial solution that has been in use for many years in standalone games, particularly computer and console role-playing games, is for landmarks on the continuous map to be iconic representations of a city or town. When the icon is touched, a fresh continuous map is presented which can have a different scale, permitting depiction of greater detail. This however is a consensually deprecated design in the community, on the (perhaps invalid) grounds that greater realism means consistency in scale.
The problem of course is that a consistent scale means a lot of empty land. One of the chief complaints players have regarding Asheron’s Call is that the realistically sized continuous map, which is around the size of Rhode Island, is rattlingly, echoingly empty. Ultima Online likewise suffers from large expanses of randomly placed trees on completely flat land. A continuous map with consistent scale demands expanses of nothing, whereas a room-based system can essentially abbreviate or symbolize the empty space with a single node, or even no node at all. This also means that travel time becomes an issue in a continuous map system, whereas it hardly existed as an issue in a room-based system.
In a room-based system, each issuance of a movement command moved you one node, and commands could be quickly entered in sequence (a trick called “fastwalk” on many muds), on a continuous map there is, because of coherent scale, an imposition of a rate of movement over time. Perforce you must move a fixed distance in a given period of time. This imposes travel time as an issue. All of a sudden, the virtual space involves tedium in a very direct way, every time you try to get from point A to point B. Now, room-based systems have always attempted to simulate limits on travel by preventing too much movement in a given span of time (usually by deducting points from an arbitrary “stamina” or “move” value stored on the character every time a node was traversed), but what this really meant was extremely rapid movement interrupted by times when the character remained stationary in order to recover the points spent. The only time delay involved in moving from node to node in virtually all room-based systems is the time delay incurred by the latency on the Internet: time for the command to reach the server and then the results be sent back to the client.
In a continuous system, however, movement of a certain distance on the coordinate plane means a fixed amount of time expended. Distance suddenly literally equals time. This applies equally as much to a room-based system on a large scale, like EverQuest, as to a true seamless and continuous map, like Asheron’s Call. The undoubted trend in mud design is towards continuous maps, but they raise interesting social issues, such as travel time to reach friends. If it is axiomatic that muds are about other people, then a map which keeps people apart is an undesirable thing. Perhaps because of this, the three major commercial graphical environments today all offer instant teleportation facilities for getting quickly from one location to another.6
Players are mesmerized by the concept of merely adding more map, because they are generally not aware of the social implications. Indeed, many agitate for the removal of the teleportation systems on the grounds that they create too many social problems (creating, in essence, a world full of transients who have no home base within the virtual space). More map means lesser player density and less interaction with others. It may indeed result in a greater sense of localized community, but may also result in it being pointless to create large worlds because of how scattered the players will be. If you have lots of widely separated communities on one map, so widely separated that they cannot easily interact, why go to the extra investment of having a server architecture that handles maps of that size? You could get a similar effect from running many smaller worlds that are completely disconnected instead—something far easier on your programmers and on the pocketbook. There is also a difficulty involved for the player who has limited time to spend online in a given play session, but who may be required to travel large distances (and therefore invest more time) in order to get to someplace interesting. Room-based systems without continuous maps within rooms, a la Habitat, Illusia, or The Realm will probably not be viable in the commercial marketplace after the current generation of games have shown the greater immersiveness of a seamless, continuous world, but it doesn’t mean that bigger is better.
The Persistence of Space
A key requirement regardless of the method used to describe the space is the fact that the space must persist independently of any connections to the server. This does not mean that it must remain running at all times—one of the most common optimizations done to virtual worlds is to let unused areas of the map go inactive. Rather, it implies that the space itself should have a degree of persistence. It may evolve over time, or grow, but it remains the same.
In this model, the server references a map that exists as an independent entity, defined in a database. The client connects to the server, which feed it information about the map. In graphical systems, there is usually a duplicate copy of the map living on the client side, in order to avoid having to send bulky graphical data across the wire. The map database is monolithic, and the server always addresses the same database. This does not imply anything about the continuity of the map defined or the spatial relationships within the map. In fact, the map may in fact consist of multiple separate sub-maps.
An alternate model, which falls outside the scope of a traditional virtual world, is one where there exist multiple spaces that the server rotates amongst. These spaces may be predefined, or they may be created on the fly using random algorithms. This model is used by first-person shooter games such as Unreal Tournament and Quake, and (with random creation of maps) by action-RPG games such as Diablo. The reason these fall outside of the scope of the genre is because they fail to offer constancy. In interacting with a virtual world, one has the expectation that the world is indeed a world, an independent entity that remains, despite changes over time, just as our world remains, even though it has been deforested, continents have shifted, and new mountain ranges have risen from the earth’s crust.
Now, many muds have offered a similar range of maps to play on, in a manner much like that of Quake. But they have always involved having a central, persistent hub space. The hubs in Quake and Diablo are not spatial depictions (in first person shooters, they are little more than a list of servers; in Diablo, it is a chat room) and therefore do not even pretend to be virtual worlds. Muds such as HoloMUD offer a standard central map that is considered by game convention to be “the real game.” Then it allows teleportation into “holographic spaces” via doorways leading off of that central map. These lead into sub-maps which are radically different, and in fact are arenas for a game very akin to Quake. The sub-maps have very little persistence, and reset most elements of their game data on a regular basis. However, the persistence of the space itself remains, because the sub-maps fall under the umbrella of the central lobby, which is, for all intents and purposes, HoloMUD itself.
A tactic for solving the issues inherent in developing large amounts of space, as well as graphically representing it, is for the space to be the output of a predictable function using a fixed random seed. Under this method, an entire map or subsection thereof could be defined using a single number. When this number is fed into the algorithm, a predictable result is always obtained. This method of map generation has been used by standalone games such as Worms; using it to fractally generate terrain maps and populate them with objects such as flora and buildings is the intent of several major commercial endeavors, including Simutronics’ Hero’s Journey. It is in use in textual environments such as Discworld as well. To date, no graphical virtual worlds have opened to the public using this idea, even though methods of employing this technology for virtual world development were publicly discussed on the MUD-Dev list in the mid-1990’s. The savings are considerable—not only is map generation the single costliest part of creating a virtual world, but in the case of worlds too detailed (or too graphical) to stream down to the user via their client, one could place duplicate algorithms on both the client and server sides, and merely send down the seed value. This keeps you from having to store large maps on the client side, and perhaps keeps you from requiring a CD as part of your game.
In fact, they foresaw a lot more than that. Vannevar Bush envisioned a device called the “memex” (using the then-obvious technology of microfiche) that contained hyperlinked and indexed files containing all the world’s knowledge. Ted Nelson took it further and saw it as Project Xanadu—a ubiquitous wireless means of accessing the now-computerized memex. In both cases, there was talk of spatial metaphors. ↩
From an email message on the MUD-Dev mailing list on Jan 9th, 2000. I have corrected some of the spelling errors that were the result of hasty typing. ↩
See the chapter entitled “Game Data” for further of discussion of reset models. ↩
A term for automated systems permitting the description of many nodes using only a few discrete database entries. Usually these involve embedding coordinate spaces inside of nodes, or using random factors to create large amounts of nodes. These techniques are generally only applied to wilderness areas of the map, hence the term. ↩
It may be a misnomer to term this an early incarnation of a graphical mud. Produced by veteran players of Neverwinter Nights on AOL, Illusia has not, as of this writing, yet launched. But it was announced and screenshots displayed on the Internet during the extremely fertile period that the first generation of commercial graphical muds was being developed, circa 1996. ↩
In Ultima Online there are moongates and a magic spell that allows teleportation for both individuals and groups. In EverQuest the fact that this ability was limited to a single type of player character was touted as an advantage, but every group then traveled with one of the players with this special ability. One of the most desirable abilities in the game is “spirit of the wolf” which provides accelerated movement. And in Asheron’s Call there are “subway stations” scattered across the map that provide instant teleportation across large distances. ↩
