Learn Faster to Play Better: How to Shorten the Learning Cycle

Author: by Daniel Sánchez-Crespo Dalmau

As computer games have grown in size, budget and complexity, the natural trend has been to make them more difficult to use, due mainly to the host of features they include. Some years ago, when we were all playing Pacman or Q-bert, there was no need to make a game simple to use: those games were already so simple that any user interface (or no interface at all) could make them enjoyable. This article focuses on how to make today's games more fun to play by shortening learning cycles, thus making it faster for the user to master them.

Getting started, I will remind you that every learning process (driving a bike, speaking Japanese, or playing Quake) can be described as a function of time and knowledge. We begin in time zero with zero knowledge, and our knowledge rises as we play until we reach a steady-state. You can see such a function in Figure 1, and you can also notice how this curve can be split in two parts. First we have a start-up or learning phase, where the user tries to learn the rules of the new system. In our case, for example, he would try to understand which controls are available and what effects each have on the game. There are two key features to this phase: the user knows only a subset of the game rules, and consequently, his performance is limited.

The second phase is the "cruise" or stationary phase, which starts when the user knows all the rules of the game. The beginning of this phase is not well delimited, but reached asymptotically in the knowledge vs. time graph. In this second phase, the user knows all the rules of the game, and thus has a higher performance.

The rest of the discussion will focus on how to design an interface to shorten phase one, and improve performance during phase two. This way we can ensure faster and better playability.

I have organized this article as a list of strategies that a designer may follow to design better interfaces. Some ideas are classic, others are rather new. Keep in mind, however, that the strategies I will be presenting are not mutually exclusive, but complementary.

Analogy Learning

Our first objective will be making the learning phase as short as possible. So, we must find a way to make the game rules easy to assimilate. The best way to do this is by ensuring the user knows how to play the game before he plays it the first time. Sound stupid? Not really. Imagine you know how to drive a car. Then, one day you decide to learn how to drive a motorbike. As a car user, it will be easier and faster for you to pick up the bike's controls, probably much easier than if you didn't know how to drive a car. Why? Because both actions share common knowledge that our brain can easily extrapolate. This concept is called analogy reasoning, and its main theorem states that:

It is easier for us to gain knowledge over some subject if this subject is related in some way (is analogous to) something we already know.

For example, when a kid learns to speak a second language he is doing so by analogy with his native language, and I learned how to use a microwave because I had already used an oven.

Easy-to-use computer games should take advantage of this theorem and apply it as a way of shortening the learning phase. Four levels of doing so come to mind inmediately. Listed from worst to best, they are:

1. Generating specific rules
2. Importing standard game knowledge
3. Importing computer (non-game related) knowledge
4. Importing real world knowledge

As we go down the list the base knowledge we need to have is more abstract. The reason is simple. We are trying to learn by using our established knowledge as a basis. As this knowledge grows in abstraction, it also tends to be more deeply understood within our brains. Take, for example, riding a bike. Once learned, you will remember how to do it for years, even if you don't ride a bycicle anymore. In contrast, I haven't used Wordperfect in some years, and I don't think I'd be able to do so right now.

Returning to the list, the first option would be to forget about all this analogy reasoning concept, and go the hard way. We would create a set of rules which are very specific to our very game, and absolutely different from anything else. A game made with this philosophy would require lots of learning and studying on the part of the player. The best example that comes to my mind is Particle Systems' Independence War, a ground-breaking space flight sim with something like 70 different keys. This kind of game requires long manuals & tutorial lessons to shorten the learning process. Independence War included many training missions which introduced you to the different subsystems of your ship.

The second strategy would be the use of standard game knowledge. Many games are similar, so players can find analogies between them. For example, playing Starcraft after having played Dune 2 would be a breeze, as would be learning Unreal after having played Doom. Moreover, analogous games don't need to share a common "genre". For example, the classic Gauntlet game is in many ways similar to any first-person shooter, and having played Super Mario Bros could make it easier for you to play Tomb Raider. The run-to-avoid philosophy is behind both games in some way, so we can recycle our existing knowledge and reduce the length of the learning phase.

