I am not completely sure on the dates of publication. I found reference to newer issues, but those seemed to be dead links, too. I’ll try to gather as much information as I can about the original content of the magazine, but don’t expect to get everything due to the legal issues surrounding abandoned intellectual property in these digital dark ages.

The most interesting part about reading this older e-zine is that it discusses social changes coming about by this new Internet that had never been experienced before. I don’t really include those sections much in the summaries, but sometimes it is the full context of the article, such as “Net Relationships”.

Summary of “Game Design – help files” by David Bennet

1998 September, David runs Discworld as Pinkfish

Help files are a must. “It is no good having some super zoopy feature if it is not documented and no one even knows about it.” Standardizing the help files layout with one shared template, improves the player experience. Avoid large bodies of text by breaking up the space with headings and spaces. Add cross references to other related help files. Provide a mechanic for users to report typos, clarity issues, or wrong information in help files as bugs.

Summary of “Net Relationships” by Derek Harding

1998 September, Derek is an admin for Discworld

People meet and start relationships online. “As we spend time with people and interact with them, even through a computer mediated interface we form associations. From passing acquaintances through to deep and lasting friendships. It is this breadth, depth and variety of friendships which encourages me to believe that mud relationships are real.”

Summary of “Strange Bedfellows Society” by Juiliann

1998 September

“Politics amongst the admin can absolutely ruin a MU*.” Specifically, romantic relations that go sour among admins and staff can ruin the experience for everyone on the MU*.

Summary of “The Writer’s Block” by Daniel McIver

1998 September, Gototh on Discworld

Make room descriptions interesting. Don’t repeat room descriptions even when the area is large and repetitive. Slight changes in the same repetitive room description uninteresting.

When creating large areas with one theme, split the area into multiple projects with multiple builders to encourage variety of approaches when creating the area. Look at reference books on the type of area to get ideas for “beautifully phrased descriptions of locations and scenery.” Fiction that give good descriptions can also inspire the room descriptions in the MU*.

Room descriptions should work whether players are in the room, or viewing it remotely via a familiar, spell, or crystal ball. “You are in a …” and “You are standing on …”, obviously don’t work if the player is viewing the room remotely. Write all room descriptions without referencing the character. No uses of “you” should get included.

Room descriptions should not include player actions, because the player may not be performing the action when they use the “look” command.

Room descriptions should not include player thoughts. “Describe the location, and let the player draw his or her own conclusion as to what they think of the place.”

Keep room and area descriptions down to 50-80 words. If a longer description is needed, split it up over several rooms in a way that makes sense. Make sure descriptions don’t scroll off the page.

Summary of “Welcome to a DIKU Mud” by Jonathan PR Monteleone

1998 September, Head administrator of Forbidden Lands (fl.wolfpaw.net 2000) since its inception in 1991

DIKU MUD’s first release happened in mid-March 1990. DIKU’s creation attempted to correct issues with the older AmberMUD. DIKU in turn spawned “Circle, Merc, Copper, Sequent, Silly, and Epic” MUDs. DIKU also spawned “Sojourn, Medieva, Mozart, Mystic, Forbidden Lands, and Perilous Realms”

Summary of “What server is that?” by David Bennett

1998 September, David runs Discworld as Pinkfish since 1991

MUDs tend to have hack and slash play with combat leveling. MOOs, Mushes and TinyMUDs put an emphasis on roleplaying and allow for “building ability” and clothing customization by players.

Summary of “Being an administrator” by Jack Thornton

1998 October, Authored a long-since-gone web site about admin’ing for MUDs

Running a MUD is more complicated than being a player. Be realistic about the time and money commitment you will need. You’ll need all the skills of a coder and builder to start, or wait until you do. Don’t expect to make any money, though it is possible.

Summary of “Beyond PKilling” by Sayeed

1998 October, “Sayeed from somewhere I am not certain of”

Online Role-Playing Game (ORPG) player kills PKs are detested, while monsters killing players makes games more fun. Player killers aren’t confined to limited rooms like NPCs, they gloat in a out of context manner, and often target weaker players. Players killers are more ruthless than NPCs and loot more extensively than NPCs. Player killers ruin the entertainment value of the ORPG for newer players.

“The four major differences between Monsters and Player Killers which reflect badly on Player Killers are the following: Interactive Intelligence, Strategic Intelligence, Location Limitation, and Looting Habits.” Any counter measures against unfun PKs built into the ORPG need counter or limit these differences.

Examples of counter measures: PK options enabled by players such as through a dangerous and hard quest. Require a certain level before PVP is enabled. Have heavily guarded routes for the protection of potential victims.

Summary of “Mud client tango” by Andy Lewis

1998 October, Former Discworld admin and current Nanvaent player. Authored Rapscallion MUD client

MUD client features should make new actions possible to the player, such as triggers, tickers or highlighting specific text to make it more visible.

When considering adding a feature to a MUD client ask the following questions.

• How useful is the feature?
• How many people would want to make use of it?
• How difficult will it be to implement?

After selecting features for development, ask the following questions.

• How would someone go about making use of the feature?
• How far can the concept extend?
• How will it integrate with the rest of the program?

Spend time getting the UI/UX planned out. “The interface will make or break a client.”

