Imaginary Realities 1999 March Edition

Summary of March 1999 issue of Imaginary Realities. Imaginary Realities was an ezine dedicated to MUDs.

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.