Summary of “eBay Launches Virtual Property” by Jon Katz

Jon was a writer for Slashdot, where the article originally appeared.

Digital property is the huge story that the media is missing. MP3s, e-trading, open source software, and virtual property are a completely new type of property. Virtual properties includes in-game items and characters. ” It suggests that space on the Net isn’t infinite after all, and that people may have to begin paying or trading for access to the parts of it they want to use. Also that people with money can alter the balance of Net and Web culture suddenly and dramatically.”

Ultima Online has introduced the world previously only known in MUDs to a greater audience, including real world purchases of in game items on eBay. This is bringing urban and suburban problems of resource scarcity into the virtual world. The whole nature of gaming has changed.

“People are trading real-world money for virtual property.” The first case of trading is reported to have been a firefighter from Texas who got a second job leaving him without time to play Ultima. He offered his game account for $39 and sold it for $521.

Summary of “How it Really Happened” by Richard Bartle

Richard ran mud2.com MUD server in the UK. He was also the co-editor of the Journal of Mud Research

Roy Trubshaw wrote the first MUD using MACRO-10 machine code for the DECsystem-10. It was essentially just a few rooms that permitted chat. His second version was also written in MARCO-10, and had definitely gained the name of MUD by then. The second version allowed users to add rooms and commands. This was quickly used to destroy the theme of the game, which was exploration and adventure.

Starting in 1979, he rewrote everthing in BCPL, finishing around Easter of 1980. Most people refer to this as the original MUD, but it was really version 3. When Roy left Essex, the author took full control of the MUD. At this version of the MUD, two people could be in a dark room, and only the person with the torch could see.

“Roy’s reasons for writing mud were twofold: to make a multi-player adventure game; to write an interpreter for a database definition language. The language he developed was rather crude, and I had to hack it to get it to do a lot of the things I wanted to do. This was partly because Roy didn’t know the kind of things that would be needed from a game-design perspective, and partly because the multi-user aspect came to dominate the project. However, the core of the database definition language (mud definition language – MUDDL) was all Roy’s. I didn’t add it, I added TO it.”

“Mud was created and written by Roy Trubshaw and Richard Bartle at Essex University in the UK.”

Essex University linked with ArpaNet in the USA, and in the spring of 1980 the MUD had its first external players. There is a reference to an earlier multiplayer version of Zork in the December 1980 issue of Byte magazine. However, the creators of the first MUD were unaware of it and have never seen it, so don’t know how MUD-like it was.

The author used the base code for the MUD to create a game called Valley. With permission, some other games were created using the base code, including ROCK, BLUD, UNI and MIST.

After leaving Essex, the author let them run MUD for a few years, but then took it away, because it was being corrupted by new undergrads. “And besides, they’d removed my name from the arch-wizard list!”

“University authorities were kind enough to allow people to log in from the outside solely to play mud, so long as they did so between 2am and 6am in the morning (or 10pm to 10am weekends). Even at those hours, the game was always full to capacity. Thus, mud became a popular pastime throughout the modem-using computer hobbyists of Britain. I also sent copies of the code to Norway, Sweden, Australia and the USA.”

The original game was licensed to CompuServe under the name of “British Legends”.

Summary of “Mob Programs” by Jeremy Music

Jeremy Music ran the MUD “Wyld Knight: The Land of Erehwon”

“Mob programs can be as simple as purely a way to improve the role-playing aspect of a mud, by having the mobs do and say things in response to actions by the players, and as complex as an entire automatic questing system based in mob programs.” This was accomplished in Diku-style MUDs by use of special procedures.

Mobprogs are variations of Mob Programs, and include ROM, Circle, Merc, and Envy. They were written N’Atas-Ha and DG Scripts. Those are specific to Circlemud.. Other scripting implementations are found in Smaug and RoA. Overall, all scripting implementations follow similar guidelines.

 

• Triggers: the MOB is triggered by an action and has a percentage chance of reacting. The trigger may be as simple as entering the room, and have an action as simple as greeting the character. The MOB can also respond to dialog.
• Variables: substitution of variables in text allows for names and gender-specific pronouns to be used in customizing dialog with the MOBs.
• Commands: Most MOBs can use all the commands a player can use, if programmed to do so. Usually, the MOB’s list of permitted commands is a safe subset of the admin’s (wiz or wizard) commands. Many times the commands for MOBs are prefixed with ‘mb’ so it is obvious they are for use by MOBs. Display messages for MOB commands are usually customized by the author.
• Ifchecks: These are IF commands that prevent the MOBs from reacting to other MOBS, or limit the interaction with players based off characteristics of their characters.

 

The most useful reason to use mob programs is to create quests for players. “Mob programs go a long way toward creating a “living, breathing” mud that is more enjoyable to players and Implementers alike.”

Summary of “Rules of Immship” by Brant Harvey

Brant was Azhanith on DragonRealms. Then he was Immortal staff on Aarinfel MUD.

The author has been an Immortal on a MUD long enough to find it boring. “I’ve found Immship is a lot easier to bear if you keep in mind four rules, which I continually pay a sort of hypocritical lip-service to.”

First, “Get Over Yourself.” Your world as a creator on the MUD is not as important as you think it is.

Second, “Don’t Let the Players Get to You.” Players throwing tantrums, being losers, or getting angry at you is going to happen, … a lot. Relax. Take a deep breath. Let it go. They want basically the same thing you want out of the MUD.

Third, “Don’t Let the Imms Get To You.” There’s going to be political games. There’s going to be insults. They’ll be lazy. They’ll complain about you and your work. They’ll disagree with you. Remember, the other Imms are dealing with you, too. You want basically the same thing from the MUD. “Be calm and conciliatory, and don’t ever convince yourself that the other person is the irrational one.”

Fourth. “Have Fun.” It’s a GAME! If you’re not having fun being an Imm, why are you wasting your free time on it. Chant to yourself, over and over, that “It’s a game,” until you remember it.

Summary of “Toei Rei, a Mud Robot” by Paul McCarty

Paul listed several (I’m sure) great chatbot resource links, but like most information in the these “Digital Dark Ages” have gone missing.

ELIZA was chatbot created by Joseph Weizenbaum at MIT in the mid 1980’s. It was included in MUDs to simulate human interaction. Hundreds of chatbots followed.

ELIZA used the trick of searching for keywords, then using a canned response with keyword substitution for responding the the user. ELIZA always answers with a question. “ELIZA really knows nothing at all except how to parse sentences and reformat them in the form of a question.”

A more advanced bot, Julia, entered the Loebner Turning Test competition in 1994. Julia keeps track of conversation topics and uses anecdotes about those topics.

“Many [chabots] have been programmed to learn from their conversations, play games like hearts, and give directions on muds, in addition to just carrying on a conversation.” The author wrote a chatbot called Toei Rei in the Perl programming language. Toei Rei can get the hiccups, get tired, get hungry, get upset, control puppets, answer email, sing songs, and read poetry. Also, Toei Rei can be puppetted by other players for role playing purposes.

Toei Rei is made from Perl scripts and some flat files for rules and data. “All the Perl scripts do is open a socket connection, logon to the mud, and loop over all the rules updating the state of the bot. The loop includes a one second pause to limit how fast Toei can respond to things she hears, to make her conversations and actions more realistic.”

The author gave a lot more technical details of how Toei Rei was written, but a summary would not suffice to relate them.

At the time of the original article’s writing, Toei Rei was still a work in progress. Occasionally, code changes result in the chatbot getting into an infinite loop, or to start talking to herself. The chatbot could conceivably add features to MUDs like answering emails about rules, finding players’ locations, or giving the status of the MUD. Several instances of Toei Rei running on multiple MUDs could also pass information or MOBs back and forth between servers.

The author gave out a link to the source code for Toei Rei. Unfortunately, the link is dead, and the code does not appear to have been added to any currently running repos like Github.