Summary of “Natural Command Handling” by Scatter ///\oo/\\

1998 October, Authored a guide to using the MudOS parser

Older MUD systems used add_action() on objects, rooms, etc. to make commands available to players. “When several objects contain the same command, the order in which the driver will try them is unspecified.” Several other problems exist.

MudOS adds natural language parsing to help resolve issues with add_action(). “Setting up a command system using the natural language parsing package does involve quite a bit of work and can be frustrating at times. Once done, though, it pays off big in several ways”

Summary of “Starting a mud” by David Bennett

1998 October, “(Pinkfish) is the founder and one of the admins on Discworld which was started in late 1991.”

“A common problem with muds is that someone starts one without a clear idea of what they are trying to achieve.” Decide exactly what type of MUD you are making before starting.

Second, choose a MUD driver or customize one to fit your needs.

“Starting a mud is a very lonely business, you can probably guarantee that you will spend months without anyone else online or anyone helping you much at all.” As an Example, Discworld was a solo project with no user and only one programmer for nine months before other coders and users gradually joined.

Make your MUD’s theme overly obvious. Put special emphasis on the descriptions and help files.

Keep tasks down to a manageable size to prevent getting overwhelmed. When working as a team, keep task assignments clear. Be careful not to over extend yourself.

Summary of “You call that a review!” by Ilya

1998 October, Ran a MUD listing and review site

MUD reviews differ from advertisements. Presenting a laundry list of features and lots of exclamation marks does not make a worthy review. Worthy reviews include the following.

• mention limited gameplay details (classes, races, etc)
• explain what you like about the game, and why
• explain what you DON”T like about the game, and why
• give anecdotes from your own experiences playing the game

“Bias is universal and unavoidable.” Make it obvious. “Readers can and will make up their own minds.”

Summary of “Beyond Player Killing” by Sayeed

November, Continued from last month…

There are lots of strategies for lowering the PK count on a server that allows PvP.

Common PK implementation “limit the area(s) where Player Killing is possible by coding in the game engine to either neutralize damage done, limit who can attack or be attacked, or simply disallow PvP combat in Player vs. Player Combat (“-PvP”) forbidden Locations.”

PK-Switches allow the rooms or areas in the MUD to have a boolean PvP that determines if PvP is allowed in the room or area. Removing all PvP preventes the role-playing of super villians, and can hurt game play. Also, having PvP areas next to non-PvP areas may result in abuse of the non-PvP areas.

Allowing players to turn on PvP, requiring a quest to turn on PvP, or requiring players to role-play a monster class/race to PvP are common PvP measures.

Town guards could swarm players of ill repute.

Loot based measures, include limiting looting of Player Kills is another common measure, either by allowing the ghost to keep some gear/treasure, or preventing looting all items on the corpse. Other measures include, limiting monster looting of player corpses, limit looting of defenders but not attackers or evil characters, prevent looting of lower level than winner.

Here are other techniques for limiting Player Kills.

• Mark loot as “stolen” and only allow certain in-game buyers to “fence” stolen items and only in limited quantities.
• Limit the number of times a player can be PK’ed per day.
• Allow high level players to take on the role of a monster or a PvP’er.
• “Text Filtering- Allow characters to tag themselves Role Player, Non-Role Player, or Both and only allow their character to see text from other players similarly flagged.”
• Have roving guards patrol roads and paths, attacking evil players.
• Have high level “good” players gain the ability to track “evil” players.

Summary of “Guide to Roleplaying” by Jarok

1998 November, Jarok was from Aarinfel MUD

Learn roleplaying by doing it.

To roleplay, you must first create a rough character, and then build the character’s depth over time though interaction with events and other players. Being in character is “a form of improvisational theater.”

Make roleplaying sessions cooperative. “Each player should try to balance their desire to push forward their own agenda with the right of the other players to express themselves and promote their own ideas.”

Proactively create situations for your character and other characters to shift the MUD’s world in directions that help every player move forward the plot of the MUD. Make up tiny bits of plot instead of just reacting to everyone else. “One of the telltale signs of a good role-player is how well they weave their plots and ideas into those of the rest of the mud.”

Summary of “Rule making of roleplaying” by Michael A. Hartman

1998 November, Jarok was the main administrator and author of Threshold RPG.

Bad rules ruin great games.

In RPGs, names “are one of the first things someone sees when they interact with other players.” If you want a consistent RPG feel for your game, you need to police names players choose in a consistent and firm fashion.

In Character (IC) communications in the game add to the immersive RPG experience. Keep IC and Out of Character (OOC) communications separate. “When people are inside your world, they should be acting like their character.” Keep a dedicated OOC channel for non-IC communications. Make the OOC channel muted by default for a more IC RPG experience especially for new players.

Keep numerical information away from players. Knowing the exact combat formulas is distracting the the realness of the role playing. Discussions of such information should be limited to the OOC channel.

“Any system of rules, whether they are written for a roleplaying game or anything else, should be consistent both in design and application.” Also, explain to players what rules they broke when correcting undesired behavior in the game.

Keep interpretation of your rules flexible so as to avoid “rules lawyers” from bending strict interpretations to their advantage and annoying you and average players.

Summary of “The search for identity” by Scatter ///\oo/\\

