Actor

The Actor class represents anything that is dynamic in a game. In our example, the ship, asteroids, saucers, power-ups, health bars, particles, and bullets are all actors. When creating a game, a subclass of GameController will handle the big details about the game, but it is the subclasses of Actor that provide the unique and interesting behaviors of each item in the game. In practice, each Actor in the game is a composition of its properties, how it is drawn (Representation), how it behaves (Behaviors), and the custom code defined in a subclass. We will look at Representations and Behaviors after we look at the class Actor. The following is a list of the properties of an Actor and what each means.

• long actorId: The actorId is a unique number assigned to each Actor. This value can be used to provide a soft reference to Actors in the game.
• BOOL added/removed: The properties added and removed can be used to test if an Actor has successfully been added or removed from a game.
• CGPoint center: The property center defines the location of the center of the Actor in game coordinates.
• float rotation: The rotation property indicates the rotation of the Actor in radians.
• float radius: The radius of the Actor describes how big it is. Together, center and radius describe the area of the game occupied by the Actor.
• NSMutableArray* behaviors: The behaviors property is a collection of Behavior objects. A Behavior object describes some sort of aspect of an Actor. It might describe how it moves or when it is removed from the game. Each Behavior in the behaviors array will be applied to the Actor on each step of the game.
• BOOL needsViewUpdated: Throughout a step of the game, an Actor may undergo changes that require its UIView to be updated. These might include advancing the image that should represent it or a change in state. This flag informs the GameController that work is required to synchronize the Actor with its representation.
• NSObject<Representation> representation: Each Actor in the game requires an object conforming to Representation to describe how to create a UIView to represent it in the game. Representations are discussed in the next section.
• int variant: It is common to have Actors in a game that differ only slightly. Perhaps they are a different color or have a slightly different behavior. Since this is a common requirement, the property variant provides a simple way of distinguishing Actors of the same class.
• int state: The property state is used to describe the state of an Actor. This state can be anything, and is up to the subclass to define exactly what this indicates. The property state and variant work with the class ImageRepresentation to figure out which image should be used for an Actor.
• float alpha: The property alpha describes how opaque an Actor is. An Actor with an alpha of 0.0 is fully transparent, while an alpha value of 1.0 is fully opaque. Transparent regions in an Actor's representation are unaffected.
• BOOL animationPaused: The property animationPaused is used to pause any animation that is being applied to the Actor. It is up to the implementation of the animation to honor this value. ImageRepresentation will not update the image, in a sequence of images, used to represent an Actor if this property is true.

In addition to the properties that define an Actor, there are a handful of tasks that come with the class Actor. These are the following:

• -(id)initAt:(CGPoint)aPoint WithRadius:(float)aRadius AndRepresentation:(NSObject<Representation>*)aRepresentation: This task is the designated constructor for the class Actor. It requires that each Actor has a center, a radius, and a representation. All subclasses of Actor should be sure that this task gets called when the Actor is created.
• -(void)step:(GameController*)controller: The task step: is called once per game step by the GameController. Subclasses of Actor can provide custom logic in their implementation of this task.
• -(BOOL)overlapsWith: (Actor*) actor: The task overlapsWith: is used to test if an Actor occupies any of the same space as another Actor. This can be used to implement simple collision detection.
• -(void)addBehavior:(NSObject<Behavior>*)behavior: The task addBehavior: is a utility method for adding Behaviors to an Actor in a single step.

Representation

Each Actor has to describe how the GameController should render it. The protocol Representation (defined in Actor.h) describes how a GameController can get and update a UIView for each Actor. There are two concrete implementations of Representation: ImageRepresentation and VectorRepresentation. The class ImageRepresentation uses UIImages and UIImageViews to create a UIView suitable for presenting the Actor. The class VectorRepresentation draws the Actor dynamically using Core Graphics. The details for how ImageRepresentation are covered in Chapter 6, while the implementation of VectorRepresentation is covered Chapter 7. There are two tasks defined by the protocol:

• -(UIView*)getViewForActor:(Actor*)anActor In:(GameController*)aController: This task is called once shortly after an Actor is added to a GameController. It is responsible for creating and returning a UIView suitable for rendering the Actor.
• -(void)updateView:(UIView*)aView ForActor:(Actor*)anActor In:(GameController*)aController: This task is called whenever an Actor's needsViewUpdated property is true. This task should make any changes to the UIView required to make it accurately represent the Actor.

