Game Development Reference
In-Depth Information
The Powerup Class
The
Powerup
class is pretty simple, really. It is just an
Actor
that moves from the right to the left. We
have reviewed in other chapters how it appears to be spinning and how it flashes at the end of its
life. In this game, the interesting thing is the effect it has on a
Viper
. This feature is implemented in
the task
doHitOn:in:
, as shown in Listing 12-23.
Listing 12-23. Powerup.m (doHitOn:in:)
-(void)doHitOn:(Viper*)viper in:(GameController*)gameController{
if (self.variant == VARIATION_HEALTH){
[viper incrementHealth:30];
} else if (self.variant == VARIATION_DAMAGE){
[viper incrementDamage:gameController];
} else if (self.variant == VARIATION_CASH){
[gameController incrementScore:1000];
}
[gameController removeActor:self];
doHitOn:in:
of the class
Powerup
. This is called when a
Powerup
Viper
. The implementation could not be more straightforward: we simply check the
Powerup
and apply the correct effect. For
VARIATION_HEALTH
, we increment the
Viper's
VARIATION _DAMAGE
, we increment the
Viper's damage
. Lastly, for
VARIATION_CASH
,
Actors
the way we do. It turned out to be a strong OO model.
Summary
In this chapter, we brought together all of the techniques we have discussed in this topic. We
started by exploring what our game, Belt Commander, is and how it is played. We then reviewed
the flow of the application and looked at how we used the
UINavigationController
class to
implement switching between views. We continued by looking at the class
BeltCommanderController
and learned how to implement the major parts of the game. Lastly, we looked at a few specific
implementation choices that added life to our
Actors
.
When creating a game, there will always be unique code and techniques involved. Each game is one
of a kind and requires a unique effort to bring it to life. It would be impossible to write a book that
explains every possible challenge a game developer can face. However, many developers and game
designers are going to face requirements that are very similar to what I have outlined here. It is my
hope that this topic shows how to work through a number of these common challenges. From the
most basic issue of switching screens and saving user data, to the more complex topics like particle
animations and in-app purchases, I think of this topic as a map of the code and classes that are the
infrastructure of a game. Ultimately, it is up to each developer to fill in the middle parts and create a
new game. Thank you for reading this topic.
