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

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

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

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

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

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

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

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

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

Flux was a first time submitter looking for feedback.

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

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

Jessica Mulligan originally wrote the article for the Happy Puppy .

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

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

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

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

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

1993 – Everything changes.

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary of “Promoting Your Mud” by Johan J Ingles

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

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

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

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

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

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

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

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

Summary of “The Debate Rages on” by Troy Fisher

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Instead, do the following.

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary of “Planting the Idea” by Lord Ashon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary of “A Working Mud Economy” by Geoff Wong

Geoff Wong is Dredd on Shattered World MUD.

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

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

The Loans Standard is based off the formula:

Bank Loans = Bank Deposits + Currency

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

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

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

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

To reform your MUD’s monetary system:

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

 

Summary of “Need No Justice!” by Erik Jarvi

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

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

Immutable laws were created by the MUD admins.

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

Common laws affect everyone.

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

Here is the MUD hierarchy:

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

 

Citizenship is received by application and a waiting period.

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

Lords are guild members that have completed the requisite quests.

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

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

Summary of “Online Relationships” by Selina Kelley

Selina Kelley was a staff writer for Imaginary Realities

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reasons for running a MUD server.

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

 

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

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