Behavior

When creating a game, a lot of different Actors will require very similar code to implement. While it is definitely possible to construct a class hierarchy that provides just the right code for each class, I find this cumbersome. One solution is the Behavior protocol and the classes that implement it. Each instance of the protocol Behavior is responsible for applying some logic to an Actor, one per step. The protocol Behavior defines a single task:

• -(void)applyToActor:(Actor*)anActor In:(GameController*)gameController;
• The task applyToActor:In: is implement by the classes that conform to this protocol to provide some sort of behavior to the Actors they are attached to. There are several implementations of Behavior included in the game Belt Commander; those are:
• LinearMotion: The class LinearMotion is used to move an Actor in a straight line during the game. The class provides several utility constructors to make it easy to define the motion based on a direction or a target point.
• ExpireAfterTime: The class ExpireAfterTime is used to remove an Actor after a given number of steps. This is handy for Particles, where you want to create them, add them to the scene, and then forget about them.
• FollowActor: This class is used to keep one Actor at a fixed distant from another Actor. This is used by the HealthBars attached to the Saucers to keep them together.

Now that we have reviewed the core classes used to create the game Belt Commander, it is time to look at the subclasses of the classes we just described to understand how we can extend and customize them to create the game Belt Commander.

BeltCommanderController: Getting Started

To understand how this game is implemented, we need to understand how the BeltComanderController gets set up to play the game. The following section provides an overview of the initial code required to get a game up and running. Let’s start with the header file for the class BeltCommanderController, as shown in Listing 12-7.

Listing 12-7. BeltCommanderController.h

@class BeltCommanderDelegate, BeltCommanderController;
 
@protocol BeltCommanderDelegate
@required
-(void)gameStarted:(BeltCommanderController*)aBeltCommanderController;
-(void)gameOver:(BeltCommanderController*)aBeltCommanderController;
@end
 
@interface BeltCommanderController : GameController{
    IBOutlet HealthBarView* healthBarView;
    IBOutlet UILabel* scoreLabel;
     
    GameParameters* gameParameters;
    Viper* viper;
     
    //achievement tracking
    int asteroids_destroyed;
}
@property (nonatomic, retain) IBOutlet NSObject<BeltCommanderDelegate>* delegate;
-(void)doNewGame:(GameParameters*)aGameParameters;
-(void)tapGesture:(UITapGestureRecognizer*)tapRecognizer;
 
-(void)doEndGame;
-(void)doAddNewTrouble;
-(void)doCollisionDetection;
-(void)doUpdateHUD;
-(void)checkAchievements;
 
-(Viper*)viper;
@end

In Listing 12-7, we see the header file for the class BeltCommanderController. As expected, the class extends GameController. It also defines a protocol called BeltCommanderDelegate. This protocol is implemented by RootViewController and is used to pass game state. There are two IBOutlets associated with this class. The first, HealthBarView, is the UIView subclass that is responsible for rendering the health bar at the upper right of the screen. The second, scoreLabel, is used to display the player’s score as the game is played.

In Listing 12-7, we see that there is a GameParameters object called gameParameters. This object is used to determine which types of Actors should be included in the game. The idea is that this game would be free and the player could purchase different types of Actors to make it more fun (and profitable). Such in-app purchases are discussed in Chapter 10. For this chapter, we are assuming all in-app purchases have been made.

The Viper object is used to keep a reference to the ship in the game. Since we will want easy access to this object, it makes sense just to keep a pointer to it, instead of searching for it in with the other Actors. The last field is called asteroids_destroyed and is used to track achievements, as described in Chapter 9.

There are a number of tasks associated with the class BeltCommanderController. The only ones we need to worry about at this point are doNewGame: and tapGesture:; the others we will cover as we go through the implementation. The task doNewGame: is called by RootViewController to start a new game—we will look at the implementation shortly. The task tapGesture: is called when a UITapGestureRecognizer detects a tap on the screen; we will see this shortly as well. More about how gestures work is covered in Chapter 8. Let’s focus on the setup first.

Understanding the Setup

There are few steps that we must take to get BeltCommanderController set up. Since we know that BeltCommanderController extends GameController, we know that it should implement a doSetup task, as shown in Listing 12-8.

Listing 12-8. BeltCommanderController.m (doSetup)

