Imaginary Realities 2000 September Edition

Summary of September 2000 issue of Imaginary Realities. Imaginary Realities was an ezine dedicated to MUDs.

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

Raph was lead designer and programmer at Ultima Online.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary of "Destroying a Mud" by Frog Brothers

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

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

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

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

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

Summary of "Ramtop Rescue" by Thirsha

Thirsha is a Witches Guild member on Discworld MUD.

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

Summary of "Muds Are Not For Wimps" by Michael "Talien" Tresca

Michael was head designer and coder for RetroMUD.

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

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

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

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

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

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

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

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

Summary of "Programming for Administrators" by Patrick Dughi

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

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

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

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

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

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

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

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

Summary of "RL vs. muds" by The Beyonder

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

Summary of "The Community" by Lord Ashon

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

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

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