Imaginary Realities 1999 August Edition

Summary of August 1999 issue of Imaginary Realities. Imaginary Realities was an ezine dedicated to MUDs.

Summary of "Dragon*Con '99" by Michael A. Hartman (Aristotle@Threshold)

Michael admin'ed and built Threshold RPG.

DragonCon is a popular gaming convention. Having a booth there was a great way to expose the gaming masses to MUDs that otherwise they probably would have never heard of. Threshold was the only MUD represented at the convention, and one of only two online games represented. The other online game was not remotely as advanced as a MUD even though it had a graphic interface and had more exposure to the gaming community.

The Threshold both provided a one page FAQ, and also a computer terminal for visitors to play the MUD. Many people were excited about the MUD, but had never heard of MUDs before. There seems to be a large, untapped audience for MUDs.

The two common negative comments were, "Where are the graphics?" and "I've played muds before, but they were boring and all the same."

Several players of graphics based online RPG's mentioned they missed playing MUDs, because there was a lot more social interaction on MUDs. "Those graphical games are really putting people's feet to sleep, and through good plots, interesting story-lines, and active preservation of the integrity of your game's theme, text muds can offer something players are really yearning for and yet not getting from the graphical juggernauts."

Many former MUD players that stopped by the booth had been turned off by the poor quality of writing and cliche implementation of the vast majority of MUDs. Many of the existing MUDs are poor clones of each other, suffering from "stockmud syndrome". The "stockmud syndrome" drives people away from playing MUDs.

The best part of running the Threshold MUD booth was meeting many Threshold players in person. It went so well, they planned to meet again at the smaller convention, MOCtoberfest.

Summary of "Muds as Social Learning Environments" by Dianne P. Butler

Soleil on Medievia since September 1995.

Learning takes place in Multi-User Domains (MUDs), but in a different way than schools and the real world. Medievia MUD, with a 15000 player base and hundreds of users often MUD at the same time, is one of these MUDs where learning takes place.

"Muds encompass the combination of both imaginary situations and rule-governed play." Medievia (and other MUDs) teach memory, game theory, coding, typing, social skills, English skills, reading comprehension, economics, management/leadership, responsibility, and of course, imagination.

The author performed a survey across several sites and usenet groups about learning experiences of MUDders. Typing and reading comprehension improvements were common. English skills improved for foreign players, "not only in reading comprehension but also the acquisition of idiomatic expressions, colloquialisms, slang and word patterns." One responder's child improved their reading skills to three grade levels above their current grade in school.

Medievia and other MUDs have allowed home-bound people to have social interactions that they would have missed out on otherwise. Other players foster relationships with people they would have never met in the IRL. General social skills improved for players of MUDs. From one of the responses to the author's survey: "Around November of last year I purchased a computer for my terminal nephew that was living with me…The game was a way for him to interact with people outside of hospital staff. It gave him joy in his last days and this was a great benefit for him."

Clans in MUDs also help players learn social skills. They teach teamwork. Clan leaders learn leadership skills.

Medievia and other MUDS foster cross culture interaction and awareness. MUD players come from every culture and country. They meet in-game and learn and share each other's cultures.

MUD admins additionally learned skills involving helping players, creativity skills related to building the MUDs, coding skills, leadership, and management. Admins learn skills involving fairness and impartiality. They learn to balance responsibilities with having fun.They also learn to deal with constant criticism and praise from players.

Not all players and admins feel they learn from playing MUDs. However, they can't help but learn, even if they don't realized they have.

There is much potential for creating MUDs specifically with the aim of teaching. One such MUD is Moose Crossing that has the target of teaching children through directed projects. It aims to teach coding, reading, and writing.

The author cited the following: 


Bruckman, Amy. (1994). Programming for Fun: Muds as a Context for Collaborative Learning.

Available: ftp://ftp.cc.gatech.edu/pub/people/asb/papers/necc94.txt

Bruckman, Amy. (1998). Community Support for Constructionist Learning.

Available: http://www.cc.gatech.edu/fac/Amy.Bruckman/papers/cscw.html

Chan, Amy. (1998). Muds as Social Communities. Available: http://www-personal.umich.edu/~aschen/MUDuse.html.

Nicolopoulou, A. and Cole, M. (1993). Generation and Transmission or Shared

Knowledge in the Culture of Collaborative Learning: The Fifth Dimension, Its Play-World and Its Institutional Contexts, in:

E.A. Forman, N. Minick and C.A. Stone (eds): Contexts for Learning, New York: Oxford University Press.

Reid, E. (1995). Virtual Worlds: Culture and Imagination. Cybersociety, 165-167. Thousand Oaks, CA: Sage.

Sempsey, James III. (1998). The Therapeutic Potentials of Text-Based Virtual Reality. The Journal of Mud Research. [online serial].

Available: http://journal.pennmush.org/~jomr/v3n2/index.html.

Vygotsky, L.S. (1978). Mind in Society. Harvard University Press
Wells, Gordon. (1999). Ontario Institute for Studies in Education, University of Toronto: "The Zone of Proximal Development

Avand Its Implications for Learning and Teaching."ailable: http://www.oise.utoronto.ca/~gwells/resources/ZPD/html

Summarizer's note: The MUD discussed in this article is still going strong after 30 years of availability for play. The author is also still listed on the site as having an admin role. This gives a lot of power to the claims in the article.

Summary of "Putting the 'Game' in your RPG" by Aaron "Ajax" Berkowitz

Ajax, AKA Dyrewulf, has been a builder/admin on several MUDs for several years.

MUDs are role-playing games. They need to balance the role-playing and gaming aspects of what they are. Otherwise, they lose their flavor.

Some people complain that class systems are too limiting and not realistic enough. However, in medieval times, professions were dominated by guilds and apprenticeships. Trade secrets were common, and kept secret to ensure success and high pay of those in the professions. "People often forget that the Dark Ages were different from today, where you can simply pick up a book or sign up for a class if you want to learn something. Back then, your trade was your livelihood, your social role, and your legacy to your children."

People complain that experience levels are not realist. For instance, in combat, sometimes an inexperienced person bests someone with years of training because of a lucky hit. "A 17-year-old might indeed be able to kill a veteran warrior with one lucky blow; but if the warrior is experienced enough, that blow won't land."

If you max out your level in a class on a given MUD, the game must be enjoyable. Start a new character with a new class, and continue to enjoy the game. No sense giving up on the world, if you max out your levels.

Summary of "The Command Line Interface" by George Reese

George ran the LP MUD FAQ, hosted Imaginary Realities, and developed code for MUDs.

We can't recreate Star Trek's holodecks. MUDs have to use the 1977 approach to translating thought into game actions, ... namely the keyboard and command line interface.

Failed commands should result in the following:

  • Tell player the action is unsupported. ('xyzabc sword')
  • Tell player the action doesn't make sense. (throw spaceship)
  • Tell the player to clarify the action. (kick goblin ... when multiple goblins are present to kick)
  • Carry out the command with unintended consequences. (jump over river ... that is too wide to jump over)

Here are the five components needed for implementing actions:

  • Rules - define syntax of action commands.
  • Parser - match the command to the rules syntax, and the tokens to the current player's room
  • Synonyms - aliases for the command
  • Command handler - code for performing the action's command
  • Error messaging - printed feedback to the player if something goes wrong
A response to a bad action command should never be simply, "What?"

Commands should always be global, even if they only succeed in a specific room or with specific objects. The commands should still be attemptable. Having local commands results in different commands for the same action based off the room or object involved. "For example, one rock from one coder should be thrown using 'throw rock' and another rock should be thrown using 'toss rock'."

Summary of "The life of a mud player" by S.E.

MUD players follow a pattern. First they are in the honeymoon phase where they love the MUD, the escape from reality, and gain new friends on the MUD. Next, they start to find things they don't like about the MUD, and lose friends and/or make enemies. Eventually, logging in on the MUD becomes more of a burden than a release from life's toils. Finally they hate the MUD they used to love, feeling they need to stop neglecting their real life outside the MUD.

This pattern resolves itself with one or more of three outcomes.

  1. They quit. Usually this involves a posted rant(s) about the evils to wasting time.
  2. They stick around, but hate everything and everyone on the MUD, because the "good old days" were so much better.
  3. They try out #1 and #2, but finally settle on a happy medium between life and playing the MUD.

Summary of "The Mud Situation" by James Wadsley

Look for James as 'Shaggy' on Discworld.

In the real world, situations of a location change constantly. "Little everyday scenes play themselves out, often leaving little things like splatted plums or pigeon poop to show what went before."

Most MUDs provide rooms that are static with an occasional random message appearing in the chat. It is more satisfying if a scene (one or more) unfolds in the room over time.

Here is a sample situation (scene) the author described. 

Starting message:
"Pigeons flutter down to the pavement from above."

Extra room description text:
"There is a flock of pigeons here."

Item:
({ "pigeon", "There are half a dozen fat little pigeons pecking at the ground." })

Chat messages:
"A pigeon mistakes some string for a worm and gets all excited."
"A pigeon who just found a hunk of bread is mobbed by the rest."

Ending message:
"A cat leaps among the pigeons and they scatter with a flurry of wings."

Have situations begin and end at random times and have events happen at random times. Let the character enter the room when the scene is already in progress, for a more immersive feel. Having multiple, progressive situations through the day and night can have a sense of development and conclusion.

Situations don't have to have any relation to a quest. They can have as their only goal, the addition of adding depth. Or, can be used as a way to introduce unseen MOBs that later in the scene enter the room.

For larger areas with several or many rooms, multiple scenes could be shared randomly between them, with some details like names and descriptions randomly generated. Most rooms wouldn't have anything special going on most of the time, but eventually all of the scenes would cycle through all the rooms.