Game Development Reference
In-Depth Information
User Selects
App
Is Game
View?
Already
Running?
YES
NO
Load Screen
YES
Pause
Game
NO
Is Game
Archived?
NO
YES
Welcome
View
Play View
Other View
Add
Continue
Option
Key
Offpage
Connector
Note
Decision
View
Start
Application Flow
Initialization life cycle of our example application
In Figure
3-11
, we see that all applications start by the user's clicking on the application icon. From
there, one of two things happen: either the application, if already running in the background, will be
brought to the foreground; or the application will start fresh. If the application was already running,
it will show up on the screen exactly as the user left it; no code is required on our part to reestablish
state. In an action game, you might want to pause the game when the application is brought to the
foreground; this will give the user a chance to reorient before play resumes. Either way, we return to
the application flow presented in Figure
3-1
.
If the application was not already running, we show the load screen as normal, and then we check
to see if the game state was archived. If yes, we want to unarchive the game state and show the
Continue button. We then continue with the flow presented in Figure
3-1
. To support the case where
we need to unarchive the game state, we obviously need to archive it at some point. Let's start by
looking at the archive logic, and then looking at the unarchive logic.
Archiving and Unarchiving Game State
In our sample application, we store the state of our game in a class called
CoinsGame
. We are going
to save some of the implementation details of this class for the next chapter, but because we know
it is being archived and unarchived, we know it probably conforms to the
NSCoding
protocol. And
indeed it does—Listing 3-17 shows the implementation of the two
NSCoding
tasks.
