Category: Imaginary Realities

Summary of “A New Paradigm for Levels” by Phinehas

 

Large level differences between players can damage sense of community in games. Additionally, being lower level can be a source of shame and inferiority. However, level advancement gives players an important goal, and community does not have to be damaged by level differences.

Imagine an empire building system with 7 levels and a king of some sort at the top level. “What if our concept of level is totally uncoupled from things like hit-points, skill, and the various other powers typically associated. What if a character’s level only indicated responsibility and authority, but not personal power? What if the peon could take the king in a fair fight? In fact, what if the peon had all of the power and abilities of the king, except one: the ability to promote.”

Each level would have the ability to promote the players at the level below them, giving players a reason to fulfil the needs of the players above the in level for the sake of attaining promotions. Promotions could also depend of public opinion, so they are kept honest.

Public opinion might not affect a promotion, but could affect the promoter’s chances of being promoted. So, they would need to pay attention to it to keep their own public opinion high. Public opinion could also be affected by charisma, dress and other factors.

NPCs and PCs could both register public opinions of players. Accomplishments and slander could sway public opinion among PCs.

“If you are the king, your life will likely revolve around public opinion issues. Prosperity, employment, success in battle, low taxes, and an expanding empire must all be balanced to ensure that you are loved by your people.” Otherwise, a rising lord might take your kingly position.

Motivation of a Peon to do the King’s bidding is merely to get levels, but the power to fight and complete quests doesn’t come from levels, so the Peon could choose to not seek rank or obey the King.

Summary of “It is not so Simple” by D.A. “Flux” Nissenfeld

Flux was involved with creating the first “twin” MUD, … I have no idea WHAT that means.

The author loved hack-n-slash (HnS) games, but didn’t want a stock MUD, or one with the same fight engine as all the other MUDs.

The author took inspiration from anime and video game fights for his fight engine. Also, he hated systems that involved pushing a button as fast as possible to win and get experience.

“In addition, do not let other people tell you what is wrong with your engine. If you want to have a Dragonball Z-ish fighting engine, so be it. If people do not like that, bad luck. It is your game; you always have to remember that. You can take consolation in the fact that there will be people who find your game interesting. How do you think all those stockish muds have player base.”

Summary of “Literary Role Play” by Phil Goetz

Phil Goetze played GarouMUSH spoken of in this article.

“You can tell a lot about a mud by its name. If it ends in ‘mud’, especially Dikumud, it is Rogue-like. If it is a Tinymud, it could be more Zork-like. And if it ends in ‘MUCK’, ‘MUSH’, or ‘MOO’, it has a lot of talking.”

Originally, the author talked of all MUDs as multi-player Zorks. They with the introduction to truly unique MUDs like GarouMUSH, he discovered his error. GarouMUSH heavily enforces role playing based off White Wolf RPG Werewolf that it is based off of. Out-of-character rooms and commands are much more distinct than in other MUSHes.

In GarouMUSH, characters must make sense and be approved.

“A central gathering place is crucial to a MUSH. Spontaneous role playing is much more likely when you have a critical mass of characters in one place. On GarouMUSH, the Caern is the center of Garou life. It is a large, circular grassy area consisting of nine locations, from any one of which you can see what people are doing in the others.”

The flirting that often bogs down typical MUSHes doesn’t happen on GarouMUSH, because Garou law prevents Garou’s mating with each other. This greatly benefits the roleplaying on the MUSH.

Before opening to the public, 30 invite-only players spent a few months ironing out roleplaying difficulties in the game. This meant that new players had a solid group to emulate (or hate and leave.)

Roleplaying in this MUSH faces the challenges you’d expect of not being there in person. Sometimes feeling are hurt because visual clues to irritation or being upset cannot be spotted. On the good side, the players take a more active role in the story, because there is no game master to tell them what their options are.

This MUSH often is more writing than roleplay. “You sit there, watching the cursor blink while you figure out what to say, and how to say it. You type a line, but before you press return, the urge to edit takes over. And before you know it, you are not just playing, you are writing.” The game becomes a work of literature.

The author gives extensive examples from the MUSH of using character actions and descriptions to replace the in-person experience that is missed out on when playing a roleplaying game remotely. The game logs become works of omniscient viewpoint literature, often devoid of fighting, sleuthing and confrontation.

“People stop acting like puzzle-solvers when they start acting like authors, and they start acting like authors when they have a good medium and an audience.” Though it suffers a little from a lack of a central director.

Summary of “Room for Improvement” by Donky + Scatter ///\oo/\\\

Donky was considered one of the best MUD coders, period.

Progress in MUD development is not adding a new area or small features. Progress is creation of game-wide, depth features that affect the structure of the game itself.

The MUD the author worked on added attempted to add these type of game-wide, structural changes. The first was to introduce new rooms that were computer generated rather than laboriously, hand-built.

Computer-generated terrain could handle the creation of a whole area or biome, then the builders would add finishing touches, such as hand-built ruins or other hand-built places of interest. A challenge to computer generated terrain is that the player must find interesting rooms, or the computer is only generating boredom. Also, large wilderness areas would need the ‘travelto’ command to work even when the player is offline, so traveling doesn’t get too boring.

“The resulting backdrop gained from this does not have to be bland filler that merely enables a player to get lost or at best take an unconventional route from A to B, it can also provide places for” resource harvesting or activities central to the game.

Computer- generated oceans riddled with hand-built (and generated) islands could provide the ability to own and navigate your own ship. Computer-generated skies open up the possibility of flight (and falling)

Another feature the author is adding to their MUD is movement and positioning within a room. This allows for multiple exits from a single direction, and ability to hang out by a door to ambush players coming through the door. A challenge to this system is that navigation commands need to be added or modified to make moving around the room easier for the player.

Wilderness areas, oceans and even rooms can have coordinates. This can become a challenge for the builders.

“Obviously, this profusion of coordinates can rapidly become a confusing pile of numbers facing creators in a text-based mud.

“The numbers alone are not the only complication. There are many other issues to take into account as well. For example, rooms have to be placed exactly beside each other with appropriately positioned doors between them for the exits to work. If the structure is a certain size, the rooms within cannot be allowed to exceed that size in total. Structures can not exceed the islands, and so forth. The jump from simply specifying a room with some exits to other rooms is fairly monumental.”

Summary of “See Timmy Run” by David Bennett

David Bennet was a Discworld MUD admin.

“There have been a couple of newspaper articles recently about online games showing the addictive side of the game. Where people have been so caught up in the game they have forgotten about life and removed them selves from their previous social life. In some cases people have lost jobs, marriages and money to online games. The question is, does the administrator have an obligation to do anything about this.”

Should admins cut off overly immersed players? How would they know the players are out of control in the real lives?

Creators could design play to allow players to take breaks every two or three hours, and continue from where they left off. Ultima Online implemented a feature that allows players to make skill advancements fastest during their first hour, and then skill advancement drops off to slower and slower rates the longer the playing session lasts, until all advancement stops after a certain length of session play time.

“There is a delicate balance between having a game that is too addictive and a game which is not addictive at all. You want you players to keep coming back week after week, but it would also be advantageous if they could play in small doses.”

Summary of “Wanted. Area Creator. Dead or Alive” by Selina Kelley

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

The author has a well built MUD, but no area creators. It is difficult to get area creators to join your MUD.

“Am I expecting too much from the current area creators I have? All I really want, is an area every, say, three months. I do not feel that I am asking too much, but it seems as soon as an area creator that I have “hired” completes their first apprentice area, they suddenly become “too busy in real life” to build more areas. Not too busy to log in and chat though. Or they become more interested in creating “mudlib” than building areas. You know the type, too “good” to make areas, but that is the reason you hired them? Argh!”

The author laments not being able to hire and retain any area builders, and has only two new area she did not build herself in the last year.

Summary of “Acting Casual About Casual Gamers” by Brian Green

Brian Green was a developer for Meridian 59 and later Communities.com.

“Definition: Casual gamers are people who like games but do not have the time or inclination to play them obsessively.” This includes people that are hard core in some games, but only casually play MUDs.

Increasing a game’s player base requires getting more casual players to join. Many people think they need to attract potential players. Casual gamers are already interested in the game, but need it to improve before committing more time.

Attracting casual gamers needs a better social environment online, and less focus on advancement. “People feel penalized for only playing a couple hours (only?!?) per night. Why? Because they can not keep up with the advancement of other players they know. Every hour they are not playing that someone else is is an hour they are behind. The only way to catch up is to spend an extra hour playing that their friends do not. If their friends spend 10 hours per day compared to 2 hours, you can see how quickly they fall behind.”

Having characters persist while the player is offline is not a good solution to characters falling behind because players don’t have time to play. However, characters could take care of repetitive tasks that benefit the character while the player is not present, such as repairing armor or trading to earn money. Keep the player doing fun stuff while in game, and have the character to the boring stuff while the player is away.

Communication with other players is another key to having better social engagement in the game. “I have found it useful to divide in-game communication into four categories: instant vs. persistent, and personal vs. broadcast. Instant messages happen in real time, while persistent messages are stored for viewing at any time. Personal messages are “private” messages between specified recipients, which can include a small, select group. Broadcast messages are messages viewable by anyone (or members of a large group) in range of the message.”

Despite having to moderate message boards, providing adequate communications options for socializing is key to retaining an active, committed player base.

“If the casual gamer cannot find his or her friends, he or she will not be playing our game for long.”

Summary of “Automating NPCs” by Zykes

 

NPC’s shouldn’t hangout at the same location all the time. They would likely need to eat, drink, work, sleep and possibly other things. Set up a state machine based off the individualized NPC stereotype and trigger their current activity based off the time of day.

For example (from the article):

FARMER (stereotype)

   |
   EAT (need that is activated at 07.00, 12.00 and 17.00)
   |
   DRINK (need that is activated 14.00 supposing he drinks while he eats too)
   |
   WORK (need that is activated after every meal he eats except the last one)
   |
   SLEEP (need that is activated after his last meal)

 

Using rules based off the stereotype, … “maybe you just want to remove him from the room telling everyone there that Joe leaves for supper, or if you want a routing system that allows Joe to walk all the rooms to his home and there start a supper scene with his wife and all the kids”

Summary of “Ciara’s Folly” by Scatter ///\oo/\\\

Scatter ran the Dawn Whispers MUD and was a staff writer for Imaginary Realities.

The article starts with a call for MUD related story submissions. This article is a story written and based off the author’s experience early in his MUDing career. I give a very brief overview and synopsis of the story, but due to copyright laws can’t reproduce the story here.

The story follows a wizard, a priestess and a warrior in Comgal. New artifacts from a strange place call Vzar started appearing in the region. The three took leave of their training and commitments, secured an inadequate boat and set sail on the high seas with no experience and no idea where they were going.

On the fifth night at sea, something with tentacles attached to their boat and proceeded to climb in. A dangerous battle ensued, with the warrior being the only one that could directly damage the monster. The wizard and priestess both healed and strengthened the warrior with their own crafts until the monster died and sank back into the sea.

With the ship’s sails gone, supplies destroyed, and anchor missing, the three began to row for home. When they finally found land, they got caught in dangerous currents near deadly rocky cliffs. The boat was destroyed on the rocks, but amazingly everyone made it to shore alive.

“This column will depend on your contribution – all of you out there who are exploring, adventuring, creating legends on muds every day. Send in your stories and become a part of the bigger myth. We can polish any rough spots, smooth out any bumps – or if you wish, even write your story for you if you give us enough detail of what happened and why. Simply use the form provided, or send in your story via email.”

Summary of “Online Relationships – Part II” by Selina Kelley

Selina Kelley spent a lot of time on ProphecyMUD.

“I have noticed something that wasn’t quite as clear to me before– that while an online romantic relationship is not similar to a real-life romantic relationship, that online relationships as groups can certainly lead to what I would call an online community.”

The reason for the new opinion was a player she referred to as, “Bob”. Bob did not adhere to the common rules of the online community, nor to the rules of society as a whole. Bob engaged with a large number of the online community that tried to change him to fit, but failed and became a source of online consternation for the greater online community.

The situation finally escalated to an effort to bar him from the community. Efforts were made to report Bob to his ISP, police, and the news. So the relationships Bob created had a very real world impact.

“So, is an online community the same as the community you live in? Maybe. The main difference seems to be that most online communities are made up of groups of people that have interests in common, while the community you live in mostly has just its surrounding area in common.”

Summary of “Til Death do us Part” by Andrew Ritchie

Andrew Ritchie was designing a MUD at the time of writing this article.

Almost all death systems fall into “permadeath” or “non-permadeath” categories. Permadeath is found on RPG type MUDs for believability. Non-permadeath systems are found on hack-n-slash style MUDs because it makes the game more playable.

Permadeath systems tend to have a fixed number of deaths before the character does not respawn. Ten lives is common. Also, permadeath systems often have a way to get more lives by completing quests or other tasks.

Consequences of death tend to fall into eight categories. The character …

• respawns somewhere else.
• loses something like levels or experience.
• loses valuables like equipment.
• cannot do something for a fixed period of time
• goes to an afterlife to perform a task to get reanimated.
• must wait for resurrection or a cool down period
• loses a life permanently.
• dies forever.

 

Death should have severe consequences, or it is meaningless. Some sort of permadeath should be possible in all MUDs.

Summary of “Why Deal With Harassment When You Are Having Fun?” by Ucchan Tsukino

Ucchan Tsukino played as Nerissa on Redemption MUD.

The entire article is a persuasive rant about caustic, NSFW players ruining the MUD experience for everyone else, and admins that punish the victims. The author wants to stop seeing players needing to ‘hush’ other players, or quitting because of the abusive behavior of other players.

“People play muds to have fun. What is wrong with that? I do not want a player killer to embrace every pacifist they encounter thus abolishing the very essence of role-playing, but I want people to stop mistreating one another and start displaying the little bit of respect that everyone deserves.”

Summary of “A Realistic Equipment System” by Logan Lewis (a.k.a. Proxima)

Logan Lewis was a MUD programmer.

If you seek for realism in your MUD, you might want to add a system for equipment to wear out, or expand upon your current system if it already has one.

“For instance, each piece of equipment has an integer value (such as 0-100, 0 being unusable, 100 being perfect) for it’s condition. This value, in my opinion, should never be directly shown to the player. It is not too difficult to translate this value to a reasonable set of adjectives. There should be a decent range of them so that players have a feeling when their equipment is going bad, not just “Good” to “Poor”.”

Wear and tear on equipment should make sense. Swords wear out faster in combat than in their sheath. Armor wears out slower than a tunic.

Equipment should become less effective at its tasks as it wears out. When an item’s condition reaches 0, it would break irrepairably.

Repairs could fall to certain character classes or NPCs for a fee. Make sure the repair system is not overly complex, or it will detract from the MUD’s playability.

Summary of “Classless Systems” by Ben Chambers

 

The author based this article mostly off of Urban Desire MUD’s classless system.

In the real world, people are not born into their profession. They grow into their profession based off their skills learned. Doing the same in a classless MUD allows for multi-class benefits without the hassles of a multi-class system. “In a classless system the things each player does molds them into a persona or character.”

Skill and level caps need to be in place. “Also in a classless system it may be wise to allow the training of statistics so that if you do have an infinite level system (which I feel is really cool) you need some incentive to continue advancing beyond the skills cap.”

In fantasy books, there tend to be no classes, so you end up with things like battle-mages, and paladin-healers. These exotic types of characters are easier to create in a classless system.

In a classless system, everything is skills based. A race may start with a base skill set they have access to learn, and gain access to more skills they can learn as they level up. Different races could have different proficiencies in different categories of skills, so they gain access to the categories quicker. “When you use a skill in a category your overall proficiency in that category expands. Each skill in that category has a specified proficiency that you must have before you can begin using it.”

Guilds would be replaced by clans in a classless system. Clan creation could be dependent on having reached a specific level, having a certain number of supporters of a given level, and lots of cash.

Summary of “Growing Your Idea” by Lord Ashon

Lord Ashon was lead developer on WheelMUD.

This is a third installment, based off Dr. Bartle’s four types of MUD players: Hearts (socialites), Clubs (PK’ers), Diamonds (achievers), and Spades (explorers).

Putting code change notifications (new quest or area info) in the Message of the Day (MOTD) is fine on hack’n’slash style MUDs, but not on roleplaying MUDs. Roleplayers want to discover changes to the MUD as they explore.

“So, to accomplish this we take our new code, and we write a story about it. The story should include the 5 W’s, the Who, the What, the When, the Where, and the Why, and occasionally the How.” Use the story you created about the MUD code change to introduce players of the four types to the new quest, area, or mechanic.

Hearts more likely care about the pros and cons of the code change.

Clubs just wait for the new thing to move, and then kill it.

Diamonds only need a hint dropped by a MOB, and they’ll be off questing.

Spades will gladly listen to a MOB talking about the new area or quest.

“So to summarize and wrap up these last three articles, Ideas are everywhere you just need to go out and find them. It’s easier then it looks. With the new idea you need to PLAN how the idea is going to work in your mud. Then you code the idea. Now that you have it down, make it’s introduction part of the mud by getting the players involved in discovering or uncovering the code. With these you create a living, changing mud that your players, and administrators will always remember.”

Summary of “Keeping Control of Grief Players” by Patrick Dughi

Patrick Dughi was a player, builder, admin and general programmer on several MUDs for several years. He also owned his own claymore.

Every online game has to figure out how to deal with griefers (including harasment.).

Banishment works by disallowing IP addresses. This becomes difficult if the player is randomizing their IP in some way. In this case, “to successfully ban someone, whole subnets must be disallowed. Imagine having to block all of aol.com, for example (though some people have that setup as the default).”

Deletion of characters is usually skipped in favor of banning, but sometimes is used if the player leveled or obtained items by cheating.

Freezing/Jailing is used to let the player watch the game happening, but not allow them to interact.

Weakening removes abilities, items, or levels. This one extremely flexible, but is not used often.

Silenced (also called muting) is often enough to stop problems involving players loudly expressing anger.

Tagged with labels like “Player Killer”, “Theif”, “Oathbreaker”, “Dishonorable”, or “Coward” may work wonders, depending on the theme of your game.

Automation of grief prevention should be applied evenly and fairly, such as a a swear filter. It should affect admins and players. Automation of tagging players that loot corpses or otherwise steal, could result in armed guards capturing or killing players that have bad tags.

