MUDs - Serious Research Tool or Just Another Game Lawrie BROWNy Department of Computer Science, University College, UNSW, Australian Defence Force Academy, Canberra ACT 2600 Australia Abstract MUDs (Multi-User Dungeons) have been getting quite a bit of press recently, much of it heated, and much of it negative. In part, this has generally run along the lines that they are simply a waste of bandwidth, and that people have better things to do with their time. Whilst there is certainly a large element of truth in this, does it mean we should write them off altogether? Well, I believe we should not, and that in fact MUDs are a very powerful tool for doing some quite interesting research. A MUD provides a controlled, user extensible environment in which a number of people can interact. The design of the programs running MUDs, the design of usage of the environments created in a MUD, and the way people interact, all involve some fascinating realms of inquiry. In this talk I intend to introduce the concepts and history of the MUDs, and then provide an overview of some uses for MUDs. These range from an on-line conference room in my own MUD, to testing garbage collec- tion algorithms, experimenting with economic models, simulating a Mars colony, and investigating the psychology of user interactions on MUDs. I'll try to conclude with an idea of where they are going, and some hints for responsible MUD management. 1 Introduction MUDs (Multi-User Dungeons) have been getting quite a bit of press recently. In part this has been because many regard them as just a game that is capable of consuming significant amounts of network bandwidth, CPU cycles, memory and disk. Even that they can pose a security threat to the host. Whilst I do not de* *ny ____________________________ This paper was presented to the AUUG Canberra Summer Conference, 17 Feb 93 yEmail: Lawrie.Brown@adfa.oz.au 1 that these can indeed be problems, I would like to consider whether there are some serious academic uses for MUDs. I believe a MUD provides a controlled, user extensible environment in which a number of people can interact. The design of the programs running MUDs, the design of usage of the environments created in a MUD, and the way people interact, all involve some fascinating realms of inquiry, aspects of which I will survey in this paper. 2 What are MUDs? A MUD is a multi-user, real-time environment which permits a number of par- ticipants from disparate network locations to be connected to a common envi- ronment in which they can interact with each other [1]. The mechanics of the interaction shares a common heritage with text-based adventure games (cf the original Colossal Cave in Fortran), however the style of interaction has evolved significantly. The MUD provides a structured yet extensible environment, one that the participants can build extensions in, perhaps even program new forms of interaction. This can allow a group of people to collaborate in building, de- scribing and developing an interactive model community as a simulation study. They can also be used to investigate aspects of computer mediated interaction, and as a prototype of possible group decision making tools and on-line confer- encing. A range of services have developed which allow people to interact over the network. Originally there were mail and news services which provided off-line (non real-time) interaction. Then came talk (for 2 people only) and IRC (In- ternet Relay Chat) for many people. These latter services allowed text to be exchanged in real-time between participants, but operated with no surrounding context, effectively in a cultural vacuum. However people are more comfortable when there is a context or environment to operate in. This is the goal of vir- tual reality systems, to provide an on-line environment. A MUD provides one means of implementing this using text-based interactions. As such it is a low technology, but high involvement system. It is also cheap, easily supported on existing systems and interfaces, and yet one capable of useful and usable degre* *es of environment modelling and simulation. A MUD is a client-server system. The main MUD server, which holds all the information of the participants and the environment runs on one system. The participants connect to it using a MUD Client program (which may just be telnet, or may be a specially written program with additional capabilities) running on their local system. There are a number of MUD servers running around the world. Each has its own characteristic environment, and at present there is little interaction between them. Your virtual character on one is dist* *inct from that on another, although participants often maintain the illusion of a common persona. There is some research into a MUD server system that allows the transfer of information between servers, but that is still in early develop* *ment. 2 3 Text Based Virtual Reality I have described a MUD as a text-based virtual reality. Most of the research, a* *nd most of the hype associated with Virtual Reality systems has involved multi- media presentation systems using 3-D sensors and 3-D displays (usually bulky and/or awkward). However I believe that some aspects of VR can be researched without such expensive (both monetary and computationally) resources. As anyone who has read a good book knows, it is perfectly possible to engender sufficient suspension of belief through a text only media to immerse oneself in another world. And after all, this is the goal of VR systems. As Waldern [2] notes "The goal of Virtual Reality is to create a simpler, more effective, human-computer interface ... whereby the human operator becomes totally immersed and unencumbered by real world distractions". Waldern claims that this requires the use of complex displays, a point on which we then disagree. He describes the elements of VR as including the following: - Space - a 6D (x, y, z, roll, pitch, yaw) space, representing real or abstr* *act data, which is decomposed into worlds. - Objects - existing in the Space, with programmed behaviour controlling their interaction with other objects. May be combined into hierarchies of objects. - Agents - programs that respond to changes in the environment. - Views - which provide reference points for perspective control. - Maps - of the Space which assist the user in navigating through it. - Sensors - both tracking (position) and kinetic (motion) which provide feedback from the users interacting with the Space. Now consider which of these elements are present in some form or other in MUDs. MUDs certainly include a space, comprising a large number of locations (rooms) which may be connected in any topology required. These locations are usually static, although the users of the system can add or modify locations. These locations can contain objects, which have attributes, and which can be programmed to interact with the users (who are also a special form of object), and with other objects. MUDs can contain agents, either controlled entirely within the MUD, or in the form of special users who are controlled by an extern* *al program, rather than by a person. A users' view of the MUD is determined by the location and object descriptions, and users can easily return to a given location. The user can construct maps of the space to assist in navigating arou* *nd it. Finally the user interacts with the MUD via a keyboard and screen, often with the assistance of a MUD client program, which provides special formatting, macro, highlighting and automatic response facilities to assist in reacting with the MUD. 3 In summary, MUDs provide many of the elements necessary for a Virtual Reality system. Whilst these are technically less sophisticated than full senso* *ry immersion VRs, it means that you can concentrate on the interactions possible in the system, rather than fighting with the technology. There are no goggles, no gloves, no fancy graphics, just descriptions of places, things and people, a* *long with a range of possible actions to take. Your imagination provides the rest. Because of this simplicity, participants can concentrate on the world-building aspects of the system, on building simulations with many participants, and in interacting with them. 4 A Partial Genealogy of MUDs MUDs have grown out of earlier work on multi-user computer games. A partial genealogy of the MUDs is given in Fig ??, taken from Bartles's report [3]. The earlier generations were written in the UK and Europe, and are mainly running on commercial systems. Then with AberMUD, we see the first Internet accessible MUD, and the start of the trend to the MUDs known and used today. At this point also, much of the development crossed to the USA, although significant contributions have also been made in Europe. The major MUD servers running today tend to include a programming language which allows the semantics of the MUD to be extended, and many also have elements of an object-oriented system. Work continues refining these aspects. 5 Some Real Examples of MUDs In this section I will briefly introduce several MUD systems currently being used, which illustrate some of the possibilities for these systems. 5.1 MUD Uses - Conference Room In the MUD I run, I have created an on-line distributed conference facility. The environment is that of a conference centre with a meeting room. The room is furnished with a conference table, chairs, and even a view out the window. It also includes some support infrastructure, especially a whiteboard. This is an object in the MUD configured so that any participant can add text to it, and all others can read it. It thus functions as a whiteboard normally does in a conference room. However this is one feature not present in the predecessors (eg IRC) of the MUDs. 5.2 MUD Uses - Newsletter Also in my MUD I have produced a newsletter. The system keeps a master copy of the contents of the newsletter, whilst each participant can purchase an 4 instance which keeps information, such as which page they have it opened to. The content of the newsletter is added using a master update program, which authorised participants can run. 5.3 MUD Uses - Monash MUD A MUD is being run at Monash University by the Computer Science department. It is being used for several projects. One of the more interesting is to evalua* *te an economic model developed by Les Goldschlager (their HOD), which concentrates on banking algorithms and their impact on the economy. In the simulation, students are asked to submit programs to run to try and make money, to test the effectiveness of the model. The MUD is also being used to trial some alternate tagless garbage collec- tion algorithms, as part of a PhD project on a new persistent object-oriented programming language (Chi), which may also be implemented in the MUD. 5.4 MUD Uses - MicroMUSE MicroMUSE is a simulation run on a MUD at MIT of an orbital colony "Cy- berion City". It includes a charter for the colony, a model of government, the economy, and of aspects of the society. Participants interact with the simulati* *on to judge the effectiveness of these models. 5.5 MUD Uses - NAU Mars Colony One of the most interesting projects to me is the Mars Colony simulation, hosted by Northern Arizona University, but with participants from a number of insti- tutions. It also includes a model of the economy, several governments, and a number of smaller settlements that interact with each other. It forms the major practical component of an interdisciplinary Honours course "Cultural Simula- tion - The Mars Mission" offered by the departments of Anthropology, and of Computer Science at NAU [4]. It is now running for its third year, having grown out of the previous CONTACT cultural simulation project which was based on more traditional role-playing techniques. The aim of both of these projects was to simulate cultural conflict between societies, in this case, the various colo* *nies. As part of their assessment in this course, the students are required to de- sign and implement a socio-cultural simulation for the Mars settlement project. They have to build on the initial assumptions, develop realistic persona with r* *e- searched areas of expertise and job descriptions, design a political economy and a method of self-government, and finally run the simulation. There are groups of participants from various campuses, each developing a separate colony. In 1993 these included NAU (Mars), U Dayton (Artic Submarine city), Intl Space Uni (L4), Cabrillo-UCSD (L5), and others. In addition there is a team of indepen- dent consultants supporting the simulation, providing advice, and evaluating 5 the results. Within the simulation they are the "Board of Virtual Consultants", with expertise including linguist, NASA engineer, VR specialist, SF author, Fu- turist, Anthropologist, meta-law specialist, and others. There are also several alumni from previous courses assisting by representing key corporations (and creating some sources of conflict). Following the simulation, the students are debriefed, and use the results to produce reports and education material based on their researches and experiences in the simulation. A dialog excerpt from this simulation when I visited it in February 93, is given in Fig. ??. 5.6 MUD Uses - MOO MOO is an object-oriented MUD run by Pavel Curtis at Xerox PARC research labs. It includes a full object oriented programming language, used for both language development, of to investigate aspects of the inheritance of attributes in this environment. Pavel has run a production server for some years, and has used it to study social interactions amongst participants in such a computer mediated environment where many of the usual non-verbal clues are obscured by the system [5]. The MOO server has also been used by others to investigate its suitability as a possible groupware environment, its advantages and limitations. 6 MUDs - Where Next? I hope I have shown in the previous section that MUDs are being used in some very interesting applications, especially in simulations, and as a forum for on- line interaction between participants (see comments given in Fig. ??). I believe these applications will grow in importance, and the MUDs show in prototype form how they may be implemented. Advances are needed, particularly in the interface. The current text-based, single output interfaces can lead to confusi* *on when trying to track three or more conversations. The development of smarter client programs, able to separate and track conversations may well help here. Also I expect to see some interaction with the more traditional VR community, with a merging of technology as more powerful hardware and greater network bandwidth becomes more common. There is already some work on graphical MUDs, although these require significantly greater efforts to build environments in. 7 Responsible MUD Management The use of MUDs has raised some security concerns. In particular some of the earlier MUDs allowed access to underlying OS facilities, and thus formed an avenue of attack. However most of the more recent MUD servers run as a single process, totally isolated from the rest of the system, accepting and authenticating their own users, and providing no means of interacting with 6 DrRiner says "Yes, I can sympathise. Our Anthro meetings have gotten so big, hence big, expensive hotels, that I've had to write them off. I guess small conferences are going to be the thing of the future." LBrown nods "for at least some of it. But the problem is its nice to go to a big conference to meet everybody, and find out whats happening in areas other than your own. So I guess we'll just have to balance between them in future. DrRiner says "I think that's where computer mediated communications has a lot to offer! I am trying to build a continuing electronic conference for my regional anthro association..." Figure 1: Dialog on On-line Conferencing the host system apart from the MUD server. Hence any security lapse only compromises the MUD server, not the rest of the host system. Obviously, as with any program, the MUD server needs to run with priority and resource limits appropriate to its use. 8 Conclusion MUDs exist, and are used for a variety of applications. They can be regarded as a text-based virtual reality, with an emphasis on low technology but high involvement with the system, and can be accessed and run on many systems now with only modest resources. They have quite interesting uses in simulations and in providing an on-line environment for participants to interact in, formi* *ng the forerunner of future distributed conferencing, groupware and simulation systems. 9 References [1]M. O'Brien, "Playing in the MUD," in SunExpert Magazine, May 1992. [2]J. Waldern, "Virtual Reality the Applications and Commercialisation," in Proc. AUUG 92 Conference on Maintaining Control in an Open World. Mel- bourne, Australia: AUUG, pp. , Sept. 1992. [3]R. Bartle, "Interactive Multi-User Computer Games," MUSE Ltd for British Telecom plc, Colchester, UK, Report, Dec. 1990, also available for FTP from parcftp.xerox.com. 7 [4]R. D. Riner, "Chaos with Feedback: The NAU Solar System and Mars Set- tlement: A Simulation," Dept. Anthropology, Northern Arizona University, Technical Report, Feb. 1993. [5]P. Curtis, "Mudding: Social Phenomena in Text-Based Virtual Reality," in Proc. 1992 Conf. on Directions and Implications of Advanced Computing. 1992, also available for FTP from parcftp.xerox.com. 8 MUD1 # the original by Roy Tubshaw & Richard Bartle, Essex Uni UK 1980 _ +---MUD2 # advanced MUD1 rewrite by Bartle & Trubshaw for BT in 1984 _ +---Shades # various UK commercial games. mostly run on Prestel 1985+ _ +---Bloodstone _ +---Sector 7 _ +---Trash _ +---Zone _ +---Void _ +---MirrorWorld # BBC PC based server, 1986 _ +---Federation II # CompuNet (UK), SF game, 1989 _ +---Gods # Prestel (UK), Fantasy, 1985-88 _ +---Future Life # SF setting, commercial, 1990 _ +---MIST # MUD1 clone, Essex Uni, JANET access, 1987+ _ +---AberMUD # first Internet MUD, by Alan Cox, Uni Wales, 1988 _ +---LPMUD # combat oriented, Swedish rewrite of AberMUD, 1988 _ +---DUM II _ +---TinyMUD # interaction oriented with user extension, 1989 _ +---Cthulhu # OO LISP based _ _ _ +---TinyMUCK # MUF programming _ _ +---TinyMOO # OO programming _ _ _ +---TinyMUSH # added daemons to react to events _ _ _ +---UberMUD # U programming _ +---YAMA # attempt at a meta-MUD, partially successful Figure 2: A Partial MUD Genealogy 9 Ship Main Corridor The corridor is featureless except for doors forward and aft. There are access tube entrances both up and down. The gravity in this section is zero. [ Exits: Crew's Quarters, Access Tube 2, Access Tube 1, Shuttle, DrRiner's Office, HoloCom ] >>> Shuttle Shuttle Poseidon Tiny and cramped, but what acceleration! [ Commands: take suit off, put suit on ] [ Exits: Surface Shuttle Pad, Orbiter ] >>> Surface Shuttle Pad Surface Shuttle Pad(#2276 ROOM Unwanted) Hope you've got your suit on! [ Exits: Shuttle, door in dome, door in hillside, downhill, uphill ] Contents: HARDHAT >>> door in dome Entry Airlock Welcome to the Mars Mission - take your suit off! [ Commands: put suit on, take suit off ] [ Exits: Inside, Shuttle Pad ] >>> inside Control Room Maps on the wall, a drafting table, and a conference table. [ Exits: out ] Contents: Azra Elijah Ravi DrRiner Azra says "What are you doing by yourself down here?" You say "I'm one of the Virtual Consultants, so I get to wander everywhere, poking my nose into things" You say "can you tell me how you think the simulation is going" Azra says "I think it is going well." Azra says "I think it is incredibly useful talking to people, I am here and I have used the DragonMud, which is wonderful. As far as the simulation goes, It really helps solidify what we are doing, make it seem real. As I said, there isn't much here right now, and not too many people to log1on."0 You say "are there many in the mars simulation class?" Azra says "In our class there are 19." Figure 3: A sample dialog from the NAU Mars Simulation