Category: Imaginary Realities

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

Summary of “eBay Launches Virtual Property” by Jon Katz

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

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

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

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

Summary of “How it Really Happened” by Richard Bartle

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

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

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

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

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

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

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

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

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

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

Summary of “Mob Programs” by Jeremy Music

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

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

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

 

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

 

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

Summary of “Rules of Immship” by Brant Harvey

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary of “What is Remort?” by Natalia

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

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

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

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

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

Summary of “Dynamic Room Descriptions” by Eli Stevens

Eli was a MUDder with over five years of experience.

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

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

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

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

</FLOOR DESCRIPTION>

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

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

Summary of “Game Critique” by Marian Griffith

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

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

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

 

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

 

Summary of “Games as art” by Raph Koster

Raph was the lead designer and programmer for Ultima Onlilne .

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

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

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

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

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

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

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

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

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

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

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

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

Summary of “Problems with mudlists” by Adam Wozniak

Adam ran Doran’s Mudlist which later became Mudlinks.

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

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

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

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

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

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

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

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

Summary of “Wear Grflx” by Nick Howe

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

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

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

Summary of “All Mudlists Are Not Created Equal” by Andrew Cowan

“Andrew Cowan runs The Mud Connector.”

The author used “The Mud List” and Doran’s List. He was dissatisfied with the MUD lists of the day, because they usually didn’t even have a description. It was difficult to determine what MUDs you would enjoy playing from the available information on the lists.

“The article in the June IR gave me the impression that the author feels more is better. I disagree with this generalization to some extent. TMC’s list is definitely smaller than the 3000+ muds listed in mudlinks://, however, every mud on our list has one thing in common, they all came to our site and made a submission to be included in the list.” Website self-promotion has become common, if not standard, on the web. It should be expected that MUD sites also self-promote if they want traffic.

June’s article about MUD lists is correct. 89%-93% of the author’s time is spent verifying and re-verifying the continued accuracy of the data about MUDs and whether they are still around. Sometimes poor information is the result of honest mistakes, and sometimes they are outright lies in an effort to drive traffic to the MUDs.

Summary of “Distance tells” by Amanda Carlston

Amanda was pursing an English Education degree. She had three years of MUDding experience.

The page (AKA tell) command sends private messages to other account holders. (Sumarizer’s note: This is long before cellphones and texting were common.) Page and tell keep non-roleplaying messages private so they don’t break immersion of the game. They also provide long-distance communication in the MUD at no cost, when getting a face-to-face conversation going in a shared room is impractical.

“The command has some problems. It can be hard to coordinate with more than one person at a time through the use of them. One person has to act as a relay, passing information through to others as they get it.” Confusion of conversations is common, leading to mistells.

“The tell command is very unrealistic, to be certain. It is akin to being able to talk mind to mind, which is not something that has been scientifically proven as being possible. However, it is a very helpful command, and will probably be with us for many more years until something better is brought about.”

Summary of “Level vs Non-Level” by Zane T. Insane

Zane had two years of MUDding experience, played on MUDweiser, and planned to start a MUD.

MUDs started out following the early D&D and RPG convention of using levels to track advancement, with skills adding even more opportunities for advancement. Levels have the disadvantage of (usually) maxing out at some point, taking the fun out of players that strive for the thrill of gaining their next level.

“Getting rid of levels is an easy step. The only problem is that gaining levels is one of the easiest ways of tracking advancement from a coding viewpoint. Once they are gone, how do you advance? A meta-type system is usually implemented to where you use XP gained from monsters to practice and train. So instead of killing monster after monster to gain a level to gain the practices and trains to advance, you simply kill monster after monster to gain XP to practice and train and advance.”

After maxing out levels, players must learn the thrill of interacting with other players, and PvP combat. Short of using some future, yet-to-be-developed AI, PvP is the greatest combat thrill in the game. You an never fully anticipate the behavior of an intelligent human player.

How much realism is too much. A fully realistic MUD wouldn’t be fun. “In real life if I slashed someone with a sword I would not do damage to their hit points, they would be seriously injured. It’s just that in a game, it would not be too fun if you were to be hit one time and die.” The fun MUD is a MUD where you can escape reality for a while.

Summary of “So, you want to code a mud?” by John Patrick

John was a software/hardware engineer based out of the Chicago area. He was Reorx on Ansalon, a DragonLance based MUD.

 

“The essence of computer programming: finding the correct way to describe to a computer what you want it to do.”

The author explains the complexities of computer programming, including machine language and compiled languages. Python isn’t included in the list of human friendly languages, but Cobol is, … as a joke.