This strategy has proven very succesful, because recycling and adapting knowledge to a new situation is less stressful than building a brand new one from scratch. Let's apply the same philosophy even more. We can import knowledge from other computer science areas. Take, for example, the mouse. We all know (from long experience with Windows) that a left click, followed by a drag and button release, means "select everything inside." This was introduced back in the Windows 3.1 era, probably in Wordperfect 5.2. Now many games have imported this concept and apply it to their interfaces. In fact, many real-time strategy titles use the click'n'drag method as a way to select units from your armies. Most mouse commands (such as left click, drag & drop, double click) are adaptations, as areo dialog boxes, menu systems, progress indicators, and the like.

Finally, we can import real life knowledge into our games as a way of making them easier to use. These are usually called "metaphors," and are the best way to ensure fast adaptation to game rules. A classical metaphor example would be the Macintosh / Windows 95 user environment. You have folders, files, a desktop, a trash can (recycle bin for Win95), etc. These things are nothing but icons on your screen, but if I say "folder," you get an instanteneous idea as to the purpose for which it has been designed. Why? Because of the analogy you are buiding with the real-world object. So, metaphors are representations of real-world objects in computer environments, and the computer representation has a behavior analogous to its real-world conterpart.

A good example of metaphors in game interfaces would be inventory systems for RPGs, such as Diablo. These inventories are usually called "paper dolls", because they are similar to classic toys: by "dressing up" our characters we can easily control their equipment.

When creating a game metaphor, the designer must choose the real-world object carefully, so there is no possible confusion or ambiguity. The object designed as a metaphor should have a single, well-defined use. For example, using a gun as a metaphor has an obvious meaning: attack or use a weapon. If we chose to depict the same action using a fist, confusion would be possible: the fist could symbolize attack, but also grabbing an object.

As humans, we have a highly developed verbal and grammatical system. Still, language may not always be the perfect solution for some communication needs. For example, take the following list of words:

All six words mean the same thing ("mouth" in Spanish, English, French, Japanese, Latin and German, respectively). Still, the symbolic representation used by the different languages is very different. No one would say that all six words express the exact same meaning. Most modern languages separate representation from meaning, and this may be unsuitable for interface design: the interface must be adapted to whichever language a player uses. On the other hand, take the image in Figure 4.

OK, so it's a picture of a mouth. Here, representation (the picture) and meaning (the concept of mouth) are closely tied. Most ancient languages where built around this idea. For example, see the Egyptian hieroglyph for mouth," and the Japanese khanji symbol for the same concept, in Figures 5 and 6.

Both resemble the shape of a mouth. Early languages were pictorial because the human brain works much better with images than it does with words. Decoding written text required much more effort than just seeing and identifying shapes in a pictogram, and that's the reason why cavemen began by drawing animal shapes onto the walls, instead of writing their names.

Maybe we should apply this same methodology to interface design. We could try to express as much information as we can in a graphical way, so that it becomes:

This trend towards pictographic interfaces is not new, and many games have made great use of this paradigm. If you decide to use this strategy, you should keep in mind the following:

To sum up: use graphical metaphors. Thus, the quest for pictographic interfaces finally meets the analogy learning trend. As a result, you get a symbolic representation (a drawing) of something the user already knows how to use (because it is a metaphor). Tests show that this provides much beter usability and user perfomance.

There is yet another practical reason to use pictograms. Today's titles sell millions, and are sold worldwide. As a consequence, they need to be translated. All on-screen messages, manuals, etc. have to be converted for every languages the game will be sold in. Pictographic interfaces, when designed cleverly, require little or no translation at all, because the symbols they use are universal. So, as a side effect, this strategy can reduce the needs of localization.

Screen Layout Techniques

Sometimes games contain relatively large sets of actions that a user may take at any time. For example, the Baldur's Gate screen in Figure 7 has (counting menus and buttons only) more than 25 clickable targets on-screen simultaneously. If we do not apply some clever layout technique, the result may only be a screen cluttered with unrelated info.

To maximize user performance in these situations, we must follow some basic laws.

