ID:38822
 
Keywords: design, interface
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:

> wear haubergeon
You are already wearing the mail shirt!


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:

> remove mail shirt
You take off the mail shirt.

wear haubergeon
You put on the mail haubergeon.


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:

> wear haubergeon
You take off the mail shirt.
You put on the mail haubergeon.


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:

> get body-armour
You pick up the body armour.

wear body-armour
You put on the body armour.

get assault-rifle
You pick up the assault rifle.

wear assault-rifle
I can't wear that.


...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:

> wield assault-rifle
You wield the assault rifle.
The bug crushes you in its jaws for 153 damage! You die...


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":

> get body-armour
You pick up the body armour.

equip body-armour
You put on the body armour.

get assault-rifle
You pick up the assault rifle.

equip assault-rifle
You ready the assault rifle.
Locked and loaded!

exit
You charge out the dropship doors.

shoot bug
You shoot at the bug! You miss!
The bug crushes you in its jaws for 147 damage! You die...


...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:

> look box
A large metal box.
It is closed.

open box
You open the large metal box.

look box
A large metal box.
Inside it you see a green jewel.

get jewel from box
You remove the green jewel from the large metal box.


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?

> look box
A large metal box.
It is closed.

open box
You open a large metal box.
Inside it you see a green jewel.

get jewel from box
You remove the green jewel from the large metal box.


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:

> look box
A large metal box.
Inside it you see a green jewel.

get jewel from box
You remove the green jewel from the large metal box.


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:

> look box
A large metal box.
Inside it you see a green jewel.

lock box
You close and lock the large metal box.

look box
A large metal box.
It is locked.

get jewel from box
The large metal box is locked.

unlock box
You unlock and open the large metal box.

get jewel from box
You remove the green jewel from the large metal box.


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?

> look box
A large metal box.
Inside it you see a green jewel.

lock box
You close and lock the large metal box.

look box
A large metal box.
It is locked.

get jewel from box
You unlock and open the large metal box.
You remove the green jewel from the large metal box.
You close and lock the large metal box.


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:

> get soda
I don't recognise that command.

grab soda
I don't recognise that command.

take soda
I don't recognise that command.

obtain soda
You obtain the soda and put it into your pack.


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.
Add comment "Nice read, Jt"
I'm sorry, I don't know the word 'add'.

Post comment "I'd also like to add the concept of user made aliases"
Could you phrase that in another way?

Put comment "You know, where a player can add 'grab' to the possible working commands for 'get'"
Please break your commands into smaller sentences.

asovhdsfj pp ap jpo a~!
Maybe you should take a break...
And here I thought you were going to be discussing things like where to put the exit button and which side the "OK" and "Cancel" buttons should be on.
Good article, JT! If I'd seen it before Lummox, I'd have approved it too. :)