Imaginary Realities 1998 October Edition

The second month into Imaginary Realities was a slightly smaller issue.

Summary of "Being an administrator" by Jack Thornton

1998 October, Authored a long-since-gone web site about admin'ing for MUDs

Running a MUD is more complicated than being a player. Be realistic about the time and money commitment you will need. You'll need all the skills of a coder and builder to start, or wait until you do. Don't expect to make any money, though it is possible.

Summary of "Beyond PKilling" by Sayeed

1998 October, "Sayeed from somewhere I am not certain of"

Online Role-Playing Game (ORPG) player kills PKs are detested, while monsters killing players makes games more fun. Player killers aren't confined to limited rooms like NPCs, they gloat in a out of context manner, and often target weaker players. Players killers are more ruthless than NPCs and loot more extensively than NPCs. Player killers ruin the entertainment value of the ORPG for newer players.

"The four major differences between Monsters and Player Killers which reflect badly on Player Killers are the following: Interactive Intelligence, Strategic Intelligence, Location Limitation, and Looting Habits." Any counter measures against unfun PKs built into the ORPG need counter or limit these differences.

Examples of counter measures: PK options enabled by players such as through a dangerous and hard quest. Require a certain level before PVP is enabled. Have heavily guarded routes for the protection of potential victims.

Summary of "Mud client tango" by Andy Lewis

1998 October, Former Discworld admin and current Nanvaent player. Authored Rapscallion MUD client

MUD client features should make new actions possible to the player, such as triggers, tickers or highlighting specific text to make it more visible.

When considering adding a feature to a MUD client ask the following questions.

  • How useful is the feature?
  • How many people would want to make use of it?
  • How difficult will it be to implement?

After selecting features for development, ask the following questions.

  • How would someone go about making use of the feature?
  • How far can the concept extend?
  • How will it integrate with the rest of the program?

Spend time getting the UI/UX planned out. "The interface will make or break a client."

Summary of "Natural Command Handling" by Scatter ///\oo/\\

1998 October, Authored a guide to using the MudOS parser

Older MUD systems used add_action() on objects, rooms, etc. to make commands available to players. "When several objects contain the same command, the order in which the driver will try them is unspecified." Several other problems exist.

MudOS adds natural language parsing to help resolve issues with add_action(). "Setting up a command system using the natural language parsing package does involve quite a bit of work and can be frustrating at times. Once done, though, it pays off big in several ways"

Summary of "Starting a mud" by David Bennett

1998 October, "(Pinkfish) is the founder and one of the admins on Discworld which was started in late 1991."

"A common problem with muds is that someone starts one without a clear idea of what they are trying to achieve." Decide exactly what type of MUD you are making before starting.

Second, choose a MUD driver or customize one to fit your needs.

"Starting a mud is a very lonely business, you can probably guarantee that you will spend months without anyone else online or anyone helping you much at all." As an Example, Discworld was a solo project with no user and only one programmer for nine months before other coders and users gradually joined.

Make your MUD's theme overly obvious. Put special emphasis on the descriptions and help files.

Keep tasks down to a manageable size to prevent getting overwhelmed. When working as a team, keep task assignments clear. Be careful not to over extend yourself.

Summary of "You call that a review!" by Ilya

1998 October, Ran a MUD listing and review site

MUD reviews differ from advertisements. Presenting a laundry list of features and lots of exclamation marks does not make a worthy review. Worthy reviews include the following.

  • mention limited gameplay details (classes, races, etc)
  • explain what you like about the game, and why
  • explain what you DON"T like about the game, and why
  • give anecdotes from your own experiences playing the game

"Bias is universal and unavoidable." Make it obvious. "Readers can and will make up their own minds."