• Aucun résultat trouvé

Automatic Mode Cancellation

Dans le document [ Team LiB ] (Page 107-112)

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.

[ Team LiB ]

[ Team LiB ]

In Closing

The DP philosophy can greatly improve your coding practices. Reusing proven software components is the best way to create stable and elegant code. However, this chapter has only scratched the surface. Make sure you check out Appendix E, "Further Reading," to learn more about DPs.

[ Team LiB ]

[ Team LiB ]

Chapter 5. User Input

"If it keeps up, man will atrophy all his limbs but the push-button finger."

—Frank Lloyd Wright KEY TOPICS

The Keyboard Mouse Joysticks

Hardware Abstraction Force Feedback In Closing

A smooth user interaction model is key to any good game. Without adequate user input mechanisms, gameplay becomes obstructed and frustration occurs. In this chapter, we will explore the basics of user input control. Sadly, there will be few general rules. User interaction takes place at a relatively low abstraction level, and implementations tend to be quite hardware dependent. Where possible, general techniques will be exposed. But most of this chapter is devoted to the specific input methods available for popular platforms on the PC, such as the Win32 API and Microsoft's DirectInput.

[ Team LiB ]

[ Team LiB ]

Dans le document [ Team LiB ] (Page 107-112)