The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

The Debate Rages on

by Troy Fisher

The debate rages on, does a mud administrator have to be a coder? Or is being a builder acceptable? I shall put forth this argument. The main mud administrator needs to be neither, it must be a game designer. Yes, he does not need to be an ego maniac coder, or a worthless builder, he must be someone who can weave a good game. This is why most muds fail. Either a) the do not have a coder and the mud becomes stagnant, b) they have a coder who keeps adding new features, or c) they have a combination of both, where neither get along.

Andromeda galaxy

A nice photo of a spiral galaxy.

So, what does a good game designer do? In plain words, she works magic. To be more specific, she answers these questions; what is the player going to do? What does the player get for doing this? What is the long-term goal? Can the player trust the game? Is it possible to play through the whole game without losing once (theoretically)? Is it possible to learn and get better? Is there a real difference between what is right and wrong to do? Is it too hard or too easy? Are there any easy solutions? Are you sure that the most fun thing to do is what you are supposed to do?

Huh!?! Simply put, she plans out the game. Let us examine each question individually. What is the player going to do? Basically, this question is asking, is the mud a role play mud, where the character interacts with other players, or is it a player killing mud, or a hack'n'slash. Define the theme, and define the motivation.

The second question to ask, what does the player get out of this? Or, what does the player get when they do what they are supposed to do? Do they gain levels, do they earn money, and influence, and power? This question goes hand in hand with our previous question. Think of this as the rewards part for completing the first question. An acute example of this is in a driving game, the more races you win, the better your car becomes.

The Third question, "What is the long term goal?" is quite obvious, but definitely requires a lot of thought. In most muds, the player becomes a wizard. It does not have to be this. If your mud is clan based, it might be he is given the right to found his own clan. Or if it is a player killer mud, the player may after accomplishing the goal, get a chance to live without threat of death. This is perhaps one of the hardest questions to answer.

Can the player trust the game? This is the most important question that the Game Developer can ask. For example, if a player tries to jump off of a cliff, and he falls to his death below, he is going to expect the same thing to happen, not a message that reads, "Sorry, you are not allowed to do that!" If a player is able to feed someone's parrot, he is also going to want to be able to feed a non-intelligent animal mob. We also call this consistency. If your mud is consistent, it is more believable and therefore more playable.

Life is a terminal disease, your game is not. So when developing your mud, the answer to the question, 'Is it possible to play through the whole game without losing once (theoretically)?' should be, yes. It should be possible that your players can go through the game without dying. Or at most, the player should not need to die to learn the answer to a puzzle. Unless the puzzle takes place in the afterlife, but then that is your problem, and not mine.