“In anycase, the biggest source of problems is adverted; the human component. I have seen, in 8 years of MUD experience, 12 separate muds either die completely, split, or otherwise fade away due to what we will term ‘politics’. I have heard of many more that suffered the same fate. In every event, it is the same; Administrators do not trust other administators, players do not trust administrators, and administrators does not trust players. This degrades the administration structure, and player base falls off as they experience the fallout from above, and also notice that their problems are not resolved satisfactorily.”

Nepotism, hypocrisy, trust issues and player angst can kill an otherwise successful server. Admins that play the game, too, often take advantage unfairly of their knowledge of the game to acquire more power and better equipment than other players.

Nepotism, hypocrisy, and trust issues can mostly be removed by having an automated anti-griefing system that applies to ALL player, even the admins that play. This only leaves player angst as an issue, and that is usually a personal problem of the player that the admin can’t resolve through automated tools.

Admins cannot personally stop players that grief, unless they happen to be online and witness the behavior. Otherwise, they are relying on second hand information. Logging may help.

One approach used is “god hate” that silently reduces all stat acquisition and combat abilities by 20%. This gave admins time to deal with a potentially problem player before they became more influential in the game. It worked very well on the MUD it was implemented on.

Bad guesswork and bad politics can get in the way of any anti-griefing system.

Another approach is player decide which administrative actions are taken against other players. This usually devolves into very childish behavior that does bad things to the game. A hybrid system of having players be sheriffs could work, provided regular players do not have the ability to mute, ban, or delete other players.

Summary of “Cymoc’s Favor” by Scatter ///\oo/\\\

Scatter ///\oo/\\\ wrote this story based off mud adventure from October of 1995.

This is a story of a thief returning to her town to find it overrun by undead, and most of the inhabitants hiding, dead, or fighting for their lives. It is an exciting story with a good ending.

Summary of “The Numbers Game” by Michael “Talien” Tresca

Michael was a staff writer for imaginary Realities, a reviewer for rpg.net, and an admin for RetroMUD.

The most leveled player on a MUD often develops a cult following. Other players do and believe whatever that player does or believes. Also, once one player figures out how to defeat your MUD, word spreads, and every player is playing the MUD exactly the same way.

In the case of RetroMUD, there are 13 damage types, but the popular players only used electrical and fire, so everyone stopped using the other types of damage.

To encourage the use of all damage types, one of the popular playing areas was modified to create a dynamic damage behavior. “Whenever a spell is cast, it adds to the pile of spells previously cast. The more the total player populace uses a particular spell, the less effective it becomes. Similarly, unused spells become more effective. The end result makes the magic system less predictable and more dynamic.”

This worked well, but a modified version of this damage scaling approached worked even better. “n RetroMUD, Rayzam, one of our administrators, took this concept a step further by creating an Elemental Damage Economy. Whenever something inflicts damage, be it through a spell, through the Damage Type of a weapon, or through the Damage Type of a monster, it is checked against the balance of elemental Damage Types. If more damage was done with opposing elements, it gains a bonus to damage (up to 120%), making it do greater damage. If that Damage Type’s element is over used, it will do less damage (down to 60%).”

This balanced damage scale affects monsters, too. So they might cause less damage due to damage type scaling, or receive abnormally large amounts of damage due to damage type scaling.

Some areas may have monster that use all of one type of damage, so the opposite damage type becomes the most powerful, and predictable, go-to damage type. This get’s boring. In these cases, just make the monster immune to the obvious choice for playability’s sake.

The “Number Economy” approach can be applied to MOB kills. For example, a “Slayer System” might keep track of the number of each type of monster killed, and decrease experience for that MOB if that is all the players are killing.

Summary of “Why Socializers are our Comrades” by Brian Green

Brian (AKA Psychochild) was a developer for Meridian 59 and Communities.com. Also, he was a frequent poster to MUD-Dev.

The author took the Bartle-quotient test and found himself to be a SEK even though he shied away from Mushes and chats. Even though the author is not much of a socializer, socializing is the whole point of putting a game online.

“I advance the notion that we worry too much about the other types defined by Bartle to the exclusion of the Socializer type. We constantly ponder the problems caused by unrestrained Killers, we tend to focus our games on keeping the Achievers happy, and we always want Explorers to grace our games. Explorers are the fun and interesting players. But, when is the last time you heard any mud developer consider, ‘How can I make my game more attractive to Socializers?’”

Developers need to get involved in the creation of positive communities, rather than let any random community form spontaneously. In Meridian 59, a small tight knit positive community was allowed to play and get established before the game was opened to the larger public. This meant that a few toxic players joining the game, couldn’t take over the already-established, positive social network.

Attract Socializer type players. Give them access to individual and broadcast forms of communication. “This also brings up another important concept: that we need to make sure that Socializers are able to meet new people and make new friends if they want, just as Achievers want new powers, Explorers want new areas, and Killers want new victims. Much of the focus I have personally seen in discussing systems for empowering social groups talk about allowing people to keep in contact with their existing friends. However, I know from personal experience that meeting new people is a large part of why I enjoy socializing with others.”

Don’t exclude the other three types of players from your game designs and goals. Also, don’t forget the importance of the Socializer for long term success of the game.

Summary of “Current and Future Developments in Online Games” by Raph Koster

Raph was lead designer and programmer at Ultima Online.

Everyone is making online games, now. Newcomers to online programming don’t understand running a service, and “old guard” don’t have production value or a sense of mass market.

“Online games have been on the verge of fulfilling their promise for so long now that everyone is getting tired of waiting. If they are to break further into the mass market, as we all agree they have wonderful potential of doing, people need to look both to the old guard for the reasons why players keep coming back, and to the new guard to topple some sacred cows.”

Online games need to be “sticky”. They need an experience that brings players back, for the purpose of getting money out of them. “We have to design our games to make players want to keep paying, and keep coming back, at minimum cost to us the service provider. This is one of those things so obvious on the face of it that people tend to miss the point.”

You want players to subscribe, so they don’t have to log in to stay a paying customer. Session-based models depend on players remembering to log in (and pay) when they often can’t remember to watch their favorite TV shows. You want retention of subscribers that don’t even log in.

It takes money to make a game attractive enough to get new players to log in. You need good art, good marketing, and good game design to succeed. Ultima Online “got lucky-it was in the right place at the right time and had the marketing muscle, the brand name, the presentation, and enough accessible gameplay functional at launch to grab the brass ring.”

Choose your battles. If you don’t like the battle, redesign the battlefield. UO did just that, by raising the bar on what an online game was.

Friends and social groups move from game to game, so are not the primary retention avenue for online games. There needs to be some sort of ownership, to retain players. The player needs something they can’t take with them. A cool avatar, player level, and friends aren’t enough.

Games need to be about the game and playing. Also, the game should NOT have an ending or completion. Players must NEVER run out of things to do. “Make your games ones where your advancement ladders are infinite rather than finite. Be it via king of the hill, player-driven content, redirecting players to socially-oriented advancement ladders.”

Players need something in the game that emotionally excites them. Don’t sanitize the game so much that it becomes boring.

The game needs to be a service, a world, or a community, but never just a game. Turn the game into an experience. Include the accompanying website. Make sure your game’s tag line empowers the player, making them feel this is THEIR experience.

Make a game that matters to people. It needs to make people feel something.

Summary of “Dark Ages Politics in Theory and Practice” by Dave Kennerly

Dave Kennerly ran Dark Ages and also Nexus: The Kingdom of the Winds.

Descriptions of attempts at 90% self-rule online political system run by players. See Dark Ages MORPG for details.

Summary of “Destroying a Mud” by Frog Brothers

Frog Brothers is a long time player that has seen several MUDs destroyed.

Mud whimping is nerfing previously overpowered game elements in the name of game balance. Mud wiping is zeroing out all player skills, achievements and weapons. Both MUD whimping and MUD wiping drive long established players from the game.

Also, random changes that have far reaching effects, with no player driven reason, drive players off.

“Once mud whimping has set in the rot is started and will not be turned around, the mud starts breaking up into little factions. The factions all start infighting and the end of the mud is in sight … nce the mud starts to splinter into factions and groups the players stop feeling that the mud is a happy place to be”.

Inform them of large reaching changes before you make them, and then listen to the players’ feedback.

Summary of “Ramtop Rescue” by Thirsha

Thirsha is a Witches Guild member on Discworld MUD.

This article is a story about a rescue of a wounded warrior from a mountain canyon.

Summary of “Muds Are Not For Wimps” by Michael “Talien” Tresca

Michael was head designer and coder for RetroMUD.

This article is a response to the “Wimping rant” by Tenarius. Tenarius’s main point is that disgruntled players create MUDs, become admins in the process, and quickly forget why they liked playing, so destroy their new MUD starting the process all over.

Thirsha states, Players are selfish and should be. Coders code. Players play. And, they both need each other.

Admins are also selfish, and they should be. Admins know they went through all that work of creating the game to make users happy. However, the admins liked the action of creation, so the players’ enjoyment is not the ONLY point of the creation of a MUD.