Summary of “What is Remort?” by Natalia

Natalia ran Game Commando’s with Ilya (her husband).

Remort is a MUD term for starting over. On rare occasions, remort is referred to as rerolling.The ability to remort is implemented differently in different MUDs. Some have an experience requirement, while others have a huge fee or completing certain quests. Some systems require a mod or admin to issue the remort command.

Usually, a remote starts your character back at level 1, but retains all money and equipment. Mana, hit points and movement may also be retained. Skills and spells are retained. Remorting is usually optional.

Besides the advantage of having advanced skills, spells, etc at a low level, remorting may open up more advanced classes, or even a second class or special spells/skills that we’re available until a remort. Some MUDs provide additional skills/spells/classes for third and greater remorts. Even some equipment can be made available to remort characters, but not unremorted characters. Many MUDs only allow multi-classing by using remort.

Remort “gives your higher level players something to continue to work towards or for.”

Summary of “Dynamic Room Descriptions” by Eli Stevens

Eli was a MUDder with over five years of experience.

The first time a player sees a room, they read the description. After the first time, they turn on ‘brief’ descriptions and never read descriptions again. This is because: 1) The descriptions are static, not dynamic, so boring after the first read; 2) the descriptions don’t reflect what is happening in the MUD. If there is a blizzard at night, the birds should not be chirping in the soft sunlight. 3) Usually the descriptions are bland.

A MUD could use a markup language for descriptions. The markup would provide descriptions that are only displayed when the conditions are met. The following is a quoted example from the article of a floor description that would only be displayed if the player looked at the floor.

<FLOOR DESCRIPTION>
<cloudless, hazy, partlycloudy, cloudy, darkcloudy>
Cracked, dry and covered in a fine brown dust,
</>
<lightprecipitation>
Slickened and streaked with a thin brown mud,
</>
<heavyprecipitation, storm>
Awash with mud and refuse,
</>
the cobblestones paving the streets look worn. Years of use have cracked them and dug long ruts filled with

<cloudless, hazy, partlycloudy, cloudy, darkcloudy>
dust and pebbles.
</>
<lightprecipitation, heavyprecipitation, storm>
dirty rainwater and rotting garbage.
</>

</FLOOR DESCRIPTION>

Using a system of description like above would provide better detail and realism based on the actual state of the current room. This does increase the builders’ work when creating an area. However, in many areas, there is a lot of default text that can be reused, such as, the roads in adjoining rooms would look pretty much the same.

“These kind of touches are what make muds stop being scrolling text and become a world.”

Summary of “Game Critique” by Marian Griffith

Marian is an experienced Role-playing gamer, and ran the Overloard project.

Ralph Koster points out that MUDs suffer from a lack of professional critique. The Mud Connector and Game Commando websites offer some amature reviews, but that is lacking a shared vocabulary and shared criteria for comparrison.

In order to improve general reviews of MUDs, a shared vocabulary must be provided. The author gave the following list of terms, partially based off the Mud-Dev list.

 

• Acting – generally more immersive than role-playing
• Artistic quality – The detail and richness of the descriptions and mechanics of the MUD.
• Bartle’s Suites – “Richard Bartle came up with an influential article about four distinctly different playing styles (this is published in the Journal of Mud Research). He named these after the suits of a card game.” The four types of players are Explorer, Killer, Socializer and Achiever.
• Consensual and Non-consensual – Do players get to choose what happens to their characters? Is there PvP, no PvP, or limited PvP based of area or arena? MUDs tend to exist on a spectrum of consensual to non-consensual.
• Completeness – How much detail is in the game? Is the size of the MUD world large enough? Is the gameplay rich enough?
• Community – Not designable. Community emerges due to the large number of players. “In general a greater variety of things that can be done and ways to express identity are enough to get the process started. If a common enemy is introduced or allowed in the game, that also is a strong way to encourage community forming.”
• Elder Games – Sequels to the initial goal keep the players entertained after the first goal is achieved.
• Game Oriented Play, or GOP – the player tries to beat the game. Role-playing is not the goal. Leveling up, might be the goal.
• Goal variety (Kill the Foozle) – Are there a large variety of goals the player could chose from? “In the typical mud, the game has a single goal (reach the highest level) that can be achieved in essentially one single way (kill the monsters). All other tasks are either utilitarian or boring (and frequently both).”
• Immersive (game)World and (game)Play
• Marian’s Tailor Problem – “Marian’s problems with the current online games is that there is no way to advance in the game without being involved in some type of combat… Then another concern, I guess, would be that even if you could advance totally without combat, what would keep the combat type players from seeing you as easy pickings…” -Brandon Cline
• Open Ended Goals – Is there a single game-winning goal, or many obscure goals that can be solved in a variety of ways and keep the players engaged? The goals probably won’t have obvious solutions until the game has been played for quite a while.
• Player versus Player, or PvP – Players killing players in-game.
• Policing – Rules enforcement. This may be handled by players, if given special tools. For policing to be effective, some sort of punishment system must also exist.
• Realism – How much sense do the laws of the game’s universe make? This might refer to monsters always being about the same strength when they are the same type of monster. “Another example of where the game fails to be realistic is when the frame of reference is mixed up. A game where smurfs, hobbits and Chtulhu wander side by side can not be considered realistic, simply because these different creatures do not belong in the same universe.”
• Role (oriented) Play, or RP – the player attempts to be part of an immersive, story-telling or acting experience.

 

Summary of “Games as art” by Raph Koster

Raph was the lead designer and programmer for Ultima Onlilne .

Art communicates something via the medium chosen. A MUD being written for entertainment does not prevent it from being an art form, too. “Mere entertainment becomes art when the communicative element in the work is either novel or exceptionally well done… It has the power to alter how people perceive the world around them.”

More people must acknowledge MUDs as art, before they will get proper artistic treatments. Proper critiques of MUDs would help push the artistic aspect of the medium. “A review boils down to just, ‘is it fun?’ whereas a critique must consider things like ‘is it ambitious? is it important? is it derivative? is it innovative?’ ”

The author would like reviews to include some basic questions. How many game mechanics does the game have? How easy is it to become part of the online community, and make, keep in touch with, and remain friends with people from that online community? How much of the game is recycled/reused from other games?

If MUDs are art, the artists have responsibilities. The artist has “the responsibility to pursue their vision.” Different audiences will gather around different artistic visions.

Artist also have a responsibility to society. Art has influence. Choosing how to influence society is another artistic responsibility.

Summary of “Mud, a thing of the past?” by Matt Steed

Matt spent four years MUDding, finally settling on his favorite, Mudweiser. He loved helping newbies and finding new people to play.

The origins of the Internet were a means of communication. “The original muds were one way of communication, people logged onto the site and created characters that would travel and explore the world and interact with other people and mobiles.”

Dungeons and Dragons style MUDs quickly spread across the internet. However, now the lists of MUDs are empty with no players on them. The ones that have players on them, have an aged player base.

Recently, games like Diablo, Ultima Online, and Everquest became available to Internet players. However, some people still play MUDs. This situation is similar to how some people watch movies, and others prefer to read books.

“Unfortunately, muds are not a mainstream part of the Internet and few people know what they are. It is up to the mudders to find new players and teach them about muds. mudding allows for creativity and imagination and creates an exciting social outlet. Muds by no means deserve to be a thing of the past, but it’s up to the mudders to keep them alive.”

One site that can help with teaching new players about MUDs is The Mud Connector

Summary of “Problems with mudlists” by Adam Wozniak

Adam ran Doran’s Mudlist which later became Mudlinks.

Scott Goehring’s “Totally Unofficial List of Internet Muds” stopped updating in 1994 with around 450 MUDs on the list. After that, came “Doran’s Mudlist”. It was written and maintained by the author. That ended around 1996.

