> mudreading.com

Articles and News for the MUD Community

Shneiderman’s Golden Rules 3-5

Oct 14, 06:52 PM by Raesanos regarding Game Design

This is the continuation of a MUD UI discussion started here.

Offer informative feedback.

For this one, the advice is generally the same for MUDs as with any computer application. If a command is issued, the user needs to know that something has happened or is happening.

The main feedback-related problem that I see is cases where the feedback a command gives is insufficient, usually followed by the player issuing another command to learn more. In RPI MUDs this is often because exposing mechanics-related information (such as your HP) is seen as making the game less immersive. “You gulp down the steaming soup” is certainly less immersive than “You restore 15 hunger points.”

Prompts are a good way to deal with this issue. For things that don’t appear in the prompt, consider a way to get both a colorful message and an unobtrusive mechanics detail together. “You gulp down the steaming soup. You now have 37 hunger.” would work. Or to make the mechanics detail even less obtrusive, one might consider a convention of appending just the new value of the relevant number, e.g. “You gulp down the steaming soup. [37]”. If that convention was consistently used I could see it as being very useful, though it would be more confusing to newcomers.

Different approaches will work for different games. In general, designing messages with careful attention to what information the player is going to want to know will make for a better UI.

Design dialogues to yield closure.

MUDs don’t have dialogue boxes, but this can be applied to any message a MUD outputs. The type of thing that would violate this rule would be the message “You throw a ninja star at the rabid tapir.” The user immediately asks “And… what? Did I hit it?”

What helps me is to look at every task as something with a beginning, middle, and end. In the case of the ninja star and the tapir, first I throw the star, then it flies through the air, then it either hits or does not hit the tapir. Looking at it this way its easier to see what the message is missing. Though this example may seem obvious, things like this seem to get overlooked as people simply get used to the meaning of messages they see a lot.

Offer simple error handling.

Generally error-handling in a MUD means a message akin to “You can’t do that.” This is certainly simple, but what would be even simpler is if there was no error to begin with.

What did the user type? Lets say they typed “read cat.” This makes no sense at first, but maybe this is a hairless cat with a tattoo that says “Lucifer.” In that (admittedly weird) case what the user typed actually does mean something valid. Its just that the game wasn’t smart enough to figure that out. What if the game instead showed the same output as if the player had used “look” on the cat? If the cat’s description includes what the tattoo says, then the user has just found what they were looking for. It may be very difficult to find cases where its reasonable to do this, but when its reasonable it can save players a few trips to the in-game help.

There are 3 rules to go, coming in the last installment of this series, which can be found here.

Comment

Commenting is closed for this article.

Players and the Roleplaying Continuum Thank You!