Game Development Reference
In-Depth Information
■
The pressure to reduce UI screen usage.
Using an icon instead of a text label
on a screen button saves space, and so does using a small icon instead of a large
one. But icons can't convey complicated messages as well as text can, and small,
simple icons are necessarily less visually distinctive than large, complex ones.
When you reduce the amount of space required by your UI, be sure you don't do so
to the point of making its functions obscure.
■
Developer familiarity with the material.
You
know what your icons mean and
how they work—you created them. That means you're not the best judge of how
clear they will be to others. Always test your UI on someone unfamiliar with your
game. See whether your test subjects can figure out for themselves how things
work. If it requires a lot of experimentation, your UI is too obscure.
Chapter 2 defined the
interaction model
as the relationship between the player's
inputs via the input devices and the resulting actions in the game world. You create
the game's interaction model by deciding how the player's controller-button presses
and other real-world actions will be interpreted as game world activities by the core
mechanics. The functional capabilities of the various input devices available will
influence your decisions (see “Input Devices” later in the chapter). There isn't room
here to discuss button assignments in detail, so you should play other games in
your genre to find examples that work well.
In practice, interaction models fall into several well-known types:
■
Avatar-based
, in which the player's actions consist mostly of controlling a single
character—his avatar—in the game world. The player acts upon the world through
the avatar and, more importantly, generally can influence only the region of the
game world that the avatar currently inhabits. An avatar is analogous to the human
body: To do something in our world, we have to physically take our bodies to the
place where we want to do it. That doesn't mean an avatar must be human or even
humanoid; a vehicle can be an avatar. To implement this mode, therefore, many of
your button-assignment decisions will center on navigation (see “Navigation
Mechanisms” later in the chapter).
■
Multipresent
(or
omnipresent
), in which the player can act upon several different
parts of the game world at a time. In order for him to do so, you must give him a
camera model that permits him to see the various areas that he can change; typi-
cally, an aerial perspective. Chess uses a multipresent interaction model; the player
may ordinarily move any of his pieces (which can legally move) on any turn.
Implementing this mode requires providing ways for the player to select and pick
up objects or give orders to units.
■
In the
party-based
interaction model, most commonly found in role-playing
games, small groups of characters generally remain together. In this model, you
will probably want to use point-and-click navigation and an aerial perspective.
