Introduction to "Interaction and Collaboration in MUDs",
Special Issue of Computer Supported Cooperative Work.
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto CA 94304 USA
I was playing a version of MUD, the Multi-User Dungeon which had been developed by Richard Bartle and Roy Trubshaw at the University of Essex in 1979. MUD was a complex variant of a common style of computer game known as the "adventure game", in which players would participate in a fictional world, moving through and acting in a textual virtual environment recorded in a software database. Adventure games were rather like on-like versions of "Dungeons and Dragons", but for one crucial element - interaction with other players. In MUD, the Multi-User Dungeon, many people could play the game at once over a network, and they would occupy the same game at the same time. Not only could players interact with the world created by the programmer, but they could also interact with each other. And indeed, they would often have to interact with each other, whether cooperating to solve a puzzle or fighting over treasure.
Bartle and Trubshaw's original MUD proved exceptionally popular, attracting players from all over the world. Indeed, many computer science departments in the United Kingdom banned their students from playing the game, worried about the network bandwidth being devoted to this frivolous activity. (This is why I was playing in an unheated terminal room at 3am.) More significantly for our purposes here, the idea behind the system was soon adopted, re-implemented and adapted by many others around the world. They proved unendingly fascinating. A few years after I was killed by Sue, I helped to run a public-access computer system, and by far the most popular application on it was another MUD.
I have never been very interested in computer games, largely because I am simply not very good at them. Adventure games were more interesting, but again I never had much of an aptitude for them. MUD, however, was fascinating. To me, it was fascinating not because of the game, which was much like many others. Instead, it was fascinating because of the other people there; people from all around the world, coming together in this virtual space to imagine themselves elves and warlocks in a great game of make-believe... and to do it together. Sue was really out there somewhere.
In today's world of Internet connectivity and concern with "virtual communities", it is perhaps not surprising that MUD technologies, and even more importantly the MUD experience, should be something of interest to those of us investigating Computer-Supported Cooperative Work. MUDs (these days, the `D' often stands for "Dimension" rather than "Dungeon") are in use in a wide variety of settings, and for a wide range of purposes. This special issue collects together papers by researchers who are investigating the present and future of MUDs.
The original MUD, and most derivative systems of that period, provided an environment for players to interact with each other and with a world whose structure and state are maintained in a database by the system. The database is structured and created separately; the system's role is to manage the interactions of the participants, and to record their actions on the world in the database. Based on the Adventure-style games, these MUD systems are generally set in a Tolkein-esque fantasy world, where the object of the game is to acrue points through problem-solving, combat and treasure-collecting, and hence to move through the multi-leveled heirarchy of ranks which the system provides.
Many systems of this sort have been developed. Most maintain the independence of the run-time system and the database so that the same MUD "engine" can be used to create a variety of games. Creating a new game, or a new environment, means creating a new database.
In 1989, Jim Aspnes at CMU began the development of a new MUD system which became TinyMUD. TinyMUD was a small server intended for UNIX systems. Two features of TinyMUD are particularly interesting historically. The first is that Aspnes created a system which could be played over the Internet, and that he made this system freely available, spurring the growth of interest in MUD systems. The second particularly notable feature was that Aspnes made a conscious effort to discard from his system the whole notion of combat, points and treasure which were at the heart of the earlier systems. Instead, the focus of worlds built with TinyMUD was conversation and creation. TinyMUD itself and its derivative systems formed a new branch of MUDs generally referred to as "social MUDs". It is these systems which have typically been seen as fruiful bases for collaboration, and most of the papers in this issue will deal largely with these social MUDs.
The second particularly significant development in the technical history of MUDs was LPMUD, created in Sweden by Lars Pensjl. LPMUD was a gaming MUD, rather than a social one, but it introduced another innovation which is critical to the current state of play; internal extensibility. While previous systems had operated from a database whose structure and contents were static, LPMUD's database was completely open and extensible. More importantly, it was programmable from within the game. Characters (in this hierarchical gaming MUD, just those who had reached the highest score and were classed as "wizards") could create new objects, new locations and new behaviours inside the game, which were then accessible to all players.
The final development which we will deal with here is the appearance of yet another MUD syste called MOO ("MUD, Object-Oriented"). MOO was originally developed by Stephen White, and subsequently adopted and extended by Pavel Curtis at Xerox PARC. In spirit at least, MOO is a blend of LPMUD's extensibility and TinyMUD's social focus. The MOO programming language allows users to create complex new worlds, but does not restrict this ability only to those with enough treasure. MOO's flexibility has made it very popular, and many of the systems which will be discussed in papers here are based on MOO.
Perhaps because of Curtis' development of MOO in a research laboratory, and his own reflective interest in the emergence of community in LambdaMOO, the first and largest environment implemented on MOO, the MOO system in particular spawned the emergent interest over the past four or five years in MUDs as a setting for collaboration research. This has proceeded on two fronts - expanding MUD environments with support for multimedia communication and collaborative tools, as in Xerox's Jupiter, and the use of MUDs for collaborative activities (whether or not work-related), as in Bruckman's MediaMOO. To date, much of this work has been conducted outside the CSCW community, or available only here and there in conference papers. The goal of this special issue has been to bring together a variety of research investigations of MUD and collaboration in those environments, and to bring them to a wider audience in CSCW.
MUDs are typically textual environments. MUD users send textual command strings to the server, which responds with textual descriptions of the effects of commands, new locations, and so forth.
Below is a fictional transcript segment from a MUD session to present the basic ideas. The lines in bold type are those which the user enters; the rest is generated by the server. We will step through this transcript to discuss interaction features as they are encountered. The Great Hall A huge chamber stretches out in front of you. At the far end is a raised platform with chairs, a long table and a lectern. An impressive canopy roof is supported by tall stone pillars, and the room is filled with seats facing the dias. Moving to a location generally causes the system to provide a description of that location. The description sets the scene and can generally be retreived by using some command like "look". Locations serve to locate action. People and objects can only be in one place at a time, and activities in other locations, beyond walls and earshot, are generally unavailable to you unless the system has made some special provision (like an X-ray machine or a radio).
You are standing on the dias at the front of the Great Hall.
There is a laser pointer here.
Paul is here.
Different systems use different forms of commands for navigation. In some, you might name the location to which you want to move. Most often, though, users move around using compass bearings or by naming the path which they want to follow. Again, a description is provided when you reach a new location, in this case the dias. The system also provides information on objects and people who share this location - in this case, one object (a laser pointer) and one person (Paul).
>say Hi, Paul
You say, "Hi Paul"
Paul says, "Hi there. Do you know how to work the laser pointer?"
Much of what goes on in MUDs is interaction between two or more people. A variety of commands are available for spoken conversation (such as say, whisper, or shout) and for non-verbal communication (smile, wave, or frown). In many systems, a more general "emote" command can be used to express emotions which have not been pre-programmed.
>examine laser pointer
A portable battery operated laser pointer with a red switch on one side.
The laser pointer hums and a spot of red light dances on the wall.
Objects generally have specific commands which can be used to operate on them. So, for example, the laser pointer can have a switch to turn it on. Creating a new object means not only creating the entity itself, and its description, but also programming the object's behaviour using the system's programming language. In most modern MUDs, this is done from within the system itself.
>say Pressing the switch turns it on
You say, "Pressing the switch turns it on"
>give pointer to Paul
Paul presses the switch on the laser pointer
The laser pointer hums and a spot of red light dances on the wall.
Paul says, "Great. Thanks!"
>emote smiles and bows.
MUDs are persistent environments which maintain object identity. Any object appears in one only place at a time, and so must be handed from person to person, just as they would in the everyday world. Similarly, of course, just as in the everyday world, there might be many identical copies of an object, so one can distinguish between "a laser pointer" and "my laser pointer". The structure of the world remains stable unless people act on it, and so objects stay where they are put, or remain with the person who last picked them up (unless, of course, they have been programmed to be active and run away). At the end of this fragment, the user creates a compound action by using the "emote" command.
The precise syntax of MUD commands varies from implementation to implementation. It is dependent on two factors - the basic system (such as TinyMUD or MOO) in which this particular environment has been programmed, and the programming of the setting itself. A laser pointer object is only likely to be of use in a setting made to support presentations, and so the details of the commands to use the laser pointer will also be unique to that setting, and operate within the constraints of the underlying system in which that setting has been implemented.
What remains constant, though, is the style of interaction based on text and gradual exploration of a virtual world made manifest.
The subsequent work conducted by Curtis and colleagues at Xerox PARC (with Jupiter and AstroVR), and by Bruckman at the MIT Media Lab (with MediaMOO) spread the idea of collaborative virtual realities as places for collaboration. They emphasised the way in which these systems could provide a focus for a distributed collaborative community, and investigated both technical and social consequences. MUDs became acceptable to the mainstream research communities.
In a sense, of course, this respectability came at considerable cost. After all, very few MUDs were (or are) used by professional communities or organisations in this way. MUDs began as games, and most of them remain games. The "frivolous" nature of these activities often caused researchers to turn away and look towards more "productive" activities as the focus of their studies (and similarly produced many titters and dismissive comments in response to Sherry Turkle's keynote address to CSCW'94 in Chapel Hill).
An emphasis on Computer-Supported Cooperative Work need not, however, blind us to the value of studying and investigating MUD technologies even outside traditional work settings. Even those with the most exclusive concentration on technologies supporting work cannot fail to recognise how the technolgies and techniques developed for collaborative fantasy worlds can be applied directly to systems supporting everyday work. Whether they're in the Corporate Boardroom or the Forest of Eternal Gloom, people are people and interact in much the same way-and the technologies they depend on are much the same.
O'Day et al. present findings from the Pueblo project. Pueblo is a MUD community focussed on a K-6 (kindergarden to Grade 6) school but which also includes participants from other research and educational settings, as well as a recent influx of senior citizens. They discuss the transition of a variety of teaching and learning practices from everyday classroom settings to the new setting of the MOO and reflect on their successes and failures.
Bruckman has also been working in an educational setting. Guided by the principles of constructionist learning, her MUD, MOOSE Crossing, is designed as an environment for children to improve their verbal skills and learn computer programming through engaging in self-selected projects. Bruckman discusses the history of this system and experiences with it, showing how it supports learning, and in particular discussing and illustrating the role which the wider community of users plays in notionally "individual" learning experiences.
The focus of Muramatsu and Ackerman's study is Illusion, a combat MUD. Drawing on the Chicagoan conceptual frame of social worlds, they discuss the social structure and activity at work in Illusion both within and without the rule structure of the game itself, and highlight the fact that the distinction between "social" and "combat" MUDs should not lead one to conclude that combat MUDs are not rich social environments.
Mynatt et al. present a more reflective consideration of the properties of network communities drawing on a range of systems, from textual MUDs to media spaces. Their concern is with the abstract characteristics of network communities and their relation to underlying technology, with an eye towards the design of communities themselves and of systems to support them. In particular, they draw out the relationship between real and virtual worlds, the support for social rhythms and the development of community as matters for examination and consideration.
Together, these papers represent a considerable body of sustained investigation into the use of MUD-based technologies in a variety of settings, from their earliest uses for collaborative game-playing to recent adaptations for learning and working. It is our hope that, by presenting these papers together in this special issue, we can not only bring the research issues into a wider arena, but also help consolidate and further research investigations of interaction and collaboration in MUDs.
A number of the authors also acted as reviewers, with further reviews carried out by Rachel Bellamy, Judith Donath, Tom Erickson, Michele Evard, Geraldine Fitzpatrick, Ellen Isaacs, Bonnie Nardi, Yvonne Rogers, Karen Ruhleder and Diane Schiano. Finally, I should like to thank Sue, who caused all this trouble in the first place.