Category: Imaginary Realities

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”.

Summary of “Clans in a Role playing World” by Sanvean (Cat Rambo) and Krrx

Both authors worked on the Armageddon MUD, a Role playing MUD.

“This is the first of three musings on the nature of clans, and what being in/running one means to a player/immortal, with the second discussing a cultural clan, where players begin the game having been born into the clan, and the third outlining some conclusions and problems with clans on role playing muds.”

Krrx revived the Byn clan because of fond memories of working together. Clans need to work together to avoid death. The original plans for the clan revival changed over time. The vision for the clan morphed from a high class “elite mercenary unit” to a “down-and-dirty version”.

Initial strict rules to benefit the clan members were introduced. Following this, careful selection of clan leaders occurred. Finding players that met the following features were sought. “(1) out of character trustworthiness, (2) a very high standard of role playing, and (3) regular playing.”

Determine trustworthiness by checking past characters played, talking to other players about the, and seeing how they behaved in previous clans.

Leaders have to have a high standard of roleplaying, so clan members don’t get lax. Good role playing involves immersing yourself in the character.

Regular playing doesn’t mean constant playing. It means being on the MUD enough that they can fulfill their roles as clan leaders.

Summary of “Confessions of a Hack ‘n Slasher” by D.A. “Flux” Nissenfeld

Flux was a first time submitter looking for feedback.

The author has a long history of gaming, including pen and paper games. The author found MUDs and then spent far more time playing as a hack ‘n’ slash player than a role player. Finally, the author started a MUD and found that 90% of the players also did the same, so has focused on making the combat more fun in the MUD.

Summary of “History of Online Games Part II” by Jessica Mulligan

Jessica Mulligan originally wrote the article for the Happy Puppy .

1989 – “Bill Louden hires Jessica Mulligan as GEnie’s first dedicated games product manager and gives her virtual carte blanche to sign up more online games.” GEnie signs Galaxy II, and licenses Avalon Hill’s Diplomacy. GEnie launches the first online 3D shooter, A-Maze-ing. “Quantum Computer Services more or less de-emphasizes online games after launching development of NeverWinter Nights.” They only finish Hangman.

1990 – GEnie begins development on game that eventually becomes Dragon’s Gate on AOL. Diplomacy Online released. Dunnigan delivers The Hundred Years’ War that can last 400 real days involving 300 players in a turn based strategy game. GEnie releases Federation II. GEnie experiments with flat rate fees, and overwhelms its servers due to popularity.

1991 – GEnie launches Dragon’s Gate. Bill Louden, founder of GEnie, leaves after seven years.

1992 – The Kingdom of Drakkar launches, charges $3-5/hour service. GEnie releases graphics-based RPG, CyberStrike. Quatum Computer Services become America Online (AOL).

By 1992, there are millions of homes actively using modem for connecting to services like AOL, GEnie, Delphi, CompuServe, and Prodigy. DARPA-Net has around 50 MUDs, and is mostly available to universities and their students. Additionally, some two-player, modem-to-modem games exist.

1993 – Everything changes.

Summary of “Instant Combat: Just Add Fudge” by Caliban Tiresias Darklock

Caliban Tiresias Darklock, … gaming and programming for 23 years, but not at the same time.

“Games, … are supposed to be fun; they are not necessarily required to be realistic, scientifically accurate, or theoretically sound.”

In the real world, combat lasts two or three turns, and combatant typically know if they will win or lose before combat begins. It doesn’t take minutes. In a perma-death MUD, not having a sense of what will happen with potential combatants can lead to huge costs.

“When you look into a room, you should be able to tell at a glance what creatures there will or will not attack you, which ones you are likely to be able to defeat, and which ones are likely to make you into an ugly stain on the floor.” MOB descriptions without useful combat evaluations are merely cruel tricks.

From a space combat game the author was working on, a sector might have the description “152178 Attack Drones”. This is not useful for combat evaluation. A more useful description of a sector is “71178 Attack Drones of the Federation [Attack the Cabal only]”.

Some randomness could alter the expected result given in the description, but the combat evaluation description is still useful.

Use statistical iterations to speed up combat resolution. Players want to play the game, not spectate combat for minutes on end.

Summary of “Objects and Trust” by Kevin Littlejohn (Darius)

Kevin Littlejohn was a Moebius developer for a Python MUDdish engine.