-(BOOL)doSetup{
    if ([super doSetup]){
        [self setGameAreaSize:CGSizeMake(480, 320)];
        [self setIsPaused:YES];
         
        NSMutableArray* classes = [NSMutableArray new];
        [classes addObject:[Saucer class]];
        [classes addObject:[Bullet class]];
        [classes addObject:[Asteroid class]];
        [classes addObject:[Powerup class]];
        [self setSortedActorClasses:classes];
         
        UITapGestureRecognizer* tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(tapGesture:)];
         
        [self prepareAudio: AUDIO_BLIP];
        [self prepareAudio: AUDIO_GOT_POWERUP];
        [self prepareAudio: AUDIO_VIPER_EXPLOSION];
        [self playBackgroundAudio: AUDIO_BC_THEME];
 
        [actorsView addGestureRecognizer:tapRecognizer];
        return YES;
    }
    return NO;
}

In Listing 12-8, we see the task doSetup as defined by the class BeltCommanderController. In this task, we define the size of the game to be 480x320, which happens to be the native size of the iPhone screen in points. We also set the property isPaused to YES, so nothing is animating until doNewGame: is called later. The next step is to indicate which classes of Actors we want easy access to as the game progresses. In this case, we specify the classes Saucer, Bullet, Asteroid, and Powerup. Keep in mind that there is only one Viper in the game, and we have a reference to it in the header file. The last thing we do is to create a UITapGestureRecognizer and add it to actorsView. In this way, the task tapGesture: will be called when the user taps on the screen. Before any of that can happen, we need to understand how a new game is created.

A New Game

Whether we are running the first game or the hundredth, they all start with the task doNewGame :, as shown in Listing 12-9.

Listing 12-9. BeltCommanderController.m (doNewGame:)

-(void)doNewGame:(GameParameters*)aGameParameters{
    gameParameters = aGameParameters;
     
    [self removeAllActors];
     
    [self setScore:0];
    [self setStepNumber:0];
    [self setScoreChangedOnStep:0];
     
    viper = [Viper viper:self];
    [self addActor:viper];
     
    asteroids_destroyed = 0;
     
    [self setIsPaused:NO];
    [delegate gameStarted:self];
}

In Listing 12-9, we see the task doNewGame:, which is called by the RootViewController to start a new game. In this task, we set the gameParameters for future reference. Then we have to reset this object so that it is ready for a new game. To remove all Actors, we call removeAllActors. We also want to reset the score, the number of steps, and the number of Asteroids destroyed. We also create a Viper object and store it in the variable viper. Once we are reset, we set isPaused to NO and inform the delegate that the game has started. Let’s take a look at how we handle input and then we will be ready to move beyond the setup.

Handling Input

As soon as isPaused is set to NO, the game is up and running. At this point, the only actor in the game is the Viper. Let’s take a moment to understand how we intercept input to make it move before the Asteroids and aliens show up. The task tapGesture: is shown in Listing 12-10.

Listing 12-10. BeltCommanderController.m (tapGesture:)

-(void)tapGesture:(UITapGestureRecognizer*)tapRecognizer{
    if (![self isPaused]){
         
        CGSize gameSize = [self gameAreaSize];
        CGSize viewSize = [actorsView frame].size;
        float xRatio = gameSize.width/viewSize.width;
        float yRatio = gameSize.height/viewSize.height;
         
        CGPoint locationInView = [tapRecognizer locationInView:actorsView];
        CGPoint pointInGame = CGPointMake(locationInView.x*xRatio, locationInView.y*yRatio);
        [viper setMoveToPoint: pointInGame within:self];
    }
}

In Listing 12-10, we see the task tapGesture: that is called when the user taps the screen. In this task, after checking if we are paused, we have to convert the point of the touch into game coordinates. On the iPhone, this is not strictly necessary because the view actorsView is the same number of points wide and high as the size of our game. However, when we play this game on the iPad, the actorsView is 1024x682, while our game is still 640x480. In order to convert from one coordinate space to the other, we divide the game width by the width of actorsView and multiply it by the X location of the touch. We repeat the process for the height and Y value. Once we have the point figured out, we call setMoveToPoint:within: on Viper, which sets it in motion. We will look at the implementation of setMoveToPoint:within: when we take a closer look at the class Viper in the next section.

We have covered all there is to know about getting BeltCommanderController setup to play the game. Everything is ready to start processing user input and adding new Actors to the mix. The following section describes how BeltCommanderController checks for an end condition, adds Actors, and performs other task appropriate for the BeltCommanderController class.