MUDs need constant fixing. If players level too fast; if killing monsters becomes too easy, due to dublicatable methods; if the economy gets out of whack with items too expensive, or too cheap; if a class or race becomes too common due to unfair advantages; the game needs fixing. Not fixing it, doesn’t stop players from leaving. Fixing it is likely to angers some players, too. Long term, the game needs fixing.

Coders want their players to stick around. “But players will only stay if they are having fun. If the game is too challenging they will leave in frustration. If the games is too easy, they will quickly overcome the game, and probably leave.”

Coders are the good guy and the bad guy. Players beat a monster they get rewarded. Players get beat by a monster, they get penalized. The Coder get the blame either way.

Shattering the illusion of an immersive MUD happens when any change is made. However, if a MUD is out of balance, or buggy, that will destroy the illusion, too.

“But players will only stay if they are having fun. If the game is too challenging they will leave in frustration. If the games is too easy, they will quickly overcome the game, and probably leave.”

Summary of “Programming for Administrators” by Patrick Dughi

Patrick Dughi was a frequent players, builder, and programmer, that owned his own claymore.

Coding and programming are not the same. Coding consists of typing, compiling, and running. Programming is everything else. That includes planning, integration, and social stuff.

If you are the only programmer and admin working on your MUD, then you don’t have two worry about all this. But usually, you have a non-programmer running the MUD, and you are not a solo programmer on the MUD.

The author gives an anecdote of a remote system being implemented in a MUD based off another MUD that didn’t have the same features or game balance. The whole design process was the admin saying “make it just like the other MUD” and “do what seems right”. The result was an unbalanced remort system that unbalanced the game and caused tons of players to quit.

The point is, a design phase is needed for any complex change. Use the 90/10 law. That is 90% of your time should be designing, and 10% of your time should be spent programming. “If you move those ratios around you start loosing time; in code rewrites, updates, conversions, bug fixes, future compatibility issues. This time should have been spent on new projects, but now is taken in just maintaining old ones. You’re actually losing twice; old project doesn’t work, and new project doesn’t exist. Project planning is very important, and whether the notes end up on the back of a cocktail napkin, or on the ever present white board, matters not a bit – it’s that they exist at all.”

Document in great detail what changes are to be made so the programmer knows everything about the expected change. One-line descriptions don’t work and will cost you tons of time in rewrites and maintenance, later.

 

1. Generate project goal & focus (initial requirement generation) – Write down everything about the project as pertains to the game.
2. Gathering Requirements – Fill in any gaps in the requirements from the previous step.
3. Requirement review – The software engineering team meets and determines what features can and cannot be implemented, along with filling in any requirements that were missed in the previous steps.
4. Requirement Approval – Create a detailed document with specifics of everything determined so far. Give the document to the software engineering team. Hammer out any issues and disagreements until the team agrees on the requirements document.
5. Requirement hand off – Create the code from the requirements document. Everything about the new feature should be in the document, so the coding process is merely coding.
6. Final Approval (beta-testing) – Check that the changes to the software agree with the requirements document. This can be quick or a multi-month process of testing depending on the complexity of the change. If the requirements themselves turn out to have been deficient, then return to step 4.

 

The author suggests reading Code Complete by Steve C McConnell, and Debugging the Development Process by Steve Maguire

Summary of “RL vs. muds” by The Beyonder

A poem comparing Real Life (RL) to MUD life. Turns out they’re not much different. The MUD is more dangerous and less restricting.

Summary of “The Community” by Lord Ashon

This article was an allegory of about builders of a space station. The original builders create and inhabit the space station, then leave for earth and other newcomers take over. Eventually, many people move to the space station–some willingly, and some by force. When the original builders come back, they find that the station is messy and filled with litter. No one even acknowledges their accomplishments of building the original structure.

This is applied to the evolution of the MUD community with newcomers, commercialization, and licensing that has been ignored.

“Beware though, the one evil in our community, the commercialization of our hobby. Do not fall to the belief that the commercialization will destroy our hobby. It will not, nor will it ever. We do what we do because we believe in it. Because we have a burning desire to do what we do. Those who commercialize our hobby, are no longer doing what they want, but what their companies want. Share and improve, Welcome and acknowledge. Rescind and forget. Remember and revile.”

Summary of “‘Cruel Doubt’ on the Net” by “The Crimefighter” Steven Lucas

Steven Lucas ran Promised Land MUD and maintained “The COMPLETE Abermud List” and the “Betterbox Mudlist”.

The author discusses the pitfalls of telling people he runs a MUD, and how lot of bad press existed around the true story, “Cruel Doubt”, where some gamers brought the D&D campaign into real life, including murder.

School shootings and other violence have been blamed on video games. This has gone as far as attempting to prevent teens from buying violent video games.

The author went through the effort of teaching his parents how to connect to the Promised Land MUD he runs, and the associated website. The father went ballistic, explaining the site was satanic and would corrupt already misguided youth. [Summarizer’s Note: This actually was not an uncommon response to fantasy novels, Dungeon & Dragons style games, and similar video games and movies back in the second half of the 1900’s.] The MUD did have a religion system with “gods” that would power up players that did what they said. But, nothing related to real mythology.

The author sought advise on handling the objections of his Christian father on the discussion forums at the Mud Connector, “and got a wide range of responses. Some were by other Christians, some were by people who thought it was a ticket to bash Christianity, and some were corny jokes. Eventually, it developed into a fight over Christaphobia and whether separation of church and state was actually in the Constitution.”

MUD’ing isn’t the worst thing to worry about in this world. Trying to get people focused on those actual bad issues, instead of MUDs, is easier said than done.

The author hosted their MUD at a university at the time, and the university received a fake letter claiming to be a mother of an impressionable teen who she no long let play the MUD due to bad language, sex, and other NSFW communication going on between players of the game. “She” also accused the MUD Connector of not listing the MUD with a warning about the adult nature of the MUD. The author new the letter was a fake, because it came from a ISP which never had logged into the MUD.

“As a result of the “parent mailing the university” incident, the Mud Connector has had posted its the front page a parental warning sheet informing everyone to keep their kids “mud-safe” ever since. The Mud Connector certainly did not get a letter accusing them of not listing any certain mud as “adult-oriented”. In all reality, the Internet is a filthy place to be. There are thousands of people who may be adults but have the maturity of three year-old children online. If you think the kids should not be exposed to bad things on the Internet, they should not be on it at all. Course the kids think, I am old enough to deal with it, all my friends and rivals at school say this stuff too! And they are right. Kids at school are filled with S, V, & D (that’s sex, violence and drugs for those in Rio Linda) and want to teach it to other students, who are just as willing to learn it–cause they want to experience what adults do here and now.”

Then a school shooting in April 20, 1999 in Colorado kicked the hysteria into high gear of blaming everything but the children and their parents for their horrible actions. Any mention of a gun or image of a gun started getting children expelled. “At this rate, sooner or later all kids entering the school system will be taught in buildings that look like, and have the security of, federal prisons–never mind we think we are serving a 13-year prison sentence anyway. What is WRONG with you people??? This makes school vouchers and home schooling VERY attractive compared to all this total nonsense going on.”

Eventually, all the related laws and blame will point at blaming MUDs when some copycat shooter is found to have played MUDs. Luckily, MUDs aren’t popular enough to become a target as of yet. Video games get all the ire.

Be prepared for misunderstandings from people who are poorly informed about playing MUDs. Remember, if one person is having fun, someone somewhere will try to punish them for it.

Summary of “Help Systems Suck” by Natalia

Natalia and her husband, Ilya, used to run Game Commando.

Most MUD help systems suck. Common problem include the following.

 

• bad design – Most fall into the hierarchical (organized like a tree of categories and subcategories that can be browsed) or shotgun (a random list of key words you find by typing ‘help ‘) approach, but not both. Both hierarchical and shotgun together would be better.
• missing topics – Admins dedicate themselves to writing their MUD, often giving up real world opportunities to write their MUD, but then fail to write thorough help documentation for their MUD. Puzzling.
• not up-to-date – Often admins won’t have even changed the name universally to match the actual name of the MUD. The help docs are just what was left over from when the started developing the game from someone else’s source code.
• missing keywords aliases – “Is the help I am looking for going to be ‘pk’ or ‘pkill’ or ‘playerkilling’ or ‘player_killing?’ Is it ‘help death’ or ‘help dying’? Even when the code for the help command will match partial words, ‘death’ will not bring up ‘dying’ unless the administrator has added both as keywords to the documentation.”
• parsing – Help topics need to be findable even if an ‘s’ is added onto the end, or just the first few letters are typed in. Expecting an exact match from players seeking help, is not good enough.
• “the evil one topic” – If the partial help topic name they user types could match multiple topics, list all the possible topics. DON’T just show the first topic.
• spelling and grammar issues – Use a spell checker.

 

If you run a publicly available Online Role-Playing Game (ORPG), you obviously care about it being seen by players. Otherwise, you wouldn’t have made it public. Frustrating players with a poor help system is antithetical to your desire for people to play your MUD.

It is amazing that an admin will add races and classes as quick as possible; announce them everywhere conceivable, then not document them in their help system.

One solution is to assign one person to the task of updating the help system. Make that their only task.

“The following help files and documentation should always be present on the game, hopefully with multiple keywords and obvious ways to get to the information:

• about the game owners (who are they, what are their game names)
• rules/policy/laws including specific notes on player killing, multiplaying, harassment, language, etc.
• about your character (for instance, how many levels are there)”

 

Log your help requests. Matched keyword logging is helpful, but help requests that failed is even more helpful. You will know what improvements you need to make to your help system. Let the player know in an automated message that the missing help request was logged for future creation.

Add an online help editing system, so admins can change the help information from in-game. Include keyword aliases. Also, add a ‘see also’ section at the end of the help entry.

Summary of “Days on the Disc” by Dogbolter/DcDhol

MUD fiction as told by Dogbolter, a creator on Discworld MUD.

This fiction is a short study of an unsavory character by the name of Mr. Tulip in Ankh-Morpork.

Summary of “From the Diary of DcDhol” by DcDhol

MUD fiction as told by DcDhol, a player on Discworld MUD

This fiction is a short and colorful travel log of visiting a nearby city, with some killing and stealing mixed in for good mesure.

Summary of “My Father is a Role Player… Sorta” by Kerry Jane

Kerry Jane used to play Ackadia, and games with stories.

This article is a touching look the author’s father, and the alternate persona of “Goody Roberts” he would take on when playing racing simulators.

Summary of “Declaring the Rights of Players” by Raph Koster

Raph Koster was an Ultima Online lead designer.

Players claim to have rights. Admins mention they have every right to be angry. But, no one wants to give players a list of actual rights.

Some say people/players have intrinsic rights, but what are those rights?

“Now, it is pretty clear that there are some rights which leak over from the real world into the virtual. If your local pay-for-play mud operator is not providing adequate service, you can report them to the Better Business Bureau; there are probably sexual discrimination laws and harassment laws and slander laws that apply equally well in both kinds of space. But rights (and much less legislation) have not caught up to the notion of virtual spaces very well. Which makes for an interesting thought experiment.

What if we declared the rights of avatars?”

The author combines the “Declaration of the Rights of Man and of the Citizen”, the “Bill of Rights”, and the “United Nations Charter of Rights and Freedoms”, changing the language to fit MUD avatars.

Some objections include:

• The server is private property, so these rights should not override the property rights of the server owner.
• Virtual space is just an extension of real life, so those rights are already covered by real world laws.
• Avatars are not real. They are just representations, like chess pieces.
• “What about Orcs storming in and oppressing the players? Or NPC thieves?”
• This all leaves the admin open to lawsuits.
• I’m the admin. I don’t want to lose control.
• My MUD is NOT a virtual world. It is a game.

 

Rephrasing the rights in modern English gives admins a more positive view of the list of rights.

“Note that I am not suggesting that all the muds or commercial endeavors should run out and implement this list of “rights,” nor am I suggesting that if they do not that they are run by power-hungry maniacs. This is too complex an issue to reduce to that level.”

The idea of an Avatar Bill of Rights goes beyond just a game. As our whole life and world move to the virtual one of the Internet, there will come a point where all our banking, reputation, and information falls under an Avatar that we wish had the same rights our real life persona does.

Summary of “Returning to the Game” by Selina Kelley

Selina Kelley was an Imaginary Realities editor, and a player of ProphecyMUD.

The author is used to being the one that codes on MUDs, rather than playing. It has been hard to enjoy a MUD once you know all the internals of how it worlds.

Recently, the author started from scratch on a old MUD that they hadn’t played in some time. The author brought a friend, and they started out from the beginning, leveling up new characters. It has been refreshing, and the author strongly recommends that the admins and coders play occasionally (and bring a friend for support) to renew their understanding of how a player experiences the MUD they are in.

Summary of “Working in a Group” by Patrick Dughi

 

In a joint project, everyone’s responsibilities MUST be defined. The more granular the definitions, the better.

The author previously called coding, “mindless.” However, programming is only mindless in the sense that the programmer shouldn’t have to figure out what to program, only how to implement it.

Every game/MUD has its own needs as far as roles. The following are common roles, but need more definition based off your MUD’s needs.

 

• MUD Owner – You made it. You own it.
• Administrator – “Administrator’s often use the phrase ‘I saw this great feature on this other mud I play, and I think we should put it in here.’”
• World Builder – If making tacky rainbow color descriptions, like ‘An amazing sword’, excites you, then you might be a builder.
• Player Helper – You don’t get paid, but they feel too sorry for you to ask you to leave.
• Enforcer – “Generally, you feel good when others cry.”
• Coder – You make things go, and know way too much about the inner workings of the MUD.
• Idea Mill/Development Team – You’ve got some new ideas for the MUD. Can they be built tomorrow? Before breakfast?

 

Seriously, … Define the roles your MUD needs, and make the distinction clear. This clear separation of responsibilities will prevent conflicts among the team members.

An experience the author had involved two Admins in charge of puppeting NPC’s to make roleplay more interesting. One admin started the process of talking through NPCs to make a party’s experience more enjoyable. The other had more experience, so took over without regard to the other having started the roleplaying work. Hard feelings resulted. One admin was fired, the other quit, and many players (friends of the two admins) were angry.

This all resulted from no rule clearly telling the more experienced roleplaying admin not to forcibly take over a roleplaying task from another junior admin that was already handling it. Clearly defined roles (and rules for those roles) are essential.

Summary of “A Contiguous World” by Natalia

Many games and MUDs present worlds that are not contiguous (AKA dense maps). You find a hot jungle literally one step away from a frozen tundra in a way that makes no sense.

When it comes to MUDs, non-contiguous worlds happen because the worlds often come pre-built that way with the code base’s starter world. Then, all the effort goes into adding new features to the MUD, instead of focusing on world development. “When time is spent on the world you get one of two main actions: (1) revisions of existing areas to change names and modify the equipment or (2) addition of new areas that are just thrown into the morass anywhere that is convenient (“just link that new zone off the north end of zone xyz… it doesn’t matter if it makes sense, but we need another low-level zone close to the home town”).”

A renewed emphasis on Game Masters (GMs) could fix this issue. GMs design worlds on paper before presenting them to players. Even a pre-existing dense map can be fixed to make more sense with proper design and planning.

Suggested world building steps:

1. Decide on the kind of world, including races, continents, oceans/lakes/deserts. What is the geography separating major cities? Consider the existence or non-existence of icecaps. Is there one big city that is the entire world? Or, is the world made up of islands, and no continents? Get inspiration from your favorite author.
2. Create a paper map of the world. Commonly, MUDs have 5k-10k “rooms”. However, remember to start small to avoid burnout before finishing a first version of your world.
3. When creating a MUD, start from scratch. Strip out any prefabricated rooms, and use your own world’s design to make all zones and rooms.
4. “Start building the world based on your map. It will obviously change as you put it together, but the more detailed your map has the faster this will go. If you already have a game online, create this new world and areas in a separate part of the game.” If it is an existing world, start by adding a new starting town, and add new areas and rooms around the town, slowly moving the stock areas to more, and more remote areas, until you can remove the stock areas without much notice.

 

Summary of “A Proposal of Marriage” by Kerry Jane

Kerry Jane frequented Ackadia MUD and other games involving stories

After getting a couple of in-game marriage proposals (one a joke, and one serious), the author contemplates the ramifications of in-game marriage. Does the commitment stretch into the real world, when you really aren’t roleplaying the character? Does the concept of marriage in-game interfere with the in-game character’s life and fantasy adventurer career?

Summary of “Creating a viable virtual ecosystem” by Patrick Dughi

Patrick was an experienced programmer, MUDder, RPGer, etc. He also owned his own claymore.

Virtual ecosystems are an attempt to copy the intricate network of life’s and nature’s checks and balances into a virtual world. This is in contrast to your typical game where the monsters in a room refresh simply by leaving and re-entering the room. A virtual ecosystem needs to be simplified more than the real world because the complexity of the real world is impossible to reproduce virtually.

First create a massive world with lots of empty spaces. A million rooms is a good start. These are the areas that wheat grows and mobs reproduce. Most MUDs shy away from large empty spaces, but they are necessary for virtual ecosystems.

Next, add terrain. Use our own planet as a good reference to what terrains exist with their locations and proportions. Follow that by weather that is based off the terrain. Then, add renewable and non-renewable resources to your world.

Cap the maximum amount of resources in an area. Have both renewable and non-renewable resources regenerate. However, renewable resources should regenerate at a slower rate than they can be harvested, and non-renewable resources should regenerate at a much slower rate than renewable resources.

Make terrain, vegetation, mineral, resource, and weather maps. The vegetation map should be a union of some sort of the weather and terrain map.

“Vegetation is the first mutable factor in our theoretical ecosystem. We need vegetation to feed creatures who will, in return, feed other creatures and so on. Your players may be only indirectly involved in this, as they will normally prefer to purchase food in its prepared form (bread, instead of wheat, or pixy stix instead of sugar cane). However, that will not change it’s impact on the players – if there is no wheat, the players will not get any bread. The crawlies – humans, bears, wolves, all the creatures in your world affect, and are affected by vegetation – they are your second mutable factor.

“Remember above where I claimed you needed a huge area? Well, this is because of the size of land needed to support one person. At best case, a sq. mile of farmland can sustain 30 people.” The author assembled several charts with land usage necessary for sustaining humans and different types of animals.