1998 November, “Scatter is the net-identity of a real person who hides somewhere in the UK. Being an enhanced personality, Scatter is much more helpful and friendly than the real thing and so is the best one to contact.”

Many MUD’s encourage roleplaying in-character (IC) and discourage out-of-character (OOC) behavior on the MUD server. Whether the player roleplays a character that is an enhanced version themselves, or plays an reverse image of their real-life self, the character they play tells a lot about them.

“One of the keys to a successful role-play game is for all the players to stay in-character and respond to other players’ characters rather than to the other players themselves. This is the downfall of many face-to-face role-play games as a group of friends respond to the friends they know so well much better than to the dwarf veteran on the character sheet. A mud on the other hand can make it possible to know absolutely nothing about the players behind the other characters, and likewise have them know nothing about the real you.” Anonymity makes it easier to roleplay, because players have less fear of being associated with behaviors in-game that they would never do in real life.

Moral implications arise when roleplaying is used to hide one’s identity for malicious purposes. The question arises, “is using an alias [online] really pretending to be someone else or just an admission that you are someone else online?” Maybe you are both the online and real life versions of yourself.

Another potential pitfall of roleplaying, is relationships. If a player is roleplaying a different gender, but extends any relationships past the bounds of the game’s roleplaying, strong negative emotions by other players could be encountered. “Role-play relationships are only okay as long as all parties involved really are role-playing.”

Summary of “The Writer’s Block” by Daniel McIver

“Daniel McIver is Gototh, Lord of the Ram domain on Discworld”

“An obvious easy way out for the area builder when they run out of inspiration is to go to great lengths in explaining how boring and non-descript the player’s surroundings are.” Avoid describing rooms as boring. Instead, describe the boring things in the rooms. Descriptions of peeling paint and tree bark provide atmosphere to a room, and occasional humor. Use lots of adjectives, and consult a thesaurus when describing common features.

Avoid too much ASCII art. If you want lots of art, use a MUD interface that supports real pictures. “Text-based games aren’t good at showing graphics, and the appeal should really come from nicely written and presented text.” Limit ASCII art to signs and occasional maps.

Summary of “Waltzing on with the mud client” by Andy Lewis

Andy Lewis was a player on Nanvaent, admin of Discworld and creator of Rapscallion MUD client.

Andy named his MUD client “Rapscallion” because of the medieval feel of the word, and with hopes that it would take on the connotation of MUD client with familiarity — which it seems to have done. He avoided looking at existing MUD clients to encourage his own ideas and original approach to dominate Rapscallion’s design.

“In reality, a mud client is nothing but a user interface, designed to suit any number of back-ends (muds) and with very few standards that can be depended upon. So it is essential that a client be as easy and efficient to use as possible.” Using the Keep It Simple Stupid (KISS) approach leads to better software design. The mapping system in Rapscallion typifies this approach and benefitted from a simpler approach than other mapping systems.

Andy released the first version of Rapscallion MUD client in May 1997. Feedback was complimentary, and included bug reports/feature requests. He released 18 updates between May and November. Using feedback and feature requests, Andy realized he needed to redesign the next version of Rapscallion from the ground up using the experience he now had.

“Fred Brooks sums it up nicely in The Mythical Man-Month … One of the decisions to be made when developing a new piece of software is whether or not to first build a throw-away version as a trial run. Brooks points out that this question is wrong – you’ll always build a throwaway. The question is whether or not the throwaway is the one you’ll give to your customers.”

Are LPMuds dead? by Geoff Wong

LPMud driver development has slowed or stopped. Is Java a better solution for MUD engine development than LPC?

An LPC to Java compiler could be built with an LPmud emulation library. Java has concurrency. LPC does not. Java has better type checking than LPC. LPmud handles hot fixing existing code better than Java. LPmud has a MUD specific library. Java’s libraries are made for general programming. Java has a better selection of development tools and IDEs than LPC. LPmuds are more stable than JVMs. LPmud does not have the large community support that the JVM has, so maintaining LPmud is difficult.

“In conclusion I don’t think LPC is dead yet, but without significant injections of highly quality energy it is certainly on the decline.”

Summary of “Assumptive and Suggestive Roleplaying” by Cayti Feric

Cayti owned Evolution and was a player on Aarinfel.

“Strengths and weaknesses provide that 3rd dimension to roleplaying, actions being the first and reactions being the 2nd.” Listing the character’s strengths and weaknesses helps avoid the character suddenly being able to do anything they see other characters doing. Weaknesses provide a way to create tension that needs resolving. Having weaknesses that conflict with goals of the character creates tension. Weaknesses make characters more believable and interesting to be around.

When describing what your character does, don’t assume the response/reaction of the other player characters. Let each player character respond to what is happening to them, rather than assume their responses. “Being suggestive is saying what your character does, being assumptive is saying what your character does, and how it affects others.”

Create hanging plots to add suspense/mystery to the ongoing campaign. Show a character doing something out of normal with no immediate explanation, or provide other clues, hints or yet-to-be-explained events that lead to a future resolution several days or weeks later.

Summary of “Comparative Skills” by St.Toad

Mobiles and players should have no differences other than the players have some control over the actions of their characters.

Traditional skill systems that use percent chance of success work well until used against opponent’s skills. Then percent chance based skills fail to handle advanced skills pitted against over players skills. Also, advanced skills versus low skills don’t take into account that low skills should rarely succeed against advanced skills, not just succeed a percentage of the time.

“Comparative systems work, as their name suggests, by comparing the skills of the attempter’s and the resister’s to work out which of them is successful. This has the benefit of making the result dependent upon the relative skills of the combatants, not upon their absolute skills.” This leads to:

• Fast fight resolutions
• Handles skill disparities better
• High damage from attacks is not needed to make more skilled attackers more likely to win

Comparative skill systems allow for unlimited leveling of skills, rather than capping skills at 100%. Leveling of skills can be throttled by giving a certain number of practice sessions per level with a limited number of skill point to be distributed between their skills. This prevents characters from over-leveling all of their skills instead of concentrating on specialties. Also, make learning already leveled skill cost more training sessions or points to making gaining higher skill levels more challenging.

Ultimate goal of Comparative Skill Systems is to place the emphasis on skill leveling instead of character leveling. This should result in better roleplaying instead of killing everything in sight to level the character.

As an example, Cthulhumud used the following system for combat and magic:

  Attack roll:   level + weapon_skill  + open_d100
  Defense roll:  level + defense_skill + open_d100

If greater than 95 was rolled on the d100, then another roll of the d100 was added. If less than 5 was rolled, then another another d100 was rolled and the second d100 result was subtracted from the total result. “Those familiar with Role-playing games may recognize certain similarities between this system and Iron Crown Enterprise’s MERP and RoleMaster systems.”

Summary of “Even movies have directors” by Richard Bartle

Richard ran MUDII and was co-editor of the Journal of Mud Research.

“Without a director, a movie would be a sloppy mixture of competing artistic views.” Likewise, a book with several authors needs an editor to make the presentation consistent. MUDs rarely have the equivalent of an editor or director. They are thrown together with competing themes and atmospheres.

Putting one person in charge of artistic vision in a MUD will result in a better, more cohesive, and immersive experience for players. However, strong editorial control is not likely to happen in a free MUD. “You can’t tell someone who’s designing for your mud out of the goodness of their heart that what they have produced is shoddy, or out of context, or incomplete, or unoriginal, or jarring. If you do, they will go away in a huff – they don’t HAVE to help you at all.”

Summary of “Dangerous Realism” by Scatter ///\oo/\\\

Scatter hides in the UK, and is much better than the real person behind the persona.

“Realism” destroys game enjoyment. Realism can mean like the real world, or believable and consistent. Pursuing the first in an attempt to achieve the second type of realism creates a mud world that “ends up a jarring combination of real world detail and fantasy or sci-fi setting.”

Real world details don’t necessarily add value to a mud. Making the game more like real life takes away the fun experience for many players. “Another danger of making things realistic is that they become too complicated to be fun.” The trick is finding the amount of realism that will be enjoyable to the most potential players.

Players understand that not every detail of the world is modeled by the game. Focus on the second type of realism–believability–and players will forgive missing details of reality. “For example, magic as represented in most muds is impossible in the real world, yet how many players complain that having magic is unrealistic? None, … The key is that magic can be believable in a mud world, despite being totally implausible in real life.”

Realistic details tend to decrease the things players can do in the game. Whereas, adding believable features to the game tends to expand the number of things players can do in the game. As a result, more players are attracted to play the game because of believability than because of real world restrictions.

Summary of “Multilayed Mapping” by Telford Tendys

Traditional mud maps consist of rooms and exits with no regard to sizes or distances involved. Other games often use square or hex grids, but run into scaling issues. For example, a small town in the middle of a vast forest cannot be to scale on the grid with the forest.

The author gets around this scaling issue by using multiple “grids that are based on the powers of two. Each grid is named by a logarithmic scale number such that scale 0 has squares with length of 1 unit, scale 1 has sides with length of 2 units, scale -1 has sides with length 1/2 of a unit.”

The author provides diagrams and examples of how this scaling of overlapping grids work. Using this method, grids will overlap. In the case of overlaps, the grids with higher resolution are considered authoritative over the lower resolution grids.

Summary of “NPC Intelligence” by David Bennett

Known as Pinkfish on various MUDs. Also, ran Discworld starting in 1991.

NPCs aren’t intelligent, and are hard to create intelligence for. Start with a common library that handles common tasks like greeting behaviors. Custom, individualized code will still be needed for specific NPC behaviors, though.

NPCs don’t need much intelligence to give players a good interactive experience. Giving them goals, or priorities will help. These should overlay strategies, “like ‘Run away’ or ‘Heal myself’”. “When an NPC receives an event of some form it would ask all the goals if they want to deal with it, each goal would then determine which (if any) strategy is most appropriate.”

Putting together a few high level goals and low level strategies can add a lot of depth to you NPCs.

Summary of “The love song of an anonymous mudder” by Twiggy@Discworld

Playful interpretation of TS Eliot’s “The Love Song of Alfred J. Prufock” Containing memorable lines such as, “In the chat-room, mudders come and go Talking of lag and data flow.”

Summary of “Advancement the Old Way” by Jeffrey Boser

Most advancement systems mirror 1970’s Dungeons and Dragons with increasing difficulty to gain levels and decreasing returns of skills and rewards, and some sort of max experience caps. Part of this set of restrictions was because it was easier to do with paper and pencil. However, with computers, these restrictions can be discarded.

Having the computer do the calculations allows for new ways to calculate success and removing caps to skill advancement.

Summary of “Completely Classless” by The Wildman

“Korthe, Head Coder and Co-Admin on Grok: The Earth You Never Knew” that was planned for beta in March of 1999.

The author started role-playing with Dungeons and Dragons and the four basic classes: Fighters, Magic-users, Thieves, and Clerics. This evolved into dual and multi classing for the sake of variety. The problem with the classed systems was that all characters of the same class and level were almost exactly the same, … and that was boring.

Later the author found classless systems, “like Torg, Heroes, GURPS (Generic Universal Role Playing System), and others…. With the ones that worked, every character was different. Even if you followed some sort of character template, it was rare that two different people chose the same set of skills.” This variety led to a richer gaming experience.

Later the author tried various MUDs and found even boring class system with a hack-n-slash theme was fun if the atmosphere was friendly. Later the author joined a team creating a classless MUD. The classes were replaced with professions in the hope of encouraging specialties without pushing characters into being all exactly the same as in a classed system.

At the time of the writing (1999), the MUD was not yet in beta.

Summary of “How (not) to puzzle a player” by David Mallard

David administrates an LPMud that works to improve human-AI interactions.

Quests and puzzles in MUDs provide challenges combat cannot. Sometimes they are required for advancement. They can be as grand as the quest for the Holy Grail, or as simple as returning a lost library book.

Don’t let syntax be the puzzle. Meaning, make sure all synonyms for the required commands for the completion of the puzzle are included, so the user isn’t stuck on figuring out the correct command long after having mentally solved the quest or puzzle.

Avoid distance as an obstacle. This favors players with automappers and speedwalking, and makes the quest less fun for players that cannot use those or teleport. If distance must be part of the quest, make the reason obvious and consistent in the game world.

Combat as part of a quest may turn off players that prefer puzzle solving over combat.

“You might also consider broader questions about how many paths lead to the solution of your puzzle: Are there any actions, besides the ones that you have allowed for in your code, that the player could reasonably assume will work? If so, and if you don’t intend to allow these actions to work, what reason will you give the player? For example, if the puzzle requires the player to set fire to an object and your code supports using a torch to start the fire, will you also allow magic spells that produce fire to work?”

Make decisions a process of discovery when completing a quest rather than a random chance. For example choosing between two doors, one of which results in instant death, isn’t as well thought out as providing a means to discover which door leads to certain death.

Use hidden objects and red herrings to spice up puzzles and quests. Remember to leave hints for the player to discover when trying to find the correct solutions for quests and puzzles.

Lastly, remember to make puzzles and quests fit logically into the game world. Make sure syntax and other non-game related factors don’t impede the solutions. And, consider game balance of the obstacles if they present burdensome challenges to some players but not others.

Summary of “Organized Roleplaying Events” by Alan Schwartz

Alan AKA Javelin is the maintainer of PennMUSH and God of M*U*S*H (telnet pennmush.org 4201).

When planning live-action roleplaying game (LARP) events, find a game first. The author recommends Interactive Literature Foundation (no longer exists). They had a great game bank of potential games to run

Next decide the when, where and who including the length of time, the number of GMs needed and how many players there will be. Email players their character data the day before, so they can digest it.

Build out the play area with an existing MUD or a custom one made just for the event. If the size of the event justifies multiple GMs, provide a private way for them to communicate with each other.

Make sure to caste important characters, but expect some to not show up. You might need to re-caste some important characters on the spot.

“At game time, the GMs should gather the characters together, outline any rules that haven’t been provided ahead of time, and explain how players can get GM help. Then the GMs can sit back and watch the fun begin! If everyone’s been well-prepared, these events often run themselves, taking on lives of their own.”

After the LARP is finished, spend 1/2 an hour having each character/player introduce themselves and reveal anything missed during the game. If you have logs for everyone to enjoy, let them know how to get ahold of them after the game.

Summary of “Remembrance” by Ted Kern

“Ted Kern is Broadman and Delta from Discworld mud, and also from Legend mud.”

A letter to “Karyn”, a player on LegendMUD that died in a car accident in real life.

“Sometimes we get so blinded by the fact that we are playing a game, trying to discover its mechanics, solve the riddles, achieve powerful levels, that we forget about the real people that we pass by on the imaginary streets every day. Sometimes it is only through tragedy that we can appreciate what it is that we have, and what we have lost.”

Real people live beyond the MUDs that we play. We don’t realize how we affect them and they affect us.

[SUMMARIZER’S NOTE: This is one of those instances that I wish our overly restrictive copyright laws allowed abandoned literature to be preserved. The letter and the article are very touching, but will disappear when the last “pirated” copy is found and destroyed. We truely live in the digital dark ages.]

Summary of “Advancement Revisited” by Scatter ///\oo/\\\

Scatter hides in the UK, and is much better than the real person behind the persona.

Most MUDs make abilities harder to improve as at higher skill levels. This prevents characters from becoming all powerful. All powerful characters destroy game balance. If abilities are meant to allow god-like characters, the game must provide something interesting for these characters to use their powers on. Otherwise, the achievements for players end in boredom. “Boredom is hardly a good reward for ‘winning’ the game.”