Adding Actors

We know from experience that Actors are added by calling addActor :. However, to make a game, we have to include some logic that dictates when and how an Actor is added. Let’s continue and see how we add new Actors to the game in the task doAddNewTrouble, as shown in Listing 12-13.

Listing 12-13. BeltCommanderController.m (doAddNewTrouble)

-(void)doAddNewTrouble{
    if ([gameParameters includeAsteroids] && arc4random() % (5*60) == 0){
        if ([[self actorsOfType:[Asteroid class]] count] < 20){
            [self addActor:[Asteroid asteroid:self]];
        }
    }
    if ([gameParameters includeSaucers] && arc4random() % (10*60) == 0){
        if ([[self actorsOfType:[Saucer class]] count] < 3){
            [self addActor:[Saucer saucer:self]];
        }
    }
    if ([gameParameters includePowerups] && arc4random() % (20*60) == 0){
        [self addActor:[Powerup powerup:self]];
    }
}

In Listing 12-13, we see the task doAddNewTrouble that is responsible for adding new Actors to the game. For each of three types of Actors we might add, we first check to see if gameParameters indicates that we should add it. If gameParameters indicates that we should add an Actor of a particular type, we perform a random check to see if we actually add it. For example, Asteroids have a 1 in 300 chance to be added. To add each Actor we create it and call addActor:. The Actor’s constructor handles the details of how and where each Actor is created. We will now move on and examine how Actors interact with each other.

Collision Detection

Now we know how each Actor is added to the scene. Let’s move on and look at how they interact. If we consider the five main Actors in this game, there are several interactions that must be considered, as follows:

• Bullets and Asteroids
• Asteroids and the Viper
• Bullets and the Viper
• Bullets and Saucers
• Powerups and the Viper

These interactions are handled in the task doCollisionDetection, the first part of which is shown in Listing 12-14.

Listing 12-14. BeltCommanderController.m (doCollisionDetection, part 1)

-(void)doCollisionDetection{
    NSSet* bullets = [self actorsOfType:[Bullet class]];
    NSSet* asteroids = [self actorsOfType:[Asteroid class]];
    NSSet* saucers = [self actorsOfType:[Saucer class]];
    NSSet* powerups = [self actorsOfType:[Powerup class]];
     
    for (Asteroid* asteroid in asteroids){
        for (Bullet* bullet in bullets){
            if ([bullet overlapsWith:asteroid]){
                [bullet decrementDamage: self];
                 
                asteroids_destroyed++;
                [asteroid doHit:self];
                [self incrementScore: [asteroid level]*10];
                break;
            }
        }
        if ([asteroid overlapsWith:viper]){
            [viper decrementHealth: [asteroid level]*2];
             
            Shield* shield = [Shield shieldProtecting:viper From: asteroid];
            [self addActor:shield];
             
            asteroids_destroyed++;
            [asteroid doHit:self];
        }
    }

In Listing 12-14, we see the first part of the task doCollisionDetection where we handle the interaction concerning Asteroids. The first thing we do in this task is to get a reference to all of the different Actors we are going to need to interact with. Once we have reference to all of the Asteroids, Bullets, and the Viper, we can start testing to see if there are collisions. Inside the outermost loop in Listing 12-14, we start by testing to see if each Asteroid overlaps with each Bullet. If they do, we have the bullet decrement the Asteroid’s damage, which usually removes the Asteroid from the game, but more on that later. We also record that we have destroyed another Asteroid before calling doHit; on the Asteroid. Lastly, we increment the score.

In Listing 12-14, after we have considered the relation between each Asteroid and Bullet, we check to see if the Asteroid is overlapping the Viper. If it is, we decrement the health of the Viper and add a Shield to the scene. The Shield is an Actor that is just decoration and has no game function beyond that; it looks like a shield went up to protect the spaceship.

Let’s look at the rest of the doCollisionDetection task and understand how the rest of the inter-Actor relationships are handled. The task continues in Listing 12-15.

Listing 12-15. BeltCommanderController.m (doCollisionDetection, part 2)

    for (Bullet* bullet in bullets){
        if ([[bullet source] isKindOfClass:[Saucer class]]){
            if ([viper overlapsWith: bullet]){
                [viper decrementHealth: [bullet damage]];
                 
                Shield* shield = [Shield shieldProtecting:viper From: bullet];
                [self addActor:shield];
                 
                [self removeActor:bullet];
                break;
            }
        } else {
            for (Saucer* saucer in saucers){
                if ([saucer overlapsWith: bullet]){
                    [saucer decrementHealth:[bullet damage]];
                    Shield* shield = [Shield shieldProtecting:saucer From:bullet];
                    [self addActor:shield];
                    [self removeActor:bullet];
                    break;
                }
            }
        }
    }
     
    for (Powerup* powerup in powerups){
        if ([powerup overlapsWith:viper]){
            [self playAudio:AUDIO_GOT_POWERUP];
            [powerup doHitOn:viper in:self];
        }
    }
}