Several other lists, like “Amberyl’s Automated Mush List”, came along. Andrew Cowan’s “The Mud Connector” was the next big MUD list with around 1300 MUDs listed. It was the first big World Wid Web based MUD list.

Indium and the author revived Doran’s Mudlist in 1997 with a web interface. This lasted until Indium became pregnant and both were overwhelmed by school and life.

The author came up with a new approach … mudlinks://

“The problems of running a mudlist can be broken down into four parts: enumeration (how many muds are there?), classification (what do we know about each of these muds?), organization (how do we tell people what we know?), and maintenance (how do we keep our data up to date?).”

Being given bad data (in accurate copyright info) took up the most time when dealing with a MUD list.

mudlinks:// scans the web looking for MUDs. At the same time, it looks for a ‘mudlinks.txt’ file. “These files, after a bit of reformatting, are imported wholesale into mudlinks:// and can be searched like any other data file mudlinks:// maintains.” mudlinks:// would scan the mudlinks.txt files for updates, once per week. Unfortunately, only 3 MUDs have included mudlinks.txt files out of 3400 at the time of the original writing.

Passive data gathering of data on MUDs is likely to only gather good information on limited numbers of MUDs. Active, human involved, MUD list creation will gather larger lists of MUDs, but not the depth of information that the admins could passively provide.

Summary of “Wear Grflx” by Nick Howe

Nick spent 5 years on Discworld as a creator and player.

This a parody of an article by Mary Schmich written for the Chicago Tribune.

The parody can’t be done justice with a summary. It began with the line, “Ladies and gentlemen of the Century of the Fruitbat”. The parody ends with the line, “But trust me on the Grflx scale.”

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.

Summary of “Applying a MUDpack” by Chris Caines

Chris was an experienced MUDder under the name of Arzac. Later he wrote a comic.

A humorous commentary of the MUDding trends, players, and the author. The author played MUDs (Discworld) nearly continuously from 1993 to 1999. After which he to a step back, re-evaluated his life, and promptly started making a weekly comic strip about how funny MUDding really is. The comic was called Mudpack.

“My long-winded point is simply, mudding is funny! It is funny for you because you know what a Womble is, or you know what it is like to be up at 3 AM because you have been killing a Rat for the last 4 hours and you are damned if you are going to give it up now. But do not forget it is also funny to other people, usually because they do not understand what a cabbage is for.”

Summary of “Mud Governments” by Griffin

MUD-like games are usually classified by the type of game play that occurs on them: social, PvP, role-playing, etc. A novel approach to classifying these types of games would be to classify them by government type. The classification would be more of society/community than game play.

Some MUD governments are made up of builders and/or admins, only. Some have players that have an in-theme government (ie star fleet command). Others have out-of-theme governments by players.

If you have an MUD government solely run by one supreme admin, you have a government that can act quickly and decisively. Also, you have the chance of abuse of power. This form of government works until the MUD grows too big for one sovereign to handle.

If the government is run by a team or counsil of builders/admins then you have “an oligarchy, a system based on a relatively small power elite that makes all key decisions.” Mortals (players) may even join this council, depending on the MUD. This sort of government often comes with secrecy to keep internal differences from the players.

These types of governments are often quick to handle issues. However, they are prone to faction conflict and nepotism. They can govern larger player-bases than the single-person government.

Adding even more people in power to handle growing population of a MUD, tends to result in lots of rules to keep corruption in check. These MUDs can become very bureaucratic and legalistic, very easily ruining the experience for new players.

Another approach is to allow votes, or purchase of in-game resources associated with desired outcomes. For example, buying coding time to have certain game features worked on. “The strength of such a mud is the high level of player participation, the risk is a form of populism that can marginalize the smaller or less powerful groups.”

Very complex government types with elected mediators have been tried with some success. These MUDs “have attempted to set up complex mechanisms of consensus decision making, typically coupled to plebiscites as ways to resolve issues that cannot be brought to consensus. Such muds tend to become very “political”, as participants are expected to invest a considerable amount of time into collective decision making.”

These government types mentioned above, typically are out of character (OOC) with the MUD themes. There are government types that are more in character (IC).

IC governments often have little or no democratic features. While an absolute leader is often accepted in the MUD realm, they are looked on with a fair bit of suspicion.

“I wonder whether the democratization of OOC mud governments is not only politically preferable, but even a better basis for more subtle IC game play.”

Summary of “Reviewing Muds” by Selina Kelley

Selina reviewed MUDs for The Mud Connector.

Reviewing MUDs is hard, even when it’s fun. The author doesn’t like giving bad reviews, even when deserved. And whether you give a good review or a bad review, you’ll still get hate mail from players and ex-players of the MUD.

The best approach to writing MUD reviews is, have a thick skin and write honest reviews. “Some people cannot understand constructive criticism, and any negative aspect of their Mud you point out will be seen as a direct attack, but regardless of their reaction, you should never fudge the truth to soften the blow.” However, some wizards and admins actually act on the review and make positive changes to their MUDs.

Reviewing a MUD without letting personal biases taint your review is difficult. The author often returns to a previously reviewed MUD at the admin’s request, when they want updates reviewed. “Regardless of how I may or may not be burned by it, I consider it an accomplishment when I complete a review as honestly as possible.”

Summary of “The Lessons of Lucasfilm’s Habitat” by Chip Morningstar and F. Randall Farmer

Originally from “The First Annual International Conference” and “Cyberspace: First Steps”.

Habitat was a 3D world inspired in part by Vernor Vinge’s True Names. The front end was for Commodore 64 and the backend was QuantumLink. The choice was purely financial and contractual.

The players had avatars controlled through a joystick. Word balloons displayed the text they typed. Habitat had 20,000 in-game locations. Habitat had ATMs, vending machines, and its own economy.

A host of objects could be carried in hands or pockets. These included books, drugs, keys, and even magic wands.

Habitat used object-oriented models, kernel handling of memory, telecommunications and other state-of-the art 1990’s tech.

The backend maintained the world state, and updated the client for display purposes.

Habitat was built on several core prinicples:

• The environment MUST by multi-user in nature to create “richness, complexity and depth”, because AI’s weren’t available to do the job.
• Use of network bandwidth must be minimal, because, … well, … modems.
• All data as objects was essential.
• Platform is unimportant.
• Standards for transport protocols for data are vital.

 

“There were two sorts of implementation challenges that Habitat posed. The first was the problem of creating a working piece of technology — developing the animation engine, the object-oriented virtual memory, the message-passing pseudo operating system, and squeezing them all into the ludicrous Commodore 64 (the backend system also posed interesting technical problems, but its constraints were not as vicious). The second challenge was the creation and management of the Habitat world itself. It is the experiences from the latter exercise that we think will be most relevant to future cyberspace designers.”

The biggest complexity of Habitat is introduced by the 20,000+ players online. By the time Habitat had reached 50 players, the engineering team crossed the complexity threshold and were over their heads in holes and rough edges in the game. Scaling was a big issue. Tens of thousands of players meant the need for 10’s of thousands of houses and a massive number of interesting places to visit. Whole towns and forests needed designing to avoid cramming everyone into the same space.

Also, 10’s of thousands of players are going to have a vast array of interests, not just the same interest repeated 50,000 times. “Most activities, however, involved some degree of pre-planning and setup on our part — we were to be like the cruise director on a ocean voyage, but we were still thinking like game designers.” Activities planned and built out for weeks were often finished by the players in hours. Some players never got to participate, they were over so fast. The result was most players did not have a good experience at activities. Unexpected outcomes were standard.

A new approach of letting the players decide the design worked better. They watched what the players were doing, and modified the software to help them to more of it. Another approach was to give suggestions to the community that the community did not know the software could do. This also worked well. What never worked was assuming the developers could tell the players what they would do.

Murder and theft were allowed in the game to provide conflict and drama. Habitat had very few rules to begin with. 50% of the players were fine with PvP and the other 50% felt it needed to stop. Eventually, cities became safe spaces where theft and murder could not happen.

