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.

Figure 1. Time vs. Knowledge graph, A.K.A. Learning curve

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.

Figure 2. Independence War, by Particle Systems

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.

Figure 3. The weapon metaphors in Baldur's Gate are intuitive to the player.

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.