What Does This Do?

February 6, 2008 at 7:06 pm (Game Design, User Interface)

In order to play a game (or, in the age of computers, maybe just in order to play a game well), you need to know how.  In an ideal world, you’d simply dedicate some time to learning whatever you need to know–read the manual, play the tutorial, peruse a FAQ, or what have you–and then you’d remember it all.

Unfortunately, most players have neither unlimited patience nor perfect memory, so that typically doesn’t happen.  Players who want to play your game will generally want to start with as little time commitment as possible, and they won’t remember everything you tell them.  So in order for them to play the game, it has to be possible to learn at least some things as you go along.  The game has to be self-documenting: the game itself needs to contain the information necessary to play it.

This doesn’t mean that you should have a button in the game that brings up the player’s manual (though perhaps you should), but that players need to be presented with context-sensitive help giving them information relevant to their current situation.  If the player wanted to simply hear everything you want him to know presented in the order you think is best, he’d be reading the manual.  What he probably actually wants is precisely the information that will get him safely through the next ten seconds of his game.

This is challenging for a couple of reasons.  First of all, it means we have to be flexible in the order concepts are presented–if the explanation for feature B doesn’t make sense until you understand feature A, then if the player manages to grab feature B before looking at A, we have a problem.  Secondly, we need the documentation to be concise and separable–we need a way to quickly and conveniently inform the player of just want he wants to learn, without flooding him with information that’s extraneous to the task at hand.  And third, we need to somehow figure out what the player wants to know–and determining intent is rather difficult.

However, I am happy to report that many programs actually do a pretty good job of this, and some general tools exist for making it easier.


One great tool is the “tooltip”–a small bit of information that pops onto the screen describing something the user is looking or pointing at.  Tooltips are becoming quite common, and it’s because they do their job very well:  they provide information on the object of the user’s attention, and (usually) only on that object.

Because they appear only on a specific cue, we don’t clutter up the screen with information the user isn’t interested in, and the user can easily seek more information about anything on-screen simply by pointing at it.  And if tooltips get in the way of experienced players, it’s simple to include an option to turn them off.

The idea of tooltips generalizes to the practice of attaching a description of something to that thing; in a tabletop game, it might be putting the rules for a card or a playing piece on that piece.  Customizable card games can be easy to learn (though they often aren’t) despite having an enormous number of rules, because each of the cards includes most or all of the information needed to understand that card.

Of course, while tooltips are a great method for presenting information to the user, nothing about them makes the information particularly easier to write–many programs are plagued by confusing or uninformative tooltips.  They really only help with the third problem from my list, not the first two.  If you’re not careful, you’ll end up documenting your user interface but not the game itself (or vice versa), and that’s generally fairly unhelpful.

Technical Terms

Games each have their own set of rules, which are often abstract and somewhat arbitrary.  In order to describe them clearly and concisely, it’s often helpful to define your own technical vocabulary.  If you play a lot of video games, you’re probably familiar with a lot of common technical terms:  hit points, buffs, cooldown time, save points, line-of-sight, fog-of-war, and so forth.  Assigning specific names to abstract game concepts helps the player to understand how the different parts of the game interrelate, and makes further discussions of what happens in the game much smoother.

Your terms don’t even need to be words–symbols are frequently just as effective.  Once you’ve trained the player to associate a heart symbol with hit points or a circular arrow with cooldown time, you can construct interfaces that are smaller and easier to read without losing any information.

Once you’ve defined some terms, they also provide a convenient structure for supplemental help.  One of the great things about the web is that it’s taught everyone that you can get more information about a colored word or phrase by clicking on it; this provides a way for the designer to make more detailed information readily available to the player at a time that the player is thinking about it–again, without cluttering the screen with lots of complicated information unless the player asks for it.

However, one common trap here is to use the same word to refer to two related but different things.  It’s easy to end up using “attack” to refer sometimes to a “standard” weapon use and other times to any offensive action, to reuse a taxonomical term as one of its own sub-categories, to apply the same name to a culture and a political faction, and so forth.  While this sort of re-use often seems natural when you begin talking about the concepts, it can quickly mire you in confusing or ambiguous exchanges, and I think it’s usually worth the effort of inventing another term in order to avoid re-use.

And of course, there’s a more fundamental problem with defining your own technical terms:  they don’t make any sense until you explain them.  This can be helped somewhat by choosing intuitive terms, but you probably still need to explicitly define your terminology, and that creates another layer of documentation the player has to climb through to figure out how things work.  So this helps with problem 2 from my original outline, but may exacerbate problem 1.


Another classic technique for introducing a player to a game is to have a highly structured game session, where the player is exposed to the game a little bit at a time, explaining things along the way.  This has the potential to control the order in which the player learns things (which can be a great help with problem 1), and if structured well makes it much easier to anticipate what the player is going to want to know.  However, it can also feel tedious and restrictive if not done well.

The biggest trap here is to make sure that the tutorial doesn’t hinder players by explaining something they already understand.  Sometimes you have repeat-players, or people who have learned something about the game from another source (anecdotes, the manual, etc.) and if they’re trapped in a lengthy explanation of something they already understand, it wastes the player’s time and can become frustrating extremely quickly.  Any non-interactive segment of the tutorial should be skippable, and the interactive portions need to avoid being too tedious for a player who already knows what to do (frequent interruptions, forced pauses, and disabled game features tend to be bad).

Sometimes you can make the entire tutorial skippable, but that goal tends to conflict with making it interesting, because it means that nothing really important to the rest of the game can happen in the tutorial.  The best way to help the player learn is usually to spread out the information over as much real gameplay as possible, and compartmentalizing it into a small, skippable segment doesn’t accomplish that.

Remember, this is supposed to solve the problem of the player being too impatient to learn everything from a manual–if playing the tutorial feels like reading a manual, it doesn’t accomplish much.  Additionally, skipping the tutorial outright isn’t a good option for someone who has learned only half the information from other sources, but we still don’t want to bore that player with tedious segments teaching things he already knows.

I think that covers the three most common tools for addressing the three problems I outlined (in reverse order, naturally), though there are others.  Remember, there’s still no substitute for simply explaining things well, and none of these should be seen as replacing normal documentation–you probably do still need a user’s manual.



  1. Kreuvf said,

    “segments teching things” –> “segments teaching things”

    Good one 🙂

  2. Antistone said,

    Thanks; typo fixed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: