영어 번역 입니다. 역부족이에요 도와주세요...

게시물 수정 , 삭제는 로그인 필요

User-centered

Games, however, often impose artificial constraints because they contribute to the fun of the game. To
illustrate this difference consider the following example. One of our games usability leads, Bill Fulton, has said that
the easiest game to use would consist of one button labeled “"Push”". When you push it, the display says “"YOU
WIN”". The irony of this example is that this game would have few, if any usability issues, but it clearly would not
be much fun. At the same time, making a game difficult does not necessarily make it fun. Consider chess. The
constraints consist of rules imposed on moving pieces. However, these constraints combine to yield a complex set
of possible combinations of movement that vary through the opening, middle, and end portions of the game. Chess
would not be “"improved”" by introducing more constraints, such as making it harder to distinguish the pieces, or by
imposing a new set of bizarre and apparently inconsistent rules of movement, such as “"after the 20th move, any
bishop left of center, but past the midpoint of the board will now be able to move seven spaces horizontally
(diagonal movement is unchanged)”". In short, games must impose consistent constraints on user behavior, while
making the process of attaining the defined goals interesting and challenging.

Function vs. mood

While productivity applications use sound and graphics to convey function, games create environments
through the use of sound and graphics.
The use of sound and graphics in productivity applications is relatively small. Buttons may have drop
shadows to produce a three-dimensional effect in an attempt to afford clicking. Icons may be placed on buttons to
afford software functions, like the disk icon to represent the save function. A “"click”" sound may be used to provide
feedback that a certain function has occurred, such as in selecting a drop down menu. Even at higher level, overall
look of the interface may produce an identity, e.g., buttons that appear to be illuminated from within, or the
“"lozenge”" look of Macintosh OS X (Apple Computer Inc, 2001).
In contrast, most games attempt to create an “"environment”" though the use of sound and graphics, which is
integral to the game. For example, House of the Dead II (Sega, 1999) creates a dark spooky environment through
the use of rain effects, compelling depictions of an abandoned city populated by zombies and a few straggling
civilians to be saved (or not). In addition, music and sound effects contribute to the environment by creating a sense
of tension.

View of outcome vs. view of world

Productivity applications rarely have a point of view, or perspective. In contrast, most games need to
assume a point of view (first person, third person, Eye of God) or perspective.
Productivity applications may offer alterative views (normal, outline, print, and Web) of the same data.
Two of these views (print and web) are intended to help envision the final product. The others provide way to see
more of the document (normal) or to manipulate the data in specialized ways (outline). It is also common for
productivity applications to offer zoom or degrees of magnification, allowing the user to see more or less detail in
exchange for a narrower or wider field of view. What is uncommon, is introducing the notion of perspective.
Games often provide perspective, or a point of view. In some games, it attempts to mimic perceived optical
flow (i.e. first-person shooters), or center of outflow to specify direction of locomotion. With the increased use of
three-dimensional environments, issues often arise in games that are very similar to those experienced in virtual
environment community (e.g., Barfield & Williges, 1998; Smart, 2000). Game designers must appreciate the
difference though between trying to simulate reality, and creating an environment that users perceive as reality (cf.
Stoffregen, Bardy, Smart, & Pagulayan, in press). Stanney (2001) provides an in depth discussion of many the
design and implementation strategies when dealing with three-dimensional environments.

Organization as buyer vs. individual as buyer

Many productivity applications are bought by organizations. Games are almost always bought by
individual users. Some productivity applications are sold to home users who are interested in using the same tools
both at work and home, but by and large, businesses buy productivity applications. In making these purchases, key
influential purchasers often spend time evaluating, learning about, and pre-justifying their decisions before ever
purchasing a product for their business. This changes the marketing of products to focus on direct sales
relationships with the influential purchasers rather than consumer advertising.
In contrast, game makers must sell to consumers rather than influential purchasers because the majority of
game purchases are made by consumers. This market is large and diverse, which makes it difficult to directly
communicate with consumers. Because of this, key features must not only be usable by relatively untrained people,
they must be visible, explainable, and appealing to purchasers using minimal media (i.e. box covers and 30-second
advertisements).

Form follows function vs. function follows form

Users of productivity applications tend to be cautious about adopting innovation while game buyers tend to
welcome innovation. Users of productivity applications tend to be reluctant to embrace entirely new and innovative
User-centered Design in Games
designs. The primary interface of many productivity applications has been relatively stable for many years (take the
graphical user interface for example found in current Macintosh and Windows operating systems). While there are
many proffered explanations for this, the most plausible one is that current designs suit user needs relatively well
and none of the innovations offered over the years have appeared compelling to users. Innovation does not
necessarily equate with greater functionality or ease of use.
Games are compelled by economics to push the technological envelope and to show off exciting features of
the system for which they are made. Like other forms of entertainment games incorporate new and novel features in
the hope of attracting a wider audience and not losing their existing audience. While this is often very exciting for
consumers, it can also lead to problems. This issue is discussed further later in the chapter.

Standard input devices vs. novel input devices

There is wider variation in game input devices than in productivity applications. Most productivity
applications utilize two input devices –- a pointing device and a typing interface. Use of pointing devices or touch
screens can be taught in short and simple tutorials. Typing is a skill that can be learned independently of the
applications. In both cases, there is not as much variability in input devices when using productivity applications.
Games, however often have unique input devices that are especially designed for a particular games,
genres, or platforms. Gamepads, joysticks, steering wheels, aircraft yolks, simulated guns, and microphones all
solve particular design problems, but often end up create problems as well. For example, one could argue that using
a joystick should be more satisfying than using a keyboard for controlling an airplane flying through the air.
However, it can also be argued that using that same joystick is not very efficient for inputting text on the screen to
save your high score. Particular game genres and platforms (see section below) complement certain input devices to
make games more or less fun, but also create new issues not see in productivity application input devices.
Figure 2 is a sample of different types of input devices.
-------------------------------------------
Insert Figure 2 about here
-------------------------------------------

Summary

We believe the above nine characteristics summarize most of the ways that games differ from productivity
applications. It is worthy to note that many of the characteristics mentioned are not solely unique to games though.
Many of these characteristics can also be found in areas such as virtual environments, web applications, or home
software applications, like home publishing software for example. However, for purposes of this chapter, all these
characteristics need to be taken into account and judged appropriately when discussing a game. Later we will
discuss how these differences create particular challenges for both the design and evaluation of games.
These principles may appear to be overly general, but that is because as a class, games are very diverse.
Below we review some common classification schemes for games and enumerate the various game types.

Types of games

PC vs. console

PC versus console (Cassell & Jenkins, 2000a) is one of the simplest classifications that can be made. It
differentiates those games played on a PC from those played on a console (e.g., Sony Playstation, Sega Dreamcast,
Microsoft Xbox). There are many characteristics that are associated with each platform. For example, the PC offers
different control mechanisms (keyboard, mouse and other possible game controls). Games usually eschew a
keyboard in favor of a controller which provides a series of buttons and joysticks.
Crawford (1982) divides games into even finer categories; arcade (coin-op), console, PC, mainframe, hand
held. These are all important distinctions. However, for the purposes of this chapter, we will often refer to the PC
versus console distinction.

NPD genre classification and examples

The NPD Group (a marketing company) uses a fine grained classification scheme for game type which is
referred to quite often in the games industry. They offer the following classes and subclasses as seen in Table 1.
-------------------------------------------
Insert Table 1 about here
-------------------------------------------

Principles and Challenges of Game Design

Having differentiated games from other applications we can look at some of the unique issues in game
design and evaluation.

Identifying the right kind of challenges

Games are supposed to be challenging. This requires a clear understanding of the difference between good
challenges and frustrating usability problems. Most productivity tools struggle to find a balance between providing
User-centered Design in Games
a powerful enough tool set for the expert, and a gradual enough learning curve for the novice. However, no designer
consciously chooses to make a productivity tool more challenging. The ideal tool enables users to experience
challenge only in terms of expressing their own creativity. For games, learning the goals, strategies, and tactics to
succeed is part of the fun.
Unfortunately, it is not always clear which tasks should be intuitive (i.e. easy to use) and which ones should
be challenging. Take a driving game for example. We are willing to argue that it is not fun to have to discover how
to make your car go forward or turn, but that does not mean that learning to drive is not part of the fundamental
challenge in the game. While all cars should use the same basic mechanisms, it may be fun to vary the ways that
certain cars respond under certain circumstances. It should be challenging to identify the best car to use on an oval,
yet icy, racetrack as opposed to a rally racing track in the middle of the desert.
Learning and mastering these details may involve trial, error, insight, and logic. Furthermore, the challenge
level in a game must gradually increase in order to maintain the interest of the player. If these challenge-level
decisions are made correctly, players will have a great time learning to overcome failure. Defining where the basic
skills should stop and the challenging skills should start is very difficult, so input from users becomes necessary to
distinguish good challenges from incomprehensible design.

Addressing different skill levels

Different strategies can be used to regulate the challenge level in the game in order to support both skilled
and unskilled players. Players of all skill levels must do more than simply learn the rules; each and every one must
experience a satisfying degree of challenge. Given that both failure and success can become repetitive quickly,
games must address the problem of meeting all players with the correct level of challenge. While this is
complicated in single-player games, it is an even more daunting task when players of different skills are pitted
against one another. Tuning a game to the right challenge level is called “"game balancing”".
There are many ways to balance the difficulty of the game. The most obvious way is to let players choose
the difficulty themselves. Many games offer the choice of an easy, medium or hard difficulty level. While this
seems like a simple solution, it is not simple to identify exactly how easy the easiest level should be. Players want
to win, but they do not want to be patronized. Too easy is boring and too hard is unfair. Either perception can make
a person cease playing.
The environments, characters, and objects in a game provide another possibility for self-regulation. Most
games will offer the player some choices regarding their identity, their opponents, and their environment. The better
games will provide a variety of choices that allow users to regulate the difficulty of their first experiences. With
learning in mind, it is not uncommon for the novice player to choose a champion football team to play against a
weak opponent. As long as the player can distinguish the good teams from the bad ones, and the teams are balanced
appropriately, users will be able to manage their own challenge level.
Another obvious approach to varying skill levels is to require explicit instruction that helps all users
become skilled in the game. You might imagine a tutorial in which a professional golfer starts by explaining how to
hit the ball and ends by giving instruction on how to shoot out of a sand trap onto a difficult putting green.
Instruction, however, need not be presented in a tutorial. It could be as direct as automatically selecting the
appropriate golf club to use in a particular situation with no input from the user, similar to the notion of an adaptive
interface, where the interface provides the “"right information”", at the “"right time”".
Some games take it even further by identifying the skill level of the player and regulating the game
difficulty appropriately. In this situation, instruction can be tuned to the skill level of the player by associating it
with key behavioral indicators that signifies that the player is having difficulty. If the game does not detect a
problem, it does not have to waste the player’'s time with those instructions.
Productivity tools have implemented similar problem-identification features, but often with mixed success
due to the open nature of tasks in most productivity applications. Good game tutorials have succeeded by setting
clear goals and completely constraining the environment. Doing so focuses the user on the specific skill and
simplifies the detection of problem behavior. Other lessons from game tutorial design will be described in later
sections of this chapter.
Another in-game approach to regulating the difficulty level requires adjusting the actual challenge level of
the opponents during the game. Evaluating the success of the player and adjusting the opponent difficulty during the
game is often called “"rubber-banding”". This tactic is frequently used in racing games. These games monitor the
progress of the player and modify the skill of the opponents to ensure that each race is a close one. If the player is
not a great driver, the game can detect that and slow down the computer opponents.
Rubber-banding works the same way in multiplayer games. However, restricting players can feel unfair to
the restricted player and patronizing to the unskilled player. The popular football game NFL Blitz (Midway Games,
Inc., 1997) uses this technique in both single and multiplayer modes to keep the challenge level continuously high.
User-centered Design in Games Even though this may seem like a good solution, there can be a downside. When players perform very skillfully,
their performance is moderated by computer-generated bad luck and enhanced opponent attributes. The likelihood
of fumbling, throwing an interception, or being sacked increases as a player increases their lead over their opponent.
Most people would prefer to play a competitive game (and win) than to constantly trounce a less skilled opponent.
But, at the same time, over-developed rubber-banding can cheat a skilled player out of the crucial feeling of mastery
over the game.
The key for the game designer is to think of ways to maintain challenge, reward, and progress for the
unskilled player without severely hampering the skilled player. A final approach focuses on providing tools that
maximize the ability of the trailing player to catch up with the leading player. One interesting and explicit example
of this is found in Diddy Kong Racing (Nintendo of America, 1997). In this game, the racer can collect bananas
along the roadway. Each banana increases the top speed of your car. The player can also collect missiles to fire
forward at the leading cars. Each time you hit a car with a missile it not only slows the car’'s progress, but it jars
loose several bananas that one (as the trailer) can pick up. Thus, trailing players have tools that they can use to catch
the leaders even if the leader is not making any driving mistakes. The chief distinction between this and rubberbanding
is that the game is not modifying skills based on success. Instead, the rules of the game provide the trailing
player with known advantages over the leader.