Moebius uses MySQL allowing rebinding methods to objects without difficulty. Next, they added the ability for players to add their own scripting, with bizarre permissions issues. Objects couldn’t truly be masters of their own data due to security issues.

Next there was an attempt to solve these issues borrowing from a language called E. “One of the core concepts for E is ‘capabilities’ – sort of like keys for attributes, that an object can hand out to other objects.” Essentially, an object has capabilities for some of its data, but not permissions to modify all of its data. Add to that mix, Mediators, which set attributes in other object and have contexts that determine rules for changing attributes.

“Finally, I am still unconvinced regarding security issues …. The crux of distributing objects still seems to be that code running on a platform outside your control cannot be trusted to have done the “right” thing, for any given definition of right.”

Summary of “Promoting Your Mud” by Johan J Ingles

Johan J Ingles could be found on Wheel of Time MUD as Nass.

Despite the perception that MUDs are in a decline the total number of players have increase. They are spread over a larger volume of MUDs, hence the misperception.

Graphic games’ user base is growing much faster. MUDs suffer from less lag, but poor marketing efforts have resulted in their bad reputation. Much of the pain is self inflicted by the MUD community.

For example, the author put a review of their MUD up on Mud Connector. “Immediately the next morning, two flames went up by people from another mud with the same theme as ours, and my mud was subjected to a Denial of Service attack. Criminal behavior, all in the name of PR.”

When promoting a MUD, … First, have a good product.

Next, create a web presence for your MUD (a website.) Educate new players about MUDding with the website. Provide social interaction for current patrons in the form of boards. Include marketing and friend referral call to action on the site. Provide a web interface to your MUD on the website. Add feedback forms to the site for player feedback. Add profiles of prominent players. Even add a monthly MUDzine. Build a community!

The author provides several examples of learning sources for HTML and explains how to best submit the website to search engines like Yahoo and Altavista.

“Remember, your web site needs to guide these people by the hand, and take them through mudding from top to bottom, even explaining such things as telnet, behavioral norms and the theme, in basic terms. The trick is to imagine that you are coming at mudding without any knowledge of what it is about at all, and your job is to educate and explain, and to make it sound engaging and fun at the same time.”

Summary of “The Debate Rages on” by Troy Fisher

Does a MUD admin need to code or is building good enough? “The main mud administrator needs to be neither, it must be a game designer.”

The game designer must determine what players do, their rewards, the player’s long-term goals, what needs to be learn and improved at as a player, difficulty level, and if the intended actions are really the most fun actions the players can take.

Game designers need to define the theme of the game: social, PvP, mob-kill-fest. The theme defines the motivation of the player to keep playing.

Next design player advancement. Define advancement in terms of money, levels, influence and power. Design the reward system for playing inline with the theme.

Determine the long-term goal of play. What is the end accomplishment of the dedicated player following the theme?

Make the game consistent, and enabling of player’s interactions. “If a player tries to jump off of a cliff, and he falls to his death below, he is going to expect the same thing to happen, not a message that reads, ‘Sorry, you are not allowed to do that!’ If a player is able to feed someone’s parrot, he is also going to want to be able to feed a non-intelligent animal mob.”

Finally, make the game playable without dying, at least in theory. “The player should not need to die to learn the answer to a puzzle.”

Summary of “An addiction to be proud of” by Selina Kelley

Selina Kelley was a staff writer and editor for Imaginary Realities.

” I started being ‘online’ fairly young, my first experience with ‘the internet’ was a BBS my brother used to frequent (play? not really sure what you call it). I was fascinated by my super-powerful ability to talk to someone across the world while sitting at the computer. I barely knew how to type, yet I was talking to a guy named ‘Manx’ that spent his time living in London.”

The author was introduced to MUDs by a friend in College. After an hour long introduction to the basics of play, a new love of MUDs was lit. The author moved up the ranks of player and builder in MUDs, and finally built and maintained one for a short two weeks as an experiment.

The author went from a planned career as an English teacher to a software and software management career. A total life trajectory change occurred because of the love of MUDs.

Summary of “Four Steps to Cooler @Descriptions” by Abby Goutal

 

“To be frank, if you believe that SexyDeath is a really cool name to be roleplaying under, then the finer points of self-description are not what you need to be studying.”

Only names and self descriptions are your chance for a first impression on MUDs. When it comes to your @desc, start with the don’ts. Don’t tell the player what their response to you is. Don’t use a one-line description. Don’t say you look like so-and-so.

