Many years ago, when I was discovering the post-commercial text adventure scene, one of the community’s most important publications was XYZZYnews, a magazine about all aspects of the “Interactive Fiction” culture, as it was starting to be called.
I had been in contact with the editor, Eileen Mullin, since my game Ralph had been included on the accompanying disk for issue #12, and so I asked her if she would be interested in an article about MUD design as opposed to text adventure design. She was, and so the article was published in the next issue, which came out in 1997.
While the old issues are still available on the IF Archive, Eileen Mullin has long since withdrawn from the Interactive Fiction scene. I believe it might be a good idea to republish the piece here, as it has never been available on its own, at least not officially. (I’m not very familiar with U.S. publishing law, but I believe the default right without a contract – as is the case here – would be for the publication to obtain First North American Serial Rights, i.e. the right to publish the piece once, before anyone else, with all subsequent rights remaining with me. Since it’s highly unlikely Ms. Mullin would object, I’m going to assume that to be the current situation.)
So here it is. (I believe Ms. Mullin lightly edited my submission to better fit into the magazine, but this is my own original copy, slightly reformatted for inclusion on these pages.)
Dungeons, Dragons, Shovels, and Telepathy – A Brief Look at MUD Design
By Miron Schmidt
1 Introduction
“MUD” is short for “Multi-User Dungeon,” as most of you will know. There are a number of similar environments which have evolved from the original MUD idea, such as MUSEs, MUSHes, MOOs, and so on. In this article, I will only talk about MUDs – partly because I feel more at home in them, partly because the differences in terms of design aren’t terribly big.
A MUD, at the time of writing, is a text-only, multi-user, real-time environment, very much like a text adventure game, and very much unlike it.
Let’s focus on the similarities first. Commands are given to the MUD in short natural sentences, like “open the door,” or “wear the chainmail.” The complexity of these sentences depends mostly on the care the designer has put into parsing, as every object is allowed to define its own verbs and their respective syntaxes. It is quite common that one area may accept only very simple, two-word commands, while the area next door allows for unbelievably complex structures. Tubmud, the only MUD where I actually code, features a quest in which, at one point, the player is required to take a shrink-head by typing the command “take the shrinkhead of the orc shaman from the pillow on the pillar next to the western wall.” If the syntax isn’t followed exactly, the – hilariously funny – error message “Take the what of the what from the what on the what next to the which what?” appears.
Those “MUD quests” are small adventures that require a sequence of puzzles to be solved, much like little games on their own. The puzzles range from simple riddles (a character might expect an answer to a verse), over logical exercises, such as building a sand castle, to monsters that have to be killed in a role-playing game fashion. In fact, fighting is an integral part of MUDs: most employ complex combat systems that make the choice of armor and weapons an important part of playing.
2 Real time
While in most text adventure games, time progresses only between subsequent input lines from the player, encouraging her to think carefully about every action, MUD time runs steadily. This results, among other things, in time-critical sequences being rather hectic: players have to type their actions as fast and accurate as possible, and the consequences cannot be undone.
In design terms, much care has to be taken that the player’s input bears instant results. Redirecting input, for instance to confirm a dangerous attempt, is a definite no-no, if it isn’t done with extensive care:
A grizzly bear paces nervously up and down.
> pinch the grizzly bear in the side
Do you really want to do that? (y/n)
Suddenly, the bear wheels around, facing you with obvious wrath!
> run away as fast as possible
Please answer yes or no: Do you really want to do that? (y/n)
The bear hits you with a bone-crunching sound.
...On the other hand, the real-time environment allows for attractive little details: a clock that strikes the hour; a magic potion that stays in effect for five minutes (thus prompting the player to plan before quaffing it); a beautiful orchid that blossoms only once a month…
3 Multiple players
Multiple players necessitate multiple solutions. This is not an option; it’s a requirement! A stone block that you can’t lift because it’s too heavy, requiring you to drink a potion of cyclops strength just won’t do: three players will be able to move it without.
When designing messages, it is always vital to ponder all possible constellations of players: there are five possible kinds of players to be considered.
- The player who acts.
- The player he acts on.
- Onlooking players.
- Players in nearby locations.
- Players in distant locations.
Thus, if Belphegor zaps a wand of earthquake at Lliana, the following messages need to be printed.
- Belphegor: “You zap the wand of earthquake at Lliana. The earth shakes violently under her feet.”
- Lliana: “Belphegor zaps a wand of earthquake at you. The earth shakes violently under your feet.”
- Others in the same location: “Belphegor zaps a wand of earthquake at Lliana. The earth shakes violently under her feet.”
- Others in nearby locations: “Suddenly, the earth shakes violently.”
- Others in distant locations: “Suddenly, a faint rumble can be heard.”
Note the different use of “the wand” vs. “a wand.” Alternatively, “your wand” and “his wand” could be used.
4 Making it feel like a whole
Players have inherent capabilities that are to be regarded when designing objects and characters. Next to skills, stats (like strength or constitution), and visual characteristics (such as scars and tattoos), there is one power to be especially minded: the power of telepathy. In most MUDs (all I know, to be sure), players can “tell” and “shout.” Telling is the ability to telepathically communicate with other players, no matter how far away they are are; and shouting is the ability to scream something so loud that every other player will hear it.
If the player is transformed into something different, or his perception is manipulated, his means to communicate will change. LPMUDs (MUDs using an interface that was initially designed by Lars Pensjö) feature a curse that will transform the player into a frog. All shouts by this player will be transformed to
A big frog shouts: Hrribit! Hrriiibbitt!A friend of mine once designed a drug that, when taken, would sporadically cause the player to see things and, unknown to him, display reactions to that. For instance, he would get the message
You say: I feel perfectly normal again.while the other players in the room would see (if the player were called Geronimo)
Geronimo says: Argl! Argh argl!To offer some further examples for objects that will change the player’s abilities: a broken arm will drastically lower the player’s fighting skill; a chewing gum will muffle everything she says; being too drunk, a delicate combination lock will prove unopenable.
5 Object orientation
While in a text adventure game, the author is responsible for every single object, this is not at all true in a MUD. In fact, good programming will even consider those objects that didn’t yet exist when it was written.
The worst imaginable situation for a player is that when he tries to dig in, say, a mouldy haystack, he gets a parser complaint (“Dig where?”) while a shovel bought in the shop around the corner will dig perfectly well. As a programmer, one has to make sure that such puzzles are handled flexible enough: one has to create the process of digging in a way that rewards the idea, not the action, even if this means anticipating bad creations by other programmers.
As an example, if I wanted to place a tree in a certain place, which the player would have to tie a rope to, I could create a rope that allows to be tied to the tree. However, if the player then tried to tie a different rope to my tree, that rope wouldn’t probably know that it could be tied at all. Thus, a better solution would be to let the tree know that a rope can be tied to it: any object that fit the description “rope” would then satisfy my condition.
Proper object oriented design is the hardest part of MUD design. I might decide that a ladder would be equally suitable to climb my tree; so I would tell the tree that an object fitting the description “ladder” could be leaned against it in order to climb up. A rope ladder, however, fits the description and still cannot be leaned against anything. So I’d have to anticipate that possibility, too. In any case, whatever amount of work I would put into my tree, I could never foresee every possible solution: Superwizards’s Fabulous Device of Climbing Like A Squirrel wouldn’t work on it.
6 Conventions
To make object orientation easier for the novice programmer, it is a good idea to follow certain conventions or create one’s own: it can be queried whether a certain object is alive, a weapon, or edible (or all of the above, such as a lobster). If I created a quill, for example, I would allow it to write on everything that calls itself “paper,” “parchment” or “papyrus” — and additionally allow other objects to identify as “writable on,” so that my quill could be used to expand their description.
This works in the other direction, too. An antidote would offer to “heal poison,” so that a dangerous fruit would know its effects could be reversed by that potion.
Still, creators will have to foresee as many different uses of their items as they possibly can, since there will certainly be those other creators who choose not to follow conventions, however bad a decision that may be.
7 Finally, a quest is prepared
Writing a quest requires further considerations.
- How many players should take part?
- Will they need prior experience (combat, casting spells, etc.)?
- Will they need to bring special equipment (such as an empty bottle, or a rope)?
- How long will it take to solve it?
Players in a MUD cannot save their game state. It is therefore advised not to top 3 to 4 hours solving time for a long quest. At least, players should be warned if the quest is exceedingly long. Such a quest should additionally provide a special service to play in multiple sessions. The quest might by split into three parts, with every part only accessible if the earlier ones have been solved. The player could go back to the campaign office and register the key events he has solved so far. Or he might have a non-player companion who will keep track of his achievements and wait for him to begin a new session.
If the quest is designed for one player, what will happen if he brings a friend? If he brings two? An unscalable wall will be much less of a problem if one character can step on another’s shoulders. Sir Archibald the Knight isn’t all that dangerous if attacked by four characters at once. A trap door won’t be suddenly closed if one character guards it from above.
These possibilities will have to be thought of when writing a quest. A simple solution would be to shut out other players as soon as one has entered the quest (teleport device, force field, riding into battle on horseback).
8 Conclusion
Design decisions have far-reaching consequences in a MUD. A mistake often made by novice programmers is to design a MUD quest in the same way as a text adventure game: a MUD is something entirely different, even though it looks temptingly similar at the first glance.
MUDs, as well as all their numerous siblings, are interactive fiction on a different level. Not necessarily a higher level, but certainly different enough to be enjoyed as a new experience.
If you haven’t already – make up your own mind. I’ll be happy to lead you through the wonders of Tubmud. Just drop me a note. (Update: I’m including this paragraph for completeness, but it’s been so long I wouldn’t be a very good guide.)
The featured image uses a photo by Matt Seymour.