Applying the law of diminishing returns to ability advancement allows the MUD creators to set a limit to skills and power in a way that players are familiar with from real life. This allows the MUD to be designed in a way that it challenges even the best of players. Otherwise there is a constant race between creators and players to make sure the players have something challenging to do. “If a mud reaches the point where a player’s abilities are massively superior to everything else in the game, the developers have lost the race”

In the previous month’s article on this topic, the suggestion was made to separate skill and ability, so skill levels produce less and less ability advancements over time. This hides the real issue and only succeeds in making the skill level less meaningful to the players.

Instead of comparing skills to determine success, use random numbers between zero and the character’s skill level to determine success. This allows for failure at even high levels rather than always succeeding. This would work well in combat too, where the random number of the attack is compared against the random number of the defense, so even large skill differences would allow for some challenge and potential for failure/success when unexpected. This approach keeps the challenge in the game for higher skill levels.

“With this comparison mechanism it is assured that things never come to an ‘always succeeds’ situation – even if the attacker’s skill is a thousand and the defender’s is a mere two, there is still a chance that the attacker’s random score will be zero or one, allowing the defender success with a score of two. An obvious way to extend this system is to add things like ‘critical fumbles’ when the attacker scores zero, and ‘critical hits’ when the attacker scores the maximum possible.”

In general, skills rules should be easy to understand. Players should find it easy to understand what level their skill are at and what improvements to the skills have taken place. Techniques for improving skills should be believable, such as learning through practice or study.

Summary of “Setting the mind to work” by David Mallard

David works with LPMud to advance human / AI interactions..

The designers of puzzles need to use ingenuity and patient effort, to make puzzles that require ingenuity and patient effort to solve. “Riddles copied verbatim from The Hobbit will be unrewarding for hordes of your players.”

Pick an object to base your puzzle around, whether that is a door, monster, weapon, room, statue, or something else. Unimportant objects are best, because less players will have cared to solve it, resulting in less spoilers. The answer to the puzzle should be obvious in hindsight, but not when yet unsolved.

Make a list of uses and behaviors of the objects. Anything you and your friends can think of, no matter how unusual. Cross off the obvious uses. Then, start combining uses for one or more objects into a unique puzzle.

Another type of puzzle involves abstract ideas instead of objects. Riddles fall into this category. Make the puzzle fit into the world, so it does not seem arbitrary and out of place. Doorkeepers are cliched, but fit into most worlds, for example. [Summarizer’s note: The “door” doesn’t have to be a physical door. It could be more abstract, conceptually.]

Test your puzzles before coding them. Use friends and fellow creators as test subjects. They may come up with valid solutions you never considered.

Once the puzzle is coded into the game, track what players are doing with the puzzle, and how many are solving it. You may end up adding solutions to the puzzle, or adding explanations of why solutions fail.

Summary of “So You Want to Start a mud” by Robert M. Zigweid

AKA Tigran on Lima Bean, Illusions, Gilded Promises and Red Dragon MUDs.

Step 1: Creating a new MUD requires a lot of time and dedication. Eighteen months to get to an alpha release is not unreasonable.

Step 2: Decide on your theme and stick to it. If your theme is a book, get the author’s permission in writing before beginning.

Step 3: Determine which code base you are going to use for your MUD. If you are not familiar with the code base, make sure you have access to someone with knowledge of the codebase, or you will have very slow progress developing the MUD.

Step 4: Get the MUD’s code base, build it and deploy it.

Step 5: Figure out your roles hierarchy. For example, admin council, mods, story tellers, area/item developers, quest developers, etc.

Step 6: Set up development and description standards for new objects and areas. “Write rules which all of your builders, administrators and players must adhere to.”

Step 7: Design the area that your MUD starts from. All other areas will be built around this starting place. Even if you eventually have multiple starting places, you have to start with one and build from there.

Step 8: Code your classes, skills, movement restrictions and other customizations you want in your MUD. Don’t settle for whatever someone else wrote for the base MUD code.

Summary of “Tasks: a new variety of quest” by Hugo Jonker

“Beldin at TiamaT, Lima Bean, Nanveant.”

Tasks are a quest type that allow characters to act like overpowered Boy Scouts. Tasks can be class based or available for all players. A benefit of tasks, is it can give specific classes, class related tasks that allow them to explore their class in ways generally not available elsewhere in the MUD. Thieves can break into all the houses in a village, or a bard can sing the news to all the villagers.

Rewards of completing tasks could go beyond experience points, task points, or ability enhancements. NPCs could start recognizing the character, or talking/singing about the deeds of the character whether they be good or bad. Tasks that reward in terms of recognition or change of NPC behavior provides an alternate reward than mere hack’n’slash style play.

The results of tasks should be localized, maybe just to the local village. NPCs of a given area may all inherit a rudimentary AI that the bankers, shopkeepers, blacksmiths, etc. all share.

“Without going into the ‘What is a task’ and ‘What is a quest’ discussions, tasks are small quests with a different rewarding system. The idea is that the local NPCs really start interacting in certain ways with the character.”

Summary of “Why Rent?” by Ilya