Instead, do the following.

• Be correct – Use correct spelling and grammar. MUDs are text games. You wouldn’t put up with glitchy avatars in a 3D game, don’t put up with bad spelling and grammar in a text game.
• Be concise – Lengthy descriptions displayed in a telnet client without scroll back don’t work well. Include details that players won’t assume. Keep to the essential details.
• Be evocative – Evoking is not the same as cataloguing exhaustively. Choose details that evoke conclusions about the character rather than spelling out everything about the character.
• Be realistic – Make sure the character’s description makes sense given the character’s background. “Try not to have innocence shine out of the eyes of Laurene the forty-year-old prostitute.”

 

Summary of “History of Online Games Part III” by Jessica Mulligan

Jessica Mulligan was a longtime online gamer. The article was originally published on “Happy Puppy”.

The author started with some additions to the previous two timelines. First Empire appeared in the mid to late 1970s. Second, BBS and DOOR Games were not included, and disappeared by the mid 1990s.

1993 – DARPA-Net now known to the public as the Internet. By the end of the year, four million users are on the Internet. The World Wide Web is still text-based, but MOSAIC (the first web browser) is starting to change the text-based nature of the World Wide Web. modem and LAN connectivity still are gaming staples. Online gaming with GEnie and AOL became more widely used with their price drop to a $3/hour rate.

1994 – Doom by id Software is became popular (released Dec 10, 1993). Warcraft by Blizzard is released. Doom and Doom II are ground breaking with the ability to play against other people over LAN. TCP/IP connectivity comes soon after the release of Doom II. Netscape Navigator is release late in the year. Big, traditional media companies take notice of the Internet and start buying Internet companies to get into the market.

1995 – Quake begins open beta generating immense publicity. CompuServe, Prodigy, and AOL start offering USEnet, gopher, and Internet access. Doom clones become common place. Over 300+ free MUDs are available at this point. Monopoly gains internet access and remains on the top 20 selling games list for years.

1996 – Quake (focusing on Internet play) is release, and shortly there are and estimated 80,000 players per night. Around 20 games have Internet connectivity by the end of the year. Ultima Online gets its first pre-Alpha test version demoed publicly. “AOL buys INN from AT&T for about 20 percent of what AT&T paid Sierra Online for it a couple years previously, proving once again that AT&T couldn’t market immortality if it had an exclusive.”

1997 – Ultima Online released for Internet play gaining 50,000+ players in three months.

Summary of “I Like to Talk” by D.A. “Flux” Nissenfeld

D.A. was working on Persecutions and Paradoxi/Realms of Insurrection

The admin found a bug on the first day after releasing his new MUD that broke group chat. He went around to every new player talking to them to let them know the issues, and talking about other things. Despite all the problems of the MUD with an original code base, few rooms and few features, a player base developed. Then the admin got sick for a while and the player base left.

Admins need to talk to the players if they want them to stick around. Talking to the players is more important than any other function of builders or admins. “To me, it just makes sense. Originally, I wasn’t even going to write this article, I thought it was one of those “duh” things, but apparently, it isn’t.”

Talking is the key to keeping new players. When coding on the MUD, log in to the MUD and talk to all new players.

“I didn’t have enough areas, and I still kept those “too high to level” characters logged in because I sat down and talked with them. There were no skill lists, at one point, so I talked to people about what they would get once I got those skill lists functional. They still leveled, despite the lack of a “goal” or advancement of skills.”

Summary of “Planting the Idea” by Lord Ashon

Lord Ashon wrote about finding and gathering ideas in a previous issue of Imaginary Realities.

Jumping into writing code after you have an idea results in incomplete projects and bad code. Use the following two steps to improve code and make projects more likely to be completed.

Step One: Write a fake log of the player and mud input and output using as many scenarios as you can think of. (You’re writing “use cases” in the form of fake logs.) Keep the logs to the most general scenarios. Don’t get bogged down by too specific of situations.

Step Two: Create a design doc describing details of how the code will work. Include new help files for the new feature. Also, keep change logs for a history of changes to the MUD.

The doc should start with a short summary of the idea, and its objective. Next, document the new or changing functions with short descriptions of the change or additions.

Save the doc with your code for future reference by you and other coders.

Summary of “Promoting Your Mud Part II” by Johan J Ingles-le Nobel