The first one is called Fitt's Law, and states that:

"The time required to acquire a target is a function of distance to the target and its size."

This law has some interesting extensions and corollaries. For example, targets located along the edges of the screen are easier to reach than those located in the middle. Even more, the four corners are the least-effort area of the screen, in terms of ease of access. So games should keep the most important buttons and controllers in these areas.

Another interesting conclusion arises from the fact that user speed decreases with distance to the clickable area, which is quite obvious. Still, most games put menus and buttons in predetermined areas of the screen, such that the user must go there to click them. Efficiency would improve if we could ensure that the buttons were always close to the current mouse position.The only way to achieve this effect is by using floating menus, so that the menu opens right around the cursor position with a click. Although Windows has been using this paradigm for some years now, I can only remember one game using this concept: Silver, a newer RPG by Infogames. As you can see in Figure 8, whenever the user clicks the right mouse button, a floating menu opens and you just select the right button. It takes some time to get used to it but, as time goes by, the system proves very agile and efficient.

A second law is to organize the screen in a coherent way. Menus, buttons and commands should be laid out in thematic groups, to improve access speed. For example, in Baldur's Gate you have game commands on the left-hand side of the screen, immediate actions (move, attack, etc.) on the bottom, and characters to the right. Grouping related items in such a way reduces the time required to click on the different areas, especially for novice users.

The third (and last) layout strategy is to keep relevant information (but nothing else) visible. All the actions a user may take at a certain point of the game should be directly visible, without a need to dwell into nested menu systems. Many users ignore all commands that are not directly available to them. On the other hand, all information irrelevant to a the current game context should disappear, or at least become unusable. This way we can prevent user errors. In a RPG, for example, selecting a character should show on-screen all the actions he can perform, and de-activate all the remaining actions.

The spatial layout techniques I have just outlined, when used together, greatly improve interaction, by make games more intuitive. This is a very important feature, especially in the first minutes of gameplay, which decide whether the player will stick to the game or get bored and stop playing.

Feedback

Every interactive process requires that communication be two-way. In computer games, communication is structured under the master-slave paradigm: we (the players) give orders, and the game must perform them, and return us any info or result derived from our orders. Whenever the game returns us info, we are talking about feedback.

Extensive research has been done to study the different ways of feedbacking the user in software applications. All studies agree on the following three "rules of feedbacking," which should always be followed:

To integrate easily these feedbacking messages into our games, one may use any media available. Graphics indications are probably the most popular, but lately many games have made great use of sound as a feedbacking tool. For example, whenever you select a unit in a Real Time Strategy game, it answers with a "Yes, sir?" kind of message, the main purpose of which is to acknowledge the selection. Feedbacking in games does not need to be in the form of the classic and boring hourglass; it can be integrated into the script, and thus become an added value for the player.

Standards

Computer games have been around for some time now, and have developed an extensive knowledge base. This knowledge may come in the form of certain keyboard commands (F1 means help, ESC means main menu, P means pause), dialog styles, etc.

When designing a brand-new title, it may be a good idea to follow trends that have been accepted as de-facto standards by the gaming community. These trends will probably be so deeply understood within your audience that keeping them in mind while building your game will shorten the learning curve.

In this section I am just going to give a short listing of common practices which are widely used in game interface design. I encourage everyone to send me more, and maybe we can make a follow-up article containing interface design guidelines. Anyway, here is my initial contribution:

Consistency

Consistency is a property that defines a system whose subsystems are all designed under the same guidelines, and thus constitute a homogeneous whole. At first sight, it sounds quite easy to understand and implement. Still, some games keep failing to offer consistency throughout their user interface. The reason? Today's games are built by large teams, and thus different interface areas may have been designed by different people, each one with his/her own ideas.

Consistency may be applied in many different areas. Here is a listing of the main points you should check out:

Software engineering tools and modern design methodologies are the best way to ensure consistency in today's computer games. Object Oriented Programming, for example, allows us to create abstract classes to define interface elements (such as buttons, dialogs, text strings, etc.). Then we can design each element as a descendant of the base class, sharing its abstract properties.

