A big problem with programmers and developers these days is that they make their game interfaces esoteric. Since you're probably not as geeky and needlessly wordy as I am, here's the definition of esoteric:

es·o·ter·ic

-adjective

1. understood by or meant for only the select few who have special knowledge or interest; recondite: poetry full of esoteric allusions.
2. belonging to the select few.
3. private; secret; confidential.
4. (of a philosophical doctrine or the like) intended to be revealed only to the initiates of a group: the esoteric doctrines of Pythagoras.

esoteric. (n.d.). Dictionary.com Unabridged (v 1.1). Retrieved February 03, 2008, from Dictionary.com website: http://dictionary.reference.com/browse/esoteric

Basically, what it boils down to is this: many developers build their games to be unintuitive. People have to already know how to play your game before they can play.

Some of this is caused by the fact that many game designers and developers don't know much about user interface design. The rest is caused by the fact that game designers and developers already know how to play their own games, so they never think about making their game easier to use because they don't know that it isn't!

Here are four handy tips that should help you avoid making your game interface esoteric and make it more fun for your players:

Don't Require Unnecessary Steps

I have a mail shirt and I find a nice, shiny new mail haubergeon which has better protective qualities. I want to put on the haubergeon:



This is a very common mistake that developers make. They assume that the player did not intend to take off the shirt they were already wearing, so they cancel the command and give the player an error message. So, the player groans and types it all out in full:



But why? If the player didn't want to replace the shirt he had on, the intuitive answer is that the player wouldn't have tried to use the command at all! When a player attempts to execute a command, the ideal response is always to accomplish something. The more intuitive action is, thus, to swap the equipment:



Don't Bog Players in Semantics

All right, let's shag it! The Commander of the ship has called you to full alert! You run to the armoury and then grab your gear:



...What? Why not? Because it's not an article of clothing, of course. So, in the middle of a full alert, with my comrades being shredded to pieces on the surface, I pause to read the manual, only to find that the actual command for readying my assault rifle is "wield". I frantically try to input the command:



Game over, man, game over.

When you boil down the the deepest semantics, what is the difference between the assault rifle and the armour? The answer is that there isn't any. I know, right now you want to prove otherwise by shooting me with the assault rifle versus bludgeoning me with the body armour, but really, when it comes down to it, in real life you'd just get them and start using them. There's no reason to be more specific than that.

The best way to avoid all of this is just to use some sort of generic command. Let's use "equip":



...Well, good try, anyway.

Do as Much as Possible

When the player enters a command, you should always anticipate what the player's next activity should be. If the player always does a certain activity after performing a single command, the first command should automatically imply the next command, especially if the next command has no actual effect on the game (is informational only).

For instance, let's look at the following situation:



Aside from this being contrary to the other rules above, let's check out the second and third steps: "open box" and "look box". When you are opening the box, you then have to type another command just to look inside to see what's in the box in the first place.

How about we reduce it to this?



One less command to type means players can get more done faster. But wait. What is the point of the opening and closing of the box? Does it serve any purpose? We can reduce that even farther:



Opening and closing the box may be realistic, and may add flavour, but it just gets in the way of gameplay.

"Well, that's all well and good," you say, "But I want to be able to lock the box so people don't snoop around." Don't worry, that's easy too. We can just do this:



Simple and effective!

If you're particularly astute, there's a way we can make that even easier, too, by following our first tips. Give up?



Ba-da-bing, ba-da-boom.

Don't Play "Guess The Verb"

Another big problem is how secret the commands can be. On one hand, it's good to make your commands precise. But on the other hand, it's important to make your commands understandable. The rule of English, which I'm pretty guilty of not following, is to choose the simplest word which conveys the meaning you want.

For instance, let's compare the following commands:

gather (object)
* Allows the player to obtain equipment from his present location.

get (object)
* Picks up something from your location.

They both mean the exact same thing... but which one is better? Aha, that's a trick question. If the player can easily see all of the commands he has access to, like on BYOND, the simplest one is best. If the player can't see all of the commands he has access to, like on a MUD, the answer could surprise you: both.

English is cursed, compared to most languages, because we have so many different words to imply the same thing in slightly different contexts. For dinner, I can get a can of soda, obtain a fork, grab a plate, and take a napkin. They all don't mean exactly the same thing, of course. But in a game context, they should.

Imagine the following circumstance:



Frustration ensues.

If the player can't see the list of commands he can use, the best option is to guess what the player might use and provide all of the reasonable possibilities.


Hope that helps! Happy designing, ladies and germs.


By day, Jeremy T. Gibson is a mild-mannered reporter for a local metropolitan newspaper. By night, however, he is Superman! Well, okay, he made both of those things up, but he's still pretty clever.