Johan J Ingles-le Nobel plays Wheel of Time MUD as Nass.

“To give an indication of what a web presence can do for you, WoTMud’s website gets about 1 million page impressions per year, and was visited by 50,000 unique people last year.”

Here are two tips related to developing a web presence: 1) You’re website needs unique content from the game, such as, help info not found in the game, or news and gossip sections not found in the game. 2) encourage users to develop websites that link back your website.

Once you have random visitors coming to the site that have no experience with MUDs, you need to help them. Creating an in-MUD atmosphere of aiding newbies is a good start. Also, having specific players assigned to the role of “Helper” is a good idea. Limiting newbies to restricted channels and restricted global features is a worse solution.

Remember to have a script removing disconnected players who just logged on to look, but never quit before closing their telnet connection. It will limit the “offline” players.

Back with the article was written, the MUD Connector was a good way for MUDs to be advertised. Usenet was the second best place to list MUDs.

Don’t over do posting to groups about your MUD. Once a month is enough. Make sure your posts about your MUD are accurate. Make sure your posts are well thought out and meaningful or funny. Also, don’t post to unrelated groups.

Banner ads bring traffic, if well done. “Other things worth considering are such features as banner ad networks, webrings, awards and leagues, … it’s all just a numbers game and sooner or later someone will come across your site via these that may actually stay and become a member of your mud family.”

Summary of “The Mud Administrator” by Joshua “dataw0lf” Simpson

Joshua “dataw0lf” Simpson was an experienced admin and coder.

In the MUD beginning, only programmers could admin. Then MERC and ROM allowed non-programmers to admin MUDs, but all the MUDs were essentially the same.

“Too many experienced players believe they can make a mud, but, once they have their first crash, they are at a loss for words. They flood various discussion groups with questions and position openings for coders. Also, this has led to a new, devious type of con-man: the invisible coder. They trick newbie administrators into giving out their shell password, and then cause havoc to the system.”

The author does enjoy teaching new admins how to code, so they can marvel at the code that goes into a good MUD.

Summary of “A Working Mud Economy” by Geoff Wong

Geoff Wong is Dredd on Shattered World MUD.

“Most simulation mud economies are total disasters; with money (“gold coins”, etc) simply hemorrhaging out of monsters etc. Shops simply create endless amounts of money for worthless items, which players continually bring in and sell at fixed prices. Essentially money is a secondary experience point system rather than a useful unit of trade.”

Most muds have a problem with price fixing, because the pool of money keeps going up without affecting the prices of goods. Shattered Worlds fixes this by using the “Loans Standard” based off a paper by L.M. Goldschlager and R. Baxter (“The Evolution of a Pure Credit Monetary System”).

The Loans Standard is based off the formula:

Bank Loans = Bank Deposits + Currency

Banks control the total amount of cash in the game based off the number of players with loans. Every business is run by players. Shops are the most lucrative endeavor in the game. Money enters the game in the form of loans from banks. The banks set interest rates and determine risk.

This approach to MUD economy has worked well, with prices reflecting effort to find items.

Financial related crime has popped up, because the financial system has worked so well. A player run legal system has dealt with financial crime.

New players on the MUD have issues with not having a credit record. They can’t get loans from banks until they prove they are a regular player. Then the only tasks they can do are the ones that more experienced players don’t want to do. This has the downside that new players don’t enjoy the game as much. A system of micro loans might fix this in the future.

To reform your MUD’s monetary system:

1. Create a new currency tracked by a factory object. Don’t make money out of thin air.
2. Put players in charge of shops and pricing.
3. Put players in charge of banks with a central bank that limits loans and charges player banks interest.

 

Summary of “Need No Justice!” by Erik Jarvi

Erik Jarvi was on Shattered World MUD as an Elder Wizard.

Shattered World’s economy and justice system were inspired by an email game, Nomic. The law system has the following types of laws: Immutable, Mutable, common, and non-law.

Immutable laws were created by the MUD admins.

Mutable laws deal regulate citizens and other laws. Each player can have one alt that is a citizen that can vote. “Most of the new proposals / amendments of mutables are for plugging up loopholes in the laws that deal with positions.”

Common laws affect everyone.

Non-laws handle admin type features “like election of magistrates.”

Here is the MUD hierarchy:

• Lords
• King/Queen
• Duke/Duchess
• Baron/Baroness
• Count/Countess
• Sir/Madam
• Citizens
• Non-citizens
• 1 Chief Magistrate, 4 Magistrates, 1 Constable, 1 Editor, and 1 Town Fool

 

Citizenship is received by application and a waiting period.

The editor runs the newspaper. Constable’s can deputize characters. Constables and magistrates handle punishments within the framework of the law.

Lords are guild members that have completed the requisite quests.

Lords can start cults, and get cult points. The King/Duke/Count ranks are determined by who has the most cult point accumulated.

Other perks of citizen rank are total amount allowed in a bank, and commercial property ownership.

Summary of “Online Relationships” by Selina Kelley

Selina Kelley was a staff writer for Imaginary Realities

The author states in many ways that online relationships and love don’t really exist. There is no real consequence for lies online, and no interaction, other than mental, happens online.

The author acknowledges that they did marry someone they met online, but not before spending time with them in the real world.

“Don’t get me wrong, Internet relationships can be wonderful things, but they need to be accepted for what they really are – relationships with possibly like minded people, possibly of the age they portray, possibly of the gender they portray, and possibly of any other infinite number of things they tell you.”

Summary of “Romancing the Blade” by D.A. “Flux” Nissenfeld

 

Humans need conflict in stories. Stories without conflict bore us. Most MUDs provide conflict in the form of combat.

Mortal conflict is part of all human history and pre-history. That makes it a logical go-to for MUDs. The author isn’t condoning blood and guts mass slaughter of innocent pixels. He wants a digital thrill of conflict with “no winners, no losers, no anger, and definitely no grudges.”

Summary of “The Skotos Proximity System” by Skotos Tech Inc

The original article was written byt Skotos gaming company and used with permission.

Good authors immediately give readers a sense of time and place to anchor the rest of the story. See the following example of Dashield Hammet’s opening for The Thin Man.

“I was leaning against the bar in a speakeasy on Fifty-second Street, waiting for Nora to finish her Christmas shopping, when a girl got up from the table where she had been sitting with three other people and came over to me.”

MUDs give that basic sense of place, but usually fail at integrating that sense of other players in the game. “In multiplayer interactive fiction, everyone is significant, and everyone passes the Turing test (well, almost). So we need to find a way to describe a player’s interaction with his environment and with other players in a fashion that is significant to characterization.” How does the player fit into the place they find themselves in inside the MUD?

Skotos games uses a Proximity System that allows players to sit at tables, be near doors, or kneel before a bride. Proximity (Prox) determines if a “knive->ON->counter”, and then these prox are made into chains of proximities. And then a room will have a tree of proximities, as in the following example from the article.

For example, this is a prox tree of a room:

   statue->ON->pedestal->NEAR->northwall->IN->room
                 painting->ON-/              |
        bowl->ON->table->NEAR->southwall->IN-/
       spoon->ON-/                           |
     chair->NEAR-/                           |
                                   floor->IN-/

Proximity determines who hears a whispers and quiet sounds. Vicinity will determine who sees actions. And loud noise can be heard in bordering rooms.

Determining close vs near spaces between objects determines what actions can be performed, such as conversation for near, but a hug or kiss or handing off an item for close proximity. The distinction and a slight pause between passing from “near” to “close” allows a character to get up and leave, preventing close contact.

Skotos games have a Sound System with varying levels of volume. Varying levels of proximity interact with the sound levels to determine what is heard and by whom.

“Proxes are a very useful method for setting up dynamically controled room descriptions. They are a very flexible method of controlling the depth at which you display descriptions and dealing with these sorts of problems in real time. In addition they allow for the creation of more fully modeled systems, such as the consent and sound systems described here.”

Summary of “Why Run a Mud?” by Peter Wood

Peter Wood was a college student in the UK. He was writing WoodMUE server, and Arien MUD.

Reasons for running a MUD server.

• Knowledge/Learning – Such as programming languages, or seeing how people behave
• Power – Some people like snoop and intimidating
• Employment – Sometimes you can make a little money at MUD setup and maintenance
• Challenge – Setting up a MUD and keeping it running is a series of difficult challenges

 

Finally, getting complements on a MUD creates a wonderful mood. However, insults cause a lot of bad mood days. “At the end of the day, running a mud can be fun, depressing, tiresome, joyful and entertaining. A mud has a lot of good experiences and just needs to be looked at in the correct manner.”