“One of the outstanding proponents of the anti-violence point of view was motivated to open the first Habitat church, the Order of the Holy Walnut (in real life he was a Greek Orthodox priest). His canons forbid his disciples to carry weapons, steal, or participate in violence of any kind. His church became quite popular and he became a very highly respected member of the Habitat community.”

A voting system was added and the position of Sheriff was added. Soon the first virtual sheriff was elected. The sheriff did not get any actual power to arrest players, because the first simulation was shutdown.

The important takeaway is that a government can be evolved in-game, if the rules allow it to be. The game does not need a fixed government before game play begins.

Players cheat. Players take advantage of bugs. Sometimes the players think bugs are features, so innocently cheat. Never trust anything coming from a client’s computer. Not everyone can be trusted.

Not allowing players to create regions and game features meant the developers were a technical and diversity bottleneck. Encourage creative involvement by the players. Get suggestions and feedback directly from the players.

In-game interaction must, Must, MUST!!! stick to the theme and rules of the world. Extraordinary, problems can result in wonderful in-game experiences for many players.

For example, in one event, DEATH (a sysadmin avatar) was killed (multiple times actually) and dropped a one-shot gun that players were not supposed to have. One solution taken was the admins forcing the player give back the gun. Much hard feelings and hate spawned from this solution.

Another solution attempted was a large ransom, and theatric exchange happening in the town square–all completely in theme. The result was a sensation that all the players loved and heard about.

Habitat was followed by “Club Caribe” in America, and “Fujitsu Habitat” in Japan.

“We feel that the defining characteristic of cyberspace is the shared virtual environment, not the display technology used to transport users into that environment.”

Summary of “The Model Economy” by Scatter ///\oo/\\\

Scatter ran Dawn Whispers MUD.

Economy is ignored in most MUDs, with values of items assigned, and seasoned players becoming immensely rich. The rich players can afford anything in the MUD, and tend to gift massive amounts of gold to new players making the economy dysfunctional even for new players.

Limiting bank accounts annoys players and doesn’t prevent them from harvesting vast amounts of gold at will. Creating expensive items like elite equipment, customize rooms, or guild halls encourages harvesting without fixing the underlying economic issues. Training costs limit gold of newer players, but becomes a non-issue as they become more powerful.

A cost of living that just barely offsets the time and means needed to acquire wealth creates a good economic balance. Some possible costs of living that can be implemented include:

• Taxes
• Rent – “not meaning the old inventory-rent idea that still crops up occasionally but rather things like renting rooms or houses within a city to personalize and live in”
• Wear – items/equipment need replacing and repairing
• Followers – include a cost to hire mercenaries/bodyguards

 

“The remainder of the excess income can often be mopped up by desirables – things that players want (but don’t need), and ideally that are either temporary and have to be replaced or cause more ongoing expenses. For example, a player that wants a horse to ride around upon needs to pay for stabling, food and services of a groom in addition to the cost of purchasing the animal.”

You could eliminate banks, or require the rent of a vault or guards to protect items and gold. Banks might not be fully secure. Maybe require installation of a safe to protect treasure and items.

Gold must enter the MUD at about the same rate as gold is used and leaves the MUD.

Summary of “Who’s Who? A look at Character Sharing” by Kethry

Kethry played on the Mystic Adventures MUD.

Character sharing has strongly opinioned opponents and proponents.

Benefits include, being able to try out character types without a big commitment. Also, being able to use skills of characters that cannot be found in the current online population. It also staves off boredom for experienced players. Another benefit is splitting up the boring parts of leveling up or long quests. Also, it allows people to show friends what the MUD is like without going through the long process of character creation and leveling.

However, issues arise from sharing characters, including resentment by veteran players who see a new player that got everything for free. Also, the player sharing the character may no longer enjoy playing as a new character because they miss the power of the leveled character.

Other in-game issue arise, such as lost equipment or experience, users that want their character back from an unwilling sharer, and even changed passwords, deleted characters, or disciplined shared characters. The original owner of the character may be very unhappy with what happened to their account when they were away, and funnel that anger towards the admins that refuse to intervene.

Then there are the in-game social consequences of not knowing if the current player of the character is the same person you have already met. The original owner can log in to find people angry that them without any clue why. The issues of MUD security and governance come into play if the character is a builder or government official in the game.

The author suggests a ban on shared characters is best. “While there are benefits to the players with sharing characters, there is no benefit to the mud itself, and sharing characters can damage a mud.”

Summary of “Art of Language Independence” by Ben Greer

Ben started ScryMUD.

Due to requests, the author has taken on the task of porting ScryMUD to support multiple languages. “There are four distinct areas of translations that are needed: the player commands, code generated messages, world database (DB) entries, and player communications.” Player communication is proving to be the most difficult change.

Most of the article focuses on the ins and outs of rewriting 20th century C code to handle multiple languages other than English. The translations of the text that is currently only in English will have to be accomplished by a small army of volunteers.

Summary of “Ethics and Virtual Reality” by Chuck Haeberle

Chuck is known as Traveling Jack and Greebo on Legend MUD.

“‘What morality exists in the context of a game? Do we treat a game as a subset of ethics or should virtuality reflect our ethics in reality?’”

The author investigates the difference between finite and infinite games. Finite games force players to play within a set of rules and the game ends. Infinite games allow players to play because of the rules and don’t have a finite duration for the length of the game. There is an infinite number of strategies for playing the game. Real life is the ultimate infinite game.

Infinite games have many types of players, most of which limit themselves by self-imposed rules of varying magnitudes.

“The different types of players will seek different definitions of morality. The infinite player will desire only what enhances the play of the game. The finite player will desire what reflects his personal standard of rules. The timid player will seek a firm set of guidelines, and will conform, generally without question. Finally, the user will seek no set of morals, wishing to fulfill his desires without reproach and regardless of effect on the game or the players.”

The author’s argument is that choosing to play by a set of somewhat selfless morals will benefit the player and the community of players. IRL Bill Gates is used as an example. Some IRL morals should be carried over to MUDs.

Infinite games, like MUDs, are merely extensions or subsets of the ultimate infinite game, real life. By extension, at least a subset of the morality of real life needs to exist in all infinite games, because if real life is not really a game, then MUDs and other infinite games are not really just games either.

Summary of “It’s Only A Game” by Kethry

Kethry was a staff writer and a player of Mystic Adventures MUD.

“As an administrator of a mud, one of my biggest pet peeves is the “lighten up, it is only a game” line which is often thrown at mud administrators for daring to enforce the rules they have established on their mud.”

MUDs are ever-changing, open worlds where the player makes the character their own. It is much more than traditional games. There is a vast time commitment, and many online relationships formed. Even IRL marriages as a result of those online relationships. Mudding is far more than just a game.

The need for Out Of Character (OOC) channels is a great proof that MUDs are not just games. Players not only invest a large effort into their characters, but seek to share more of themselves with other players in a non-game chat. Some angry players make IRL death threats against admins that dare enforce the rules of the MUD. Even those shouting, “It’s only a game!” feel strongly otherwise.

Summary of “You Were Different When You Were A Player!” by Selina Kelley

Selina was a staff writer and member of The Mud Connectors.

The transition from player to immortal can result in the loss of old player friends. Information you could share freely as a player becomes privileged and unsharable after the transition. There are strict rules on what immortals can share with regular players.

Knowing how the MUD works destroys a lot of the magic of the game. “When you know the inner workings, and know when you run into X monster in Y area that he’ll have Z spells and Q hitpoints, the adrenaline rush that comes with attacking an “unknown” just never kicks in.”

The fun in the game comes from different sources once you’re an admin. The satisfaction comes from creating, then seeing other players enjoyment of the game.

Summary of “Tao of the Hunt” by A Shriner

