Game Development Reference
In-Depth Information
AUTOMATIC SAVE AND CHECKPOINTS
A few games automatically save the state of the game when the player exits, so play-
ers can leave and return at any time without explicitly saving. This harms the
player's immersion least of all, but if the player has recently experienced a disaster,
he has no way to recover from it. More often, games save whenever the player
passes a checkpoint, which may or may not be visible to him. Checkpoint saving is
less disruptive than quick-saving because the player never has to do anything. The
player
can
go back and undo a disaster, provided that the disaster happened after
the most recent checkpoint. But it means that the player can't choose to save when-
ever he wants or choose to restart at some earlier point. If the checkpoints occur
infrequently, he might lose a great deal of progress in the event of a disaster.
Although it's better for immersion from the player-centric standpoint, automatic
checkpoint saving is inferior to quick-saving. With quick-save, the player always
has the option
not
to save if for some reason he enjoys the risk of having to go back
a long way. With automatic checkpoints, he has no choice.
A few games offer optional checkpoint saving in which the player may choose to
save or not every time he reaches a checkpoint. This gives him a little more control
but still doesn't allow him to save at will, which is preferable.
To Save or Not to Save
A few designers don't allow players to save their games within certain regions of
the game or even to save at all. If the player can save and reload where he wants
and without limit, he can solve puzzles or overcome other obstacles by trial and
error rather than by skill, or he can use the saving system to avoid undesirable ran-
dom events; if something bad happens by chance, the player can reload the game
repeatedly until the undesirable event doesn't occur. This reduces the game's diffi-
culty, and some designers argue against allowing players to save on that basis.
That, however, is lazy game design. Preventing the player from saving adds diffi-
culty without adding fun. If you really want to make the game harder, devise
harder challenges. Forcing the player to replay an entire level because he made a
mistake near the end wastes his time and condemns him to frustration and bore-
dom—and that certainly is not player-centric game design.
You may not like it if a player repeatedly reloads a game to avoid a random event or
to solve some problem by trial and error rather than skill, but the player doesn't
play (or buy) the game to make you feel good. He might need to save the game for
perfectly legitimate reasons. The notion that saving makes a game too easy assumes
that the player is your opponent, a violation of the player-centric principle. Most
games now recognize that players want—and sometimes need—to cheat by offering
cheat codes anyway.