In Listing 12-15, we continue looking at the task doCollisionDetection. While iterating over all of the Bullets, we start by considering the interactions between Bullets and the Vipers. We do this by checking the source property on the Bullet. If the source was a Saucer, then the Bullet was intended for the Viper and cannot hurt a Saucer. If the Bullet overlaps with the Viper, we decrement the Viper's health, add a Shield, and remove the Bullet from the game.

If the Bullet was not shot by a Saucer, it must have come from the Viper. So we check to see if the Bullet overlaps with any of the Saucers. If it does, we decrement the health of the Saucer, add a Shield to the Saucer, and remove the Bullet.

The last relationship we have to consider in doCollisionDetection is that between Powerups and the Viper. We iterate over all of the Powerups in the game and check if they overlap. If they do, we call doHitOn:in: on the Powerup to apply the bonus. The implementation of doHit:in: will be described when we consider the Powerup class in detail.

We have now looked at all of the interactions between the different Actors. Before looking at each of the different Actor classes, let’s take a look how we update the score and the health bar on the screen.

Updating the HUD

For every step of the game, the score or the health meter might change. Collectively, these two components are called the heads-up display (HUD). Looking back to Listing 12-7, we see that these two components are connected to the BeltCommanderController though an IBOutlet. We see that the scoreLabel is a simple UILabel, but the class HealthBarView is unfamiliar. We will discuss the class HealthBarView in a moment; first, let’s look at the code that updates these components in the task doUpdateHUD, as shown in Listing 12-16.

Listing 12-16. BeltCommanderController.m (doUpdateHUD)

-(void)doUpdateHUD{
    if ([self stepNumber] == [self scoreChangedOnStep]){
        [scoreLabel setText: [[NSNumber numberWithLong:[self score]] stringValue] ];
    }
    [healthBarView setHealth:[viper health]/[viper maxHealth]];
}

In Listing 12-16, we see the task doUpdateHUD that is called for every step of the game. In this task, we check to see if the current stepNumber is equal to the property scoreChangedOnStep. The property scoreChangedOnStep is the value of stepNumber when the score was last updated. So, if stepNumber is equal to scoreChangedOnStep, we know that the score was changed in this step and, hence, scoreLabel needs to be updated. To update scoreLabel, we simply call setText: and pass in an NSString version of the score.

In Listing 12-16, we also call setHealth: on healthBarView to update how the health bar is drawn. The object healthBarView is of type HealthBarView, which is simply a UIView with a custom drawRect: task, as shown in Listing 12-17.

Listing 12-17. HealthBarView.m (drawRect:)

- (void)drawRect:(CGRect)rect
{
    [self setDefaults];
    int index = 0;
     
    float marker = [[percents objectAtIndex:index] floatValue];
     
    while (percent > marker) {
        marker = [[percents objectAtIndex:++index] floatValue];
    }
     
    UIColor* baseColor = [colors objectAtIndex:index];
    const float* rgb = CGColorGetComponents( baseColor.CGColor );
 
     
    UIColor* frameColor = [UIColor colorWithRed:rgb[0] green:rgb[1] blue:rgb[2] alpha:.8f];
    UIColor* healthColor = [UIColor colorWithRed:rgb[0] green:rgb[1] blue:rgb[2] alpha:.5f];
     
    [frameColor setStroke];
    [healthColor setFill];
     
    CGSize size = [self frame].size;
    CGContextRef context = UIGraphicsGetCurrentContext();
     
    CGRect frameRect = CGRectMake(1, 1, size.width-2, size.height-2
                                  );
    CGContextStrokeRect(context, frameRect);
     
    CGRect heatlhRect = CGRectMake(1, 1, (size.width-2)*percent, size.height-2);
    CGContextFillRect(context, heatlhRect);
}