Ilya plays and things about games, too frequently. Also, helps his wife Natalia with the Game Commandos site.

Rent is a surprise to new players. Many MUDs require you rent a room at an inn or lose all your equipment, and rents become more expensive the more valuable your equipment is that you want to save. Rent can become quite a burden as your character advances in the game.

Here are some pros and cons for rent. Rent sucks up excess money that higher level players accumulate, balancing the MUD’s economy. Rent based off equipment value tends to limit hoarding of valuable equipment. Less hoards of equipment also results in less gifting of upper tier equipment to under powered characters, too.

Rent systems encourage some players to play more often to keep up with rent. Though, this often results in players leaving the game, too.

Rent systems are generally hated by players, with many refusing to play on MUD servers that have rent systems.

Rent systems generally exist to eliminate excessive hoards of money and equipment. There are other approaches to eliminating money and equipment.

• Limit number of powerful items
• Level-restrict powerful items. [Summarizer’s note: An item that harms unskilled players more than it helps them is better than an item that states, “You need to be such-and-such level to use this item”. Think Zorro and his Wuhan sword in One Piece, or even his “unlucky” sword test that could have chopped off his arm early on in the series.]
• Lose all items every time the character logs off. The first LP MUD used this system.
• Some of the benefits of a rent system would also be realized by an equipment repair system, as an alternative. Make items unrepairable because of expense, especially after multiple repairs
• Make multiple magic items cause annoying side effects. One item is fine, two cause slow healing, three cause inability to talk or walk, etc.
• “Imprinting or Tuning: Give items their own preferences. This would be something like the alignment based item flags seen in some games now, but much more. Alignment based item flags restrict the usage of the item to those who are in alignment. Items might attune to the first player who touched them. Items might scoff at being used by inferior players, or betray their unworthy owners.”
• Have items react to the level of the user, becoming more powerful if the user gains levels.
• Most powerful items could be one-time-use items that are created by players at an incredible cost.

Summary of “A Rape in Cyberspace” by Julian Dibbell

The full version of this article may be reproduced. The link to the full article is here.

“This article originally appeared in The Village Voice, December 21, 1993, pages 36 through 42.” Later, the article was included in Dibbell’s book, My Tiny Life.

From the Wikipedia page about this article, “A Rape in Cyberspace” describes a “cyberrape” in a multi-player computer game or MUD called LambdaMOO that took place on a Monday night in March 1993 and discusses the repercussions of this act on the virtual community and subsequent changes to the design of the MUD program.

A player named, Mr Bungle misused a command that attributes actions to other players that they did not issue. One of the the victims later that night posted, ” I’m not calling for policies, trials, or better jails. I’m not sure what I’m calling for. Virtual castration, if I could manage it. Mostly, [this type of thing] doesn’t happen here. Mostly, perhaps I thought it wouldn’t happen to me. Mostly, I trust people to conduct themselves with some veneer of civility.”

The author writes, “Months later, the woman in Seattle would confide to me that as she wrote those words posttraumatic tears were streaming down her face–a real-life fact that should suffice to prove that the words’ emotional content was no mere playacting.”

Calls for “toading” of Mr Bungle rose all over the MOO. Only “wizards” had permissions to alter the database and remove characters from the MOO. It was not easy to get any wizards to make the change, because they had turned governance of the community over to the players, who never got around to making an actual government. The final meeting about the fate of Mr Bungle faded with characters losing interest and leaving one-by-one.

It was also at this point, most likely, that JoeFeedback reached his decision. JoeFeedback was a wizard, a taciturn sort of fellow who’d sat brooding on the sidelines all evening. He hadn’t said a lot, but what he had said indicated that he took the crime committed against legba and Starsinger very seriously, and that he felt no particular compassion toward the character who had committed it. But on the other hand he had made it equally plain that he took the elimination of a fellow player just as seriously, and moreover that he had no desire to return to the days of wizardly fiat. It must have been difficult, therefore, to reconcile the conflicting impulses churning within him at that moment. In fact, it was probably impossible, for as much as he would have liked to make himself an instrument of LambdaMOO’s collective will, he surely realized that under the present order of things he must in the final analysis either act alone or not act at all.

So JoeFeedback acted alone.

He told the lingering few players in the room that he had to go, and then he went. It was a minute or two before ten. He did it quietly and he did it privately, but all anyone had to do to know he’d done it was to type the @who command, which was normally what you typed if you wanted to know a player’s present location and the time he last logged in. But if you had run a @who on Mr. Bungle not too long after JoeFeedback left evangeline’s room, the database would have told you something different.

“Mr. Bungle,” it would have said, “is not the name of any player.”

The end result was that a citizen voting system was put in place whereby wizards could be forced by general consent to use their powers as the community desired. Member players gained the @boot command to kick guest players that were abusing the game. Also, a player vs player arbitration system was put in place.

Mr Bungle did open a new account as Dr Jest. However, he toned down his bad behavior a little. His new character was ostrisized. Eventually, he either created a new cleaner character, or stopped logging in all together.

Summary of “Embarassing Mischannels” by John Hopson

Mistells, AKA mischannels, result in some out-of-context humor. The players on the author’s MUD started ranking mistells on a scale of 0-10. The list the author provides includes one ranked at 11.