After carefully constructing a well balanced ecosystem, your players are likely to come along and kill everything that moves. The trick is only to allow the players to see or find a small percentage of the animals that are present. Make random encounter charts based off the animal populations in the area, and that is all the players can find to kill. The rest are hidden from view.

If animals in an area start dying off due to disease, weather, or starvation, modify the random encounter chart to have them encounter animals that are already dead. This could be expanded to include trees, crops, and herb–both living and dead.

Allow for players to plant crops, after razing a forest (room) and driving out the animals from that area. This could be part of city building or trade and commerce systems.

Summary of “How to Write Effective Mud Help” by Sheila Summers

Advise on writing help systems is nearly non-existent. The author’s article focuses on technical writing techniques that apply to writing MUD help systems.

Make help files concise and consistent. Use visual signals. Put one person in charge of help files.

The following is an example of a help file by the author.

---

Syntax
  help <topic> : displays help on the topic

Description
  Our help system contains over 1000 entries, so if you have
a question about a topic, try the help files.  If more than one
entry matches the topic you enter, a list will be displayed.

Note: Every time you use the help
system, we log the topics
you try to access.  We use this information to help improve
our help system.

Examples
  help help : displays a list commands useful for obtaining help
  help a    : displays all help topics that begin with the letter a

Related help topics: Index

---

The heading and colors in the above sample are examples of visual signals. This helps players scan through the help article and save time finding information. Whatever the format is, all of your help should follow the same format with same colors and sections. Use indentations to further help people with trouble seeing colors. Use the same template for all help files.

Avoid common mistakes. Don’t overuse color. Never use more than three colors, and use them sparingly. Don’t put headings in caps.

“Most People Were Taught in Grade School to Capitalize Nearly Every Word of a Title. Journalists call that “up style”, and most don’t use it in headlines or headers anymore because it is difficult to read. Use “down style” in your online help: only capitalize the first word and proper nouns, and the titles of books or other complete works if they are cited.”

Keep explanations short, and paragraphs short. Document every command, even if it seems obvious to you.

Write every entry as if a newbie is reading it.

Above all else, … “Be consistent, concise, clear, complete and accurate.”

Summary of “Mei Manifesto” by Savant

In the past, celebrities came in the form of sport heroes, and anyone that had their face on a Wheaties box. These days, the heroes are the game creators and skilled game players. As the new hero, you have a responsibility to guide the next generation on to a productive future. Don’t ignore them, even when they’re annoying. They need their new heroes to help them make the best of themselves and pursue their dreams.

Summary of “The Mud World” by Jonathan Untied

Jonathan Untied was the main coder for Shattered Worlds MUD.

MUDs are essentially RPGs or adventure games. The game never really ends, so keeps players longer than classic RPG games. Players would stay even longer, “if the game kept changing.”

“If room descriptions were created based certain elements such as flora and structures, they could be easily altered due to player interaction or the passage of time. For example, a tree in a room would be different in the winter as opposed to the summer. Rivers could dry up, streams could become lakes and flood other rooms. This also adds an element of realism to the game.”

Let players make changes to the world, like building shops or cutting down trees.

Add a game engine that writes or rewrites areas and rooms on its own. Have it create items, quests and MOBs. Room descriptions couldn’t be ignored, because they would change at random times, and the change would be meaningful.

The game would never end, keeping players indefinitely. Even adding more powerful monsters and items would happen automatically to match the players’ needs.

Summary of “The Word Game – Reactions” by Selina Kelley

Selina Kelley was an Imaginary Realities editor, and a player of Prophecy MUD.

The author started playing MUDs online before anyone even had computers. The one friend that had a computer only used it for Word.

Times have changed. Now everyone is Internet savvy. However, they all want to play 3D graphic games, and mock playing text-based MUDs.

Then and now, most people don’t understand the great allure of playing an anonymous game with or without friends, just to relax with no real danger and just fun. It would be nice if more real life friends would join in the fun, though.

Summary of “Another Day, Another Lawsuit” by Kerry Jane

“Kerry Jane has nothing what so ever to do with Online Game Development.”

Volunteers should not deal with customer issues. Customer service is a job handled by employees at every retail store, except those on the Internet. “Companies should facilitate and encourage (but not administrate!) peer support, and let paid employees of the company deal with customer service.” The so called Volunteer Model of Customer Service denies customers of real, trained customer support when they need it.

This kind of volunteer customer service has already got AOL and UO into lawsuits. The lawsuits will likely result in better, paid customer service at a lot of online companies.

Summary of “The First Prince” by Scatter ///\oo/\\\

Scatter was the author of Dawn Whispers MUD, that this story was based off of.

The main character, Falen, is a lord trying to get the local city council to prepare for an impending attack by the Magar. The council refuses to acknowledge any threat. Falen commits treason by devolving the council, and preparing for the coming battle. Falen barely succeeds at saving the town, after which the towns people make him first prince of the what later becomes the Western Realm.

Summary of “Naming NPC’s” by Lord Ashon

Lord Ashon worked on WheelMUD as a main developer.

Some MUD creators, believe that NPCs are of little interest to game play. The author believes that the best MUDs require immersive game play and well thought out NPCs. Having good names is an important part of well thought out NPCs.

The following steps are used by the author when constructing names.

Step 1: Give each race its own name template. “Dwarves for example have something like [First Name], [Descriptive Action] + [Relevant Item]. So we can get a dwarf named Karish from the clan BattleHand. An elf on the other hand would have a template [Human Name] + [Silly sounding string of vowels], [Silly sounding vowels] + [odd sounding vowels] + [awkward pronunciation] to produce a name like: Helenilal Siloajaihove.”

Step 2: Come up with quick reference of a list of stock names for each part of the name template. This allows for new names to be generated on the fly, when a new NPC is encountered.

The author also references “Language in MUDs” by David Bennett. The author suggests that David Bennett’s method translates into code for a MUD nicely.

Summary of “Player-Driven Class Alliance System” by Jenna

Jenna was creator of Shattered World MUD.

A Player-Driver Class Alliance System (PDCAS) was made as an improvement on multi-classing. Classes are actually guilds that give special skills and powers. It results increased time online, while players negotiate guild alliances. The alliances are easier to make, when the guild is smaller (under powered), so the relative class power self balances. The Class Leader (essentially, a guild president) role, provides a goal for new players to strive toward. There is also no reason to start over, if the players can change guilds to try new classes.

The PDCAS gets dissolved and reformed every three months. Alliances cost money based off the size of the class guild forming the alliance. Larger guilds get charged much more than smaller guilds to form alliances. This prevents large guilds from gaining too much power.

Also, a compatibility survey is sent to each player in a class’s guild. If the players from two guilds are shown to be incompatible, the guilds can still form an alliance, but the cost is greater.

Ultimately, the forming of alliances is done by the Class Leaders. However, if they run out of money, all alliances are dissolved for their guild.

A talented Class Leader could build up the coffers of the guild so much that they can form alliances despite cost. An untalented Class Leader could bankrupt a class guild and prevent any success with alliances. Zero-sum economic models in your MUD, help keep the balance, though.

This alliance system is then used to allow players to multi-class based on the alliances with their own base class’s guild.

Class Leaders get a wage from their guild’s coffers.

This is the system used in the author’s MUD, Shattered World.

Summary of “QuitMud, It’s Time” by Selina Kelley

Selina Kelley was an admin for ProphecyMUD and editor for Imaginary Realities.

The author contemplates the pull of real world friends, family, work, and life over online life in the MUD. The author notices that taking breaks happens more and more, especially at Christmas time. And, the thought of leaving the MUD scene permanently becomes more of a temptation each year.

“When it’s all said and done though, it comes down to one simple fact. I don’t have the courage to leave. It’s been such a large part of my life in the past that there’s no way I can abandon it. The true QuitMud never lasts. If I ever, honestly, let go, there will be no article for me to write about it, and no real goodbyes to say.”

Summary of “Alchemy Alternatives” by Ilya

Usually, some class is given a spell that allows them to make potions. This is a missed opportunity for creating a whole alchemy system.

“To succeed as a new game system, alchemy must be interesting, dangerous, rewarding, and unique. Especially unique. It must have results or powers or advantages available in no other way.”

Keep it interesting by letting alchemists experiment with components to see what they can craft. For example, maybe the base recipe requires expensive/rare/hard-to-get ingredients. Let them search for cheaper and easier substitutes.

Keep it dangerous, because experimenting could result in explosions or poisons. Even when the crafting itself didn’t kill you, testing the new thing might.

Keep it rewarding by allowing the skilled and patient alchemist to undercut expensive NPC shops and practically put them out of business.

“These are the five pillars of alchemy: process, component, reagent, effect, and analysis.”

• Process – the crafting step, such as exposing to the new moon’s light, or placing next to a certain type of plant
• Components – anything ranging from a gnat wing to a chunk of lead.
• Reagents – the component that starts the process of change, like a match starts a fire. Reagents should be far more rare than the components being crafted.
• Analyses – check purity, or come up with new component/reagent suggestions. This might be done through touch, taste, special equipment or some other means. After analyses, the alchemist knows what to try next.
• Effects – The learned, or desired outcome. Not just death or poison.

 