In Listing 12-17, we see the task drawRect: of class HealthBarView. In this task, we draw two rectangles. The first rectangle is filled and the second is just an outline. Besides just drawing the rectangles, we want to adjust the color of the rectangles to reflect how damaged the ship is. To figure out which color we should use as our baseColor, we iterate through the NSArray percents until the percent we are going to draw is higher than the percent at index.

Once we have our base color, we create two modified colors from it. The first is the color frameColor used for the outline of the health bar; it has an alpha of 0.8. The second color is healthColor and will be used to draw the interior of the health bar; it has an alpha of 0.5.

To draw the rectangles, we first define them by calling CGRectMake. Once the CGRect is created, we call CGContextStrokeRect and CGContextFillRect, respectively.

We have looked at the class BeltCommanderController and know it works. In the next section, we will consider the four main actors and understand how they have the features that they do.

Implementing the Actors

We have reviewed how the class BeltCommanderController handles the big picture. It controls how and when Actors are created, and it manages the interactions between them. However, a lot of the functionality of the game is implemented in the classes that make up the different Actors. In this section, we will take each of the four main Actors and understand what the key customizations are to make them work the way we want. In several earlier chapters, we have implemented Actors of different types. In that light, we are only going to look at the bits of code that make each interesting feature of the Actor work. If you would like a refresher on how to implement Actors, check out Chapters 6 and 7. Also, you can always look at the full source code. Let’s start with the class Viper.

The Viper Actor

The Viper class represents the spaceship at the left side of the screen. This is the Actor that the user controls to achieve a high score. The Viper fires Bullets continuously to the right. To move the Viper, the user taps the screen, indicating a point above or below the Viper where it should travel. When traveling, the graphic changes to show thrusters on the top or bottom of the craft. Also, a Viper can intercept a Powerup that improves its guns. Lastly, the Viper has a fixed amount of health that slowly regenerates. In summary, the key features of the Viper are as follows:

• Moves to a point specified by user.
• Thrusters fire when ship moves.
• Fires bullets continuously.
• Improves quality of bullets when “powered up.”
• Has a health value that regenerates.

Let’s take a look at the source code and see how we implement these features, starting with the header file for context, as shown in Listing 12-18.

Listing 12-18. Viper.h

enum{
    VPR_STATE_STOPPED = 0,
    VPR_STATE_UP,
    VPR_STATE_DOWN,
    VPR_STATE_COUNT
};
 
@interface Viper : Actor <ImageRepresentationDelegate, LinearMotionDelegate>{
    LinearMotion* motion;
     
    long lastStepDamageWasModified;
}
@property (nonatomic) float health;
@property (nonatomic) float maxHealth;
@property (nonatomic) long lastShot;
@property (nonatomic) long stepsPerShot;
@property (nonatomic) BOOL shootTop;
@property (nonatomic) int damage;
 
+(id)viper:(GameController*)gameController;
-(void)setMoveToPoint:(CGPoint)aPoint within:(GameController*)gameController;
-(void)incrementHealth:(float)amount;
-(void)decrementHealth:(float)amount;
-(void)incrementDamage:(GameController*)gameController;
-(void)decrementDamage:(GameController*)gameController;
@end

In Listing 12-18, we see the header file for the class Viper. In this file, we see that we define an enum with three states. This is very much like the enums we have declared in the past to specify the state of an Actor. Looking at the properties, we can see that we have a property for health and maxHealth. We also have a property called lastShot, which will be used to keep track of whether it is time to shoot another Bullet in conjunction with the property stepsPerShot. The BOOL property shootTop is used to keep track if the next Bullet should come from the top of the Viper or not. The last property damage indicates the damage value of the next Bullet.

The tasks in Listing 12-18 are pretty mundane. There are four tasks for incrementing and decrementing health and damage. Each keeps the value of health and damage within a reasonable range. The interesting task is setMoveToPoint:within:, as shown in Listing 12-19.

Listing 12-19. Viper.m (setMoveToPoint:within:)