Ranked 9: “No, this was before I ran up those gambling debts. I killed him because he was blackmailing Marion about her secret affair with Karjat”

Summary of “Gender and the Mud” by Marcie Kligman

Marcie is a player and creator for Discworld.

This article documents the results of an online survey of 11 women and nine men MUD players on Discworld about gender bias and experiences related to gender in the MUD.

Most players did not experience severe discrimination based on sex other than being hit on, or not being let into the witch’s guild due to being male.

All the men had tried women roles. Less than half the women had tried men’s roles.

“Men who had played female characters generally noticed that questions they posed to other players were answered quicker, that they received more assistance in the form of money and other help, and tended to be attacked less often.” Though, this was not universal.

Men playing women noticed being hit on and affectionate comments. At least, one stopped logging into the account because it was too much to handle.

Women playing males noticed language changes when other players talked to them. Less use of words like “babe”, and less notice of their aggressive behavior as a character by other players.

“The women who had cross-played also responded that it was what they had predicted. One woman claimed that it was ‘great fun’, and another ‘loved…being extravagantly chivalrous to female characters. In a way, I loved doing all the things girls wish guys would do.’”

Players of both genders reported being hit on. One male player said, “I did have one guy ask me to marry him, because he thought I was a female. When I told him I was male, he retracted his proposal. I was hurt and disappointed, …. I had already picked out a gown and everything.”

The author was surprised to see that women did not have the same grouping of experiences. Their experiences varied greatly. Same for men.

Summary of “Languages in Muds” by David Bennett

David is an admin for Discworld MUD, and edits the MUD magazine.

Adding ethnic languages to a MUD enhances player immersion in your world. However, isolating low level players from each other due to language barriers prevents them from enjoying the social aspect of your MUD. Have a way for them to learn or speak a common language for player-player interaction.

You can implement languages with an on/off knowledge, or a progressive skill based method. In a progressive skill based language system, larger percentages of the language become clear (instead of gibberish) as the skill of the player advances in that language.

With a progressive language system, you must decide if the language is learned from listening to it, from NPCs, other players or a combination. Also, does the partially understood language mask individual letters, random words, or entire sentences when a skill is not maxed out for that language? “It makes sense to make the transformations work on a word by word basis and only transform a certain amount of the words, such that the longer words are the harder to recognize.”

Dialects of languages, or older variations of languages could require a higher skill than modern standard dialects of a language to understand.

Use a random number generator with a fixed seed for each language and dialect, so that the randomization of understood and garbled words is reproduced with the same results every time the language is heard.

“Some very simple transformations of text can result in a distinctly different looking word. For example: if you map the 26 basic letters to 10 letters in a new language system, with a few special transformations for some two letter sequences, you can end up with a very foreign-looking language.” Transforming based on syllables instead of letters adds a nice effect. Garbling words instead of letters or syllables might work best.

Another transformation that works well is to have a list of commonly mistaken words in the foreign language. So, when the player almost knows the language, all words translate, except that some words are literally the wrong words. This could require a large substitution table for the language, so might take more processing power than simpler methods of garbling the language.

Above all, don’t let the language system get in the way of playability of the game.

Summary of “Limited Advancement” by Derek Harding

Derek Harding was an admin for Discworld MUD.

Unlimited character advancement in MUDs leads to boredom for the players. “There are no more challenges left to the game. There is nothing left to achieve. You can kill anything, steal anything from anyone, cast any spell or ritual at will. I know it sounds idyllic to a player struggling to improve but oddly enough that is the point! All a mud can really offer is the struggle to improve and the sense of achievement that comes with succeeding in that struggle.”

Three techniques for limiting player advancement:

1. Purge all players at regular intervals. Essentially, reset the MUD.
2. Create a hard limit were the character is retired or “reaches wizard status.”
3. Decrease the speed of advancement as levels of character increase.

Under all techniques for limiting advancement, characters will eventually reach the limit, or reach the point that advancement happens so slow that advancement is no longer a reason to play the MUD.

Summary of “The Mudder’s New Clothes” by Rebecca Handcock

Rebecca was a red haired, snowball throwing, Ph.D. student from Australia studying in Toronto at the time of publication of the original article.

In the real world, we wear clothing for protection, individual expression, and group identification. In a MUD, the most compelling reason for clothing is as an expression of individuality. Some MUDs allow the player to write a description of their own clothes, while others provide special shops that allow the upgrading of clothing as quest successes allows enough wealth to do so.

The author recommends the following titles to the reader:

• Barber, E.W. (1994). “Women’s Work : The first 20,000 years”. Norton : New York
• Barnard, M. (1996). “Fashion as communication”. Routledge : London
• Bouncher, F. (1967) . “20,000 years of fashion : The history of Costume and Personal Adornment”. Abrams New York
• Davis, Fred. (1992). “Fashion, culture, and identity.” University of Chicago Press : Chicago
• Joseph, N. (1986). “Uniforms and nonuniforms : communication through clothing”. Greenwood Press : New York
• McDowell, C. (1992). “Dressed to kill : sex, power & clothes” Hutchinson : London
• Ribeiro, A. (1986). “Dress and morality”. Holmes & Meier : New York
• Tarrant, N. (1994). “The development of costume”. Routledge : London