Game Development Reference
In-Depth Information
You call the loadLevelsStatus method in the constructor of PlayingState so the updated level
information is used from local storage when the game starts. Whenever the player finishes a level,
you call the writeLevelsStatus method. That way, the next time the player starts the game, the
game will remember which levels the player has already completed.
An an exercise, try to extend the PenguinPairs4 example by storing more information. For example,
currently the game doesn't remember the player's preferences for the music volume or whether
hints should be shown. Can you create a version of the game that retains this information over
different sessions?
THE CURSE OF SAVED GAMES
Most games contain a mechanism that lets the player save their progress. This is normally used in one of three ways: to
continue playing later, to return to a previous save point when the player fails later in the game, or to exploit alternative
strategies or storylines. These possibilities all sound reasonable, but they also introduce problems; when you design a
game, you must carefully consider when (and how) to allow the player to save and load the game state.
For example, in older first-person shooters, all enemies were at fixed locations in the game world. A common strategy
among players became to save a game, run into a room to see where the enemies were (which led to instant death), load
the saved game, and, armed with the information about the location of the enemies, carefully clean out the room. This
made the game a lot easier to play, but it was definitely not the intention of the creators. This can be partially remedied by
making it difficult to save a game or to load a saved game. Other games only allow saves at particular save points. Some
even make reaching a save point part of the challenge. But this can lead to frustration because the player may have to
replay sections of the game over and over if there is one very difficult spot. The most interesting games are the ones
where you never have to return to save points because you never really fail, but this is extremely difficult to design.
So think carefully about your saving mechanism. When will you allow saves? How many different saves will you allow?
How does saving work in the game? How does the player load a saved game? Does it cost the player something to save
or load a game? All these decisions will influence the gameplay and player satisfaction.
What You Have Learned
In this chapter, you have learned:
How to create a tile-based game world
switch instruction to handle different cases
How to retrieve and store level-status data using local storage
How to use the
 
Search WWH ::




Custom Search