-(void)setMoveToPoint:(CGPoint)aPoint within:(GameController*)gameController{
    if (motion){
        [[self behaviors] removeObject: motion];
    }
    CGPoint point = CGPointMake([self center].x, aPoint.y);
     
    if (point.y < self.center.y){
        [self setState:VPR_STATE_UP];
    } else if (point.y > self.center.y){
        [self setState:VPR_STATE_DOWN];
    }
 
   
    motion = [LinearMotion linearMotionFromPoint:[self center] toPoint:point AtSpeed:1.2f];
    [motion setDelegate:self];
    [motion setStopAtPoint:YES];
    [motion setPointToStopAt:point];
     
    [motion setStayInRect:YES];
    CGSize gameSize = [gameController gameAreaSize];
    [motion setRectToStayIn:CGRectMake(63, 31, 2, gameSize.height - 63)];
     
    [motion setWrap:NO];
     
    [[self behaviors] addObject:motion];
     
}

In Listing 12-19, we see the task setMoveToPoint:within:. In this task, the goal is to set up a LinearMotion object that will move the Viper to the specified point. The first step is to see if we have an existing LinearMotion object stored at the variable motion. If so, we want to remove it from our active set of behaviors. The next step is to create a new CGPoint called point, based on the CGPoint that was passed in. Because this method will accept a point from any place in the game, we have to find a point that keeps the Viper horizontally fixed. Once we know where our point is, we can set our state to either VPR_STATE_UP or VPR_STATE_DOWN.

Creating the new LinearMotion is as simple as passing the Viper's current center and point to the constructor linearMotionFromPoint:toPoint:AtSpeed:. Setting self as the delegate, and telling it to stop when it reaches the specified point, further modifies the LinearMotion. The last modification is to set LinearMotion so that it stays within the specified rectangle. This prevents the Viper from going outside the bounds of the screen.

We have looked at how the Viper moves about the screen. The rest of the interesting features are implemented in the task step:, as shown in Listing 12-20.

Listing 12-20. Viper.m (step:)

-(void)step:(GameController*)gameController{
    long stepNumber = [gameController stepNumber];
    if (stepNumber - lastShot > stepsPerShot - damage){
         
        [gameController playAudio:AUDIO_BLIP];
 
        CGPoint center = [self center];
        CGSize gameSize = [gameController gameAreaSize];
         
        float offset;
        if (shootTop){
            offset = −15;
        } else {
            offset = 15;
        }
         
        CGPoint bCenter = CGPointMake(center.x + 20, center.y + offset);
        CGPoint bToward = CGPointMake(gameSize.width, bCenter.y);
         
        Bullet* bullet = [Bullet bulletAt:bCenter TowardPoint:bToward From:self];
        [bullet setDamage:damage];
        [gameController addActor:bullet];
         
        shootTop = !shootTop;
        lastShot = stepNumber;
    }
    if (stepNumber % 60 == 0){
        [self incrementHealth:1];
    }
    if (lastStepDamageWasModified + 10*60 == stepNumber){
        [self decrementDamage:gameController];
    }
}

In Listing 12-20, we see the task step:, which is called for every step of the game. We do a number of things in this task; primarily, we figure out if a Bullet should be shot and, if so, shoot it. But we also regenerate our health and keep track of whether we are still under the influence of a Powerup. To figure out if we should fire a Bullet, we see if stepNumber minus lastShot is greater than stepsPerShot minus damage. In this way, we fire more often if damage is higher, which happens when a Powerup has given the Viper extra damage.

To fire a Bullet, we figure out if the Bullet should come from the top or the bottom of the ship. Then it is just a matter of creating the CGPoints that describe its motion. Lastly, we clean up by flipping the value of shootTop and set lastShot to stepNumber.

In Listing 12-20, we also increase our health. This is done by calling incrementHealth every 60 frames. Calculating if we should decrement our damage is done by checking when our damage was last increased and calculating if 600 frames (∼10 seconds) have passed.

All in all, very little is required to get our Viper class to do what we want. Let’s move on the Asteroid class.

The Asteroid Class

The Asteroids are the primary opponents in Belt Commander (presumably, the word belt in the title refers to an asteroid belt). These Actors start on the right and travel to the left. When they reach the left side, they start over again on the right. We have used the variations of the Asteroid class several times in this book, and they are well documented. However, the feature that makes the Asteroid interesting is how it breaks up into multiple, smaller asteroids while shooting Particles. This code was modified from previous examples, and is shown in Listing 12-21.

Listing 12-21. Asteroid.m (doHit:)

