Game Development Reference
In-Depth Information
back to the driving mode. Pressing the Start button on the controller while driving
brings up a pause menu, and so on. You need to document these details for the rest
of the development team.
To doc ument the str uct ure, you can begin by mak ing a list of all the modes and
menus in the game. You must also include a description of
when
and
why
the game
switches from one mode or menu to another: what event, or menu selection, causes
it to change. Each mode or menu description should include a list of other modes
and menus it can switch to and, for each possible switch, a notation about what
causes it.
NOTE
A video game
is always in either a
gameplay mode or a
shell menu or screen.
The gameplay modes
and shell screens,
and the relationships
among them, collec-
tively make up the
game structure.
You can document the relationships among all the modes and menus by simply
listing them all in a text editor. However, the result isn't easy to follow. A better
approach is to document the structure of a game with a
flowboard,
a combination
of flowchart and storyboard. This type of diagram is described in the section
“Flowboard,” later in this chapter.
Normally, a game moves among its shell menus in response to player actions and
nothing else, although arcade games often display an
attract loop
that repeatedly
shows a title screen, a short noninteractive video of a game in progress, and a
high score table. During actual play, a game changes from one gameplay mode to
another in response to player actions, or automatically as the circumstances of the
game require. For example, in a soccer game, certain violations of the rules result in
a penalty kick, in which a single athlete on one team tries to kick the ball past the
opposing team's goalie and into the goal and the other athletes on both teams play
no role. This is clearly a gameplay mode different from normal play. The game
enters the penalty kick mode not in response to a specific player choice but because
a rule has been violated.
Now that you have learned about the player-centric approach to game design and
the key components and structure of a video game, you are ready to start thinking
about how to go about designing one. Unfortunately, there are so many kinds of
video games in the world that it is impossible to define a simple step-by-step process
that produces a single design document all ready for people to turn into content
and code. Furthermore, unless a game is very small, it is not possible to create a
complete design and then code it up afterward. That is how the game industry built
games in the 1980s, but experience has shown that large games must be designed
and constructed in an iterative process, with repeated playtesting and tuning, and
occasional modifications to the design, throughout development. However, not all
parts of the design process can be revisited. Some, such as the choice of concept,
audience, and genre, should be decided once at the beginning and should not
change thereafter. The process is therefore divided into three major parts:
