Usability Patterns

In recent years, the concept of DPs has surpassed the boundaries of software architecture and is being used in many other areas of application design and development. Web sites, GUIs, and so on can all be described in terms of DPs that are used frequently and have been researched (and hopefully solved satisfactorily). In this section, I will provide some hints on usability DPs that for some reason or another can be useful for game developers.

Shield

A shield is a protective layer that prevents the user from accidentally activating a feature or function that causes undesirable side effects. For example, a button that causes the game to shut down would constitute an undesirable side effect. When designing these kinds of situations, the shield forces the user to confirm his decision, so two mistakes are required in order to activate the said option by error. A classic example of shields is the confirmation messages to leave the game. But some shields also involve clever screen trickery. Think of a real-time strategy game where the user can choose to disband one unit, thus losing it forever. This is a sensitive option, because choosing it by mistake will have a deep impact on the player. Thus, sometimes games require the player to perform two clicks of a button to choose an option. This way if the player wants to disband the unit, he must select a more complex click sequence, ensuring he is not activating the option by mistake.

State

States are visual cues of the user's current configuration. An example would be the changing mouse cursor in old Sierra adventures. The left mouse button performed an action (moving, talking, and so on), whereas the right button was used to cycle through the available actions. The mouse cursor depicted the current state—a walking character for the move option, an open mouth to engage in dialogue, and so on.

States are incredibly popular. From "lock on" indicators in a combat flight simulator to robes worn by a role-playing game character, states are a handy and elegant way to inform the player of the current configuration.

A potential issue with states is preventing ambiguities. The number of states for a specific option must be small, and their symbolic representations must be clearly distinguishable. Also, state representations must be simple to identify, especially for those states that change often.

Automatic Mode Cancellation

The automatic mode cancellation (AMC) pattern can be used in games that have modes/automata, like a real-time strategy game, for example. To move one unit, a player must first click the unit, then click the Move button on the GUI, and then click the destination. But what happens if the user clicks somewhere in the game's scenario before clicking the Move button on the GUI? Logically, we will cancel the current mode and start over. This is what AMC is all about—detecting actions that do not fit the current mode and using them to cancel the current sequence of operations.

Other known uses of AMC are found in many games where an action requires two key presses/mouse button presses. Imagine a soccer game where you can control the force of each pass and shoot by pressing the Shoot key twice. The first time you press the Shoot key, a progress bar begins to increase on the GUI. By pressing the key again at the right moment, the shoot is performed using that force. The same principle is found in many golf games and some space shooters. But what if the player does not press the required key the second time? Quite likely, that means the first attempt was a mistake, or he simply has changed his mind and does not want to shoot. From a usability standpoint, we will cancel the shoot so the game is more playable.

Magnetism

Magnetism is a very powerful paradigm to use when we need the user to be precise. For example, consider a first-person shooter where the player needs to aim at enemies from far away in combat. At least in "easy" mode, it makes sense to code an auto-aim, so that if the enemy is located more or less in front of the player, it takes care of the precise aiming. This is what magnetism is about: making some positions dominate, so the user can have more fun with less effort. But sometimes magnetism can get in the way of realism. An advanced player will want to aim manually, so magnetism should always be an option, not a must.

Another interesting use of magnetism is found in strategy games or, generally speaking, games where we must be able to pick units or positions on a map. In a strategy game, we need our mouse cursor to gravitate around units so it is easier to select them. Imagine that you have one unit selected and are in "combat" mode, so you must click on the position of the map where the unit should move in order to engage in a fight. Because it doesn't make sense to fight against a rock or a piece of land, you can code the GUI so when the user clicks, it automatically detects the closest unit to the cursor and sends the player unit there. This way we can prevent the inexactitudes in user control that make the game less fun.

Focus

The focus pattern is useful when we need the user to concentrate on a specific piece of information so the rest becomes momentarily irrelevant. It has been used extensively in games in many visual reincarnations. One of the most popular focus examples is the deactivation of some menu options by graying them out. This is found in many Windows applications. The programmer does not want us to get lost in a sea of possibilities, many of which are actually not useful. Thus, the ones that make no sense are deactivated.

This pattern is used extensively in games, especially in strategy and RPG titles. For example, many sports titles involving teams allow us to specify tactics for each player. While we are working on a specific player, the rest of the team is blurred, thereby reducing the amount of information we must be aware of.

Focusing can be depicted visually in a variety of ways, from graying out to effectively blurring the irrelevant information.

Progress

Progress is one of the most widely used usability patterns. Its main application is displaying quantitative information about a process with a beginning and an end, so the user knows how long the process is and exactly where he is currently.

The obvious example is progress bars such as the ones used to depict level loading. Not providing such a cue makes the player nervous, because he does not know if the game is actually doing something or is simply malfunctioning. But there are other uses of the progress pattern. A good example is life meters. The player character in Diablo had two meters, one for health and one for mana, which was useful to perform spells. Diablo is a good example of how to integrate the progress inside the game aesthetics. The progress bar was depicted as two flasks, one red and one blue. Other games propose more extreme approaches. A good example is Wolfenstein, which depicted the life level using the face of our character with increasing damage levels. There is a potential risk with these artistic representations: Too often they will not convey the distance from our current state to the end of the process as accurately as a numeric/graphic bar would. We play Wolfenstein and see our character with a scar and a nosebleed. But do we know how many hits he can sustain, or how far he is from full health? It is hard to tell. Therefore, progress bars should be carefully designed so aesthetics do not destroy the usability pattern.