Game Development Reference
In-Depth Information
return YES;
}
return NO;
}
Here you can see the setup code for the class
GameController
. Because we want to set up a
GameController
only once, we put the setup code inside an if-statement governed by the variable
isSetup
. The
isSetup
task will return YES if setup was performed, and return NO if setup was not
performed.
As for the actual setup of the class, we have to initialize several variables. We start by setting the
property
gameSizeArea
to a default size. Then we initialize the collection's actors,
actorsToBeAdded
,
and
actorsToBeRemoved
. Finally, we set the
stepNumber
to zero.
displayLinkCalled
and
updateScene
CADisplayLink
. In this chapter, we set up the
slightly differently from previous examples. Instead of having the
CADisplayLink
call
directly, we have it call
displayLinkCalled
, which in turn calls
updateScene
, as shown in
GameController.m (displayLinkCalled)
if (workComplete){
workComplete = false;
@try {
[self updateScene];
workComplete = true;
}
@catch (NSException *exception) {
NSLog(@"%@", [exception reason]);
NSLog(@"%@", [exception userInfo]);//break point here
}
}
}
The task
displayLinkCalled
calls
updateScene
only if the variable
workComplete
is true. The variable
workComplete
can be true only if this is the first time
displayLinkCalled
is called or if
updateScene
has completed successfully. If
updateScene
throws an exception, it is logged, and
workComplete
is
not reset to true. This, in effect, causes the game to stop if there are any errors. This is desirable
because exceptions raised by tasks called by
CADisplayLink
are silently swallowed. To facilitate
debugging the task
displayLinkCalled
, it is required to both log the exception and halt the game,
letting the tester know that something has gone wrong. In production, you may wish to change this
behavior; it might be better to keep the app moving even if there was an error. The exact behavior
required will depend on the application.