-(void)doHit:(GameController*)controller{
    if (level > 1){
        int count = 1;
        float percent = arc4random()%1000/1000.0f;
        if (percent > 0.9){
            count = 3;
        } else if (percent > 0.5){
            count = 2;
        }
        for (int i=0;i<count;i++){
             
            float radius = [self radius];
             
            float rx = arc4random()%1000/1000.0*radius*2 - radius;
            float ry = arc4random()%1000/1000.0*radius*2 - radius;
            CGPoint newCenter = CGPointMake(self.center.x + rx, self.center.y + ry);
             
            Asteroid* newAst = [Asteroid asteroidOfLevel:level-1 At: newCenter];
            [controller addActor:newAst];
        }
    }
     
    int particles = arc4random()%4+1;
    for (int i=0;i<particles;i++){

ImageRepresentation* rep = [ImageRepresentation imageRepWithDelegate:[AsteroidRepresentationDelegate instance]];
        Particle* particle = [Particle particleAt:self.center WithRep:rep Steps:25];
        [particle setRadius:6];
        [particle setVariant:arc4random()%AST_VARIATION_COUNT];
        [particle setRotation: (arc4random()%100)/100.0*M_PI*2];
         
        LinearMotion* motion = [LinearMotion linearMotionRandomDirectionAndSpeed];
        [particle addBehavior:motion];
         
        [controller addActor: particle];
    }
    [controller removeActor:self];
}

In Listing 12-21, we see the task doHit: as implemented by the class Asteroid. In this task, we check to see if the Asteroid we are working with is above level one. If it is, then we need to create sub-Asteroids to replace this one. In other examples, we just randomly picked a number of child Asteroids to create. However, while play-testing Belt Commander, this was unsatisfactory because the number of Asteroids generated was way too high. To reduce the number of Asteroids created, a percentage was given for each possible value of count. So only 10 percent of the time an Asteroid will create three children Asteroids; 40 percent of the time there will be two children Asteroids; the rest of the time only a single Asteroid is created. In this way, the game is balanced, keeping it fun and playable.

The other interesting thing about the task doHit:, as shown in Listing 12-21, is how it creates Particles to emphasize the destruction of the parent Asteroid. By creating 1 to 5 Particles that look just like Asteroids and sending them out in random directions, we make a very pleasing Asteroid destruction.

Let’s continue and explore a little about the class Saucer.

The Saucer Class

The Saucer class is mostly a troublemaker. It appears at either the top or the bottom of the screen, shooting Bullets at the Viper. What makes the Saucer class troublesome is that the Bullets most often break apart Asteroids, creating an unpredictable pattern. The implementation of the Saucer class in this chapter is much likes its implementation in the other chapters. However, some modification was made to the step: task as shown in Listing 12-22.

Listing 12-22. Saucer.m (step:)

-(void)step:(GameController*)gameController{
    if (health <= 0){
        [gameController incrementScore:[self radius]*10];
        [gameController removeActor:self];
        return;
    }
     
    CGSize gameAreaSize = [gameController gameAreaSize];
    CGPoint center = [self center];
     
    if (center.y < −[self radius]){
        [linearMotion setDirection:DIRECTION_DOWN];
    } else if (center.y > gameAreaSize.height + [self radius]){
        [linearMotion setDirection:DIRECTION_UP];
    }
    if (arc4random()%180 == 0){
        BeltCommanderController* bc = (BeltCommanderController*)gameController;
         
        [gameController addActor:[Bullet bulletAt:[self center] TowardPoint:[bc viper].center From:self]];
    }
}

In Listing 12-22, we see the implementation of the class step: from the class Saucer. In this task, we check to see if the Saucer's health is below zero. If it is, we increment the gameControllers score and remove the Saucer from the game. The next part of the task step: is to determine if the Saucer should change direction on account of going off the screen. The last section of the task step: is responsible for shooting Bullets. In order to do this, we get the viper property of the gameController so we can target the Bullet on it. This is the first case where we had to cast gameController to BeltCommanderController. It raises the question of how we might add a general way to reference particular actors (like Viper) without depending on class definition. But, this is an exercise for another time.

The last Actor we are looking at is Powerup.

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];
}

In Listing 12-23, we see the task doHitOn:in: of the class Powerup. This is called when a Powerup collides with the Viper. The implementation could not be more straightforward: we simply check the variant of the Powerup and apply the correct effect. For VARIATION_HEALTH, we increment the Viper’s health by 30. For VARIATION _DAMAGE, we increment the Viper's damage. Lastly, for VARIATION_CASH, we just increment the score by 1,000. I think the simplicity of this task is a direct byproduct of using Actors the way we do. It turned out to be a strong OO model.