The author is a “shriner” on Artic MUD.

The author understands that pkilling is frowned on by many players, but enjoys the hunt of other players in what is only a game. ” Some play to role-play, some play to be part of a community, I play to be feared. I enjoy those other aspects too, of course, but they pale in comparison to the thrill of the hunt.”

The author has a long monolog boiling down to it’s a game. I have a normal life. You chose to join a PvP server, and should understand what that means. “Do not bleat at me, little sheep, for this path you chose of your own free will . you knew the wolves lurked here, you simply chose to ignore them.”

Summary of “Role-Play vs. Multi-play” by Brad Smith

Brad, AKA Majick Salavari, had three years of MUD experience and worked as an immortal at qs.mudservices.com

Playing multiple characters reduces the ability to roleplay. However, multi-playing is fun as a player. But, for admin, it is not fun.

“Should mudding be solely resticted to one character online per person? Perhaps. If you strive for role-playing, it’s definitely an experiment worth trying. But, if your main interest is running a mud where players can create ten characters on two sets of equipment, or even a mud where role-playing isn’t important, then perhaps multi-playing is right for you”

Summary of “Player Killers Exposed” by Lexley Vaughan

Lexley played MUD 2 and ran Witch? magazine.

Players can really feel horrible when another player kills there character. Typically, Pk’ers are hated, even though they are rarely successful at PK’ing.

Some reasons for PK’ing are not stigmatized by the MUD community. For example: self defense, PK’ing thieves, PK’ing bullies, and accidental PKs. Typically, the community does not label you as a PK’er if you had a good reason.

PK’ers fall into the following categories:

• Newbie – they come from PvP games and don’t know any better
• Wannabe – they aren’t any good at combat, so attack in packs
• Achiever – they’re experimenting to see if PK’ing is a good way to get points
• Explorer – they just want to know how PK’ing works, out of curiosity
• Broken Achiever – they’re usually angry at being killed too many times
• Broken Explorer – they snapped for some reason. They tend to be more dangerous than broken achievers.
• Psycho – “They do it because they can get off on it, end of story.” They tend to be poor losers, so if a party takes them out enough times, they quit.
• Prover – Usually have an inferiority complex. “They prefer to show their skills off against much weaker opponents”
• Big Whacker – Usually have a superiority complex and behave like rutting stags.
• New Wiz – admins that abuse their powers by snooping, then use their experience to PK. They might succeed purely from skill, but death of their temporary characters doesn’t mean anything to them, so their is no risk from their end.
• Pkk – an over achieving PK’er that is disruptive to the MUD. Sometimes the admins cull them, they’re so disruptive.
• Spicer – an admin that shows up in mortal form and shows regular players in tournaments that they have a lot to learn
• Auto PK – they are admins that flip between mortal and wiz constantly just because it is habit to PK anyone that come across

 

Common excuses for PK’ing fall into the following categories:

• “I’m Only Role-Playing”
• “The Game Needs Pks”
• “Players Who Can’t Fight Deserve To Be Killed”
• “The Game Lets Me Do it”
• “No Offense, I Need the Points”

These are all just excuses. The only type of PK’er that tends to not use excuses is the broken achiever.

Summary of “A Player’s Right To Privacy” by Selina Kelley

Selina was a staff writer.

“I’ve always felt that snooping is wrong and that it is a gross invasion of privacy. Difficult as it may have been to stop snooping, once I had done that, it was as if a great burden had been lifted from me–the burden of guilt.”

The author follows her journey of becoming and admin and snooping as part of the job, to snooping as a hobby, and eventually turning her back on the practice of casual snooping. The turning point was realizing players didn’t like her anymore, and losing some friends due to snooping.

Arguments for snooping are to fix bugs, track balance, and catch code thieves. There is always a better solution than snooping. “If you have a snoop command in the game, it will be used. No matter what restrictions are in place, there is always a way to get around them and a way to insist that it’s “OK” because of “XYZ-lame reason”.

[Summarizer’s note: The author never addresses the situation of proving sexual harassment and other vile forms of online abuse.]

Summary of “Around the World in 24 Hours” by Marcie Kligman

Marcie edited for Imaginary Realities and played Discworld MUD.

MUDs attract players from all nations and backgrounds. They are international communities that share their own unique cultural experiences with everyone on the MUD. As an American on a British MUD, the author found out how much America is not the center of the universe or world. “Simply declaring myself as an American on a chat channel can result in comments like ‘I’m so sorry’, ‘I’ll use shorter words then’, and ‘we’ll try not to hold it against you’. Experiences like these have taught me that the American educational system is quite bereft of real education about the international community”

Playing a MUD with an international community can teach more about international relations and politics than any class.

Summary of “Communicating on a Mud” by Tilly

Tilly was a Discworld MUD player.

MUDs in the late 1990’s were often the first form of real-time text communication that people had seen, including the author. Real-time text communication presents a new problem, snail mail didn’t have. The texts happen so fast, that writers don’t spend nearly as much time as necessary to make sure their messages are clear, typo-free, and carefully thought out. The problems with real-time, text-based communication are similar to spoken language.

Misunderstandings happen more in this new real-time, text-based communication. However, visual and audible clues about what the speaker was saying and the reader’s reaction are completely missing, so miscommunications in rea-time text based communication are more severe than in oral communication. Emojis and emotes help get around the barrier, but aren’t as useful as verbal and visual clues.

“We would all do well to keep these limitations in mind, both when saying things ourselves and when interpreting things that others say to us.”

Summary of “Creators vs Players” by Anthony Peck

Anthony was a Discworld MUD playtester.

Players need to remember that creators spend massive amounts of time improving the MUD without compensation. Creators need to remember to play the game. Be curteous to each other.

Summary of “Denumerization of Muds” by Brad Smith

This is Brad’s second article.

“Does giving players access to all of their statistics in numerical form draw away from the ability to role-play?”

Describing stats without numbers helps force players to roleplay. The characters can’t spout stats about their stats that way.

“I will concede that some numbers are necessary. Not having of idea at your hit points pushes the fine balance between role playing and realism. Hit points, Mana, and Stamina are three statistics that hiding would cause more trouble than benefit.”

Summary of “Use Your GDI!” by Aaron “Ajax” Berkowitz

Ajax was a builder at Questionable Sanity MUD.

This article is a response to a Game Commandos article, “Fix Your Room Descriptions” by Natalia. Natalia, in the original article, pointed to eight distracting description features found in many gloomy forests. They are: Typos, Addition of Emotion, Time of Day, Wrong Word Choice, Built-in Actions, Implied Direction, Seasons, AND Incorrect Exit Descriptions

The author accepts that typos, wrong words (there/they’re/their), and inaccurate exit descriptions should be fixed.

Time of day and season issues that create inconsistencies when compared to the room description (ie it’s noon but the room is bathed in moonlight) are minor, but are distracting.

Addition of Emotion means, the builder is explicitly telling the player what they feel, rather than letting the reader come to their own conclusion.

Built-in Actions that describe what the occupants (that might not even be present) are doing in the room as part of the static room description.

Implied Direction in the room description, assuming the character is always coming from the same entrance. This should be part of the entrance description, not the room description.

Using Dynamic Room Descriptions (DRD) fixes time, direction, and action description issues. The room descriptions can morph based on time, weather, season, race, etc. However, this is hard, and most builders hate writing room descriptions to begin with.

As stated by the author … A common rule of thumb for the inclusion of any feature in a mud is:

    if benefit > effort, Implement; else 'thank you for your idea!'

 

“Use your Gosh-Darned Imagination!” and get over it.

As for the remaining issue of describing what the player feels. That doesn’t matter either, because no one is going to think the macho character was afraid or homesick unless they start doing in-game actions like sniffing or crying.

Just be glad when a decent effort was put into writing a description, because most builders don’t bother doing that much.

Summary of “Why use Artificial Intelligence?” by Tony Wilkinson