The author recommends studying a good programming book, such as A Book on C by Al Kelley and Ira Pohl; reviewing lots of well written code; and practicing writing larger and larger programs before tackling writing code for a MUD. “I say that mud code has to be some of the worst C programming style and code I have ever seen.” [Summarizer’s Note: That’s the truth for MANY MUD code bases.]

Summary of “Who are you?” by Michael A. Hartman (Aristotle@Threshold)

Michael admin’ed and built Threshold RPG.

Requiring player’s to interact before they see names adds significance to social interaction. This is called an introduction and recognition system, or more simply and intro system.

1) What are the goals for your intro system?

Temper your intro system design based off goals you have for your MUD. A strict intro system makes sense in a PvP based MUD, but not as much sense when you want your MUD to encourage more player social interaction.

2) Is your system playable?

Make sure it isn’t onerous to get introduced. Also, make sure unintroduced players can be distinguished from each other.

The introduction “syntax could be something like ‘introduce to Foo’ or even ‘introduce Foo to Bar’.” Never make it mandatory that introductions be by a third party. Require introductions to be accepted rather than automatic. It might be a good idea to have a forget or unintroduce command for situations that arise where you don’t want to be remembered.

3) Keep the intro system code lean.

“The other thing to keep in mind is that most likely, whatever function you code to check if Person A knows Person B is going to get called a LOT. It will be called every time someone walks into a room with people in it, every time they use any “who”-like command, every time they type “look” or “glance” or any other visual command in a room, etc.”

4) Remember security and rules compliance.

If there is a need to report players for rules violation or harassment, the intro system needs to not get in the way.

Summary of “Wilderness Systems for Muds” by Alex Kallend

Alex was a software engineer with 20 years of D&D experience and 11 years of MUDding experience. He ran the Lensmoor MUD.

In the traditional levels-based map system, adding new low levels becomes a challenge because the higher levels need to be traveled thru to get to the new low levels. High level characters can get to them, but find them boring, and low level characters die trying to get to them. A wilderness system fixes these issues.

“The wilderness is generally a large grid of rooms, to which the other zones of the mud are linked.” The wilderness is meant to connect exploration zones, not to be an exploration zone. The wilderness should be big enough to make the world feel big. Also, the same commands that work in exploration zones should also work in the wilderness.

Wilderness areas should be dynamically generated. Static rooms the size of a wilderness will waste memory. Define the rooms of a wilderness using a byte per room with the first nibble indicating terrain type, and the second nibble containing flags. Using this technique, 1,000,000 rooms will only occupy one meg of memory.

The author uses the following example:

With 'F' meaning forest, 'D' meaning desert, 'H' meaning hill, 'M' as mountain, and lowercase letters meaning there is a road present, the following block shows how a section of wilderness can be defined in a file:

FFFHHMMmhdDDD
FFFFHmmHHDddd
FFFhhHMMHDDDD
FFfDHMMMHHDDD
FfFFHMMHHDDDD
fFFFHHHMMDDDD

Don’t keep the whole world’s map in one file. It will kill access times. Give the dynamically generated rooms last access timestamps so cleanup is performed in the order of least need. Grow the list of rooms, if in high use, and shrink the list of cached rooms if in low use.

When dynamically creating wilderness rooms:

1. Create the description of the room. If including random features in the room, seed the random features based on the room’s coordinates, so they are always generated when the character enters the room. This could be very important if the player is using those random features as landmarks to navigate by.
2. Create the exits
3. Add random MOBs to the wilderness rooms. MOBs should be rare and of low level. The wilderness is not meant for leveling the characters. It is meant for travelling between exploration zones. High level MOBs should not block passage of low level characters to low level exploration zones.
4. Add any persisted data about the room.

If too many MOBs are generated in the wilderness and are moving from room to room, you could cause resource issues with your MUD server. Preveninting MOBs from moving from room to room of their own accord mitigates this issue.

Pathfinding through the wilderness should be disallowed, as it generates a lot of rooms quickly.

Large wildernesses are awful for players to navigate. Adding a ‘navigate’ skill of some sort will help.

Make sure rooms load properly and aren’t cleared from cache if a player saves their game there, or logs in there.

“A zone may have multiple exits that lead into the wilderness, and yet only one entrance from any given direction. This can lead to some exits not returning to where they came from.” Limiting exits and entrances might help.

Using the wilderness as a quest site for finding a MOB that moves around can be a fun challenge.

Also, consider using the wilderness zones for resource gathering. They are a rich resource for player craft items.

This technique of wilderness zone generation provides a consistent scale for world maps. This makes it easier for players to map out the world and find their way around. Also, a truly massive world can be generated without overusing the MUD servers limited resources.