Imaginary Realities 1999 July Edition

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

Summary of "All Mudlists Are Not Created Equal" by Andrew Cowan

"Andrew Cowan runs The Mud Connector."

The author used "The Mud List" and Doran's List. He was dissatisfied with the MUD lists of the day, because they usually didn't even have a description. It was difficult to determine what MUDs you would enjoy playing from the available information on the lists.

"The article in the June IR gave me the impression that the author feels more is better. I disagree with this generalization to some extent. TMC's list is definitely smaller than the 3000+ muds listed in mudlinks://, however, every mud on our list has one thing in common, they all came to our site and made a submission to be included in the list." Website self-promotion has become common, if not standard, on the web. It should be expected that MUD sites also self-promote if they want traffic.

June's article about MUD lists is correct. 89%-93% of the author's time is spent verifying and re-verifying the continued accuracy of the data about MUDs and whether they are still around. Sometimes poor information is the result of honest mistakes, and sometimes they are outright lies in an effort to drive traffic to the MUDs.

Summary of "Distance tells" by Amanda Carlston

Amanda was pursing an English Education degree. She had three years of MUDding experience.

The page (AKA tell) command sends private messages to other account holders. (Sumarizer's note: This is long before cellphones and texting were common.) Page and tell keep non-roleplaying messages private so they don't break immersion of the game. They also provide long-distance communication in the MUD at no cost, when getting a face-to-face conversation going in a shared room is impractical.

"The command has some problems. It can be hard to coordinate with more than one person at a time through the use of them. One person has to act as a relay, passing information through to others as they get it." Confusion of conversations is common, leading to mistells.

"The tell command is very unrealistic, to be certain. It is akin to being able to talk mind to mind, which is not something that has been scientifically proven as being possible. However, it is a very helpful command, and will probably be with us for many more years until something better is brought about."

Summary of "Level vs Non-Level" by Zane T. Insane

Zane had two years of MUDding experience, played on MUDweiser, and planned to start a MUD.

MUDs started out following the early D&D and RPG convention of using levels to track advancement, with skills adding even more opportunities for advancement. Levels have the disadvantage of (usually) maxing out at some point, taking the fun out of players that strive for the thrill of gaining their next level.

"Getting rid of levels is an easy step. The only problem is that gaining levels is one of the easiest ways of tracking advancement from a coding viewpoint. Once they are gone, how do you advance? A meta-type system is usually implemented to where you use XP gained from monsters to practice and train. So instead of killing monster after monster to gain a level to gain the practices and trains to advance, you simply kill monster after monster to gain XP to practice and train and advance."

After maxing out levels, players must learn the thrill of interacting with other players, and PvP combat. Short of using some future, yet-to-be-developed AI, PvP is the greatest combat thrill in the game. You an never fully anticipate the behavior of an intelligent human player.

How much realism is too much. A fully realistic MUD wouldn't be fun. "In real life if I slashed someone with a sword I would not do damage to their hit points, they would be seriously injured. It's just that in a game, it would not be too fun if you were to be hit one time and die." The fun MUD is a MUD where you can escape reality for a while.

Summary of "So, you want to code a mud?" by John Patrick

John was a software/hardware engineer based out of the Chicago area. He was Reorx on Ansalon, a DragonLance based MUD.

"The essence of computer programming: finding the correct way to describe to a computer what you want it to do."

The author explains the complexities of computer programming, including machine language and compiled languages. Python isn't included in the list of human friendly languages, but Cobol is, ... as a joke.

The author recommends studying a good programming book, such as A Book on C by Al Kelley and Ira Pohl; reviewing lots of well written code; and practicing writing larger and larger programs before tackling writing code for a MUD. "I say that mud code has to be some of the worst C programming style and code I have ever seen." [Summarizer's Note: That's the truth for MANY MUD code bases.]

Summary of "Who are you?" by Michael A. Hartman (Aristotle@Threshold)

Michael admin'ed and built Threshold RPG.

Requiring player's to interact before they see names adds significance to social interaction. This is called an introduction and recognition system, or more simply and intro system.

1) What are the goals for your intro system?

Temper your intro system design based off goals you have for your MUD. A strict intro system makes sense in a PvP based MUD, but not as much sense when you want your MUD to encourage more player social interaction.

2) Is your system playable?

Make sure it isn't onerous to get introduced. Also, make sure unintroduced players can be distinguished from each other.

The introduction "syntax could be something like 'introduce to Foo' or even 'introduce Foo to Bar'." Never make it mandatory that introductions be by a third party. Require introductions to be accepted rather than automatic. It might be a good idea to have a forget or unintroduce command for situations that arise where you don't want to be remembered.

3) Keep the intro system code lean.

"The other thing to keep in mind is that most likely, whatever function you code to check if Person A knows Person B is going to get called a LOT. It will be called every time someone walks into a room with people in it, every time they use any "who"-like command, every time they type "look" or "glance" or any other visual command in a room, etc."

4) Remember security and rules compliance.

If there is a need to report players for rules violation or harassment, the intro system needs to not get in the way.

Summary of "Wilderness Systems for Muds" by Alex Kallend

Alex was a software engineer with 20 years of D&D experience and 11 years of MUDding experience. He ran the Lensmoor MUD.

In the traditional levels-based map system, adding new low levels becomes a challenge because the higher levels need to be traveled thru to get to the new low levels. High level characters can get to them, but find them boring, and low level characters die trying to get to them. A wilderness system fixes these issues.

"The wilderness is generally a large grid of rooms, to which the other zones of the mud are linked." The wilderness is meant to connect exploration zones, not to be an exploration zone. The wilderness should be big enough to make the world feel big. Also, the same commands that work in exploration zones should also work in the wilderness.

Wilderness areas should be dynamically generated. Static rooms the size of a wilderness will waste memory. Define the rooms of a wilderness using a byte per room with the first nibble indicating terrain type, and the second nibble containing flags. Using this technique, 1,000,000 rooms will only occupy one meg of memory.

The author uses the following example:


With 'F' meaning forest, 'D' meaning desert, 'H' meaning hill, 'M' as mountain, and lowercase letters meaning there is a road present, the following block shows how a section of wilderness can be defined in a file:

FFFHHMMmhdDDD
FFFFHmmHHDddd
FFFhhHMMHDDDD
FFfDHMMMHHDDD
FfFFHMMHHDDDD
fFFFHHHMMDDDD

Don't keep the whole world's map in one file. It will kill access times. Give the dynamically generated rooms last access timestamps so cleanup is performed in the order of least need. Grow the list of rooms, if in high use, and shrink the list of cached rooms if in low use.

When dynamically creating wilderness rooms:

  1. Create the description of the room. If including random features in the room, seed the random features based on the room's coordinates, so they are always generated when the character enters the room. This could be very important if the player is using those random features as landmarks to navigate by.
  2. Create the exits
  3. Add random MOBs to the wilderness rooms. MOBs should be rare and of low level. The wilderness is not meant for leveling the characters. It is meant for travelling between exploration zones. High level MOBs should not block passage of low level characters to low level exploration zones.
  4. Add any persisted data about the room.

If too many MOBs are generated in the wilderness and are moving from room to room, you could cause resource issues with your MUD server. Preveninting MOBs from moving from room to room of their own accord mitigates this issue.

Pathfinding through the wilderness should be disallowed, as it generates a lot of rooms quickly.

Large wildernesses are awful for players to navigate. Adding a 'navigate' skill of some sort will help.

Make sure rooms load properly and aren't cleared from cache if a player saves their game there, or logs in there.

"A zone may have multiple exits that lead into the wilderness, and yet only one entrance from any given direction. This can lead to some exits not returning to where they came from." Limiting exits and entrances might help.

Using the wilderness as a quest site for finding a MOB that moves around can be a fun challenge.

Also, consider using the wilderness zones for resource gathering. They are a rich resource for player craft items.

This technique of wilderness zone generation provides a consistent scale for world maps. This makes it easier for players to map out the world and find their way around. Also, a truly massive world can be generated without overusing the MUD servers limited resources.