Ran xploding.com as Bagpuss.

Player Kills (PK) fall into four categories.

1. Players have more loot.
2. The killer likes being mean.
3. Players want to prove they are the best.
4. Monster are boring

 

Reasons 1, 3, and 4 are fixable by improving the MUD. Better quests and good MOB AI would work.

On most MUDs and other online games, … “The problem is in the monster bashing. There are only so many times that you can kill the same monster using the same tactic before it becomes boring. The monsters in most muds use virtually no tactics.”

Another approach to prevent PKs would be to reward good behavior. Some power weapons might only work for “good” players, for instance. Make it more rewarding to avoid PK’ing than to do it.

Summary of “Any Publicity is Good Publicity!” by Selina Kelley

Selina worked on The Mud Connectors and was a staff writer for Imaginary Realities.

Any publicity is good publicity is a common phrase, but not true in the author’s experience. Bad publicity results in people hating your MUD, and advertising tends to have no real effect a gaining new players.

What does seem to work is word of mouth advertising. Players find quality areas (even if there aren’t many of them yet) in a MUD and tell friends and family about it, and word spreads. This also leads to a more positive experience for the admin/creator.

“Promoting growth is a good thing, but to have a mud grow and succeed, it is more the strength of impressing the players you have so they will tell others, than constantly publicizing the mud on bulletin boards and newsgroups. Sure, people will soon enough know and recognize your mud, but without the backbone of good areas, good staff, and good players, a mud that receives only self-touted or negative publicity will never really gain the player base it strives for.”

Summary of “Building the Land” by Jeffrey Laikam

Jeff (Ytrewtsu) implmented Adventures Unlimited.

Even stock MUDs can be enjoyable with proper layout and infrastructure. “Begin by laying down a structure that will provide originality for your mud immediately.” Start with a network of rivers and roads as a foundation. Next, keep stock areas that fix the MUD’s theme, deleting the rest. Make sure the locations of stock areas make sense.

Here are initial tasks to consider:

• determine areas and terrains
• map out cities on grid paper
• add city terrains
• add roads between cities
• add rivers
• determine world boundaries
• flush out all terrain
• define difficulty levels of areas
• when using stock areas, delete unwanted connections
• build out the map you created
• reconnect the stock areas
• ensure connection rooms between areas have lots of flavor
• add additional connections between areas that make sense, including rivers

 

Summary of “Deciding on Mud Code Improvements” by John Patrick

John was an electrical engineer, masquerading as a software engineer, and staff writer.

Prioritizing MUD code improvements is a huge challenge. First make a list of all the desired changes including the smallest of changes. Give lots of details about each task in the list.

Split the coding tasks into the following categories.

1. Code removal – Finish all code removal before opening the MUD for the public. This prevents players that liked a feature from losing it.
2. Bug fixes – This includes crashes, playability, and annoyances. Fix them in that order.
3. Improvements – Enhancements to stock code or other features
4. New code – This can range from high to low priority. The author tries to add some new code at least monthly. New code falls into the following categories by priority: Genre enhancements, Fun features, New skills/abilities/tallents, Reality mimicking, and Pet projects.

 

Many MUDs have source code and Mobprog (Mobile programs). Source code affects the MUD’s rules and features. Mobprog affects the details of the areas and rooms. Source code is harder to write than mobprog. If mobprog will work for the limited scope of the change, like something that only affects an area or a room, then make the change using mobprog instead of source code.

Some MUDs have objprogs and roomprogs, too. They are also a better choice for changes of a small scope than would source code changes.

Some massive changes make previously generated players unusable. Plan on doing a player wipe (pwipe) if this is the case. This will anger many players which will leave your MUD. Do pwipes only as a last resort.

Summary of “The Making of a Pantheon” by Michael A. Hartman (Aristotle@Threshold)

Michael was the admin and author of Threshold RPG and a staff writer.

“Religion is a vital element of any role playing game, as its potential for generating conflicts, quests, and plot lines is basically limitless.” A well designed pantheon is critical to fill out a MUD.

First, determine the size of pantheon. Don’t dilute your player base with too many deities, or they won’t have any measurable effect on game experience.

At the same time, you must have enough diversity of deities to keep conflict alive. “having many interesting and diverse concepts represented by your deities will create many situations where players have a specific deity they can pray or tithe to. They can do this asking or tithing when something they want to do falls within the purview of one of the deities of the campaign world. In such situations, they might need to seek out a cleric of the deity for advice. Such situations create very interesting role play situations for the both the aspirant and the cleric(s) involved, and can result in some very memorable scenarios and player given quests or tasks.”

Second, determine the concepts your deities are related to. Create an exhaustive list of possible concepts. Do this by examining historical religions “like Greek, Roman, Norse, Indian, Egyptian, Chinese, and other mythologies.”

After creating your list of concepts, determine opposites for each concepts. You need conflict.

Organize your concepts by importance. Determine the deities that will have each (or several) of these concepts related to them. Make a final selection of deities and concepts. Do NOT dilute your pantheon with too many deities for your player base.

Third, come up with names for your deities. Names are important. The names should feel like they are associated with the concepts they represent.

Fourth, “each deity does not exist alone in a vacuum. They should be part of a much larger and more complicated cosmology wherein conflict, alliances, intrigue, and mystery abound. Each deity should have its own history, goals, and motivations that explain the demands it makes upon its clerics and followers.” This most of this is for the admin and builder’s to know, and NOT for the players to know.

Summary of “The Power of the Written Word” by Kethry

Kethry was a staff writer and could be found on Mystic Adventures MUD.

Actions and speech in real life (IRL) can be accidental or unplanned. In a MUD, speech and actions have to be thought up, typed out, and sent intentionally. “So why is it that even on a mud we have sexual harassment and harassment in general”

Harassment, IRL and in game are harmful and abusive. Also, being “in character” or saying “it is just a game” doesn’t give players the right to harass other players. This extends from cursing in the game channels or, at the other extreme, virtual rape.

“Flirtation is a case in which sometimes the envelope can be pushed. There was a female player who was very flirtatious. She enjoyed hugging and kissing players, little things, nothing major, just some innocent flirtation. The player would make many reports to the immortal staff about being harassed. Many people she flirted with took it seriously and would flirt back, sometimes crossing the line. Many times they were unaware they had even crossed the line. The problem was, someone took an innocent flirtation and thought it was more than it was. When they responded, the original female player who had initiated the flirtation got offended and would complain about being harassed.”

If there is an issue with players crossing the line, tell them. Be firm, but polite. Say something like “please do not do that, I don’t care for that social.” Most will be careful and respectful. The ones that won’t change their behavior should be dealt with by an admin.

For MUD admins, … have a clear help file with explanations of what is harassment and what penalties could be enforced. Often, clearly letting individuals know they need to change their behavior is enough. Otherwise, banning or sending a detailed message to their ISP’s admin may be needed.

Summary of “Third Person Mudding?” by Ken McQueen

Ken, who also went by Souma and Mokona, was working on a nameless MUD as the head builder.

Most MUDs tell their story as though the player is reading a story in the first person perspective. Though more rare, setting a MUD in the third person is a valid and natural approach.

“This allows for all sorts of informative possibilities. If you treat the “storyteller” as some sort of highly trained bard or traveler replete in the legends and tales of the land as well as place names and the like. It is possible for the player to be regaled with all sorts of information that is completely out of context to the current conditions and what the actual character knows.”

Instead of addressing the player directly, tell the story like the player is reading a book.

Summary of “Designing God” by Scatter ///\oo/\\\

Scatter was a staff writer and Dawn Whispers MUD “High Lord”

Start designing your MUD’s pantheon from the beginning of designing the MUD. Choosing a no god system opens up the possibility for players to gain god like status and power. Having gods, allows for their motivations and conflicts to spawn quests and adventures for the players.

