"Design of Everyday Things" Applied to Game Design
Don Norman's book The Design of Everyday Things is the definitive masterpiece on industrial/consumer design for the layman. It cleanly and neatly broaches the subject of intuitive, sensible design without being overly academic. Readers finish the book with an a-ha! feeling of insight into the problems that designers of all types must solve, yet often don't (his example of the transition away from the effective but staid Bell telephone to the many stylish but eminently unusable phones of today is illuminating).
Needless to say, I highly recommend The Design of Everyday Things and its sister book, Emotional Design, even if you're not a designer -- the books are simply fascinating in and of themselves. But if you're a game designer, the bulk of the principles detailed in his book map directly to the problems of game design, particularly in the area of player interaction and involvement.
Before I get into Norman's design principles, I want to take a moment to talk about the definition of game design. This phrase has taken on a life of its own, acquiring more definitions than a similarly ambiguous term, artificial intelligence. Game design encompasses a multitude of topics:
- mechanics: the rules of the game and how the game's systems are defined.
- setting: the genre, location, and style of the game
- narrative: the story, characters, and any relevant fiction for the game
- player interaction: specifically how a game communicates to and accepts input from the player
This article concentrates on the last item, player interaction, since user interaction is the focus of Norman's work.
Norman's Design Principles
Norman specifies five basic design principles:
- Constraints (Forcing Functions)
Visibility is the property of making "what to do" and "how to do it" visibly obvious to the end user. In game design, this means that the palette of actions available to the player should be readily apparent. Some games force the user to get close to an object and then hit an "interact" key, unsure if it even makes sense. This has been a problem from the "word hunting" days of text adventures to the "pixel hunting" days of 2D graphical adventure games. Modern games have solved this, to some degree, by highlighting objects you can interact with (alt-key in Diablo) and using changing reticles/crosshairs when near something "usable" (first-person games).
Mappings define the relationship between controls and their actions. Bad mappings are difficult to memorize, forcing the user to pause and think about which button/stick does what action. For example, "stick up" to duck is counter-intuitive and thus a poor mapping. The WASD key cluster is an example of a good mapping system for forward/back/left/right. Likewise using the L and R triggers for "juke left" and "juke right" is good -- it is easy to remember what controls correspond to which actions. There were old games that used to do crazy things like map D/F and J/K to left/right and up/down respectively. How in the world could someone think that mapping a horizonal key pair to a vertical axis is going to feel right?!. There have even been some relatively modern games that mapped a controller's stick to an on-screen character's relative direction -- so pushing up would move your character right if that character was facing to the right. While this may have made intellectual sense to those game designers, most players were exasperated by such schemes. Why? Becaeuse the mapping didn't feel right -- when you push left, what you're controlling on screen should move left relative to the player.
Affordances are the properties of objects that clearly indicate how they are supposed to be used. A chair "affords" sitting; a button "affords" pushing; etc. In a game, affordances are very closely linked to visibility, almost such that they are one and the same.
Constraints prevent the user from doing something that they shouldn't do. In a game this means things that aren't part of the core gameplay mechanic are disabled, hidden, or prevented. Well done constraints are invisible and help funnel the player along the play path. If killing an NPC is not part of the core game play and can only screw things up for the player, then don't let the player kill the NPC. If jumping out the window isn't what the player is supposed to do -- and if doing so would logically kill them -- then don't let them jump out the window. It is best if the constraints are invisible instead of capricious. For example, if a device affords some particular action, but doing that action does not push the player along the game's arc, then remove or redesign that in-game device instead of building an invisible wall around it.
A special type of constraint is known as a forcing function. A forcing function constrains the user from doing one thing until another thing is done. Obviously tried and true gamisms such as locked doors/keys are one example, but a subtler example might involve restricting a players movement until he has attained a certain level of power in an RPG. An appropriate forcing function would be a guard NPC that prevents further travel until the player has "demonstrated his skill some more". I've run into several RPGs where I've "outlevelled" the game, only to find myself woefully underpowered at the next major encounter. Forcing functions in this case may feel overly restrictive, but they improve the experience for most players.
Feedback tells the user that something happened after they performed some action. This can be visual and/or audible. If the user can't do something or is suffering from some state that they should be aware of, then give them that information. Quake 3 implemented this with the directional "red flashes" indicating the direction from which you were being hit. If the player is out of ammo, play an "out of ammo" sound instead of making them wonder why their gun isn't shooting. If a player falls a long distance and takes damage, let them know -- they shouldn't have to watch their health bar to keep track of injuries. Console games have an especially powerful mechanism with rumble controllers that provide tactile feedback. The "plucking" feel in Pikmin when you pull a pikmin from the ground is a wonderful example of appropriate feedback.
Immediate feedback goes a long ways towards immersing and educating players. It also lowers frustration since they can see/hear/feel the cause/effect of their actions.
Ignoring Norman's Design Principles on Purpose
Norman's emphasis (and the emphasis of every human interaction designer) is ease of use. This means that the design decisions are made specifically to ensure that the optimal usage is most readily at hand. Sometimes the optimal desigm is to inhibit the use of something by others. For example, child safety locks are specifically designed to prevent small children from accessing drugs, chemicals, and other dangerous substances -- ease of use, in this case, is something that the designer is intentionally avoiding.
Some game designers have done something similar in an attempt to challenge the player. Older adventure games violated the principles of visibility (making the player "find the magic pixel" or phrase a sentence just so), mapping (requiring the random combination of unrelated in-game objects), and constraints (performing some otherwise valid action would result in instant death).
Deliberately removing ease of use is often considered a cornerstone of game design -- it introduces challenge, obviously, since what might have been trivial is now arduous. However, right now I'm not convinced that this is solid game design. You can make a game easy to play but still very difficult to master without purposefully irritating the player. "Learning by death" is poor game design -- if a wall is going to kill a player just by touching it, make it rather obvious so the player can skip the necessary but aggravating "Hey, what's this wall d-*** RELOAD ***" sequence.
Implementing Norman's design principles won't guarantee that a game is interesting or fun, but they will at least make it consistent, logical, and easy to play, which is a good first step.