This concept was introduced some years ago with products such as the Microsoft Foundation Classes, but the game development community has been reluctant to adopt them for the sake of performance. The truth is that OO languages (such as C++) tend to be a little slower than classical ones, and are also harder to optimize. Still, with today's hardware technology, maybe the small performance hit can be worth the extra robustness OO designs can offer. Some years ago, we were all refining our assembly "putpixel" routine. Now these low-level graphical tasks have been successfully transferred to specialized hardware. The OOP vs. classical programming issue is quite similar, and maybe it's time that some developers give away some control, and get robustness in return.

As a final note on how to get better consistency, game designers may be interested in taking a look at a new trend in generic software engineering. It's a design methodology based upon OOP, and it goes way beyond it. It is called "design patterns," and its central idea is that some problems have been around for quite a long time and appear frequently in software engineering. So, brilliant software solutions have been developed, and catalogued. These proven, successful solutions are called "design patterns," which you may find in a design pattern catalog and use whenever you encounter the same problem again. The design patterns solve the problem by offering a set of OO classes which implement the solution.

Okay, so what does all this design pattern blurb have to do with user interfaces? Simple. Many of the design patterns that have been developed deal with user interfaces, as this area contains many lines of code, many complex issues to handle, and many headaches for the programmer. If you grab a design pattern textbook and take a look at the catalog, you will find many great ideas that will tell you the way to build well laid-out user interfaces, and get the consistency you need.

As a bibliographical recommendation, you may be interested in taking a look at the classical design pattern textbook, Design Patterns : Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing), by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch Keep in mind this is not a product endorsement; the book specified above is one of the few that deal adequately with design patterns, so you don't have much of an option.

Invisible Interfaces

Thinking broadly, computer games are about fun and immersion. We (game developers) try to make them (players) have a good time and escape from everyday life for a while. Under these rules, a visible and obstructing interface may break the sense of immersion, and thus spoil the experience as a whole. Take, for example, the first-person shooter genre. In Quake, the game is laid out as a collection of levels. Between levels, the game is interrupted and the classical "Loading..." page appears. Now compare this to Valve's Half-Life (built on top of the same Quake engine). Here, the game is a continuous whole, and loading sequences are avoided by caching map sections.

When the user is playing Quake, we have him (or her) immersed completely in the gaming environment. To sum up, he's having a real good time. So, when the "loading level" screen appears, we are deceiving him, by breaking the sense of immersion. Interface interruptions should be avoided whenever possible, by integrating them into the game. Some interruptions may be easier to handle than others (integrating a CD-ROM swap into the script of a medieval RPG would be quite hard). Still, we must try to keep the player immersed in the game as much as possible.

The idea of integrating interface aspects into the game to improve immersion is quite powerful, and not necesarily limited to hiding level loading sequences: it can be applied in many other situations as a global strategy. The X-Files game, for example, did a fine job hiding its own user interface under the storyline. Our player (an FBI agent) carries a series of typical special agent items (a PDA, a flashlight, a cellular phone, etc.) which allow him to interact with the game. The PDA (one of those portable electronic agendas), for example, serves as game map, inventory manager, etc. This makes the game very intuitive and easy to pick up. Blade Runner, from Westwood, followed a similar approach: since our character was a futuristic special agent, it seemed logical that he carrieed a personal computer, where most of the interface functionality was integrated.

So, we can build a non-intrusive interface by basically encapsulating its functionality into the game itself. Still, we must not forget the other principles of interface design I have been outlining - for example, the screen layout principle that tells us to keep relevant controls visible at all time. Making invisible interfaces does not mean taking buttons and commands away from the screen, as doing so would make the game hard to play. A better goal would be to substitute every control that can break the game's sense of immersion with an adequate metaphor. If the metaphor we choose integrates nicely within the game environment (as the PDA in the X-Files game, for example), the game atmosphere will be greatly improved.

Customization

When it comes to playing games, people are more different than one might think. Some are left-handed, others right-handed. Some are aggressive, others are more strategic. If we are all so different, how come many games offer little or no customization at all?

Customization may come in a variety of ways. As a first step, one may offer control customization. This includes the basic keyboard-remapping routines, joystick and mouse configuration, etc. The need for such features can be demonstrated with an obvious example: as a left-handed person, I feel much more comfortable playing with the left area of my keyboard than with the usual right side cursors.

Still, there's more to customization than keyboard remapping. For example, a game should provide a way to record new commands, and encapsulate several low-level actions under certain keystrokes. This may be very helpful in medium-to-complex games, such as simulations or RPGs. Just imagine the potential of a well designed macro language in a Real Time Strategy title: the user would be able to record something like:

These simple scripts would allow the user to automate character behavior, and may be helpful to improve performance, especially in the steady state of the time vs. knowledge graph.

Some games offer this kind of functionality right now. Baldur's Gate, for example, allows the user to assign "behavior scripts" to your characters. This way you don't have to control every reaction, but allow the system to follow the behavior guidelines you outline. As an example, see the script below, borrowed from Sean Woodcock's great AI article:

Sean used this as an example of extensible AI, and he was right. Still, to me it looks also like a nice interface feature: the ability to automate tasks which would become boring and repetitive.

As a first step, this feature is brave and brilliant. However, these advanced options are usually hidden in some obscure configuration files, and are thus unfriendly and hard to use. Future games should allow this customization to be performed in a simple way, from inside the main game engine, as easily as you change your weapon.

Uniqueness

Here comes an obvious recommendation. Great games do not follow the rules; they make up new ones, and this applies to all areas -- graphics, sound, and AI, but also the user interface.

Take, for example, the SCUMM interface defined way back by Ron Gilbert at Lucastarts. At its time it was strange, unusual, but re-invented the graphics adventure genre. Or the Myst-Riven gameplay system, or the real time strategy interface paradigm. All of them were new, and now have become industry-wide standards.

Moreover, sometimes building what may seem to be a bad interface according to the "textbook" will improve the overall game value. An interesting and recent example would be Independence War, by Particle Systems. This game has a really steep learning curve, and breaks many of the rules I outlined above. Still, it was a great success. Why? because its user-unfriendliness was exactly what the market niche it was designed for desired. The same philosophy guided the design of Third Reich, a strategy game published way back by Avalon Hill. If the manufacturer had built a easier to use interface, probably the game would have lost most of its interest in the hard-core strategy gaming community it was designed for. So, interfaces may be sometimes used as tools to approach your target audience. These games tell us not everyone wants standard interfaces, so all the rules I explained above sometimes can't be applied.

The Future

User interfaces are complex software pieces, requiring a smooth intersection of art and usability. We need the art to give the interface its visual appearance, but we need to apply usability criteria to make our games easy to use.

In the past, the first part has been widely explored. All interfaces looked great, and really made the user want to play the game. The great deception comes when we try to interact. Usability has not been widely explored, and sometimes we end up with games that look great, but play bad. This is changing rapidly, and new games offer better and better playability by improving user interfaces. In the future, we will probably see art and usability balance.

Another idea I would like to point out is that most interface design techniques focus on making the learning phase as short as possible. As an example, only one of the strategies outlined above (adapting to the user) is specifically designed to improve performance in the steady-state. Games are getting longer and longer each day. Final Fantasies, Baldur's Gates, and so forth guarantee about one hundred game play hours each. Obviously, most of that time belongs to the steady-state phase, as these games are easily picked up. So, we are concentrating all our effort in around two hours of gameplay (the time required to learn to play one of these games). What happens afterwards? What strategies will game designers apply to improve interaction once the player knows all the game rules? Maybe we should do some kind of "player profiling," to adapt the interface to his or her gameplay, give tips on how to improve performance, and so on. This is quite an unexplored path, but is probably going to get more and more attention in the next few years.

Daniel Sánchez-Crespo Dalmau is a Computer Engineer from Barcelona, Spain. He teaches game programming, and writes monthly columns in the Spanish edition of PCFormat and Byte Magazine. His all-time favourite computer game is Privateer.