If gods exist in the MUD’s mythology, they could be fictional, rather than real, NPCs in the world. If fictional, then the change in leadership of a religion would greatly affect the role and beliefs of that religion.

Thirdly, some gods could be real NPCs, while others are mythical, only.

Answer these four questions about your gods:

• Who are they?
• What do they want?
• Where did they come from?
• Why are they here?

 

Differences in worship beliefs of one god can be as interesting to the world as having multiple gods.

“The style or type of gods must be decided. Should it be a pantheon where each god represents one or more emotional concept like love, hate or war; do they embody aspects of life such as time, fate, chance or death; or aspects of the natural world such as air, the sea, the forest; natural forces such as fire, storms, earthquakes; or ways of life such as law, chaos and balance.”

The pantheon could be filled with individuals with personal agendas. Those agendas could be good or bad for humanity, or of no affect on humanity.

“What is the nature of the being called a god, does it really live and can it die or be destroyed or banished?”

The above questions can be answered even if they pantheon is only mythological rather than real, too.

“Each god needs one or more religions, each religion needs holy books and doctrine, prophets and legends, holy symbols and icons, styles of temple and organization, ceremonies and rituals of worship, a calendar of holy days and festivals, a hierarchy of priests complete with dress codes, titles, symbols of position, rights, duties and obligations.”

Summary of “How Young is Too Young?” by Holly Fanelli

Holly was a Discworld creator and player.

Younger creators–pre-teens–do not share the conversational interests of the older creators. This causes some tension on the creator channel when younger players monologue, or older players start talking about adult topics.

Solutions include creating a separate under-age creator channel that all creators can participate in, or not accepting younger creators into the team.

Summary of “I Think, Therefore I Role play” by Sanvean

Savean is the Overlord of Armageddon MUD.

Armageddon MUD (Arm) is a mandatory roleplaying MUD. Admins are know to be gruff with players that don’t roleplay properly, and even kick players that refuse.

A huge improvement to the game, was the addition of a the ‘think’ command. Only the player, and admins can see the echoed back sentence, but it has helped with roleplaying immensely. Also, admins can cause the player to ‘think’ adding a level of revelatory elements to the game.

Think has the syntax of

think 

Think then echoes back the “You think, ” and the sentence/word to the player and any watching admin.

Summary of “Why do a 3D mud?” by Tommi Leino

“The project was active from year 1995 to year 2002. Initially the project started as a MUD (text-based Multi User Dungeon), then became a 2D roguelike-game, and finally a 3D game.”

Majik started as a Diku MUD. They switched to LPMud (MudOS) and ref4rained from used stock libraries to avoid lock-in and allow for easier customization.

Combat, and especially ranged combat, proved difficult to create in a way that allowed a map of the action and spectators to watch the multi-room combat. All the difficulties of creating a satisfactory combat system resulted in a rewrite to version 4.

In version 4, special downloadable client programs were used to get past the limitations of telnet. The combat customizations turned Majik 4 into a 2D Rogue-like game, mostly.

“We got the fourth incarnation to the point where the base code was almost ready. You could go shopping, cut an orc’s arm off and eat it afterwards, improve in skills, cast spells, use different combat maneuvers, solve puzzles, and generally do almost anything you could imagine being in the initial base code. It just was lacking the world. While waiting for it to build up, we had an extreme urge to break the limitations found in our engine by one way or the other.”

Height and terrain were the next problem to tackle, and that couldn’t be handle unless Majik became a 3D game. At first an isometric 3D client was tried, but that turned out to be more difficult than moving over to pure 3D.

Summary of “The World Does Not Need Another (Diku) mud” by Jeff Bennett

Jeff was a Software Engineer in Rochester, New York. He worked on Grimhaven MUD formly known as SneezyMUD.

Stock MUD libraries have damaged the MUD community.

Originally, there were very few MUDs due to technical and administrative challenges. This led to a concentration of players and developers on those few MUD servers. This was good for the community.

Diku MUDs tended to release their code bases to the public, and better servers were available and easier to find and install a pre-made MUD on.

“While the increase in the number of muds might make the maintainers of mud lists happy, it has also diluted the overall mudding community. Fewer players play each mud, meaning there are fewer ideas offered when problems occur. Unfortunately, the availability of the stock muds makes going your own way all too easy. No longer is there any compelling reason to correct a wayward mud through debate or reasoned discourse.”

This lead to a downward spiral where new players don’t find thriving communities in the MUDs they join. Also, most MUDs have a cookie-cutter feel, due to premade worlds they start with.

“Now, I’m not advocating that distribution of mud code should be abolished. Obviously, no one wants to keep reinventing the wheel. But it sure would be nice if the stock mud distributors placed more restrictions on the people that downloaded their stock.”

Summary of “The WorldForge Gaming System” by Bryce Harrington

The game described in this article summary can still be found at worldforge.org

The goals of WorldForge is to create the first game that allows “creating immersive, persistent role-playing worlds that are free to play, and free to change – and graphics rich”. With the exception of graphically rich, MUDs have already succeeded at these goals. Ultima Online, iD, Blizzard, and others have made attempts, but have not released much for free.

“In allowing anyone to run a copy of the game, we will force WorldForge to always be free to play. While we are not going to put a restrictive license on the game preventing pay-to-play use of the game engine”.

WorldForge will benefit from being opensource. It will allow much custimization through configurations, and it will allow for modules called toolboxes to add features.

Additionally, like advanced MUDs, gamers will be able to alter and build the world themselves, including the creation of new types of objects, buildings, or even new styles of shirts.

Player macros or scripting will be allowed. This provides for combat advantages, or removal of potential drudgery in the game. “At the extreme, a character that is fully scripted is akin to a ‘mobile’, only better because it has a human watching over it, enhancing it, and in effect doing the AI development for the game administration, for free.” AI facilities are built into the game.

At the time of the original article’s writing, WorldForge had been in development for a year. [EDITOR’S NOTE: In 2023, WorldForge is still actively developed.]

WorldForge has made great strides in its first year, and gathered a large team of artists and musicians that any professional game house would be proud of. “We’re currently focused on a series of milestones leading up to the production of our next release target, a working game called “Acorn”. This will be built using our AI engine Cyphesis, and will provide a true, playable game.”

Summary of “Harvesting Ideas?” by Lord Ashon

“First a Disclaimer: This article walks a thin line. We, the Law, and the Mudding community, find that there is a huge difference between stealing code or ideas, then there is to using and idea. Using an idea means that you come up with your own implementation. Stealing code is using someone else’s implementation. Also Note: it is a good policy to get permission from the originator of the idea.”

Public mail list archives that relate to MUD development are a good first location to look.

 

