MUDs Grow Up: Social Virtual Reality in the Real World Pavel Curtis and David A. Nichols Xerox PARC January 19, 1993 1 Introduction MUDs, or "Multi-User Dungeons," are programs that accept network connections from multiple simultaneous users and provide access to a shared database of "rooms", "exits", and other objects. Users browse and manipulate the database from "inside" the rooms, seeing only those objects that are in the same room and moving between rooms mostly via the exits that connect them. MUDs are thus a kind of virtual reality, an electronically-represented "place" that users can visit. MUDs are, however, unlike the kind of virtual realities that one usually hears about in three important ways: o MUDs do not employ fancy graphics or special position-sensing hardware to immerse the user in a sensually vivid virtual environment; rather, they rely entirely on plain, unformatted text to communicate with the users. For this reason, MUDs are frequently referred to as text-based virtual realities. [1] o MUDs are extensible from within; MUD users can add new rooms and other objects to the database and give those objects unique virtual behavior, using an embedded programming language. o MUDs generally have many users connected at the same time. All of those users are browsing and manipulating the same database and can encounter both the other users and their newly-created objects. MUD users can also communicate with each other directly, in real time, usually by typing messages that are seen by all other users in the same room. We believe that this last difference provides the most interesting basis for generalization, so we refer to MUDs as the first examples of social virtual realities. MUDs have existed for about ten years, becoming particularly prominent on the global Internet in the past five years or so. Throughout that time, they have been used almost exclusively for recreational purposes. Many MUDs are specialized for playing a game rather like "Dungeons and Dragons," in which the players are assigned numerical measures of various physical and mental characteristics and then have fantasy adventures in a role-playing style. Nearly all other MUDs are used almost exclusively for leisure-time social activity, with the participants spending their connected periods talking with each other and building new areas or objects for general enjoyment. A recent list of Internet-accessible MUDs showed well over 200 advertised, running at sites all over the world. The busiest of these frequently host 50 to 100 simultaneous users. Clearly, these recreational MUDs are very popular systems. It seems clear to us that the simple technology of MUDs should also be useful in other, non-recreational applications. This paper presents our plans for exploring the implementation, applications, and implications of MUDs in work-oriented contexts. In the remainder of this introduction, we describe the capabilities of our own MUD server. We then describe the two major systems we are building as foci for our research. The LambdaMOO Server We use a MUD server developed here at PARC, called "LambdaMOO." The facilities it provides are generally typical of those available on other MUD servers, though in a form that we find particularly convenient. The server has only three jobs: accepting and managing network connections from the users, maintaining the database in a robust and persistent way, and executing programs written in the server's embedded programming language, called "MOO." Users invoke MOO programs each time they enter a command and the server interprets a simple compiled version of the MOO code. MOO code has access to all of information about the objects stored in the database (including the code for all of the stored MOO programs) and produces its effects either by changing those objects or by reading or writing simple text strings from or to the various users' network connections. To make the programming model as simple as possible for naive users, each user command's associated program is run to completion before any other command is begun; thus, no issues of concurrency or locking arise. As a consequence of this design, MOO programs do not run so quickly as to allow them to be used to handle any high-frequency events, such as character-by-character typing, mouse motions, or real-time network processing. On the other hand, the interpreter is efficient enough for use in most human-speed command-response interfaces. 2 The Astro-VR System In collaboration with Dave Van Buren, an astronomer at the NASA/JPL Infrared Processing and Analysis Center, we are building "Astro-VR," a social virtual reality intended for use by the international astronomy community. We expect to have our first serious users, a major research project with principal investigators in both the United States and Italy, in March of 1993. The system, built on top of the LambdaMOO server, is intended to provide a place for working astronomers to talk with one another, give short presentations, and otherwise collaborate on astronomical research. In most cases, this system will provide the only available means for active collaboration at a level beyond simple electronic mail. Initially, Astro-VR will provide the following facilities of interest to our user community: o real-time multi-user communication, o a self-contained electronic mail and bulletin board system, o shared, user-supplied links to online astronomical images, o an editor/viewer for short presentations of text and images, and o collaborative access to standard programs used by astronomers. Because Astro-VR is built on top of LambdaMOO, all of these facilities can be extended and customized by individual users, using the embedded programming language built into the server. Real-time Communication The standard MUD means of textual self-expression and communication (e.g., speech, gestures, paging, whispering, self-description, etc.) are available to our users as well, because Astro-VR is, at heart, a MUD. While such communications channels are obviously not optimal, they are, at present, the best kind of conversational tools widely usable in today's global Internet. The wealth of experience already gained with recreational MUDs leads us to believe that this level of communications technology will prove useful and even sufficient until such time as something better (such as networked digitized voice) becomes feasible on a large scale. Self-Contained Electronic Mail The international astronomical community, like most modern scientific communities, already makes a great deal of use of electronic mail. However, there remains a need for email forums both concerned with astronomical research and restricted to use by working astronomers. Bulletin boards and mailing lists such as the newsgroups of USENET have the problem (and virtue, perhaps) that access is unlimited; every user on USENET has the option of reading and posting to any newsgroup. From the perspective of a serious practitioner in some field, this communication channel is very "noisy." The sci.space newsgroup, for example, is posted to by people with all levels of astronomical background and expertise, from utter novices to working professionals. The general level of discouse is thus driven toward the middle ground, the knowledgeable hobbyists. Clearly, such a forum is inappropriate and ineffective as an outlet for serious discussion between experts. The standard LambdaMOO database includes an electronic mail and bulletin board system completely contained in the virtual reality; email sent on a MUD does not, in general, leave it and email from outside the MUD cannot come in. In effect, the MUD provides a self-contained electronic mail community; the users can send email and maintain bulletin boards that are open only to that community, even though the participants are geographically scattered. We expect the users to find that a much higher level of bulletin board discourse is possible inside Astro-VR than outside. Active Links to Images Astronomers, perhaps to a larger extent than many other professionals, rely heavily on detailed photographs and other images to convey their ideas and discoveries to one another. At present, however, it is difficult for them to make their images easily available to one another. For example, it is difficult to discover if any (local or remote) colleague has online an image of any particular celestial object, let alone to get access to that image and display it on a given computer screen. In Astro-VR, it is easy for users to "register" the images in their collections, creating an object in the virtual reality to represent it. When another user ``opens'' such an object, the corresponding image is automatically fetched across the network and displayed in a window on the requestor's screen. These active links to images will be indexed in a number of ways on Astro-VR (e.g., by name, location, type of image, type of celestial object, etc.) for searching and browsing by other users. Presentation Editor and Viewer An important part of the scientific work practice is the periodic meeting of relatively small working groups, usually having 5 to 20 members. At such meetings, individual project members frequently give short, 10 to 20 minute presentations on recent efforts and/or results. To facilitate this kind of activity within Astro-VR, we are providing a set of conference rooms, which have extra commands for preparing and presenting such short talks. A talk is structured as a sequence of segments, each containing a paragraph or two of text and one image, accessed using the active links discussed above. When each segment is presented, its text is printed out to all participants and the associated image is displayed on their screens. A distinguished user, the presenter, controls the "pace" of the talk by deciding when to move from one segment to the next. Any discussions that take place during the presentation are recorded and stored with the talk. These discussion may be displayed during subsequent presentations of the talk. This allows project members who were not present at the initial presentation to catch up on what happened there and even to add their own annotations to the talk for other listeners. All talks are potentially archived for viewing by interested parties at any later date. Collaborative Access to Standard Tools There are a number of computational tools frequently used by most working astronomers. For example, tools like the interactive plotting system mongo, the symbolic algebra system Mathematica, a variety of astronomical database systems, and even simple calculators all qualify as major tools in their day-to-day work. Through Astro-VR, we intend to allow for astronomers to use these familiar tools collaboratively. Using these tools will be like crowding around the screen of a shared workstation, handing the keyboard and/or mouse back and forth and discussing the results produced. In the case of Astro-VR, though, the shared workstation is a virtual construct and the users can "crowd around" from the comfort of their individual offices around the world. It is important to note that we are not, in this case, attempting to provide any new tools for our user community; there are many more knowledgeable people in astronomy doing that already. Rather, we see our task as providing the "glue" that allows collaborative use of those tools the astronomers are already using. 3 The Jupiter System To a large extent, Astro-VR represents the level of interface functionality that we can easily export to a large number of users, given the current state of the global Internet and the kinds of workstations typically available to our users. In an environment where we have much more control over the network and the workstations in use by the participants, though, we can explore the use of more advanced technologies. Then, as the Internet and users' workstations improve, we can use the lessons learned in our more controlled environment to improve the general lot. Our other major effort, then, is an extended MUD that supports a richer set of communication media than plain text. This system, called "Jupiter," will be used by researchers both here at PARC and at our companion laboratory, Euro- PARC, in England. In addition, it will support users both within the laboratory buildings and at their homes. Enhancements to standard MUDs Current MUDs use text as the sole communication medium, both between users and between the server and user. Text has the advantage of being universally available, allowing a wide range of users to participate. For recreational use, text has additional advantages similar to those of radio over television, as words can often paint a more compelling mental image than can a picture produced with MacDraw. Unfortunately, text has significant drawbacks in a work environment. First, typing is much slower than speech for real-time communications. While most people can read faster than they can listen, they can speak much faster than they can type. In a world where telephones and face-to-face communications are readily available, real-time typing will not be a popular alternative. Secondly, the aesthetic properties of text descriptions are largely wasted in a work setting. A worker's use of the computer is generally secondary to accomplishing some other task, and a dramatic description of the successful printing of a document, after defeating the evil forces of paper jams and toner spills, gets old after a while. In addition to text-based interaction, therefore, Jupiter provides audio, video, and window-based graphical user interfaces. While typical MUDs assume that users have only a dumb terminal, Jupiter assumes that they have digital audio and a graphics display, with optional video input. This is an increasingly realistic assumption, as almost all computers sold today (PCs, Macs, Unix workstations) have graphics displays, and most have telephone-quality audio or can have it added cheaply (for about $100). Jupiter embodies more assumptions about the capabilities of the underlying network as well. In addition to demanding more bandwidth than the Internet can currently provide, we assume that a "multicast" capability [2] is available, in which individual packets can be received by many hosts without duplicating the packets on any link and without the sender knowing who any of the recipients are; we use this, for example, to handle real-time audio and video traffic efficiently. Audio Each room in Jupiter has a distinct audio channel associated with it. Users hear all the sounds from the room they're in and contribute to these sounds with their speech. When they move to a new room, their audio is automati- cally switched to the channel for the new room. Because the channel management is performed by MOO code inside the database, we can even arrange for the sounds from "nearby" rooms to filter through at a lower volume, allowing users to notice when possibly-interesting interactions are happening "right outside their door." The audio is roughly telephone-quality and is transmitted over the local network. We are currently using the audio devices built into our Sun SPARCstations, but any equivalent audio hardware (such as the current flock of PC sound boards) would do. Window-Based User Interfaces The next addition to the standard MUD model is support for graphical user interfaces under the control of MOO programs. This allows MUD objects to interact with users via windows that appear on their screens. For example, opening a map object might display a diagram of the layout of the local rooms, allowing the user to move between them. Window-based interfaces can also be used for various shared applications, such as text or graphics editors that appear on more than one user's screen at once. Our protocol for communicating between the server and client programs uses high-level descriptions of the interface elements. This allows us to move as much code as possible into the clients from the server, which reduces load and makes it easier to write new window-based MUD objects. It also reduces network bandwidth since the communication is in terms of high-level interface element events instead of low-level mouse and keyboard events. Finally, it allows for a great deal of interoperability, since the details of each user's local window system are hidden from the MOO program controlling the windows; thus, for example, one user of a shared window application might be using a PC running Windows while another uses a Unix workstation running X. Just as current MUDs can be extended with new text-based objects, Jupiter can be extended to support new window-based objects. This flexibility is important; it allows for easy enhancement of the system, either by the original implementors or, indeed, by the individual users. Video While the addition of audio to MUDs provides a dramatic and obvious improvement in communication, the effect of adding real-time video is more subtle. It can enrich the perceived quality of computer-mediated conversation, as gestures, facial expressions, and physical surroundings are transmitted. Also, it makes it possible to monitor remote locations; for example, one can have a sense of whether or not someone else has been "around" recently, or if someone is currently using the telephone or holding a face-to-face meeting. Finally, video can allow users to participate in remote meetings where overhead slides or other visual props are used in presentations. In Jupiter, we intend to make it easy for users to view the output from any cameras associated either with other users in the same room or, indeed, with the room itself. The latter case comes up, for example, when Jupiter is used to attend meetings taking place in real rooms in the laboratory. At present, we are using Sun VideoPix boards and small attached cameras. We have software-only video compression algorithms that allow any workstation to display the resulting video, even if it is not equipped with a camera. The resulting video is half-size grayscale at about 5 frames/second. This video facility is not enough to support full video conferencing with audio/video lip-sync. However, it is sufficient to provide a sense of the activities of other users and for attending lectures via Jupiter; in the latter case, one only needs to see the speaker's slides and hear the audio to get most of the benefit of a talk. Casual Interaction One of our goals in building Jupiter is to support casual interactions between its participants and to allow them to participate in the casual interactions taking place in the real environment of the laboratory. The use of audio is clearly important for this, because casual interactions must be essentially effortless, and speaking is easier than typing. We plan to provide other kinds of support, as well. Informal meeting areas are one example. In addition to the meeting rooms and offices, we envision areas that encourage casual interaction. The presence of a user in such a room would be an implicit invitation for conversation from others. One might keep casual use objects there, such as newspapers (automatically generated from wire feeds) and games. It is important that users be able to use these objects together, as this encourages conversation. We also want to provide facilities to encourage chance encounters. One example is to use computer-generated sounds to notify users of the arrival or passage of other users. These electronic "footsteps" would remind a user to check to see who else was in the area. Another example is to mix in a small amount of audio from adjacent rooms, if their doors are open. These would provide the snippets of speech that often draw newcomers into a conversation. Finally, we intend to equip the casual meeting areas of our laboratory building (such as coffee alcoves and lounges) with audio and video devices. These should allow Jupiter users to "happen upon" people in those areas and then to hold informal conversations with them. Telecommuting Many people currently spend some portion of their average week working from home, or telecommuting. In our experience, such people are effectively absent from the social milieu of the workplace, only "visible" in the form of occasional electronic mail messages, if that. We are interested in exploring that possibility that Jupiter can support a much more effective form of telecommuting, in which even remote workers can be active social partici- pants. Jupiter's relatively modest network bandwidth requirements, coupled with recent advances in telephone connection quality, should allow workers to use Jupiter almost as effectively from home as from work. ISDN telephone service is slowly becoming available from local phone companies thoughout the world, and provides two 64-kilobit/sec full-duplex channels per user at affordable prices. Jupiter would have to fit audio, windows, and varying amounts of video over such a connection. Audio can be compressed to as little as 13kb/sec, using techniques such as linear predictive coding, without major losses in quality. Our window-system protocol takes much less than half a channel because the interctions are at a high level of abstraction. This leaves one channel to use for video. Our experimental video procotols can send 5 frames/sec of grayscale video using 128kb/sec of bandwidth. Using only 64kb/sec, the quality is lower but still tolerable, especially for largely static scenes such as workers in their offices. For a talk, we can send single frames of each slide, which easily fit into a single 64kb/sec channel. The goal of telecommuting is to allow a worker to accomplish as much from home as they can by physically going to work. While Jupiter is not a full replacement for being there, it provides a good substitute for many structured activities, such as meetings. Beyond that, its value as a replacement for travelling to work will depend upon the extent to which the goals of casual interaction are met. 4 Project Status Both Astro-VR and Jupiter are currently running, though neither is yet ready for new users. All of the technologies mentioned in the paper exist in fully-functional form; all that remains is to tie them together and then start learning from our users. We expect that both systems will be in daily use by their intended communities by the beginning of the summer of 1993; we should be able to start saying something about our experience with the system at that time. References [1] Curtis, Pavel, "Mudding: Social Phenomena in Text-Based Virtual Realities," in the Proceedings of the 1992 Conference on Directions and Implications of Advanced Computing, Berkeley, May 1992. Also available as Xerox PARC technical report CSL-92-4. [2] Deering, Stephen E. and David R. Cheriton, "Multicast Routing in Datagram Internetworks and Extended LANs," ACM Transactions on Computer Systems, vol. 8, no. 2, May 1990.