A Definition
Part One: The Play’s the Thing
Hamlet, Act ii, Sc 2.
In which we attempt a definition of what virtual worlds are, discuss what has been done before in their name, how to evaluate what you do, and what the populace of these worlds is like
This book is about design patterns and known consequences of those design patterns in virtual world design. In other words, it gathers together information on what has been done in the field in the past, and it also assesses the consequences and results of many of those choices. Much of the book is concerned with taxonomy, in that it attempts to classify and sort into tidy little bins many of the general design decisions made in the past. We should recognize from the outset that things are rarely so clear-cut that particular games or designs can be neatly classified—things are not commonly so black and white. But it is still of value to engage in this sort of pattern recognition, even if no single implementation fits the archetype that the pattern defines, because it allows us to intelligently discuss design elements within a context, with a commonly shared vocabulary, whilst well-informed as to the history of the field. The hope is that by thus classifying and identifying design patterns and history, the book can arrive at a partial grammar of the genre.
In the case of virtual spaces, the history worth examining is not that of virtual reality research (which has never had a significant actual virtual population of users) but rather, the history of muds and their ilk, the largely text-based games and social spaces that began to be actively played by college students on the Internet in the early 80’s. Fortunately, despite the lack of criticism, there’s a copious quantity of historical information available, dating back to the very origins of the genre.
A Brief History
The first mud we recognize as such came about in the late 1970’s, developed in England by a couple of students at Essex university, Roy Trubshaw and Richard Bartle. According to Bartle,
The very first MUD was written by Roy Trubshaw in MACRO-10 (the machine code for DECsystem-10’s). Date-wise, it was Autumn 1978. The game was originally little more than a series of inter-connected locations where you could move and chat. I don’t think it was called MUD at that stage, but I’d have to ask Roy to be sure. Roy rewrote it almost immediately, and the next version, also in MACRO-10, was much more sophisticated. This one was definitely called MUD (I still have a printout of it). The database (ie. the rooms, objects, commands etc.) was defined in a separate file, but it could also be added to during play. However, the result was that people added new rooms that were completely out of keeping with the rest of the environment, and, worse, added new commands that removed any spirit of exploration and adventure that the game may have had. In those days, memory was at a premium, and on Essex University’s DEC-10 we had something like 50K maximum (36-bit words) to use. The game definition stuff took up too much memory, so Roy decided to ditch it. The program was also becoming unmanageable, as it was written in assembler. Hence, he rewrote everything in BCPL, starting late 1979 and working up to about Easter 1980. The finished product was the heart of the system which many people came to believe was the “original” MUD. In fact, it was version 3.1
It’s worth noticing that even in this very early beginning, several of the basic design patterns for muds are established already, and some of the issues that were to plague designers for many years to come were already evident, such as the issues involved with player-contributed content.
Now, this was not the first instance of persistent world online gaming. For one thing, the original MUD was not particularly persistent in nature, and therefore might justifiably not even be called a mud under modern definitions. There were projects on PLATO, the graphical education network in the United States, which had mud-like characteristics.2 These games were instrumental in inspiring people like John Taylor and Kelton Flinn to go on and found Kesmai and create seminal mud-like games such as Islands of Kesmai. There had also been multiplayer versions of the text adventure variously titled Adventure and Colossal Cave, which went on to become Zork. Bartle says
There’s a reference to MUD in an article on Zork in the December 1980 issue of Byte. Interestingly, it also mentions an earlier multi-player version of Zork, but neither I nor Roy were aware of it at the time. I’ve never found any other references to it, so I don’t know how MUD-like it was.
Regardless of whether there were these other projects, the fact remains that most things of substance that has been accomplished in virtual worlds spring from MUD1 and its children. And children did it have! Martin Keegan’s taxonomy of muds, The MUD Tree, shows that it had around a dozen direct descendants, and from those descendants spring all the major code bases in use today.3 Taken together with the descendants of a few other early endeavors (some of which may well have come before MUD1, such as the efforts of Taylor and Flinn, or SCEPTRE, developed by Alan Klietz, which went on to become Gemstone), these children are the heritage of virtual world design today. These mud types segment along design principles, not just code branches, and have come to represent basic approaches or design goals; when one speaks of a MUSHlike environment or an LP-style architecture, one means specific design patterns and constellations of features that are typical of these code bases. And if one cannot speak of these things, then one is likely acting in ignorance of some well-known design patterns and is therefore liable to repeat mistakes made years ago.
Text versus graphics
The vast majority of muds made thus far are text-based, not graphical. This has served as a stigma, preventing many from seeing the graphical muds as muds, and instead, leading to the coinage of many of the above-mentioned pointless and difficult acronyms. However, both are still concerned with the portrayal of virtual spaces. In examining design issues, it’s best not to get caught up in the past stereotypes of what the word “mud” means. When many think of a mud, they think along the lines of the following quote from a typical Usenet post responding to my assertion that Ultima Online was a mud:
When I think of a mud, I think of text based descriptions with at best a static graphic backdrop to provide some atmosphere
There had certainly been commercial graphical muds with scrolling backgrounds prior to Ultima Online. Habitat (launched in 1985, designed by Chip Morningstar and Randy Farmer), Neverwinter Nights (on America Online), Legends of Kesmai (likewise, and a descendant of the original Island of Kesmai which was text-based), and Dark Sun Online are examples. Meridian 59 and The Realm also beat Ultima Online to market in either final form or open beta. Most of these commercial efforts relied on graphics stored on the client side to minimize network traffic. All that was sent across the wire was an identifier for the client-side graphics to be used. In the non-gaming realm, notable examples of graphical mud systems have included The Palace, which is a room-based chat system; AlphaWorld, a collaborative architectural building environment with a 3d display; and WorldsChat, a 3d environment for chatting. All three also predated Ultima Online.
There have also been text-based muds with continuous, grid-based maps (as opposed to room-based, which is the common stereotype of a mud). Many text muds, perhaps the most prominent of which was Medievia, offered grid-based wilderness areas displayed as overhead ASCII maps. DartMUD actually offered a wilderness area that used a hex grid similar to that used by miniatures war gaming. Muds designed and programmed by Owen Emlen gave split-screen displays using ASCII to give both a room description and an overhead map via an ANSI-compliant Telnet connection.
BSX muds are a particular and largely forgotten breed of muds that use Bram Stolk’s X-Windows protocol added to an LPMud codebase, to give a graphical display using polygon primitives in a side view. The engine supports parallax and 16 colors using a dedicated client available for PC, Amiga, and X-Windows platforms—it looks remarkably similar to The Realm, in fact, except that it’s somewhat lacking in the artwork department. A snippet of the markup language used looks like this:
@DFS house.02040400000A000A0A000A0503000A0A0A0515
Since the underlying code base was a standard mud code base, the scenes represented rooms just as in a regular LPMud.
One of the most interesting takes on adding graphics to text muds was the now-unmaintained Pueblo mud client developed by Chaco Inc., which supported embedded HTML and VRML within a standard text mud. As far as most muds got was adding basic HTML support—the full potential of the system was never realized, perhaps due to the cumbersome nature of VRML. There was a similar attempt at mixing WWW protocols and Telnet done with htMUD, which opened a browser window and a Telnet connection simultaneously. Alas, the site for this mud appears to be off the Internet now.
The single most ambitious attempt to integrate graphics into a text-based server was the WOO project. The most use it has been put to is on ChibaMOO – The Sprawl, which terms itself a “collaborative hypermedia.” Over a half-million people have visited this graphical environment based on the cyberpunk fiction of William Gibson, but it averages under 100 users a day, pointing up the fact that web-and-mud hybrids have never gathered the audience that client-side graphics systems have. WOO (also known as WOODS, for Web Object Oriented Distributed Server) was created by Samuel Latt Epstein in 1994. Shortly after, work began on MOOniverse, which created a distributed server system intended to combat the key problems of scalability and latency in a large-size collaborative building environment. To my knowledge, the project, despite having functional code that accomplishes some things that the commercial servers today do not, has not met its objectives in terms of audience in the way that advanced commercial servers such as Asheron’s Call have.
So, where are we? In common usage, yes, text muds seem to be called muds in preference to other terms. However, in the design community, there should be no hesitation whatsoever in calling typical text muds from any code family, BSX muds, Ultima Online, The Realm, Gemstone III, the original Neverwinter Nights, Kingdoms of Drakkar, Legends of Kesmai, Meridian 59, EverQuest, Habitat aka WorldsAway, WorldsChat, or AlphaWorld all muds. They are all about representing virtual space—the interfaces for doing so are radically different, be it text or graphics, but they nonetheless have that one element in common.
A Somewhat Strict Definition
Certain things are shared in common among all of the many inheritors of MUD1, and these things make up the core of what a mud is—and therefore, what a virtual world is today. These are:
- A spatial representation of the virtual world
- Avatar representation within the space
- A sandbox to play in that offers persistence for some amount of the data represented within the virtual world
Anything that meets these criteria can profitably be called a mud for the sake of examining it and comparing features in the design to things that aren’t ashamed to use the term. Those who are ashamed to use the term have seized on terms like “persistent world” (useful in that it informs the novice as to the nature of the beast) and the truly hideous “MMORPG” acronym, standing for “massively multiplayer online role-playing game.” I suspect that we will find this term falling away over the next few years as we begin to develop persistent worlds that are not explicitly role-playing games. MMORPG in particular is a game industry term which undoubtedly arose from a couple of factors—the desire to avoid the term “mud” (though one of the first major commercial graphical endeavors, Meridian 59, in fact advertised itself as “the first graphical commercial MUD”—it wasn’t, since that honor probably belongs to the original Neverwinter Nights on America Online) and the need to explain the difference between the multiplayer games—including role-playing ones such as Diablo–that supported 32 players or less, and the mud-like games that supported a minimum of 150.
One is tempted to use the term “virtual reality” except for two key facts: one, that the VR field has developed definitions of its field of endeavor that do not accord with the topic of building multi-user virtual spaces; and two, that the VR field has made little appreciable progress in tackling the issues underlying shared virtual spaces. This is not to say that virtual reality research has been useless—rather, that it does not have direct applicability to the problems that by and large will be discussed in this book.
The name “mud” itself is subject to a fair amount of debate. Its original use was as an acronym for Multi User Dungeon and later, Dimension or Domain. But by now, it’s best used as a word, in lower-case, in order to avoid the religious wars that come with the issues of whether something is a MUD, a MUSH, a dungeon game, another type of space, etc. There’s a bewildering amount of these acronyms (and religious wars) and by and large they are only useful to know about for identifying certain broad types of mud designs. Throughout this book, I’ll use “mud” interchangeably with “virtual spaces” and other such terms.
In general, muds are client-server applications, with the client merely being some manner to display the culled and collated output of the server to a particular user connected via an IP protocol.4 The fact that muds generally fit this sort of pattern, however, does not mean a mud has to be that way. Rather, it is that way because it is the best practice for achieving the design goals of a mud without sacrificing the security of the world’s data.
Muds do not have to visibly reflect any of the heritage of the past (particularly text muds, which originated the genre) in terms of their interface and appearance. As basic definition for what a mud is, let’s take the following statement:
A mud is a spatially based depiction of a somewhat persistent virtual environment, which can be experienced by numerous participants at once, who are represented within the space by avatars.
This is different from much of virtual reality research, which often fails to tackle multiple users, often skips avatars, and is generally lacking in persistence. Prior to Jonathan Steuer’s radical redefinition of the term “virtual reality” in his paper “Defining Virtual Reality: Dimensions Determining Telepresence,”5 the definitions were, as he notes, centered around technological niceties such as VR goggles. Steuer instead defines virtual reality in terms of telepresence:
Telepresence is defined as the experience of presence in an environment by means of a communication medium.
In other words, “presence” refers to the natural perception of an environment, and “telepresence” refers to the mediated perception of an environment. This environment can be either a temporally or spatially distant “real” environment (for instance, a distant space viewed through a video camera), or an animated but non- existent virtual world synthesized by a computer (for instance, the animated “world” created in a video game).
This leads him to his final definition:
A “virtual reality” is defined as a real or simulated environment in which a perceiver experiences telepresence.
In order to better refine this definition, however, Steuer has to make use of terms such as “vividness” and “interactivity.” Roughly, these refer to the manner of presentation of the virtual environment depicted, and the degree to which a user of the space can affect the content of the space. In this scheme, muds place midway up the vividness scale and all the way over on the interactivity scale. Of course, we know full well that muds have not yet reached anywhere near their full potential in interactivity. Steuer also rates graphical muds higher in vividness, and graphical muds with sound higher yet. Interestingly, the highest rated elements that fulfill the convergence of vividness and interactivity are fictional: Gibson’s cyberspace, Bradbury’s children’s playroom from the science fiction short story “The Veldt,” and of course, Star Trek’s Holodeck. Janet Murray, the hypertext and interactive storytelling theoretician at MIT’s Media Lab entitled her classic book on the subject Hamlet on the Holodeck.6
For my purpose, I am going to immediately discard vividness as a factor in the definition of a virtual world. There are far too many systems in which a user can experience a sense of telepresence with a highly vivid system (meaning, one with a reasonably high degree of fidelity in representing all types of sensory inputs—visual being the key one, of course). As Steuer himself notes, users have reported the sensation of telepresence with chat rooms and webpages. Frankly, all of the most interesting challenges in designing virtual environments have nothing at all to do with vividness or client-side representation. And of course, for a true virtual reality, to my mind, you have to have other people participating in the space at the same time, which Steuer’s definition does not require. Lastly, of course, the idea of a virtual reality being a “spatially distant ‘real’ environment… viewed through a video camera” is simply not helpful and is clearly outside the field.
It’s worth noting that there are games such as Diablo and Quake which offer virtual spaces with multiple participants and persistence of data (indeed, Quake and other first-person shooter games offer a higher degree of vividness than any other sort of virtual space available today). One can point at the hard cap of 32 maximum participants, at the fact that the space does not persist, but rather is recreated every game, at the session-based nature of the gaming experience, and other such things that do not meet up with the expectation of a mud—but there’s only so much value to be had from the exercise. The definition offered is not intended to completely pin down what a persistent world, MMORPG, or mud is going to be. There are gray areas and dragons lurk in the less-explored fringes of the definition.
Quoted from the USENET post “Early MUD History” made by Dr Bartle on November 15th, 1990. He maintains a copy of the post at http://www.mud.co.uk/richard/mudhist.htm. ↩
PLATO was introduced in 1961; by 1972 the multiplayer game Empire existed on it, and the first mud-like games existed by 1974. See the Appendix entitled Online World Timeline. ↩
Keegan’s MUD Tree can be found at http://camelot.cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi. ↩
A protocol such as Telnet, raw TCP/IP, or UDP. Culling in this context means that the server has a great deal information about the world, and needs to decide which bits it will send to an individual user. The key here is deciding what not to send. Collating means that this information generally needs to be gathered from a number of different subsystems within the server (such as ongoing updates, movement, the activity of other players, etc) and must be organized into coherent output of some sort. ↩
http://www.cyborganic.com/People/jonathan/Academia/Papers/Web/defining-vr1.html has an electronic copy of the paper. It was published in the Journal of Communication, 42(4) (Autumn, 1992), 73- 93. ↩
MIT Press, 1997. A webpage of resources for the book exists at http://web.mit.edu/jhmurray/www/HOH.html. ↩
