Game Development Reference
In-Depth Information
Figure 6-5 . The pause button will run the shouldPauseGame selector
There's also a Continuous check box that you should not check; if you check it, the button
would run the selector once every frame as long as the user keeps a finger on the button.
This can be useful for a rapid fire or d-pad button, but here it is undesirable.
Tip I like to prefix user-initiated actions with “should” because they can be
seen as a request, not a command that must be obeyed indiscriminately. If that
sounds contradictory, consider a platformer game where you can jump and
double-jump, with the jump button always being active. The user requests a
jump by having the jump button run the shouldJump selector. The method
first checks if the player is on ground, and if so, initiates the jump. If the request
is sent when the player is in the air, the shouldJump selector will either initi-
ate a double-jump or ignore the request.
It is best practice to double-check all user interactions for validity. For instance,
if you didn't instantly disable the pause button when pressed, the user might tap
the pause button a second time accidentally, potentially causing issues like run-
ning the animation twice. Naming selectors with the “should” prefix is therefore
a nice indicator that an action should be performed but can also be denied or in-
terpreted differently based on certain conditions.
Assigning the GameMenuLayer Class and Ivar
The button's shouldPauseGame selector is sent to the Document root . The document
root is the root node of GameMenuLayer.ccb . Therefore, the root node of GameMenuLay-
er.ccb needs to have a custom class where the selector can be implemented.
Search WWH ::




Custom Search