“Effects is where this could really shine. Take some time to think of effects that aren’t just one more way of hashing up an enemy — there are plenty of combat effects that boil down to magic missile (only bigger and harder). We don’t really need more of those! Subtler effects could be more useful and interesting, and might make roleplaying more interesting too (creating impatience perhaps? or sneezing? or itching?).” The effects could be an ongoing function that happens randomly, like an involuntary sneeze or other involuntary actions until the effect is removed or wears off.

Summary of “The Exercise of Power” by Damian Campbell

Damian Campbell played a wizard named Sekiri on Discworld MUD.

The story was a day in the life of a wizard, including visiting several locations by magic means, helping out a dwarf, a younger wizard or two, and getting an item fixed. All this was told in a style familiar to those who have read to source material.

Summary of “Mud Administration, Can You Handle It?” by “The Crimefighter” Steven Lucas

Steven Lucas was an admin for Promised Land MUD, maintained The COMPLETE Abermud List, and the Betterbox.net Mudlist.

Running a MUD is expensive. Hosting easily costs $50 per month.

Coding and debugging skills are a must.

Admins have to enforce rules on players that don’t like you or following rules. Some players literally are only there to make your life miserable. That is the fun for them. They cheat. They shout NSFW content. They won’t go away, and keep creating new accounts, so zapping them isn’t enough.

Admins become a shoulder to cry on for some players with serious real world issues. “I’ve taken this role a number of times, it’s not fun, it’s usually heartbreaking, and it’s emotionally draining. Many times you don’t know the answer and struggle to come up with some idea of what to do based on past experiences or knowledge.”

Summary of “Mutinies and You” by Vashkar@Split Infinity

Vashkar was from Split Infinity MUD.

All MUDs face the threat of hackers. Those that survive with good security still have to deal with political issues and discontent within player base of the MUD itself. Political issues can evolve into real world issues, like a site lockout requiring a costly legal battle to get the site re-opened. And then there are social engineering approaches to take over control of a site and its MUD.

“Next, the staff-stealing attack. Let’s say you’re a coder who has given plenty to a mud, and doesn’t want to stay at a mud because of something the mud owner is doing that you really have a problem with. You can perhaps start your own mud. It’s not that hard. Flip through a book on C or C++ and it’s a breeze. Then you can find like-minded coders on the old mud to leave there and join you on your new mud, promising not to make the same mistakes. In fact, you can even tell them to bring whatever code they want from the old mud. It’s a relatively quick way to overthrow a mud owner.”

Then there is the boycott attack. Players and coders boycott until some demand is met. All it takes is on charismatic player or coder to start this boycott.

Finally, there is the petition attack, that overloads the owner with whiny ASCII spam from many sources.

There are different styles of MUD leadership ranging from dictatorship, to monarchy with advisors, to pure democracy by the players. If done right, the last one is going to generate the most loyal players.

Last resort with player discontent, or admin discontent, is you’re the admin and quit if it’s no longer fun. If you have open dialog with the disgruntled coders and players explaining what your goal was, and what went wrong, you might get feedback that you like and can compromise with.

Summary of “Theft of Ideas” by Selina Kelley

Selina Kelley was an admin for Prophecy MUD and an editor for Imaginary Realities.

The author contemplates whether “stealing” ideas from other games is immoral. Stealing code definitely is immoral, but ideas seen in other games is more akin to using general life experiences to flush out your game.

“I consider myself a moral, ethical person. I don’t really consider that using an idea taken from another game is wrong, as long as I don’t pretend to have thought of the idea myself. I always give credit where it’s due, and would never attempt to pass myself off as an ideas genius.”

Summary of “Case for Multiple Experience Games” by John Buehler

Most games provide one “experience”. That might be combat, or city construction, or something else. But, only one experience is available.

When a player gets bored of the one experience (maybe because they finished that experience’s available story line, they look for another experience in the same game, but usually don’t find a second well-developed experience, and have to move on to another game to get a new, fresh experience.

In fact, most game designers intentionally create a new game around one experience, because they won’t make more sales from having more work from creating a multi-experience game “Instead of developing multiple games with a single experience each, companies should also be pursuing games that provide multiple experiences. When organizing multiple experiences into a single game environment, there is the issue of how to present the overall package. One such presentation is that of a virtual environment, where different experiences can be presented largely as they are in the real world. For example, if presenting the experience of auto racing, the player visits the racetrack. If presenting the experience of amusement park design and construction, the player visits a certain tract of land. This suggests that there exists a virtual world where the player can interact with and affect a number of objects in the world, permitting the player to experience various activities.”

In a multi-experience game, players don’t have to learn new controllers. Additionally, the following occur.

• Experiential depth – experiencing the same game from different angles requires less work to obtain suspension of disbelief. Players are more easily drawn in.
• Built-in demonstrations – The world itself is the demo.
• Development tools – Making tools for designing your game become cost effective, because the will be reused creating new experiences within the game.
• Retention of player investment – Character development transfers between experiences, so the player doesn’t need to start completely over with a new experience.
• Community development – community springs up, and players leaving the game lose their community

 

There are some challenges to multi-experience games for the game designers.

• Keeping up with technology (computers/APIs/etc) is a real challenge.
• Understanding the multi-experience game concept continues to evolve, making original design obsolete.
• Merging in new experiences to an existing platform is tricky, and if done wrong, can destroy the revenue stream.
• Some players prefer the single player experience.

 

Transitions between game experiences must new interfere with suspension of disbelief. Having all experiences be from the perspective of one player works. Also, being in control of a city that has several venues you can enjoy is another approach.

Separate the experiences by distance. This is similar to real life, and readily accepted by players.

The game experiences can be separated by discreet steps, or a spectrum. For example, city guards protect a city, but not outside the walls, so that is a quick step outside the city gate to get a combat experience. However, if the guards became less and less frequent the further you moved from a city, then the combat options would slowly become more common (on a spectrum) rather than instantly outside the city gate.

In multi-player games, all players are interested in only their own entertainment. Admins, however, can only be interested in the entertainment of their players.

In PvP style games, some players may not want to have the challenge of combat with another players. The experiences of the players are in conflict. “A very straightforward approach to ensuring that conflicting experiences do not get mixed is to ensure that the experiences cannot be mixed, period. Geographically separate them, or separate them based on time of day or age of the player or a token held by the character. For example, only if the leader of the race is carrying the “Intrigue” card can he be interacted with by the “Deus Ex” character. Or only night races are subject to infiltration by a “Deus Ex” character, and so on.”

This naturally brings us to a discussion of Justice Systems. Justice Systems discourage players from imposing their experience on reluctant players who are pursuing a different game experience. Penalties could be in-game or a real world penalty, such as degraded game performance. Real-world penalties should be reserved for griefers.

“Justice systems are useful for maintaining separation of game experiences by declaring that if an interaction between two players’ experiences are unsatisfying to one or the other, that there is a defined way to pursue a reasonable penalty for the transgressor. A ‘reasonable’ penalty is one that ensures that actions that are inconsistent with a victim’s experience are made to be unreasonably difficult for potential transgressors.”

The purpose of the justice system in a multi-experience game is to keep players’ experiences distinct unless there is desired mingling of experiences. For example, in a game that allows PvP combat, the players could be required to agree to PvP before any other player can attack or steal from them. Essentially, they would turn on PvP for their character.

Summarizer’s Note: At the time of this summary, Hypixel would be a great example of a multi-experience game.

Summary of “Developing a Storyline” by Wes Platt

Wex Platt (AKA Brody) is the creator of OtherSpace MUSH.

Story line (or story arc) is the key to player retention. The story can’t end. It must be ongoing to keep players coming back.

“Many of you are probably familiar with the concept of a TinyPlot, or TP. These are often short-term events and often self-contained. A story arc is nothing more, in the simplest context, than a series of related TinyPlots woven together to form a cohesive story line”.

Story arc is not a script, but an outline. First, you need to know in a general sense how the story arc ends, but not necessarily how the players will get there. Plan a series of events as the players progress toward the ending. Each event should open possibilities for the players to explore, but not dictate what they will do, or how they will act.

You create major events that are important to the characters pursuing the story arc goal. However, add in some less serious event that are related but just for fun.

Plan out a final event as a grand finale. This event should wrap up the story arc and lead into the next one.

Summary of “I Want to Bake Bread.” by Sie Ming

Originally published as an editorial for Stratics.

There is a whole untapped niche market for crafters. These gamers want to create, not kill. Almost no games tap this market.

Here is a list of requirements for crafters to find your game interesting.

• Crafted items should be items other professions want to purchase due to utility or beauty.
• Similar ranks, status, and wealth as other professions should be achievable, though maybe slower because of less risk.
• Crafters should have some utility when partied with other classes.
• All items should degrade with use and time, for a healthy economy.
• It should easy for players to buy items from crafters
• It doesn’t have to be complex to make the items like bread. (Selling is part of the fun.) It should also not be tedious.
• Researching crafting recipes can be a fun sub-game, but should be optional. Make recipes tradable or sellable to those who hate research.
• The economy must have good enough balance that new bakers can sell to customers because your shelves occasionally run out of items.
• Make cost of rare or hard-to-make items expensive enough that many players can’t afford them.
• Allow crafters to specialize, so they aren’t all making the same things.
• NPC crafters should not compete directly with player crafters. Quality or better price should be the hallmark of the player crafter.
• Trading and haggling with real players is a must. Don’t sent NPCs to buy the crafters’ goods.
• Provide ways to increase crafters levels other than flooding the market with unwanted goods.
• Don’t make crafters able to produce more low level items as they advance, or they will price out new crafters by directly competing with them.
• “The amount of time it takes us to bake a few cakes should not depend on how quickly we can click our mouse button. It should not depend on how fast our connection to your game is It should not depend on how advanced our macro program is. Characters with the same traits, abilities, equipment and raw materials should take the same amount of time to whip up some cakes. Let the mechanics of your game determine how quickly we produce items. Please do not make us into ‘twitch bakers’”
• Don’t forget to keep expanding the game for crafters, too. They don’t have to be large changes, just don’t forget us.
• Market the game to us, so we know there is a crafting class we’ll enjoy.

 

Summarizers Note: This article came out before Minecraft made crafting and sandbox games cool.

Summary of “Losing Players to Responsibility” by Chad Elwartowski

Chad Elwartowski was the admin for The Four Lands MUD.

Giving more responsibility to a player often results in them playing less, or even avoiding your MUD.

“Whether it is a sense of…I beat this game. Or maybe, you are more restricted because you are sorta looked upon to be an example for others and you can not just swing this way or that when it comes to your moods since your position is pretty much set in stone.”

You hire a player to be an Immortal and they go from three hours a day of play to too busy to play within a couple of weeks. People who are leaders in real life, do well, but other players come into the position of responsibility with no real understanding of how much work it is, so stop playing, because the responsibility isn’t as fun as it seemed to the uninitiated.

If you find players that are already doing leader type things in the game even before they are given an official leadership position, then the new role will be less overwhelming, and even fun for them.

Summary of “The Aedon Attribute and Rule System” by Federico Di Gregorio

The author gives a brief overview of creating a MUD in Python. The overview is less than you’d understand after reading one beginner’s Python book or Python class.

Summarizer’s Note: If interested in getting familiar with writing a MUD in Python, checkout Evennia MUD/MU*.

Summary of “Zen and the Art of Spiral-Carved, Green Marble Incense Burners” by Sanvean

Sanvean was an admin on Armageddon MUD.

Moving away from an economy based off killing required the introduction of crafting our MUD. Foraging, butchering, and skinning systems were introduced first. Foraging introduced resources such as salt, wood, roots and other biome-based crafting items.

As a joke, basket weaving was the first craft introduced, but it turned out to be a good way to test the whole crafting system.

Crafting was added to the Magic Users skill set for magic based crafts. Some crafting skills, like cooking, everyone got.

Planning out the whole system in advance would have made it easier to implement.

Some great ideas came from players.

Fitting crafting into an economic system needs to be watched and tweaked carefully and often, so prices are reasonable, and items don’t become too plentiful.

Dyes add another dimension to crafting. Items can be custom ordered with a guild’s colors, for instance.

Summary of “Advancing Advancement” by Tony Wooster

Tony Wooster was found frequently on The Two Towers MUD and Final Realms MUD.

Most MUDs have an advancement system consisting of killing MOBs to get training and experience points. No matter how much time the MUD creators spend improving areas and other elements of game design, they never improve on the same old advancement system.

An alternative could be player ratings of other players, either up or down, within limits. A system like this works best if players can only rate other players of a lower level, with admins rating the top tier of players.

Summary of “Cartoon – The Mud Slinger” by Rebecca Handcock

This cartoon seems to be lost from the Internet. So sad.

Summary of “Mud Schools” by Michael “Talien” Tresca

Michael Tresca was an admin for RetroMUD, and a reviewer for All Game Guide and RPG Net.

MUDs promise fun. MUDs that start with a newbie school are not fun. Expect users to log off very quickly if you don’t instantly provide epic battles and heroic feats. “Want to create an introductory system to your mud that allows players to learn your game AND have fun? It’s going to take more work. Or, you could just be lazy and continue to lose new players and stick with your boring old mud school.”

First step to introducing your new players to your MUD without boring them is to have a good help system. This includes logging help queries that players are looking for, so you can add them if they aren’t there. Also, organize your help files into logical categories and sections. Even ask players to write help files for you.

In RetroMUD, they have chatty NPCs that follow new players around telling them about areas they should be interested in and answering questions by quoting the help files. This puts the newbies IN THE GAME with other players instead of sending them to MUD school.

“Code into the game parameters to deal with new players. Introduce concepts slowly, but they should be playing in the same universe as everyone else. Otherwise they’re playing the “Newbie School” as a game within the game, and it’s probably not a particularly good representation of the game either.”

Make sure you have a channel for new players to ask questions. Assign other players as helpers. Prevent other players from treating new players poorly.

New players on your MUD are not infants in real life. The real world person wants entertainment, and that doesn’t include MUD school, or slaughtering butterflies and bunnies to level up to something useful.

Summary of “Mutinies and You” by Scott Danzig

Scott Danzig was Vashkar at Split Infinity MUD.

This is a slightly edited version of the Jan 2001 article of the same name.

Summary of “Permanent Death Sliderule” by Eric Rhea

Permanent Player Death (PPD) removes a player’s avatar permanently from a game.

By introducing a slide rule of death, each type of death results in a percentage of death, rather than PPD instantly. The types of death are: environmental (ie falling off a cliff), large monsters (ie a dragon), or PvP.

These three types of death would result in decrease in percentage of avatar capacities, scenario flags, and death categories.

Each type of death should result in a flag, a capacity decrease, and a category. If not reset by some in-game method, like visiting a healer, then they add up quickly to a PPD. That would be the end of playing as that avatar.

Summary of “Seek and Discover” by Lord Ashon

Lord Ashon was busy re-inventing the wheel as Wheel MUD.

Some players like exploring. That is their thrill in playing the game.

“Explorers delight in having the game expose its internal machinations to them. They try progressively esoteric actions in wild, out-of-the-way places, looking for interesting features (ie. bugs) and figuring out how things work.” -Dr. Bartle

Most games do not reward explorers. Give us travel points or some reward for exploring, and give us some sort of in game advantage for not revealing what we found, if you don’t want us sharing it openly.

Travel points could be an invisible object that hands out point for exploring that room, then reloads itself into an new random room somewhere else in the world. Don’t require travel points by all players. Just make it a different way to get experience for those that don’t enjoy fighting.

Summary of “So, You Want to Be an Admin?” by Jesse Seymour

Jesse Seymour (Grakor) was a MUDless admin, willing to help our on any MUD that needed help.

New MUDs show up at the rate of about 10 per week, and are gone before a week has passed. The reason is a lack of technical knowledge. Also, the admin burns out quickly. It takes a team of at least 10 people to run a MUD, including:

• dsigners – design of areas, objects and quests
• builders – code areas, objects and quests
• MUD engineers – to create new feature of the MUD system (like commands or combat systems)

 

Volunteer teams are almost impossible to put together, because skilled volunteers are more rare than the number of MUDs looking to get volunteers. To attract volunteers, the admin must code enough to create a unique MUD that attracts players and coders.

First the new admin needs a server. Secondly, a easily modified mudlib, such as TMI is needed. And thirdly, unique areas, commands and skills are needed. The admin needs to know C at the very least. (Summarizer’s note: These days MUDs can be found in many languages besides C.) Most importantly, plan/design what you want to do before doing it.

“Once you are able to do all the things I discussed here, then you shouldn’t need very many people to help make your mud a success. You should know enough to stand on your own two feet, and shouldn’t have to clutter the newsgroups with posts begging for help with all the simple things. Then, you will no longer be regarded as a mere ‘newbie’, but as someone who is willing to put forth the extra effort and create something unique, something that can grow to take a life of its own, so to speak.”

Summary of “Value on a MUD” by MSKing the hellcat

Something in the game must have value that gives players a goal to pursue.

 

• Usefulness – levels, houses, clans, etc
• Bragging Rights – Rarity or difficult of obtaining can be as important as high stats
• Sentimentality – quest prizes, gifts and rewards/awards. Have events/parties where players can show off these prizes, gifts and rewards. Make the quests memorable, and not just trivia or kill-collect, to increase sentimental value.
• Location – give something value by its proximity to resources, portals, areas, or quests.

 

Once you figure out what is valuable in the MUD, spread the word.

“You may be able to neglect your mortals, but immortals need to know a little about value, especially if they aren’t long-time players of your MUD. They need to know everything from how high in value an objects stats may be to where they go. They need this information to run quests, build zones, and encourage good behavior.”

There should be immortals handbooks and players guides that explain what is valuable in your world. An immortal that doesn’t know what is valuable and why it is valuable can damage value/balance in your game.

Don’t use signs to tell players what is valuable. Instead, use help files, message boards, prices and word of mouth. In the help files don’t say, “Such and such is valuable.” Instead, explain the value, and let the players figure it out. In the case of message boards, tell the players what prizes events earned players. The prizes will be inferred to be valuable.

Setting high prices can infer value of things. Also, immortals/admins treating something as valuable will make players treat it as valuable.

“Knowing the values of your MUD will help to keep it in balance. Btw, I meant it when I said don’t tell your mortals straight out what’s valuable. When you do that, it brings it to their attention and they start to question it. Submit it to their subconscious and they’ll be far more likely to accept it.”