1. The ROM mailing list. (http://www.hypercube.org/tess/rom/)
2. The CIRCLE mailing list (http://post.queensu.ca/~listserv/wwwarch/circle.html)
3. ADV-mud (http://www.egroups.com/cal?listname=adv-mud&m=1)
4. DejaNews (http://www.deja.com) This one is obviously not a mail list but is great for checking the Newsgroups

 

Try searching: “idea”, “feature”, “snippet” and variations such as “request for snippet.”

Look for web resources for implementing snippets. Look at discussion boards, such as, Imagine Realities’s and Mud Connector’s discussion boards.

Corner some builders (at least two) in a room and ask, “Are there any features you would like to see added to the mud?” With two or more builders, they’ll start bouncing ideas off each other. You just need to make sure you keep a log of the ideas, so you don’t forget.

Always write your own implementations of the ideas.

Summary of “Know Thyself” by Carolyn Ebenstein

Played on Discworld MUD as the witch Sibyl.

People need identity. In MUDs, real life social status, background, and name are hidden, and identity is based of what you say. personal insecurities might make even that accurate reflection uncomfortable.

“Identity is often confused with the image one projects. In both muds and in real life a person can be labeled based on how he is dressed and the groups with which he is affiliated, among other things.” Projected image can still result in artificial labels imposed on the player due to association.

Even when not insecure, players may search for self-concept. “A person needs a sense of self to keep from feeling lost, useless, and helpless.”

James Marcia stated that individuals can find themselves in four states (not stages) when searching for identity.

• Identity Achievement – well defined self-concept, often occurring after an identity crisis. They arrive at a firm understanding of their own values and goals.
• Identity Foreclosure – a person accepts the identity and values imposed since birth
• Identity Diffusion – a person has no goals or clear self-concept, and is not search for them
• Moratorium – similar to diffusion, except that the individual is searching for self-concept and goals

 

When in a state of Identity Achievement, a person is more likely to be able to feel real love.

Summary of “History of Online Games” by Jessica Mulligan

Jessica Mulligan was a long time online gamer by the 2000’s and originally wrote this article for the Happy Puppy site “Biting the Hand”.

1994 and 95 with Doom and Warcraft was not the beginning of online games. The general public and press haven’t figured it out, but online gaming began in the 1960’s.

Circa 1969 – Spacewar for the Plato Service.

1970-1977 – Star Trek, Avatar (later Wizardry!) for the PLATO service, and Airfight for the PC.

1979 – MUD for the DEC-10 at Essex

1979-1980 More version of MUD. Playing time eventually needs restricting due to popularity and drain on resources

Circa 1982-1983 – source code for MUD gets shared legally and illegally starting the global MUD craze

1982 – Kesmai Corporation contracted to develop text RPG, later released as Islands of Kesmai. DECwars code sold for $50, and later launches as MegaWars I.

1983 – MegaWars * launches on CompuServe and ran until 1998.

1984 – Commercial version of MUD released. CompuServe releases Islands of Kesmai. Later spawned Legends of Kesmai. Aradath set up as home business, charging $40/month to play.

1985 – GEnie and America Online (Quantum Computer Services) launch as competitors to CompuServe

1986 – Stellar Warrior (MegaWar I) launched on GEnie. Rim Worlds War (play by email) launched commercially. Graphics-based, Air Warrior previewed at West Coast Computer Faire. Graphics-based, Rabbit Jack’s Casino launched. LucasFilms’s Habitat begins development.

1987 – Air Warrior for GEnie released. Rabbit Jack’s Casino for QuantumLink released. MegaWars III launches as Stellar Emperor on GEni. British Legends launches on CompuServe.

1988 – Gemstone II launched on GEnie. AD&D: NeverWinter Nights begins development.

To be continued next issue …

Summary of “If You Don’t Like it, Leave!” by Selina Kelley

Selina Kelley was a staff writer and reviewer.

Even calm, rational admins occasionally tell problem players to leave. “It’s difficult to just idly sit by and say nothing when a player becomes abusive, but what really is the ‘best’ way to handle them?”

A player should have a right to express themselves in a non-abusive manner. Also, problems aren’t resolved by removing players that complain about them. Most players won’t become abusive, if they feel you are listening and talking to them.

“With the general population of muds tending toward younger players these days, you are always going to run into immaturity, and while it would be nicer to receive an intelligent, cohesive, constructive email from a player regarding your mud, you have to understand that the younger player cannot always place their true feelings in words that will not upset you.”

After receiving the poorly worded complaint stating the MUD sucks, ask “why?” Encourage respectful dialog. Don’t lose your temper. Improvements to your MUD won’t happen if no one tells you what is wrong with it.

Summary of “Mud-Area Style Guide” by Marshall Buhl

Marshall Buhl was one of the creators of Discworld MUD.

The following are elements that make for a good area in a MUD.

 

• Know basic MUD programming concepts
• Check your grammar and spelling. Long descriptions should always use full sentences.
• Don’t use names in short descriptions, and use names sparingly in long descriptions. For example, don’t describe it as Marshall’s Study, instead mention envelopes addressed to Marshall in the description. Or “A cluttered study”, instead of “Marshall’s study” in the short description.
• Add items to look at. If the description has a waterfall, you should be able to ‘look waterfall’ and get meaningful information instead of a message stating that is not here.
• Players need reasons to search. Add little micro-quests to rooms. Make hidden items a standard for most rooms. Useful (like change in couches) or useless (a tissue in the couch) items are fun to find.
• Make things interactive. Make sinks work. Make standing in the rain cause the players to ‘squelch’.
• Make entrance descriptions match direction traveled, or don’t include direction in the descriptions. When heading out of a forest, the player should not read descriptions about heading deeper into the forest.
• Add humor. Subtle or overt humor helps improve the areas. Leave a table at the fork in the road, or anthropomorphize objects in the descriptions.
• Give hints of danger. Don’t put characters in situations where they walk into a room and die instantly, unless they had hints that this might be dangerous. Don’t be overt with 4th wall breaking descriptions, instead make it part of the game. For example, a guard could sum up a player (check their level) and warn them they might die if they go exploring ahead. Feelings of dread are useful, too.
• Be consistent across areas. Weapons, MOBs, and armor should not vary wildly from area to area.

 

Summary of “Taking Muds to the Next Level” by Nolan Darilek

Ten years have brought great improvements to 3D games, but not MUDs. The solution to MUDs’ lag is to create a new platform for MUDs to run on top of. The author is working on such a solution.

“Coordinate-based mechanics can serve to eliminate the room-based environment which dominates the arena of text-based games. By defining area boundaries in terms of maps, and attaching descriptions and dimensions to these maps, it is possible to retain the basic, vividly-described feel of a room-based game while enhancing it to include a true coordinate system with real-time movement.”

NPCs typically fall into the assistant and target categories. This interaction could be expanded on to allow groups of NPCs to at together or even communicate with each other, creating intelligent agents for more interesting behavior.

Event based systems could modify NPCs behavior, so changes in weather or time of day would affect their reactions.

Summary of “Roleplayability in Muds” by Tommi Leino

Tommi Leino helped develop Magik 3d’s gaming system.

The game “Adventure” was the first adventure game, and as such, quite popular. Even though it ran on a server, everyone played a solo game. It isn’t surprising that soon after, the first multi-user dungeon appeared.

“The Adventure game and others of its kind still share the same user interface with muds. Everything is text-based and centered around ‘rooms’. A room can lead to various directions and it can have objects you can pick up, monsters you can kill or puzzles you can solve. The only difference between these games is that muds are capable of having multiple simultaneous users and thus lack a linear story or any kind of story at all. A good story always has a beginning and an ending. In a mud, if there would be an end to the story, it would also be the end of the mud which is not at all suitable for a multi-user environment.”

MUDs have stories, but they reset after a time. So that players don’t get bored with the same stories, advancement systems keep players receiving new rewards. This leads to selections of difficulties for players ranging from training areas and newbie areas to hard areas.

Player interaction is a big reason players keep coming back to a MUD that isn’t changing. Also, the gaming system keeps them coming back by dangling more rewards for more play.

Gaming systems originate in Role-Playing Games (RPGs). These were just advanced interactive stories, at first, and were played using pen and paper.

In MUDs, the carrot of better stats or treasure drives the story. In true RPGs, the story itself is modified by the players’ decisions. Some MUDs try to encourage better Role Playing by hiding the numbers that the players see, but this doesn’t change the carrot players are pursuing, just the way they speak about the carrot. The story isn’t significantly modified by the players’ actions. Hiding the truth about the carrot players are pursuing by hiding numbers, generally leads to role-playing-required MUDs being less popular that ones that don’t hide the numbers.

To bridge the gap between MUDs and RPGs, the MUD worlds need to be modifiable by the players themselves. “For this to truly work, everything must be changeable for real so in practice you would need to be able to burn cities or make new ones. Then here would be stories such as wars between two of the cities, trading, making alliances and such at the higher positions and if you would be just a beginner you would do things for the players in the higher positions or just for yourself”.