Multi User Domains

A MUD is a world you enter through language. You read about your surroundings and type what you want to do. Other people are there too, acting on the same places and objects. If someone takes the lamp, it is gone when you look for it.

Langscape, the system I am building for Black Rip, began as an attempt to give that kind of world a modern multimedia client. It also brought me back to a part of MUD culture that interests me: people learning to program by making things for one another.

Worlds people could build

Roy Trubshaw began the original MUD at the University of Essex in 1978. Richard Bartle helped develop it and took over in 1980. Later known as MUD1, it let several people inhabit the same text adventure. Trubshaw wanted a reusable system, with a language for defining worlds, so a new adventure would not require a complete rewrite. ^{1, 2}

The MUDs that followed took different forms. Some concentrated on combat and advancement; others became places to socialise, teach or build things together. LambdaMOO and MediaMOO belonged to that second tradition. MediaMOO was a meeting place for researchers, with much of its environment built by its members. ^{6, 7}

For some participants, making things became their introduction to programming. They had a reason to learn, people who could help, and friends who would use the result. Amy Bruckman and Mitchel Resnick’s MediaMOO research described twelve adults who had learned to program for the first time on MUDs. ⁶

A room could be a meeting place or a classroom as readily as part of an adventure. The names Multi-User Dimension and Multi-User Domain reflected how far these environments had spread beyond dungeon games.

The branch that became the MMO

Graphical MMORPGs carried MUD ideas to a much larger audience. Ultima Online pursued a simulated world shaped by its inhabitants. EVE built around player activity too. World of Warcraft’s success made the theme-park approach particularly influential: guided quests, authored stories, and dungeons and raids that groups could run repeatedly. ^{9, 10}

That split predates graphics. Some combat MUDs already revolved around repeatedly clearing areas suited to a character’s level. Others allowed more freedom to build or change the environment. The choice of text or graphics tells you little about how much control inhabitants have over a world. ^{3, 9}

Collaborative Programming

In a programmable MUD, builders could change the world while others were using it. They might add an object or change how a door worked, then see people encounter the result. Who could make those changes depended on the system. Wizards often held broad administrative powers; other participants might have programming rights over their own creations. ^{5, 6}

LPMud supplied a language called LPC for programming world behaviour. LambdaMOO kept objects and their code in the world’s database. With the right permissions, a programmer could inspect and replace an object’s verbs while the server continued running. ^{4, 5}

Alan Kay and his collaborators developed a related approach in Croquet. At Stanford in 2003, Kay described a network of shared worlds linked by portals, drawing a comparison with the Web. People could develop those worlds together using tools within the running environment. Using and programming the system were part of the same activity. ⁸

In Second Life, creators put scripts inside objects to make them respond to people and events. A door, vehicle or tool can contain a program that communicates with other scripted objects. People encounter one another’s code through what it does in the shared environment. ¹²

Croquet and Second Life use 3D, but this kind of environment does not require it. Shared objects and their operations can be presented through text, a two-dimensional interface or a specialised application.

Langscape

My starting point was the client. Most terminal MUD clients present descriptions, dialogue and actions in a scrolling feed. I wanted prose alongside scene imagery, with character activity and ambient sound helping people follow what was happening.

I thought about how graphical browsers such as Mosaic changed the experience of using the Web. ¹¹ The move from IRC to Discord offered another comparison: text conversation remains central, with other media around it. A MUD could retain its language-based interaction while making room for images, video and sound.

The client presents a world that runs independently of it. A graphical interface, a terminal interface and an agent can each interact with the same state and rules. Black Rip is where I am developing the graphical client.

Language was the next part to reconsider. MUDs and parser-based interactive fiction already accept instructions resembling English, such as “take the lamp.” Traditional parsers usually require particular words and sentence structures, so players learn the vocabulary the game recognises. ²

An LLM can interpret a less rigid instruction and translate it into a command. The simulation then applies its rules, determines the outcome and records the change. After that, an LLM narrates what happened.

SLIP supplies programmable behaviour within the world. Its multidispatch allows the same verb to invoke different code depending on the objects and context involved.

A narrative sandbox

For Black Rip, I want a narrative sandbox: a small group of friends sharing a world whose stories develop through play and carry forward into later sessions.

The creator supplies the setting, background lore and rules. Players make decisions within it. Characters need their own knowledge and memories, so that what they do later can depend on what they experienced earlier. A large part of the work is keeping that history consistent with the state of the world.

Building software together

The programmable environment also suggests uses beyond games. A location could offer a set of operations through a specialised interface and serve as an application within the domain.

Imagine a shared inventory. One person writes a tool for adding and inspecting items. Another adds a reservation system that works with those same items. An agent adds a reporting tool that reads the inventory and reservations. The programs call one another’s operations and act on the same persistent objects.

In that example, the participants build parts of an application as they use it. They can extend something another person or agent has made, with access governed by ownership and permissions. A location could present a conventional interface to these tools; it would not need to look like a room.

Black Rip gives me a reason to implement persistence, programmable behaviour and access control. I also want to find out what people and agents can build with them outside the game.

Sources and further reading

1. Richard Bartle, Interactive Multi-User Computer Games: Introduction, 1990.
2. Richard Bartle, Stuck in the MUD, 1985.
3. Raph Koster, Are MUDs and MMORPGs the same thing?, 2006.
4. LDMud history.
5. Pavel Curtis, LambdaMOO Programmer’s Manual.
6. Amy Bruckman and Mitchel Resnick, The MediaMOO Project: Constructionism and Professional Community, 1995.
7. Pavel Curtis, Mudding: Social Phenomena in Text-Based Virtual Realities, Stanford seminar abstract, 1992.
8. Alan Kay, Croquet: A Collaboration Architecture, Stanford HCI Seminar, 25 April 2003; David A. Smith, Alan Kay, Andreas Raab and David P. Reed, Croquet — A Collaboration System Architecture, 2003.
9. Raph Koster, Sandbox vs themepark, 2022.
10. Blizzard, World of Warcraft Classic manual; CCP, EVE Online.
11. CERN, CERN celebrates Web anniversary, 2003.
12. Linden Lab, LSL Reference and Script Recipes. Object behaviour, events and communication between scripts in Second Life.