This is a post by special contributor Andreas Loew, the creator of TexturePacker and PhysicsEditor.

Create this vertical scrolling platformer with Cocos2D!

Welcome back to the Monkey Jump tutorial! In this series, we are creating a fun vertical scrolling platformer with Cocos2D, TexturePacker and PhysicsEditor.

In Part One on the tutorial series, we introduced the MonkeyJump! game design, created the sprite sheets and shapes we needed, and began coding the game.

Before we stopped for a break, we had all of our game layers set up and had just finished making random objects drop from the sky, with sound effects.

In this second part of the tutorial, we will add our hero to the game, make him move and jump, and start adding some gameplay.

We’ll be starting with the project where we left off last time. If you don’t have it already, grab the source code for this tutorial series and open up 3-DraggingObjects.

Without further ado, let’s get back to (monkey) business! :]

Getting Started

We created the monkey’s shape in PhysicsEditor in Part One of this tutorial, but haven’t added the monkey to the game yet. Let’s do that now!

Add the Monkey class by creating a new file with the iOS\Cocoa Touch\Objective-C class template. Name the class Monkey, and make it a subclass of GB2Sprite. (Again, remember to change extension for the Monkey.m file to .mm)

The monkey will react to different events in the game world: he’ll put up his hands when something drops from above, push items, jump, etc. This is why you won’t be using Cocos2d’s standard animation routines, and instead implement some of your own.

For this, you need some member variables to store the additional data. Paste this code into Monkey.h replacing what’s there already:

    #pragma once
 
    #import "Cocos2d.h"
    #import "GB2Sprite.h"
 
    @class GameLayer;
 
    @interface Monkey : GB2Sprite
    {
        float direction;      // keeps monkey's direction (from accelerometer)
        int animPhase;        // the current animation phase
        ccTime animDelay;     // delay until the next animation phase is stated
        GameLayer *gameLayer; // weak reference
    }
 
    -(id) initWithGameLayer:(GameLayer*)gl;
    -(void) walk:(float)direction;
 
    @end

Now switch to Monkey.mm and replace it with the following lines:

    #import "Monkey.h"
    #import "GB2Contact.h"
    #import "GMath.h"
    #import "Object.h"
    #import "SimpleAudioEngine.h"
    #import "GameLayer.h"
 
    #define JUMP_IMPULSE 6.0f
    #define WALK_FACTOR 3.0f
    #define MAX_WALK_IMPULSE 0.2f
    #define ANIM_SPEED 0.3f
    #define MAX_VX 2.0f
 
    @implementation Monkey
 
    -(id) initWithGameLayer:(GameLayer*)gl
    {   
        // 1 - Initialize the monkey 
        self = [super initWithDynamicBody:@"monkey"
                    spriteFrameName:@"monkey/idle/1.png"];
 
        if(self)
        {
            // 2 - Do not let the monkey rotate
            [self setFixedRotation:true];
 
            // 3 - The monkey uses continuous collision detection
            // to avoid getting stuck inside fast-falling objects
            [self setBullet:YES];
 
           // 4 - Store the game layer
            gameLayer = gl;
        }
 
        return self;
    }
 
    @end

Let’s go through the initWithGameLayer method step-by-step:

1. First, we initialize the monkey. The monkey’s movement will be affected by the physics engine, so make him a dynamic object. We’ll use the idle frame as both the first frame of the monkey animation and the monkey’s physics shape.
2. The monkey should stand straight up all the time, so we set his rotation to fixed. This means the monkey is moved by Box2d, but does not rotate or tilt.
3. Set the monkey to bullet mode. Bullet mode enables continuous collision detection on an object. Without it, Box2d moves objects and then performs the collision checks. With fast-moving objects it’s possible that an object will pass through another without any collision detection at all or that an object will get stuck in another. Continuous collision detection calculates collisions all the way from an object’s current position to its new position – not just for the end point.
4. Finally, you need to store the game layer – keep it as a weak reference and just assign the value.

A monkey bullet! Bullet mode enables continuous collision detection.

With regards to bullet mode for step #3, if you were coding a project with only a few objects, you could set the Box2d engine to run continuous collision detection for all game objects. However, when a game has a lot of objects that would add a lot of CPU overhead. So, for our game we’ll set the continuous mode on just the monkey and fast-moving (dropping) objects.

To enable the monkey, add him to the GameLayer. Open GameLayer.h and add the following lines at the top, just below the import statements:

    @class Monkey;

Now, add the following member variable to the GameLayer class:

    Monkey *monkey;

Then switch to GameLayer.mm and import Monkey.h at the top of the file:

    #import "Monkey.h"

At the end of the init selector in GameLayer.mm, initialize the monkey, add him to the game layer and set a starting position for the monkey:

    monkey = [[[Monkey alloc] initWithGameLayer:self] autorelease];
    [objectLayer addChild:[monkey ccNode] z:10000];
    [monkey setPhysicsPosition:b2Vec2FromCC(240,150)];

Compile and run, and you’ll see the following:

The monkey is in the house! Objects drop onto him and he gets pushed away – perfect. That’s exactly what we want.

Do the Monkey Walk

Our next goal is to make the monkey walk, using the accelerometer as input.

Go back to GameLayer.mm and add the following code at the end of the init method:

    self.isAccelerometerEnabled = YES;

This will ensure that for each change in the built-in accelerometer values, the GameLayer class gets an automatic notification. The notification handler has to be added to GameLayer.mm at the end of the file, before the @end marker:

    - (void)accelerometer:(UIAccelerometer*)accelerometer 
            didAccelerate:(UIAcceleration*)acceleration
    {
        // forward accelerometer value to monkey
        [monkey walk:acceleration.y];
    }

The accelerometer handler calls the walk method of the monkey object with the y-axis value of the accelerometer. This method will handle actually moving the monkey back and forth based on the accelerometer input.

So, move to Monkey.mm and add the walk method to the end of the file (before the @end marker). This method simply stores the new movement direction for the monkey in a member variable.

    -(void) walk:(float)newDirection
    {
        direction = newDirection;
    }

Try compiling and running the code now … Surprise! Nothing new happens. This is due to the fact that while the direction value has been stored, it has not been applied to the physics simulation yet. In order to update the physics simulation based on the new movement direction, we need to override the updateCCFromPhysics selector, which is called by the GB2Engine on every frame for a GB2Node object to update the physics.

Update Monkey Physics

Add the following code to Monkey.mm:

    -(void) updateCCFromPhysics
    {
        // 1- Call the super class
        [super updateCCFromPhysics];
 
        // 2 - Apply the directional impulse
        float impulse = clamp(-[self mass]*direction*WALK_FACTOR, 
                              -MAX_WALK_IMPULSE, 
                              MAX_WALK_IMPULSE);            
        [self applyLinearImpulse:-b2Vec2(impulse,0) point:[self worldCenter]];        
    }

In the above, you first call the selector of the super class. This will update the monkey’s sprite based on physics simulation.

Then, you push the monkey in the right direction based on the stored direction value. It is important not to take complete control of the monkey. Otherwise, his “natural” behavior in response to events such as items dropping or collision detection won’t work properly.

All you really do is to give the monkey a nudge in the right direction. Since the physics engine updates happen 60 times per second, it’s important to keep the push quite light. It’s a monkey – not a bullet, even if he is in bullet mode!

You can move a box2D object by applying an impulse to the object. And you do this using the GB2Sprite’s applyLinearImpulse method, which takes two parameters: the impulse to apply and the point of application.

For the point of application, we’ll use the world center of the object. Applied at the world center, the object will be pushed without any torque that would result into a rotation. (Which, by the way, would not happen to the monkey anyway, since we already set him not to rotate.)

When applying an impulse, I recommend using the mass of the object, which you can get with [self mass]. This is because the impulse is the product of mass and velocity.

Multiply the mass value by the stored direction value. This gives you small impulses when the device is tilted slightly, and bigger impulses when its tilted sharply.

Scaling the impulse with the object’s mass frees us from having to worry about the movement changing when we change the object’s shape in PhysicsEditor. If we didn’t scale the impulse and later we made the monkey a bit smaller (for example), the same impulse applied to a monkey of less mass will result in a faster-moving monkey.

We will also clamp the value to a maximum to avoid impulses that are too strong. The maximum impulse is defined with the MAX_WALK_IMPULSE variable.

Compile and run. Still nothing? Ah, I forgot to tell you one thing: the iPhone simulator does not simulate the accelerometer. So, from now on, we need to test on the device! Switch to the device and test.

The monkey now slides left and right – but the movement doesn’t look very natural.

Make the Monkey Move

We’re going to add some code to Monkey.mm to get the monkey animations working. Add the following to the end of the updateCCFromPhysics method:

    animDelay -= 1.0f/60.0f;
    if(animDelay <= 0)
    {
        animDelay = ANIM_SPEED;
        animPhase++;
        if(animPhase > 2)
        {
            animPhase = 1;
        }
    }

The first line simply updates the time till the next animation by decreasing the time delay till the next animation phase. I use the value 1.0f/60.0f because I assume that the application runs at 60 fps and the updateCCFromPhysics method does not have a delta time parameter which would provide the timer interval between each update accurately.

If the animation time delay drops below zero, reset the animation delay value to the animation speed and increase the current phase by one. If the highest phase is reached, loop back to 1 so that the animation will continue to play in a loop.

Next, we need to determine the direction the monkey is facing. There are two ways to do this:

1. Use the direction from the accelerometer
2. Use the monkey’s velocity vector

I prefer to use the accelerometer, since it gives the player immediate feedback when he or she tries to change the direction by tilting the device. We’ll respond to velocity changes via accelerometer later.

Add this code to the end of updateCCFromPhysics:

    // determine direction of the monkey
    bool isLeft = (direction < 0);
 
    // direction as string
    NSString *dir = isLeft ? @"left" : @"right";    
 
    // update animation phase
    NSString *frameName;
    const float standingLimit = 0.1;
    float vX = [self linearVelocity].x;
    if((vX > -standingLimit) && (vX < standingLimit))
    {
        // standing
        frameName = [NSString stringWithFormat:@"monkey/idle/2.png"];            
    }
    else
    {
        // walking
        NSString *action = @"walk";
        frameName = [NSString stringWithFormat:@"monkey/%@/%@_%d.png", action, dir, animPhase];        
    }
 
    // set the display frame
    [self setDisplayFrameNamed:frameName];

Basically, all the code above does is, if the monkey’s speed is lower than standingLimit, it makes him look directly at the player with his idle animation frame. Otherwise, it uses a walk display frame matching the current direction and animation frame number.

Compile and run. The monkey now runs about – nice!

Slow Down Little Fella

I’m still not happy with one thing: I think the monkey moves too fast. We could reduce the impulse we’re applying to make him walk, but this will also make him slow and clumsy.

We need a strong enough impulse to make him react fast – but not too fast.

Replace the current code for updateCCFromPhysics in Monkey.mm with the following code:

    // 1 - Call the super class
    [super updateCCFromPhysics];
 
    // 2 - Update animation phase
    animDelay -= 1.0f/60.0f;
    if(animDelay <= 0)
    {
        animDelay = ANIM_SPEED;
        animPhase++;
        if(animPhase > 2)
        {
            animPhase = 1;
        }
    }
 
    // 3 - Get the current velocity
    b2Vec2 velocity = [self linearVelocity];
    float vX = velocity.x;
 
    // 4 - Determine direction of the monkey
    bool isLeft = (direction < 0);
 
    if((isLeft && (vX > -MAX_VX)) || ((!isLeft && (vX < MAX_VX))))
    {
        // apply the directional impulse
        float impulse = clamp(-[self mass]*direction*WALK_FACTOR, 
                              -MAX_WALK_IMPULSE, 
                              MAX_WALK_IMPULSE);            
        [self applyLinearImpulse:-b2Vec2(impulse,0) point:[self worldCenter]];        
    }
 
    // 5 - Get direction as string
    NSString *dir = isLeft ? @"left" : @"right";        
 
    // 6 - Update animation phase
    NSString *frameName;
    const float standingLimit = 0.1;
    if((vX > -standingLimit) && (vX < standingLimit))
    {
        // standing
        frameName = [NSString stringWithFormat:@"monkey/idle/2.png"];            
    }
    else
    {
        // walking
        NSString *action = @"walk";
        frameName = [NSString stringWithFormat:@"monkey/%@/%@_%d.png", action, dir, animPhase];        
    }
 
    // 7 - Set the display frame
    [self setDisplayFrameNamed:frameName];

As you’ll notice, we’ve moved a few code blocks around but the major change is the addtion of a new line to section #3 for the vX variable and moving the impulse code to section #4 to be wrapped within an if condition that checks if the velocity is below a maximum value for the current direction. This allows the monkey to steer against being pushed away by an object, but keeps him from accelerating too fast on his own.

Compile and run. I thinks this looks much better now.

The source code of the project in its current state is available in the folder 4-WalkingMonkey.

Jump, Jump!

Now, let’s make the monkey jump. For this, we need to make the game detect touch events anywhere on the GameLayer, because we want the monkey to jump at every touch.

Open GameLayer.mm and enable touch detection by adding the following line to the init selector:

    // enable touches
    self.isTouchEnabled = YES;

Also add the following selector at the end of the file (but before the @end marker). It forwards the touches to the monkey object via the jump method.

    -(void)ccTouchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
    {
        [monkey jump];    
    }

You might notice at this point that we don’t have a jump method in the Monkey class. That’s what we’ll add next. Switch to Monkey.h and add the following method definition just before @end:

    -(void) jump;

Now open Monkey.mm and add the following code before the @end marker:

    -(void) jump
    {
        [self applyLinearImpulse:b2Vec2(0,[self mass]*JUMP_IMPULSE) 
              point:[self worldCenter]];   
 
        [[SimpleAudioEngine sharedEngine] playEffect:@"jump.caf" 
              pitch:gFloatRand(0.8,1.2)
              pan:(self.ccNode.position.x-240.0f) / 240.0f 
              gain:1.0 ];
    }

All the above code does is to apply an impulse to make the monkey jump and play the jump sound. We’ll pan the sound as we did for the object sounds in Part One of this tutorial.

Compile and run. Tap the screen to make the monkey jump.

Outta Sight!

But this is far from perfect: if you tap the screen multiple times, the monkey goes through the roof! Worse still, the camera does not follow the monkey.

Let’s fix the camera first. First, add the following code to the top of the update selector, above the existing code, in GameLayer.mm.

    // 0 - monkey's position
    float mY = [monkey physicsPosition].y * PTM_RATIO;

The above code copies the monkey’s y-position into a new variable mY. Of course, we could also access the monkey’s ccNode and take the y-coordinate from there. The end result will be the same as multiplying his physics position by the PTM_RATIO.

Now, add these lines to the end of the update selector after the closing curly brace after section #7.

    // 8 - Adjust camera
    const float monkeyHeight = 70.0f;
    const float screenHeight = 320.0f;
    float cY = mY - monkeyHeight - screenHeight/2.0f; 
    if(cY < 0)
    {
        cY = 0;
    }

Here, we calculate a good value for the camera’s y-coordinate, one that will more or less center the monkey on the middle of the screen. Clamp the value so that it does not go below 0 so that the camera does not move below ground level.

Now let’s implement parallax scrolling of the background so that the monkey’s movement appears more natural. The effect is quite easy to accomplish: just multiply the background layer by a factor below 1.0 and set the position for the layers. This will make the background layer scroll slower. The further away a layer is from the camera, the smaller the factor must be.

Add this code below the last few lines added to update:

    // 9 - Do some parallax scrolling
    [objectLayer setPosition:ccp(0,-cY)];
    [floorBackground setPosition:ccp(0,-cY*0.8)]; // move floor background slower
    [background setPosition:ccp(0,-cY*0.6)];      // move main background even slower

Feel free to adjust the values to your liking.

That’s it – compile and run. Tap the screen multiple times to see the monkey rise. And beware of flying monkeys!!!!

And It All Piles Up!

If you play the game for a while, you’ll notice that the items continue to drop from the same fixed height – sometimes way below the monkey’s current position. In fact, after some time, items don’t even drop because they’ve piled up beyond the spawning point.

Fix this by changing the following line in GameLayer.mm‘s update method:

    float yPos = 400;

Change the above line to this:

    float yPos = 400 + mY;

Items will now spawn 400pt above the monkey’s head, wherever it may be.

Back to the monkey. You’ll have noticed that the monkey can actually jump again and again while up in the air. This just won’t do. We need to fix it so the monkey only jumps when he has contact with the floor.

Let’s start by counting the number of contacts the monkey makes with the floor.

Add a new variable to Monkey.h:

    int numFloorContacts;     // number of floor contacts

Switch to Monkey.mm and add the following two new collision detection handlers to the end of the file (but above the @end marker):

-(void) beginContactWithFloor:(GB2Contact*)contact
{
    numFloorContacts++;
}
 
-(void) endContactWithFloor:(GB2Contact*)contact
{
    numFloorContacts--;
}

As the names imply, the first one detects the beginning of a contact/collision with the floor and the second the end of a collision. In the beginContact selector, we increase the value of the floor contact variable, and then decrease it in the endContact selector.

These selectors are going to get called by GBox2D every time a contact starts or ends between the monkey and the floor. (Remember: we created a separate class for the floor so that GBox2D now can call the appropriate selector with the class’s name).

Now, if the monkey is standing on the floor, then the numFloorContacts value should be at least one. Use this to our advantages by wrapping the code in the jump method in Monkey.mm with an if condition to see if the monkey is actually standing on the floor before jumping:

    -(void) jump
    {
        if(numFloorContacts > 0)
        {
            [self applyLinearImpulse:b2Vec2(0,[self mass]*JUMP_IMPULSE) 
                               point:[self worldCenter]];   
 
            ...
        }
    }

Compile and run. Everything seems fine. Well… except that when the monkey lands on an object, he loses the ability to jump. To fix this, we’re going to consider any contact the monkey has with objects similar to a contact with the floor.

And it’s very simple to implement. Simply add a couple more collision-handling routines to the end of Monkey.mm and count object contacts the same way we counted floor contacts:

    -(void) beginContactWithObject:(GB2Contact*)contact
    {
        // count object contacts as floor contacts 
        numFloorContacts++;        
    }
 
    -(void) endContactWithObject:(GB2Contact*)contact
    {
        // count object contacts as floor contacts 
        numFloorContacts--;        
    }

Compile and run. Isn’t it much better now? And our game is already playable!

Push It!

Let’s improve the gameplay and allow the monkey to push objects to the left and right – and give him the ability to put his hands above his head to shield him from dropping objects.

Do you remember how you added the sensors to the left and right sides of the monkey in Part One? They come into play now! The key to the sensors was setting up the “Id” parameter in PhysicsEditor. You are going to retrieve this value now!

But before we do that, we need to add a few instance variables to keep count of the left and right sensors, as well as the number of contacts made with the monkey’s head. Add these variables to Monkey.h:

    int numPushLeftContacts;
    int numPushRightContacts;
    int numHeadContacts;

Next, the beginContactWith* and endContactWith* selectors have a contact parameter we can use to determine which part of the monkey has contact with an object – the “Id” value we added in PhysicsEditor is stored as user data in each fixture. So replace the existing object contact handlers for Monkey.mm with the following:

    -(void) beginContactWithObject:(GB2Contact*)contact
    {
        NSString *fixtureId = (NSString *)contact.ownFixture->GetUserData();
        if([fixtureId isEqualToString:@"push_left"])
        {
            numPushLeftContacts++;
        }
        else if([fixtureId isEqualToString:@"push_right"])
        {
            numPushRightContacts++;
        }
        else if([fixtureId isEqualToString:@"head"])
        {
            numHeadContacts++;
        }
        else
        {
            // count others as floor contacts 
            numFloorContacts++;        
        }
    }
 
    -(void) endContactWithObject:(GB2Contact*)contact
    {
        NSString *fixtureId = (NSString *)contact.ownFixture->GetUserData();
        if([fixtureId isEqualToString:@"push_left"])
        {
            numPushLeftContacts--;
        }
        else if([fixtureId isEqualToString:@"push_right"])
        {
            numPushRightContacts--;
        }
        else if([fixtureId isEqualToString:@"head"])
        {
            numHeadContacts--;
        }
        else
        {
            // count others as floor contacts 
            numFloorContacts--;        
        }
    }

As you see from the new code, you retrieve the Id, which we’ll call fixtureId here, by accessing the contact parameter’s fixture and then accessing the fixture’s user data via the GetUserData method.

Now that we’re tracking the contacts, we can update the monkey’s animation frames to handle additional events.

Here’s the decision table for the various animations:

Using the above table, we modify section #6 of updateCCFromPhysics in Monkey.mm as follows:

    // 6 - Update animation phase
    const float standingLimit = 0.1;
    NSString *frameName = nil;
    if((vX > -standingLimit) && (vX < standingLimit))
    {
        if(numHeadContacts > 0)
        {
            // Standing, object above head
            frameName = [NSString stringWithFormat:@"monkey/arms_up.png"];                        
        }
        else
        {
            // Just standing
            frameName = [NSString stringWithFormat:@"monkey/idle/2.png"];            
        }
    }
    else
    {
        if(numFloorContacts == 0)
        {
            // Jumping, in air
            frameName = [NSString stringWithFormat:@"monkey/jump/%@.png", dir];
        }
        else
        {
            // Determine if monkey is pushing an item
            bool isPushing =  (isLeft && (numPushLeftContacts > 0))
            || (!isLeft && (numPushRightContacts > 0));
 
            // On the floor
            NSString *action = isPushing ? @"push" : @"walk";
 
            frameName = [NSString stringWithFormat:@"monkey/%@/%@_%d.png", action, dir, animPhase];        
        }        
    }

Compile and test. Perfect! The monkey now behaves just as we want.

It Takes a Strong Monkey …

Playing a little bit more though, I think the monkey should be a bit stronger under certain conditions. Currently, he’s too weak to break free when an object is above his head. Let’s give him some extra strength when he’s trapped like that and wants to jump.

This is the current line from the jump selector in Monkey.mm that makes the monkey jump:

    [self applyLinearImpulse:b2Vec2(0,[self mass]*JUMP_IMPULSE) 
                       point:[self worldCenter]];

Replace it with:

    float impulseFactor = 1.0;
 
    // if there is something above monkey's head make the push stronger
    if(numHeadContacts > 0)
    {
        impulseFactor = 2.5;
    }
    [self applyLinearImpulse:b2Vec2(0,[self mass]*JUMP_IMPULSE*impulseFactor) 
                       point:[self worldCenter]];

That’s our monkey on steroids! He now uses a 2.5-times stronger impulse when there’s an object resting above him – this should allow him to break free of most of the objects.

Let’s also change the walking impulse in case the monkey needs to push an object to the side to break free. Go to updateCCFromPhysics and cut the following lines from section #6:

    // Determine if monkey is pushing an item
    bool isPushing =  (isLeft && (numPushLeftContacts > 0))
                   || (!isLeft && (numPushRightContacts > 0));

Now paste that code into section #4 and modify it as follows:

    // 4 - Determine direction of the monkey
    bool isLeft = (direction < 0);
 
    // Determine if monkey is pushing an item
    bool isPushing =  (isLeft && (numPushLeftContacts > 0))
                   || (!isLeft && (numPushRightContacts > 0));
 
    if((isLeft && (vX > -MAX_VX)) || ((!isLeft && (vX < MAX_VX))))
    {
        // apply the directional impulse
        float impulse = clamp(-[self mass]*direction*WALK_FACTOR, 
                              -MAX_WALK_IMPULSE, 
                              MAX_WALK_IMPULSE);       
        if(isPushing)
        {
            impulse *= 2.5;
        }
        [self applyLinearImpulse:-b2Vec2(impulse,0) point:[self worldCenter]];        
    }

Compile and test – that’s much better. But there’s still a problem: when the monkey slightly grazes an object with his head, the new jump power makes him go through the roof!

We need to clamp his maximum speed inside the updateCCFromPhysics method. Add this to the end of section #3 of the updateCCFromPhysics method:

    const float maxVelocity = 5.0;
    float v = velocity.Length();
    if(v > maxVelocity)
    {
        [self setLinearVelocity:maxVelocity/v*velocity];
    }

Notice that in the code above we are directly modifying values controlled by the Box2d engine, thus affecting the overall behaviour of the physics engine. You should try to avoid doing this kind of manipulation.

Compile and test. I like the monkey’s behavior now. He reacts quickly, and is strong enough to push objects but does not become uncontrollable.

Where To Go From Here?

If you don’t have it already, here is all of the source code for this tutorial series.

You’ve now reached the end of Part Two of the MonkeyJump tutorial! The project in its current form is available in the source code zip in the folder called 5-MonkeyJumpAndRun.

Stay tuned for the final part of the series, where we’ll add some performance improvements, add a HUD layer to the game, and yes – kill the monkey! :]

In the meantime, if you have any questions or comments, please join the forum discussion below!

This is a post by special contributor Andreas Loew, the creator of TexturePacker and Physics Editor.

How To Build a Monkey Jump Game Using Cocos2D, PhysicsEditor & TexturePacker Part 2 is a post from: Ray Wenderlich

This is a post by special contributor Andreas Loew, the creator of TexturePacker and PhysicsEditor.

In this tutorial, youll learn how to make a game about a monkey having a rough day. He’s just minding his own business, but these crazy objects keep falling from the sky!

To see what I mean, check out this cool video:

By the end of this tutorial, you’ll have created a cool physics enabled game, and learned how using TexturePacker and PhysicsEditor can save you a ton of development time.

To go through this tutorial, you should have some basic familiarity with Cocos2D. If you are new to Cocos2D, check out some of the other tutorials on this site first.

You will also need a copy of TexturePacker and PhysicsEditor. To to through this tutorial you can use an evaluation version from TexturePacker.com and physicseditor.de, but note that there are some features that are not present in the evaluation versions. If you want to order the full versions, here’s a direct link to order the bundle.

Ready to make that monkey jump? Keep reading to get started!

Getting Started

We will start with the design phase. So let me give you a brief overview of how the game will work.

As you’ve seen, our main character will be a monkey. His movement will be controlled with the accelerometer – that is, by tilting the iPhone or iPad left and right. The monkey will jump when the screen is tapped.

During the game, items will drop from the top of the screen, and the dropping frequency will increase the longer the game continues. We will have a drop indicator to show the player where the next item will fall. Items pile up, and the monkey must stay on top to stay alive.

There will be two sorts of items: those that hurt the monkey, and those that heal him – namely, bananas! The monkey’s health will be displayed in the top-left corner as a bar of bananas.

The score will be displayed in the top-right corner, and will be at the height of the highest item on the stack.

To get started, download the tutorial source code and unzip it into your preferred location. Your starting point will be 0-BaseProject, which contains the basic Cocos2d setup and some integrated assets.

I’ve added directories for several stages of the development process containing the results you should achieve. These directories will make your life easier in case you get lost, or if you simply want to skip one part of the project.

Each folder contains the complete project and is independent from the rest. Inside each folder are two more folders:

The first is called Assets, and contains such things as the TexturePacker and PhysicsEditor save files, a directory holding the Xcode project, and a free game art pack created by Vicki Wenderlich.

The Assets folder is organized further into the subfolders background, containing the background graphics, and jungle, containing the foreground objects and animation.

The second folder is called MonkeyJump. It contains the Xcode project and the sources, which are contained in a second MonkeyJump folder which has the following subfolders:

• libs: Cocos2d, Box2d, Cocos Denshion… all the Cocos2d stuff
• GBox2D: my ObjectiveC++ Box2d wrapper
• Resources: sounds and music

Creating Sprite Sheets

Time to start the real work, beginning with sprite sheets.

Open the 0-BaseProject folder and have a look at the Assets folder. I’ve already arranged the images for us. We’re going to add the sprites from the “background” folder into one sprite sheet, and the sprites from the “jungle” folder into as second.

The background sheet will use RGB565, a 16-bit image format that reduces the amount of memory used by 50%. Using RGB565 will also speed up rending. The foreground sheet, with most of the content, will use RGBA8888 for full quality. For more information on pixel formats with TexturePacker, check out this tutorial.

Creating the Background Sprite Sheet

Let’s start by creating the background sheet. Start TexturePacker, navigate to the O-BaseProject\Assets\background folder, and drag it into the right hand side of the TexturePacker window. You’ll see the jungle background image show up in the center of the window.

To set up the parameters for the texture, first choose the Data format, which is of course Cocos2d. Next choose the Texture format. We will use zlib compressed PVR format .pvr.ccz.

TexturePacker warns us that we should turn on pre-multiplied alpha. Let’s agree to that and click “Apply.”

Pre-multiply means that all color values get multiplied by their transparency value when saving the file. This speeds up graphics rendering in the game, since the multiplication step does not need to be performed at runtime.

The main advantage of pvr.ccz is that it can be loaded quite fast, and it usually consumes less memory than PNG. Note in the bottom-right corner of TexturePacker how the memory consumption is reduced from 8192kB to 4096kB.

The quality of the image will suffer a bit: we can see that the gradients are now not as smooth and have some artifacts called banding. We can compensate for this by setting Dithering to FloydSteinberg.

The following two images show a part of the jungle. The left one has no dithering, while on the right one, dithering has been enabled:

RGB565 image with banding artifacts

RGB565 image with dithering

Next, set the Data file to background-hd.plist in the Resources directory of the Xcode project. This will automatically set the Texture file to background-hd.pvr.ccz.

Don’t worry that the paths are displayed as absolute paths. TexturePacker creates a relative path to the document file as soon as it is saved. This means we can move our project around as long as we don’t change the relative position of the assets and resources to the saved .tps file.

The -hd extension is important, because TexturePacker can save retina display and reduced resolution images for older devices. To enable this, simply check the AutoSD option. This will create background-hd.plist and background-hd.pvr.ccz files for retina display, and background.plist and background.pvr.ccz for reduced resolution.

Max. width and Max. height appear in red, which means TexturePacker can’t layout the sprite within the texture’s dimensions. This is because padding is set to 2 by default.

Scroll down on the left pane and set both border padding and shape padding to 0. Now all numbers should appear in black.

Finally, let’s save our sheet as background.tps in the Assets folder by first clicking Save and then Publish. This creates four files in the Resources folder: background-hd.plist, background-hd.pvr.ccz, background.plist and background.pvr.ccz. (Open the Resources folder to make sure the files are there.)

Creating the Jungle Sprite Sheet

Now create a new sheet for the foreground by pressing the New button on the toolbar. Drag the complete jungle folder from the Assets folder into the empty right pane.

See how TexturePacker builds the complete directory structure on the right pane? (You can expand the tree view by pressing the arrow button to the left of the word “jungle”.)

We’re using a feature called Smart Folders, where TexturePacker rescans the directory every time we add sprites to the folder. If you want to add a new asset, or rename or change an existing asset, just drop it into the folder on your file system, and when you reenter TexturePacker it will automatically update the sheet.

For the options, we’ll use a nearly identical setup as for the background sheet (see screenshot below). Just make sure to leave the image format at RGBA8888 for full quality.

Also be sure to leave the paddings set to the default of 2. This will reduce artifacts on the sprite borders. Sometimes OpenGL drags in pixels from neighboring sprites. Padding avoids this problem by adding transparent borders around the sprites.

Set jungle-hd.plist in the Resources folder of the project as the Data file, and jungle-hd.pvr.ccz in the same folder as the Texture file. Check the box next to AutoSD.

Finally, save the sheet as “jungle.tps” in the Assets folder and click Publish. This creates four files in the Resources folder: jungle-hd.plist, jungle-hd.pvr.ccz, jungle.plist, and jungle.pvr.ccz. Check and see if they are there.

Creating Physics Shapes Manually

Next we’ll set up the physics shapes with PhysicsEditor!

Launch PhysicsEditor and start with the basic setup. We need to set the Exporter to Box2d Generic (PLIST). For this I added a loader which you can use in your Cocos2d projects. If you are not satisfied with the formats supported by PhysicsEditor, you can simply create your own custom data exporter.

Set the PTM-Ratio to 170. This tells Box2d that 170 pixels are equal to 1 meter (39.37 inches), the internal measurement unit of Box2d. I chose 170 pixels because this is the monkey’s height, and he is going to be 1 meter tall in the simulation.

We’re going to create all the physics shapes for the high-res sprites only. This is okay, since we want the physics parameters to be identical on retina display and old displays.

Creating different shapes for different screen resolutions would create different masses for each object, resulting in different physics behavior – which we don’t want! The idea is to run the same simulation on all devices and only adjust the visuals.

Setting Up the Fixture

We’re now going to create our first shape by hand. Drag the jungle/floor/grassfront.png shape onto the left pane of PhysicsEditor. When you do this, the shape will also appear in the center pane, which is the main editor area.

Note the small blue circle with the cross inside: that is the anchor point of the shape. We’re going to leave the anchor point for this shape where it is, on the bottom right corner. Later on, I’ll show you how to change the anchor point.

First use the polygon tool from the top tool bar. As soon as you click on it, a small red triangle appears. You can drag this triangle with your mouse.

The handles allow you to change the triangle’s shape. Double-clicking somewhere near a line will add an additional vertex. Double-click the vertex to remove it.

You do not have to care about things like polygon orientation or convex or concave shapes. This is all handled by PhysicsEditor.

Now create a rectangular shape for the floor. It should cover the soil but not the grass, and look something like this:

Setting Up the Parameters

Since the floor is going to be a static shape, its parameters are going to be very basic.

Density affects the weight of a body/fixture. Since the floor will not move, the value of the density is of no importance. Restitution is the degree a colliding shape will rebound from another object. For the floor, we want to keep this at 0.

Friction is the only important value here, as it determines how much the sprites will slide on the floor. Set this to 0.7.

The next items to set up are the collision bits. PhysicsEditor lets you handle these parameters quite easily – that is, without doing hex math. First, give the bits useful names by setting up the names in the text fields associated with the bits:

• floor – both the floor and the walls
• monkey – what else?
• good_objects – objects that don’t hurt the monkey
• bad_objects – objectw that hurt the monkey

Ignore the other bits – we don’t need them.

Two objects can collide only when Object B’s bit category is of a type that has been selected as a mask for Object A, and vice-versa. We will tick the Category field for the floor bit since this shape is a floor, and then the Mask field for all the bits. This enables collision between all objects and the floor.

Save the project as “shapes.pes” inside the Assets folder.

A Little Magic: Creating Shapes with the Tracer

Creating shapes by hand isn’t always fun. So let’s use the magic wand tool and let PhysicsEditor do the work for us!

Drop the following objects onto the left pane: backpack, banana, bananabunch, canteen, hat, pineapple, and statue.

Select the backpack, and click the magic wand icon on the tool bar. This will open a new window, the tracer. The tracer shows the current shape with an overlay of the traced shape.

The most important setting is the Tolerance. This value tells the tracer how exactly the polygon should match the shape. It directly influences the number of vertices the polygon will have. For example, setting the Tolerance to 20 will result in a 5-vertex polygon that no longer fits the shape; setting it to 1 creates a perfectly-matching polygon with 39 vertices.

Not enough vertexes

Too many vertexes

Good trace

A Tolerance value of 5 gives us an acceptable match, with about 15 vertices (the exact amount sometimes varies with the starting point of the tracer). That’s fine! Click OK to get back to the main screen. If you want you can fine-tune the shape, but don’t be too finicky!

Now set the backpack’s parameters. Set the Density to 5.00, the Restitution to 0.10 (so that the backpack bounces a little bit) and the Friction to 0.5. You might want to play around with these parameters later to get a better feel for how they work.

In the collisions section, tick the Cat. box next to bad_objects, and enable collision with all other objects by making sure all the Mask boxes are ticked.

Also drag the anchor point (the blue circle with the cross inside) to the center of the backpack shape. Alternatively, you can set the anchor point to the exact center of the shape by setting the Relative anchor point values in the right sidebar to 0.5 and 0.5.

Now that you know how to create shapes, either by hand or using the tracer, go ahead and do the remaining ones yourself! Use the parameters indicted in the table below. And don’t forget to drag the anchor point for each shape to the position indicated in the images below.

Last But Not Least: the Monkey

There’s one shape we have left to create, and that’s because it’s the most complex. Our monkey consists of quite a few animation phases (fourteen total):

The first idea that comes to mind is to add a collision polygon for each animation frame to make a perfect match for each phase of the animation. But this would be a bad idea.

First of all, the frequent exchange of fixtures would consume a good deal of CPU power. But the bigger problem is that with each new shape, the mass of the monkey would change!

This is because Box2d calculates mass based on a polygon’s area and density. If you change the polygon, the monkey will gain or lose weight! And this will lead to the physics simulation behaving erratically.

The solution is to make only one shape for the monkey, which we will try to make as good a fit as possible. To begin, drag one of the monkey shapes onto PhysicsEditor. You can rename the shape by double-clicking its name.

Now click the “+” button to add the other animation phases for the monkey. The files will show up in the combo box and you can switch between them.

Start the tracer by clicking on the magic wand icon. What you see now is that the shape does not fit the monkey anymore. This is exactly what we want.

The tracer is now in animation tracing mode. You can switch between two frame modes: intersection and union. Intersection creates the polygon only from the parts that are covered by all sprites, whereas union uses the parts that are covered by any sprite. Choose intersection.

The slider allows you to browse through the animation phases and see how the shape fits the different phases.

We will take the shape the tracer gave us just as an estimate. This is because we must split up monkey’s body into several parts. Here is what we have to build:

Sometimes polygon shapes don’t slide smoothly over other polygons and stick to each other. This is why we’re building the monkey from circle shapes.

The other reason is that using circles results in faster collision detection. The math to check if a point is inside a circle is much simpler than that for testing for a point inside a polygon. So we’ll save CPU power. We’ll delete the tracer shape after the other parts are set up.

First build the head of the monkey. Use a circle shape and make it as big as the traced version. The head must be treated differently from the other body parts, since we want the monkey to get hurt when objects land on his head from above.

To distinguish the head from the other parts, set the Id to “head.” The head’s category is monkey, and it collides with good_objects, bad_objects and floor, so make sure these are selected as masks. Set the density to 2.0, the restitution to 0.1, and the friction to 0.5.

Next build the body of the monkey from two circles, one covering the torso and one the legs. Set the Id to “body.” The body’s category is monkey, and it collides with good_objects, bad_objects and floor. Set the body’s density to 2.0, its restitution to 0.1, and its friction to 0.5.

Cycle through the different animation phases by selecting the different images from the Filename combo box. Check if the circles fit all phases. It doesn’t have to be a perfect fit, and you can come back to PhysicsEditor any time you want to tweak the collision set.

Finally, delete the polygon created with the tracer.

During the game we need to check if there are objects to the left or right to trigger the push animation. To do this, place two sensors on the left and right sides of the monkey.

Sensors are fixtures that don’t interact with other bodies and simply report collisions. To make a fixture a sensor, set isSensor.

Set the Id to “push_left” for the left sensor and “push_right” for the right one. The category is monkey, and they collide with bad_objects only – we don’t want the monkey push the floor and the bananas away!

Make the monkey shape fit all animation phases

One last thing to do: save and click Publish! When asked for a location, store the file in the Resources folder of the project as shapes.plist.

That’s it for now in PhysicsEditor. Next we move to Xcode and start coding our game!

The Xcode Project: Overview

I created the starter project using the standard Cocos2d+Box2d template that comes with Cocos2d and removing all the demo stuff. I also added the sound resources and some classes which will make your life easier when working with Box2d inside Cocos2d.

One important thing to know about this project is that all files must have the .mm extension instead of .m. This is because Box2d is C++ based, so we must use Objective-C++ for development.

Now let’s discuss the starter project in more detail:

GBox2D

First let me give you some information about GBox2D. GBox2D is an Objective-C wrapper for Box2d that I developed for my upcoming game TurtleTrigger.

These are the main classes in Gbox2D:

• GB2Engine: This class wraps the Box2d world simulation. It runs the simulation, updates all sprite positions and rotations and can iterate through all objects in the world. It is implemented as a singleton class to make access as easy as possible.
• GB2Node: This class combines a CCNode and a B2Body. It’s the glue between the physics simulation and the graphics representation inside Cococs2d. It also contains selectors for simple management of the physics object and implements a proxy to access the inner node’s data.
• GB2Sprite: This class is derived from GB2Node and specializes in using CCSprite as the inner object.
• GB2DebugDrawLayer: This is a Cocos2d layer that wraps the debug drawing. It can be added to your project like a normal layer. When added it will draw the physics shape outlines. The nice thing about it is that it detects when running on a retina display target and scales the content accordingly.
• GB2Contact: This structure will be passed as parameter to an object when a collision is detected. Both objects involved in the collision will be called for each single point of contact.
• GB2WorldContactListener: This is a C++ class that reacts to collisions in the physics simulation.

If you’re curious, go ahead and scan through these classes to get an idea of what they do. Don’t worry if you don’t understand what they’re doing – you’ll learn how to use it in the next few sections.

Collision Detection with Gbox2D

GBox2D makes collision detection a piece of cake! This is because you do not need to create one huge switch-case statement or a series of if-else cascades to detect the various possible collision combinations.

Instead, GBox2D simply uses the names of the colliding classes and calls selectors with names derived from the class names! If this sounds too abstract, take a look at the following example:

Let’s assume you have a monkey that is an object of class Monkey, and a banana that is an object of class Banana. If both objects begin to collide, the following selectors will be called by GBox2D:

    [banana beginCollisionWithMonkey:collisionA];
    [monkey beginCollisionWithBanana:collisionB];

If the collision is released, because the objects do not touch anymore:

    [banana endCollisionWithMonkey:collisionA];
    [monkey endCollisionWithBanana:collisionB];

The collisionA and collisionB parameters contain collision information, e.g., which objects and which fixtures took part in the collision. We will use this information to see if the monkey was hit on his head or body.

AppDelegate

Things I changed from the AppDelegate contained in the original Box2d project are as follows:

First I set the default pixel format of the frame buffer to RGBA8. That means that the game gets the full 24-bit color depth. I disabled the depth buffer, since we don’t need it.

EAGLView *glView = [EAGLView viewWithFrame:[window bounds]
	pixelFormat:kEAGLColorFormatRGBA8
	depthFormat:0
	];

The next important thing to set is pre-multiplied alpha. This is because we use pre-multiplied PVR images created with TexturePacker. If we don’t set pre-multiplied alpha, our images will have dark borders.

    [CCTexture2D PVRImagesHavePremultipliedAlpha:YES];

Since we’re going to use the random generator to select objects to drop, we have to seed it. The best way to do this is using time(). If you forget to seed the random generator, you will still get random numbers – but they will be the same with every start of the game.

    srand (time (NULL));

When the initialization is done, the GameLayer scene is started:

    [[CCDirector sharedDirector] runWithScene: [GameLayer scene]];

GameLayer

The GameLayer is a simple class derived from CCLayer. In this state it consists of an empty init function…

    -(id) init
    {
    	if( (self=[super init]))
        {
    	}
    	return self;
    }

…and a static selector that wraps the CCLayer into a CCScene to hand over to the Director:

    +(CCScene *) scene
    {
    	// 'scene' is an autorelease object.
    	CCScene *scene = [CCScene node];
 
    	// 'layer' is an autorelease object.
    	GameLayer *layer = [GameLayer node];
 
    	// add layer as a child to scene
    	[scene addChild: layer];
 
    	// return the scene
    	return scene;
    }

Audio Resources

I got the theme music, tafi-maradi-loop.caf, from http://incompetech.com/

Since I knew I wanted to loop the music, I made things easier on myself and chose a theme without a vocal track.

The sounds effects for the objects were obtained from http://soundbible.com (thanks to Mike Koenig). Some of them were created using cfxr.

All sounds and the music files were converted to caf format. See Ray’s Audio 101 tutorial for more information.

If you compile and run the project, you will simply see a black screen. So let’s add some content to that screen now!

Basic Setup in Xcode

The goals for this section of the tutorial are to set up the basic game layers and backgrounds, and to set up the physics engine.

Before we dive into the code, there’s one more thing to do: add the resources we created in PhysicsEditor. Remember these?

• background.plist
• background.pvr.ccz
• background-hd.plist
• background-hd.pvr.ccz
• jungle.plist
• jungle.pvr.ccz
• jungle-hd.plist
• jungle-hd.pvr.ccz
• shapes.plist

Add the above files to the Resources folder in your Xcode project by Control-clicking on the Resources folder inside Xcode, selecting Add Files To “MonekyJump” and then selecting the files listed above from the project Resourcess folder.

Now for the code. First, we need to create a Floor class to represent the floor for the game. Add Floor.h and Floor.mm files to your project by creating a new file with the iOS\Cocoa Touch\Objective-C class template. Name the class Floor, and make it a subclass of GB2Sprite. And don’t forget to change the extension for Floor.m to .mm once it has been created.

Floor.h simply contains this:

    #pragma once
 
    #import "cocos2d.h"
    #import "GB2Sprite.h"
 
    @interface Floor : GB2Sprite
    {
    }
 
    +(Floor*) floorSprite;
 
    @end

And Floor.mm this:

    #import "Floor.h"
 
    @implementation Floor
 
    +(Floor*) floorSprite
    {
        return [[[self alloc] initWithStaticBody:@"grassfront" spriteFrameName:@"floor/grassfront.png"] autorelease];
    }
 
    @end

The only remarkable line of code here is the call to the initWithStaticBody selector. This makes our object a static object – one that isn’t moved by the physics engine. It initializes the body’s shape using a shape from the shapes.plist file with the name “grassfront.”

It also uses a sprite image with the name floor/grassfront.png that is taken from jungle.plist.

Why did we derive this class from GB2Sprite instead of simply using a GB2Sprite directly? The answer is GBox2D’s collision handling, which uses the name of the class to call appropriate selectors on the colliding objects. Since we want to know when something collides with the floor, the class name for the floor object must be distinguishable from other GB2Sprite objects.

The next thing to do is update the GameLayer. Add some instance variables to hold the required objects in GameLayer.h:

    @interface GameLayer : CCLayer
    {
        CCSprite *background;                   // weak reference
        CCSprite *floorBackground;              // weak reference
        CCSpriteBatchNode* objectLayer;         // weak reference
    }

We will store the objects as weak references – that is, without increasing the retain count for each object.

You do not need to worry about the CCSprites being deleted. They will be added as children of the CCLayer and thus have a retain count of at least 1. This is done because otherwise we will be caught in a retain cycle and not able to free the memory allocated by these objects.

Now fill GameLayer.mm‘s init selector with content. First, load the sprite sheets:

[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"jungle.plist"];
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"background.plist"];

Next, load the physics shapes into the GB2ShapeCache:

[[GB2ShapeCache sharedShapeCache] addShapesWithFile:@"shapes.plist"];

Then, set up the layers. We’ll divide the game into the following layers:

• Background layer: The jungle image
• Floor background: A single sprite with the tall grass
• Object layer: Contains all the items and the monkey
• Debug draw layer Activated as needed
• Hud layer Has the score and live energy indicators (to be added later)

Add the code to create the basic background and floor background layers to init:

    // Setup background layer
    background = [CCSprite spriteWithSpriteFrameName:@"jungle.png"];
    [self addChild:background z:0];
    background.anchorPoint = ccp(0,0);
    background.position = ccp(0,0);
 
    // Setup floor background
    floorBackground = [CCSprite spriteWithSpriteFrameName:@"floor/grassbehind.png"];
    [self addChild:floorBackground z:1];
    floorBackground.anchorPoint = ccp(0,0);
    floorBackground.position = ccp(0,0);

Then, add the object layer. This will be a sprite batch node to speed up rendering of the objects:

	objectLayer = [CCSpriteBatchNode batchNodeWithFile:@"jungle.pvr.ccz" capacity:150];
	[self addChild:objectLayer z:10];

And finally, the debug draw layer:

    // add the debug draw layer, uncomment this if something strange happens ;)
    [self addChild:[[GB2DebugDrawLayer alloc] init] z:30];

If you want to disable the debug drawing, simply comment out the second line. If enabled, the physics shapes will be drawn over the sprites, allowing you to see where collisions happen and if all shapes are properly aligned.

Next, add the floor object as the child of the object layer. Include Floor.h at the top of GameLayer.mm:

    #import "Floor.h"

Then add the floor object at the end of init:

    [objectLayer addChild:[[Floor floorSprite] ccNode] z:20];

There isn’t anything more we have to do to add the objects to the physics world – everything else is covered inside Gbox2D!

Compile and run the project in the iPhone simulator. (By the way, the project in its current state is available in the folder called 2-BasicLayerSetup.) You should see something similar to this:

Nice – now let’s add some action to the game!

Dropping Objects

We have two related goals for this section of the tutorial: make our objects drop from the sky and add our sound effects.

Our base class for all the dropping objects will be called Object. It will handle the sound and some basic collision detection. We will derive other sub-classes later on in the tutorial from the Object class.

First, create a new file with the iOS\Cocoa Touch\Objective-C class template. Name the class Object, and make it a subclass of GB2Sprite. (And remember to change the extension for Object.m to .mm)

Object is a simple class, derived from GB2Sprite. This means that it comes with physics and graphical capabilities built in.

To make our lives easier, I’ve named the sound files in the same way as the physics sprites and the images from the sprite sheet. This allows us to simply use the object’s name to create the right shape and sound when needed. You’re welcome!

In order for this to work, we need a property named objName – objName is passed into the initWithObject selector and stored as part of the class.

RandomObject is a factory method that creates a random object and hands over the right object name upon creation.

Paste this code into Object.h:

   #pragma once
 
    #import "cocos2d.h"
    #import "GB2Sprite.h"
 
    @interface Object : GB2Sprite
    {
        NSString *objName; // type of the object
    }
 
    @property (retain, nonatomic) NSString *objName;
 
    -(id) initWithObject:(NSString*)objName;
    +(Object*) randomObject;
 
    @end

Let’s now go to Object.mm. Start with some needed imports and with synthesizing the objName property.

    #import "Object.h"
    #import "GB2Contact.h"
    #import "SimpleAudioEngine.h"
    #import "GMath.h"
 
    @implementation Object
 
    @synthesize objName;

GMath.h contains some helper functions – for example, gFloatRand, a ranged floating point random number generation.

Next, add the init selector and instantiate the physics object. You can use the object’s name as it is to instantiate the physics shape. For the sprite frame name, you’ll need to add the folder’s name (which is object) and the .png extension. Store the objName in the property – we’ll need it during collision detection to play the sound effect.

-(id) initWithObject:(NSString*)theObjName
{
    self = [super initWithDynamicBody:theObjName
              spriteFrameName:[NSString stringWithFormat:@"objects/%@.png", theObjName]];
    if(self)
    {
        self.objName = theObjName;
    }
    return self;
}

In the dealloc selector, simply release the objName property and call super dealloc:

    -(void) dealloc
    {
        [objName release];
        [super dealloc];
    }

The next thing to add is our static factory method, which will simply create a random object. I decided to use a simple switch-case statement for this. The reason is that we’ll need to create special classes for banana and banana bunch later on. These two objects get only one case entry, while the other objects get three each, so that there’s a higher probability they appear more often.

Switch case constructs are quite efficient (usually implemented by the compiler using a jump table). You might save some CPU cycles by using an array with the names instead, but since the routine will be called once in a second, our way is fine.

+(Object*) randomObject
{
    NSString *objName;
    switch(rand() % 18)
    {
        case 0:
            objName = @"banana";
            break;
 
        case 1:
            objName = @"bananabunch";
            break;
 
        case 2: case 3: case 5:
            objName = @"backpack";
            break;
 
        case 6: case 7: case 8:
            objName = @"canteen";
            break;
 
        case 9: case 10: case 11:
            objName = @"hat";
            break;
 
        case 12: case 13: case 14:
            objName = @"statue";
            break;
 
        default:
            objName = @"pineapple";
            break;
    }
    return [[[self alloc] initWithObject:objName] autorelease];
}

Finally, add the closing end to the file:

@end

Now switch to GameLayer.h and add a forward declaration for the object class, directly after the #import statement:

    #import "cocos2d.h"
    @class Object;

Add these new members to the GameLayer class:

    ccTime nextDrop;    // Will keep the time until the next drop.
    ccTime dropDelay;     // The delay between two drops.
    Object *nextObject;   // Contains a reference to the next item to drop.

Switch to GameLayer.mm and add an import of Object.h to the imports at the start of the file. Also import GMath.h:

    #import "Object.h"
    #import "GMath.h"

Initialize the new variables at the end of the init selector, and schedule an update selector with every frame update:

    nextDrop = 3.0f;  // drop first object after 3s
    dropDelay = 2.0f; // drop next object after 1s                
 
    [self scheduleUpdate];

The last line will call a selector called “update” for every frame. The parameter to this selector is the time elapsed since the selector was last called. Add the update method right after init:

    -(void) update: (ccTime) dt
    {
        // 1 - drop next item
        nextDrop -= dt;
        if(nextDrop <= 0)
        {
            // 2 - do we have the next object?
            if(nextObject)
            {
                // 3 - set the object as active, making it drop
                [nextObject setActive:YES];
 
                // 4 - set next drop time
                nextDrop = dropDelay;
                // reduce delay to the drop after this
                // this will increase game difficulty
                dropDelay *= 0.98f;            
 
            }
 
            // 5 - create new random object
            nextObject = [Object randomObject];
            // but keep it disabled
            [nextObject setActive:NO];
 
            // 6 - set random position
            float xPos = gFloatRand(40,440);
            float yPos = 400;
            [nextObject setPhysicsPosition:b2Vec2FromCC(xPos, yPos)];
 
            // 7 - add it to our object layer
            [objectLayer addChild:[nextObject ccNode]];
        }
    }

Let’s go through the above code section by section.

1. This section simply reduces the time interval since update was last called from nextDrop. If nextDrop falls below 0, it’s time to create a new item to drop.
2. If the nextDrop timer runs out, this section checks if there is already an object stored in nextObject.
3. If so, it’s set to to active in here. Setting the object to active gives the physics engine control over the object.
4. This section sets the time until the next drop to the current drop delay, and reduces the drop delay by 2%, making the game a bit more difficult with each dropped item.
5. This section creates a new object to drop using our factory method in Object – randomObject – and sets the object to inactive, which keeps the object from dropping and participating in the physics simulation.
6. This section gives the object a random position. The screen is 480pt wide (Cocos2d uses points as the base unit, with 1 pt equivalent to 1 pixel on “old” devices and 2 pixels on retina display devices). The code ensures that the object’s position is somewhere between 40 and 440 points. The section also sets the y-coordinate to 400 for the starting position so that the object will start offscreen from the top of the screen. The b2Vec2FromCC method is used to create a box2db2Vec2 from the point coordinates. B2Vec2FromCC transforms Cocos2d’s points to Box2d’s meters-based values.
7. Finally, this section adds the object to the object layer.

Compile and run! You should see something similar to the following but of course, with different items. The items look a bit blurry since debug drawing is still enabled:

Disable the debug draw layer as follows by commenting out the relevant line in GameLayer.mm:

    //        [self addChild:[[GB2DebugDrawLayer alloc] init] z:30];

Now your game should look much nicer:

Notice how the items can tumble out-of-screen to the left and right? The goal of the game is to let the items pile up, so we need to add a wall on each side of the screen.

To do this, simply create two new GB2Node objects. They will be out of the screen to the left and right.

Since GB2Nodes add themselves to the current physics simulation, you don’t need to add them manually. They are not represented graphically, so creating them will suffice.

Add these lines to the init in GameLayer.mm, right after the floor layer:

    GB2Node *leftWall = [[GB2Node alloc] initWithStaticBody:nil node:nil];
    [leftWall addEdgeFrom:b2Vec2FromCC(0, 0) to:b2Vec2FromCC(0, 10000)];
 
    GB2Node *rightWall = [[GB2Node alloc] initWithStaticBody:nil node:nil];
    [rightWall addEdgeFrom:b2Vec2FromCC(480, 0) to:b2Vec2FromCC(480, 10000)];

Compile and run. See how the objects are now kept inside the screen by our walls?

This looks nice, but there is still something missing. I think the objects should make some noise when colliding with each other. Don’t you agree?

I don’t want the objects to make sounds all the time, just when they hit each other at a decent speed. So we’ll check the object’s velocity, and play a sound only when it collides at a fast enough speed.

Add this code to Object.mm:

    -(void) beginContactWithObject:(GB2Contact*)contact
    {
        b2Vec2 velocity = [self linearVelocity];
 
        // play the sound only when the impact is high
        if(velocity.LengthSquared() > 3.0)
        {
            // play the item hit sound
            // pan it depending on the position of the collision
            // add some randomness to the pitch
            [[SimpleAudioEngine sharedEngine] playEffect:[NSString stringWithFormat:@"%@.caf", objName]
                        pitch:gFloatRand(0.8,1.2)
                        pan:(self.ccNode.position.x-240.0f) / 240.0f
                        gain:1.0 ];    
 
        }
    }

The above method must be named beginContactWithObject so that it will be automatically called by GBox2D each time two objects collide.

The linearVelocity method gives us the velocity of the object. Calling Length or LengthSquared on the object delivers the velocity’s value. I prefer using LengthSquared when comparing with a constant value, since it doesn’t require calculating the square root of the value.

We’ll play the sound with a call to SimpleAudioEngine’s playEffect method. The first parameter is the name of the audio file.

Remember that to make our lives easier I gave the sound effects the same name as the objects and sprites. So you can use the objName we stored earlier to get the right sound file. Use NSString to append .caf to the name.

Add some variation to the pitch by using gFloatRand with 0.8 and 1.2. This will play the sound with some pitch variation. It would be boring if every object made the same sound all the time.

The last trick to apply is to pan the sound’s source to the position of the object. Pan allows values between -1.0 and 1.0. The object’s x position (in points) will be somewhere between 0 and 480, so subtracting 240 and dividing by 240 will deliver that range.

If you want objects to make a sound when they hit the floor without rewriting a lot of the code, add the following method which forwards the object-floor collision to the object-object collision to Object.mm:

-(void) beginContactWithFloor:(GB2Contact*)contact
{
    [self beginContactWithObject:contact];
}

Compile, run and see how the objects drop and make a sound upon collision.

Ah, but there is one more thing I don’t like about our game right now. The first item drops and then pauses in mid-air while the sound engine is initialized.

This won’t be a problem once we add the theme music, since the music will initialize the sound engine right away. But if you want to fix this now, first add an import statement to the top of GameLayer.mm:

#import "SimpleAudioEngine.h"

Then, add a call to SimpleAudioEngine’s shared object inside GameLayer’s init selector:

[SimpleAudioEngine sharedEngine];

The above implementation plays the same basic sound (with pitch variations) for all falling object collisions. If you’re ambitious, you could play different sounds depending upon the types of objects colliding. That is, play one sound when a canteen hits a canteen, and another when a banana hits a canteen…

Another way to improve this code would be to vary the gain of the effect with the speed of the collision.

Where to Go From Here?

If you don’t have it already, here is all of the source code for this tutorial series.

You’ve now reached the end of Part One of the MonkeyJump tutorial! The project in its current form is available in the source code zip in the folder called 3-DroppingObjects.

Stay tuned for Part Two, where we’ll add our hero (the monkey), make him move and interact with objects – even make him teleport! Plus injury and death, life-giving bananas, a drop warning light… there’s lots of exciting stuff ahead.

Before we get there, let me know if you have any questions or comments about what we’ve done so far. I’ll be following the discussions in the forum below.

This is a post by special contributor Andreas Loew, the creator of TexturePacker and Physics Editor.

How To Build a Monkey Jump Game Using Cocos2D, PhysicsEditor & TexturePacker Part 1 is a post from: Ray Wenderlich

This is a blog post by iOS Tutorial Team member Gustavo Ambrozio, a software engineer with over 20 years experience, including over three years of iOS experience. He is the founder of CodeCrop Software.

Learn how to get your app all the way to the App Store!

So you’re on your way to being a big iOS developer, eh? You’ve jumped through Apple’s hoops, paid your $99 fee, and had your brilliant app idea. Maybe you even put it all together and got it running in Xcode.

What, you haven’t finished coding your app since reading How to Submit Your App to Apple, Part One? No matter. There are other tutorials that cover that.

This is the tutorial series explaining the basics of how to register as an iOS Developer, and how to interface with Apple’s portals to test and then submit your apps for approval.

In Part One, we went through the developer registration process, and we used the iOS Provisional Portal to register our devices and to create the certificates and profiles Apple requires to test and submit our apps.

Now in Part Two, we’ll configure an app to run on the devices we registered, we’ll use iTunes Connect to send Apple all the information it needs to pay you for your apps, and finally, we’ll submit an app to Apple for approval.

Ready to jump from beginning developer to approved seller? (At least virtually.) Then read on!

Getting Started

OK, that section header is a fake-out. Before we actually get started, I wanted to show you an easier way to get your apps running on your devices than setting up the provisioning profiles manually like we did in part 1.

Don’t be mad that I showed you the hard way first… believe me, you’re going to need to do it that way someday. You should be relieved you already know how!

The truth is, in some situations, such as when working with more than one developer account, the automatic provisioning I’m about to show you just does not work. But here’s how to do it to save yourself time, when you can:

Open Xcode if you haven’t already. Note that for this tutorial, I’m using the latest version of Xcode as of the time of writing, version 4.2.

Once in Xcode, open the Organizer (CMD-SHIFT-2). Plug in your iOS device and go to the Devices tab. Your screen should look something like below. Click “Use for Development”:

After a few seconds, Xcode will ask you for your credentials. Enter your iOS Developer’s credentials and click “Log in”:

Initially you should not see much:

Why did Xcode ask for your credentials? Because it’s going to connect automatically to the Provisioning Portal for you and add the device you’ve connected to your device list (if it isn’t there already). Then it will create a provisioning profile called “iOS Team Provisioning Profile,” which you should soon see displayed in your Xcode window:

From now on, whenever you plug in a new device and click “Use for Development” in Xcode’s Organizer, it will add the device to your account and update your Team Provisioning Profile so you don’t have to go to the provisioning portal all the time. You can then use this provisioning profile when testing your apps in your device.

Pretty easy, eh? :]

You can turn this behavior on and off by checking or unchecking this box in the organizer:

BUT: as I said, there will be times you’ll still need to know how to do these things using the Provisioning Portal, so it’s a good thing I showed you the hard way first. Some situations in which you’ll need to know the old-school way:

• You’re working for a person or company that has their own account, and you need to use their account instead of your own.
• You’re building a beta version of an app for someone’s device and you don’t have access to the device itself, just the UDID.
• You need to test push services or in-app purchases. For this you need a provisioning profile with a bundle ID that is not the wildcard *. The Team Provisioning Portal bundle ID is *. As you might remember from the first part of this tutorial, * works with every app, but does not allow you to test push services or in-app purchases, so in this case you need a provisioning profile with a unique bundle ID.
• You want to be the cool kid that does not use these “generic” profiles and has a profile for every app. OK, maybe I’m trying to boost my ego with this one…

Well, now I’ve got this weight off my shoulders let’s get started with our first real task for this tutorial: preparing the app to run on your device.

Running Your App on Your Device

For this section of the tutorial, we need an app to test in your device. I’ll use cute-a-pult, the app from my last tutorial, “How To Make a Catapult Shooting Game with Cocos2D and Box2D.” You can download the final project here.

The version of the app I submitted to the App Store is an improvement on the original project, done with LevelHelper and SpriteHelper. Some day I might even write a tutorial on how I did this.

If you already have an app of your own that’s ready to test, feel free to use it instead, or use any of the other great apps from Ray’s site.

Open the project you chose (mine, your own, or one from Ray’s site) in Xcode. Open the project navigator and click on the project node of the tree (1), then click on the target (2) and fill out the app version and deployment target (3):

Note that deployment target is a fancy way of saying “the minimum version of iOS that your code supports.” Be careful though, because if you set this to iOS 3.0 and use an API that is only on iOS 5 without checking first, your app will crash! The safest thing to do is to test your code on a device running the oldest version of iOS you want to support (I know, easier said than done!)

For this tutorial, just set it to 4.0.

Next, click the “Info” tab and change the bundle identifier. This should be the same bundle identifier you used for the App ID you registered in the Provisioning Portal:

Next we need to point Xcode to the provisioning profiles. Click on the “Build Settings” tab and search for the word “signing.” In the search results list, click on the cells indicated and choose the correct provisioning profiles from among those presented by Xcode.

You should choose the developer profile for the Debug build, and the distribution profile for the Release build.

We’re almost ready to build. Before we do, choose to build for the device using the scheme chooser:

CMD-B to build the project. If there are any problems with your profiles, you’ll see something like this:

Click the log navigator on the left to check the problem. In my case, I created a provisioning profile with the bundle identifier as “com.codecrop.cute-a-pult,” but my app has the bundle identifier set to “com.codecrop.cuteapult”:

Let’s fix this. Click the project navigator (1), click the project tree node (2) and change the bundle identifier (3). Hit CMD-B to build again.

Now everything should be OK:

Connect your iOS device to your computer and hit CMD-R to run the app. In a few moments you should see your app running on your device! Finally!

Next I’ll show you how to submit your project to Apple for approval. For this, we’ll have to log into iTunes Connect.

Last Stop: iTunes Connect

Now it’s time to get to know iTunes Connect. Go to https://itunesconnect.apple.com and log in with your new iOS Developer credentials.

The first time you connect, you’ll have to accept the Terms of Service. By now you know the drill: lawyer, checkbox, “Accept Terms.” It might be a good idea to keep that lawyer on a retainer…

There are a lot of things to do here in iTunes Connect. I’ll show you the basic steps to get your app submitted, but if you want the gritty details you can check the complete (currently almost 200 pages long) iTunes Connect Developer Guide.

First things first: If you want to get paid for your apps, there is a lot of “paperwork” you must fill out. It’s better to get this stuff out of the way right now. It’s pretty boring and it will vary a lot from country to country but, seriously, if you want to get money from your apps you’ll have to endure it.

If all of your apps (or at least the first) will be free, you can skip this section and go right to “Submitting Your App,” below.

Hey, you’re still here? OK then, click “Contracts, Tax and Banking.”

You’ll have to electronically sign two contracts, one for apps and another for iAds. This is fairly quick, so even if you don’t plan to use iAds now, you should do it.

Click “Request”:

Phone lawyer (told you you should get a retainer), yada, yada, yada, checkbox, “Submit”:

You’re welcome!

Repeat for the iAd contract:

Are you bored yet? Hold on, it’s about to get worse…

It’s time to set up your contact information. Click the first “Set Up” button, under “Contact Info”:

Click “Add New Contact”:

Add yourself as a new contact. Since no one is looking, give yourself a nice title, like CEO or President. Click “Save” when done:

Assuming, as in Part One, that you are an individual developer and have no employees, you can set all contacts as yourself. Change every drop-down menu and click “Done”:

Now click the second “Set Up” button, under “Bank Info.” Again, since this is your first time here, you’ll have to first click “Add Bank Account”:

Choose your bank’s country. If you choose anything other than United States, be aware that the steps from now on may be different. Click “Next”:

Your bank’s ABA Routing number is located on your checks or statements, as indicated below in the orange box. Click “Next”:

Now you have to look for your bank’s branch. Look for one in your city but don’t expect to find an exact match for your branch. Don’t worry, it does not have to be exact. Click “Next”:

Check the information (again, don’t worry if the address is not exact) and click “Next”:

Now comes the important piece: your account number. This is also found on your checks or statements, as indicated in the blue box below. Fill out all the details for your account and click “Next”:

Confirm all the information, check the box indicating that it is correct, and click “Save”:

Now you can select this new back account and click “Save”:

We’re almost done. Click “Set Up” under “Tax Info.” You’ll at least have to fill out the US tax forms, as they are required for everyone. So go ahead and click to do so:

Fill out all the required information. Though the process should be straightforward for US citizens, you may have questions. Before coughing up money to speak to an accountant, make sure that your question can’t be answered in the W-9 instructions available for download from the upper-left corner of the page.

Scroll down, fill everything out, and refer back to the W-9 instructions if you need to. Make sure everything is correct and click “Confirm”:

Phew, that’s done! Now I promise you, the boring part is over. Better yet, if all was done correctly, you can get paid.

Submitting Your App

Before we go any further, if you really want to submit an app of your own instead of just following along, there are certain items you’ll need to get in order. Make sure you have the following ready before you even get started:

• Your app’s name
• Your app’s description
• Your app’s icon sized 512px by 512px
• At least one app screenshot. These should be sized 320×460 (no status bar); 320×480; 640×920 (retina, no status); 640×960 (retina); or, for landscape, 480×300 (no status bar); 480×320; 960×600 (retina, no status bar); or 960×640 (retina).

Once you’ve got all this assembled, click “Manage Your Applications” in iTunes Connect:

Click “Add New App”:

Choose the primary language of your app and your company name.

Be careful here. This is the only opportunity you’ll have to enter your company name. Once you click “Continue,” it will be very hard to change, so think about how you want your company name to appear in the App Store before proceeding. When you’re ready, click “Continue”:

Fill in the name of your app (it should at least be similar to the app name that appears under your app’s icon on the device), an SKU number (any number with two or more digits will do) and your bundle ID. The possible bundle IDs are pulled from the app IDs you registered in the Provisioning Portal, so choose the right one for your app.

Click “Continue” when ready:

Now you have to choose the availability date for your app. You have three choices:

• You want your app to be available as soon as it’s approved. If this is the case, just leave the date as the submission date.
• You want your app to be available at a certain date in the future. In this case, enter the date you want your app to be available. Please note that if your app is not approved by this date, then it will be released as soon as it’s approved. In other words, the date you enter is not a guaranteed release date.
• You want to choose the release date once the app has been approved. In this case, change the year to next year, or a date far enough in the future that when your app is approved, you can come back and reenter the date you want.

Now choose your price tier or indicate that your app will be free. View the Pricing Matrix for more information about the price tiers.

Check the box if you want your app to be offered at a discount to educational institutions when they purchase multiple copies at once.

Once you’re done, click “Continue”:

Set the version number (should be the same as in your app’s Xcode project), fill out the description (this is what the users will see in the app store), and select the categories appropriate for your app.

Then consider the keywords.

Keywords are very important. Only your app’s name and keywords are indexed in iTunes’ search engine, so brainstorm words that potential users might think of using to find your app or your competitor’s apps. You can only change keywords when submitting updates, so choose wisely.

Fill out a copyright notice (generally just the release year and your name or your company’s name), a contact email and affiliated websites.

The Review Notes can be used for details about your app that you want the reviewer to know. For example, if users need to sign up at a website or even within the app in order to use your app, provide a couple of credentials here to make the reviewer’s life easier.

Here’s another example: if your app requires special hardware, explain that in the Review Notes section, and try to have a way for the reviewer to use the app without the hardware.

Scroll down and fill in the required information to determine your app’s rating. Be honest, as the reviewer can make changes to this section if they disagree.

Scroll down some more to submit your graphic assets. You have to upload your app’s icon and at least one screenshot. If your app is universal, you’ll need to submit one screenshot for the iPhone and one for the iPad.

After uploading, check order of the screenshots and click “Save”:

The app is almost ready to be submitted. We just need to do one more thing. Click “View Details” below the app’s icon:

On the next screen, click “Ready to Upload Binary”:

Answer the question honestly and click “Save.” If you’re using only the default cryptography libraries supplied by Apple’s API, it should be fine for you to answer “No” here.

You’ll be provided with some instructions telling you how to submit your app. Ignore these, as there is an easier way to submit using the latest version of Xcode. Just click “Continue”:

Now your app is ready for upload. Let’s go back to Xcode and finish this journey.

Submitting with Xcode

Your application should now be tested and ready to roll. All we need to do is submit to Apple for approval. This is surprisingly easy considering what we’ve been through already.

Go to Xcode and choose iOS Device in the scheme chooser:

Then choose “Archive” from under the “Product” menu:

If everything is okay with the build, Xcode will open the Organizer window with your app in the Archives tab. You don’t really need to click “Validate…” here because this will be done when you submit anyway, and Xcode should have already validated against most problems. So save yourself some time and click “Submit…”:

Enter your iOS Developer credentials and click “Next”:

Choose the app you want to submit and your submission identity. The identity is the provisioning profile you used to sign the app and should be pre-selected. Make sure everything is correct and click “Next”:

Your app will start uploading to iTunes Connect:

When the upload finishes, you should see this message. Just smile and click “Finish”:

You’re done now. You should receive a couple of emails from iTunes Connect telling you your app has been uploaded and is waiting for review. If you go back to iTunes Connect you should see your app changing status:

After a few minutes the status should change to “Waiting For Review”:

All you have to do now is wait for your app to be approved! You will receive emails about every change in status your app moves through. Usually after about a week the status should change to “In Review,” then to “Approved.” Unless you chose a future release date, a few minutes after approval your app’s status will shift to “Processing for App Store,” then a few minutes later to “Ready for Sale.”

If your app is not approved, Apple will email you with more information. They have gotten pretty good at being specific at what the exact problem is and how you can fix it, for the most part. If this happens, it’s no big deal – just fix the problem and re-submit.

Here are the exact dates and times that cute-a-pult achieved every step of the approval process (all times are UTC):

• Waiting for Review: Fri, Jan 6, 2012 at 1:51 AM
• In Review: Wed, Jan 11, 2012 at 3:43 PM
• Processing for App Store: Wed, Jan 11, 2012 at 6:40 PM
• Ready for Sale: Wed, Jan 11, 2012 at 6:41 PM

I also submitted an update of the app a few days later, with a last scene with the purpose of the app and a few links to my first tutorial post. Here is the timing for that:

• Waiting for review: Fri, Jan 13, 2012 at 3:21 PM
• In Review: Fri, Jan 20, 2012 at 3:31 PM
• Preparing for the app store: Fri, Jan 20, 2012 at 3:53 PM
• Ready for sale: Fri, Jan 20, 2012 at 3:55 PM

The time for reviews for your apps will vary based on traffic, but in general it takes around 5-10 days for most people.

Where to Go From Here?

If you’ve followed with me all the way, that was a long journey: from no account to App Store! You may not have an app ready to submit yet, but you should feel confident about the submission and approval process once you do.

If you’ve submitted your first app along with me – congratulations are again in order! Now go get ready for your next update or your next big app!

I look forward to reading and responding to your feedback in the forums.

This is a blog post by iOS Tutorial Team member Gustavo Ambrozio, a software engineer with over 20 years experience, including over three years of iOS experience. He is the founder of CodeCrop Software.

How to Submit Your App to Apple: From No Account to App Store, Part 2 is a post from: Ray Wenderlich

This is a blog post by iOS Tutorial Team member Gustavo Ambrozio, a software engineer with over 20 years experience, including over three years of iOS experience. He is the founder of CodeCrop Software.

Learn how to join the Apple Developer program and get your app on the App Store!

This two-part tutorial series will document every step of becoming an Apple iOS developer – from literally no account, to published on the App Store!

I’ll show you how to sign up for Apple’s iOS Developer Program, how to generate the various certificates needed, how to configure your app, and how to submit to the App Store for approval.

To create this tutorial, I created a completely new App Store account and submitted a new app to the App Store, keeping careful note of each step along the way.

The app I submitted to the App Store is an improved version of the app I built during my last tutorial series, How To Make a Catapult Shooting Game with Cocos2D and Box2D. The app, cute-a-pult, has already been approved and can be downloaded for free in the App Store.

For this tutorial, you will need US$99, a valid credit card, and a browser. And it may go without saying, but to develop apps, you’ll need a Mac computer, preferably with OS X 10.7 Lion installed.

Finally, you will need Xcode, Apple’s development software. You can download Xcode once you are registered as an Apple iOS developer. Which you will be, after the first few sections of this tutorial!

It will help to approach this tutorial with some patience and perspective. Becoming a registered iOS developer is a lengthy process and is sometimes repetitive. Just remember: in the end you will be able to submit your apps to the App Store for potential fortune and glory!

Getting Started

The first step on the path to the App Store is to register as an Apple developer. Note that becoming an Apple developer is free and is not the same as becoming an iOS developer, for which you must pay the aforementioned US$99 fee.

You may already have a developer account with Apple. If so, feel free to skip this section and move on to the next.

If you don’t yet have an Apple developer account, go to the iOS Dev Center and click the “register” link:

Click “Get Started”:

On this next page, you can choose to create a completely new Apple ID or use an existing one. If you want, you can save time and use the Apple ID you already use for your iTunes purchases, for example. But I’d suggest creating a new, clean ID. It helps ensure all your data is correct, and it keeps your personal and professional lives separate.

So, select “Create an Apple ID” and click “Continue”:

Fill in your email, password and security information. Use an email address that you check often, because Apple sends frequent updates on the program and on the status of apps you’ve submitted for approval.

Scroll down, fill out your personal information and click “Continue”:

The next page contains questions about your professional profile. There are no right or wrong answers to these questions. You don’t even necessarily have to select iOS as a platform, though of course it doesn’t hurt to be accurate:

Scroll down, fill out the rest and click “Continue”:

The next page is the “oh, so fun” legal agreement. Call your lawyer and read the whole thing to him/her on the phone. As soon as you get your lawyer’s approval, click the checkbox and click “I Agree.”

Almost done.

Check the email account you entered when registering. You should have received an email just like this. Click the link in the email or just enter the number in the final page of the registration process.

Cool, you’re an Apple developer! That’s great, but can you start developing apps and submitting them to the App Store? Well, not so fast… Click “Continue” and let’s give Apple some (more) money.

Joining the iOS Developer Program

Being a registered Apple developer gives you access to a lot of information, but to be able to send apps to the App Store (and to have access to certain associated portals) you need to enroll in Apple’s iOS developer program. This is the part that will cost you US$99 per year.

If you followed along with the previous section and clicked “Continue,” you should be in the right place. If you skipped the previous section because you already have an Apple developer account, then go to the Developer Member Center, log in, and you’ll be in sync.

Once logged in, click the “Join Today” link on the right of the page:

This next page is just a preview of the “what looks like 3 steps but is really 15″ process. Take a deep breath, make sure you have half an hour to spend, and click “Continue”:

Choose to use your existing Apple Developer ID and click “Continue”:

The next page asks if you want to enroll as an individual or as a company. For this tutorial, I’m enrolling as an individual, as this is what most of you will do. If you choose to enroll as a company the process won’t be as easy. You will need to submit a lot more paperwork to prove your involvement in the company.

If you do choose to enroll as a company, read the requirements on the right to make sure you have everything you’ll need.

Otherwise, just click the “Individual” button on the left, and let’s continue.

You’ll have to provide your newly-created credentials again. Fill out the form and click “Sign In.”

Enter your billing information to verify your identity. Apple will attempt to confirm this information with your credit card company, so make sure you enter it correctly:

Scroll down, fill in the remaining fields and click “Continue”:

It’s time to select a program. This tutorial series focuses on the iOS Developer Program, so that is the only option I will select. If you want to develop OS X apps, you can also choose to enroll in the Mac Developer Program, but this will cost you another US$99. (You can always sign up later, so don’t worry if you aren’t sure.)

Once you’ve selected your programs, click “Continue”:

Review your information, going back to correct any mistakes if necessary. When you’re ready to submit, click “Continue”:

Next we have yet another “oh so fun” license agreement. So call your lawyer again, get the OK to check the box and click “I Agree”:

Note: The following steps only apply to the US and other countries with online Apple Stores. For countries without online Apple Stores, the process will be slightly different, requiring you to fax your credit card information to Apple. Unfortunately, readers in those countries, you’ll be on your own for the remainder of this section. So, follow Apple’s instructions and meet me again in the next section.

For everyone still following along, click “Add to cart”:

This brings us to the Apple Store to continue the process. Click “Check Out Now”:

You’ll have to log in yet again. Use your newly created Apple ID.

You need to enter a “shipping address,” even though Apple is not going to ship you anything. I suggest you use the credit card billing address you entered previously (and will enter again shortly!). Fill out the form and click “Continue”:

Click “Continue” again:

Now enter your billing information and credit card number once again, and click “Continue”:

We’re almost done. The page you are on now might show estimated sales tax, as mine did, which you may or may not be charged (I was not). Once you’re ready, click “Place Order Now”:

You’re welcome!

Now, Let Me In!

After submitting and paying for your iOS Developer registration, you’ll need to wait a day or so for Apple to process your order.

If you had to fax your information to Apple because you’re in a country without an online Apple Store, you’ll need a little more patience. This was the case for me when I originally signed up, and it took a week for Apple to get back to me.

In either case, eventually you should get an email from Apple like this one:

At the same time, you should receive this email:

It is as this point that you should download Xcode, the main iOS development tool, if you have not already, using your new iOS Developer credentials. While we will only be using Xcode very briefly in this tutorial, there are many other excellent tutorials on RayWenderlich.com to teach you how to use it!

Now go to the iOS Dev Center and click “Log In”:

After providing your credentials, you’ll be in! Finally!

The iOS Dev Center has a LOT of information. There are programming guides, downloads, documentation, videos, the very helpful developer forum and a support center.

Spend some time exploring to familiarize yourself with what’s available. Be aware that some of this information might be confidential, especially if it involves beta versions of iOS or Xcode.

In this tutorial, we’re going to focus on two portals that you’ll use a lot when developing your apps, the iOS Provisioning Portal and iTunes Connect:

But first, a brief introduction to both is in order.

iOS Provisioning Portal

As we should all know, a non-jailbroken iOS device is only able to run apps approved by Apple and installed through the App Store.

Apple achieves this by requiring that every app run by iOS have a signed Apple Certificate. Apps installed from the App Store come bundled with a certificate, which the system verifies before it allows the app to run. If there’s no signature or if the signature is invalid, the app won’t run.

As developers, we need to be able to run our apps on our devices on a regular basis as we’re developing them. For this we need a way to create and sign our own certificates.

That’s where the iOS Provisioning Portal comes in. The portal allows you to generate what Apple calls “profiles.” Profiles, sometimes called “code signing identities,” are files generated by the portal that allow Xcode to sign your apps in a way that your devices’ iOS will identify as valid.

There are two types of profiles:

• Development profiles. These are tied to specific devices, so the app can only run on those devices.
• Distribution profiles. These are used to sign your app before you submit it to Apple for approval. They contain no device-specific information, but you can’t use them to install apps on any device yourself, because Apple still has to sign the app after the approval process.

The Provisioning Portal can also generate push certificates in case your app wants to send push notifications (think: pop-ups sent from your server when something occurs).

iTunes Connect

iTunes Connect is the portal you’ll use to submit your apps. This is where you’ll register a new app, enter the app’s description and screenshots, choose the price, and configure game center and in-app purchases.

This is also the portal you’ll use to agree to new contracts, set your financial data (so you can bank that profit) and check your sales.

We’ll spend the rest of this tutorial using the Provisioning Portal. Next time, in Part Two, I’ll introduce you to iTunes Connect.

Certificates, Device Registration, and Profiles

In this next part of the tutorial, we’re going to use the iOS Provisioning Portal to set up the information we need in order to deploy our app to our device (and later the App Store).

Note that there is a simpler way to do this in Xcode called Automatic Device provisioning, that we will cover in part two of the series. But for now, I’m going to take you through the process step by step. You’ll understand how things work better this way, which is especially important information to know when submitting to the App Store.

If you still have your iOS Dev Center page in front of you, just click the link on the upper right, or go here:

There are a lot of things you’ll need to do from this portal. Some of them you’ll only have to do once, like generating your certificates and registering your devices. Other things you’ll have to repeat for every app you make, like generating development and distribution profiles.

First you’ll need to generate two certificates, one for your development profiles and another for your distribution profiles.

Let’s click on the “Certificates” link to get our certificates:

Click “Request Certificate”:

The next page explains how to ask for a certificate. I’ll guide you through the process.

Let’s leave the browser for a little while and open the Keychain Access app on your Mac. If you don’t know where it is, search for it using Spotlight:

Once the program is open, from under the Keychain Access menu choose “Certificate Assistant,” then “Request a Certificate From a Certificate Authority…”:

In the Certificate Assistant window, fill in your email address and name, choose “Save to disk” and click “Continue”:

Save the file somewhere on your Mac.

Go back to your browser, find this file using the “Choose file” button and click “Submit”:

Apple will take some time to generate a certificate for you. I’ve seen it take a few minutes, but sometimes it can take a lot longer. While we wait (the status might say “Issued,” but the certificate isn’t actually ready until a download button appears), let’s do something else we need to do anyway.

You should see a message at the bottom of the “Current Development Certificates” section that says, “If you do not have the WWDR intermediate certificate installed, click here to download now.” Click that link.

This will download a file called AppleWWDRCA.cer. Double-click this file to install it. It will open Keychain Access again in case you closed it. Once the file is installed, keep Keychain Access open because we’ll need it again in a few minutes.

You’ll also need a distribution certificate. Click the “Distribution” tab and submit the same certificate signing request as for the development certificate. I’m not a security expert, but I think reusing the same certificate signing request in this case is not a big deal. Feel free to correct me if I’m wrong.

Again, it sometimes takes a while for the certificate to become available for download. We need both certificates to continue, so if you’re still waiting, go get a coffee or peruse another great tutorial on the site, and come back later.

Once both are ready, click the “Download” button under the Development and Distribution tabs to get both certificates.

Double-click both files to install them in your keychain. You should see your certificates as follows:

Now you can close Keychain Access.

Let’s continue. The next step is to register our devices. On the left-side menu, click “Devices” and then on the right, “Add Devices”:

You need to get the UDID of the device(s) you want to use to run your apps. There are many ways to get a device’s UDID: there are free apps available that will do it for you, or you can use Xcode’s organizer. I’ll show you how to get a UDID using iTunes.

Open iTunes and plug the device into your computer. Select the device from the left-side menu. iTunes will display your device name, capacity, version, serial number and phone number. Click on the serial number and it will change to your device’s UDID:

Now just use CMD-C to copy the UDID to your clipboard.

Go back to your browser, enter a device name and paste the UDID into the appropriate field. The device name can be anything you want. To register additional devices, click the “+” button. When you’re done, click “Submit.”

You can always go back later to register more devices, such a those belonging to friends and beta-testers. Apple allows you to register up to 100 devices per year to your account. (Note that if you register a device and later remove it, it still counts towards your total for the year.)

Now that our device is registered, we need to register an app ID. Every app you build will need its own app ID. Click “App IDs” on the left-side menu:

You’ll see a detailed explanation of the app ID concept. In a nutshell, an app ID is a combination of a 10-character “seed” prefix generated by Apple, and a bundle ID created by you. Together they create a unique identifier for your app.

Here are some important things to know about app IDs:

• You can elect to have all of your apps share the same seed prefix, if you want to share keychain information between them. Say you have a suite of apps that all make use of the same website via a login. If the apps share the same seed prefix, and one app saves the user’s login information to the iOS keychain, any other app in the suite can get this login information from the keychain.
• The bundle ID has to be unique for each of your apps. It will be used by Apple’s push service for in-app purchases and for iCloud storage.
• Apple recommends that you use “a reverse-domain name style string” for the Bundle Identifier portion of the app ID. The suggested format is “com.domainname.applicationname.”
• Apple does allow you to use an asterisk character to create a “wildcard” bundle ID that can be used across all your apps, but I don’t recommend this approach.

  Using an wildcard may make it easier to create provisioning profiles, but you won’t be able to use push services or in-app purchases. You might not plan to use these services now, but if you change your mind, you won’t be able to change your app ID without creating a new app.

Now that you know all about app IDs, let’s create one. Click “New App ID.”

Fill out the description (usually just your app’s name) and the bundle identifier. The seed ID will always be your team seed ID. (In the past there was a way to have more than one seed ID, but this seems to have been disabled.)

Remember to use a reverse-domain name style string for your bundle ID. Click “Submit” when done:

Now we’re ready for the last step (for now) inside the Provisioning Portal: creating the provisioning and distribution profiles.

Click “Provisioning” on the left-side menu and “New Profile” on the right:

Fill in your app’s name as the profile name, select the certificate, choose the app ID you just created, and finally select the devices you want to use to test your app. Click “Submit”:

When you return to this page, the status of your profile will be “Pending” as Apple generates the file for you. Usually if you just click the “Development” tab again, you’ll see your status has already changed to “Active” and a “Download” button has appeared.

Before we download the file, let’s go ahead and generate the distribution profile. We won’t actually need the distribution profile until we’re ready to submit the app for approval, but since we’re here, let’s do it now.

Click the “Distribution” tab at the top of the page and click “New Profile.”

Choose “App Store” as the distribution method, enter a profile name (can’t be the same name you used in the development profile), choose your app ID and click “Submit.”

I won’t go into detail here about Ad Hoc distribution, since distribution is not the subject of this tutorial. You can learn more about Ad Hoc distribution here.

Your provisioning profile should be ready. Go back to the “Development” tab, click “Download” and save the file to your computer. Do the same for your distribution profile by clicking the “Distribution” tab and clicking “Download.”

Now find the files you just downloaded on your computer, and double-click them. They should open in Xcode’s organizer:

Where to Go From Here?

If you completed the process along with me, then you’ve taken a huge step by becoming an official iOS Developer – congratulations! Even if you’re still contemplating it, I hope the process is now less intimidating.

In Part Two of this tutorial series, we’ll have some fun getting our app running on a device and submitting it to the App Store. And I’ll show you how you can get your apps running on your device quickly with Xcode’s Automatic Device Provisioning feature!

If you have any questions or comments about what we’ve done so far, please join in the forum discussion below!

This is a blog post by iOS Tutorial Team member Gustavo Ambrozio, a software engineer with over 20 years experience, including over three years of iOS experience. He is the founder of CodeCrop Software.

How to Submit Your App to Apple: From No Account to App Store, Part 1 is a post from: Ray Wenderlich

iOS Apprentice Tutorial 4: StoreSearch now available!

If you signed up for the monthly iOS newsletter on this site, you have received a free copy of the iOS Apprentice Tutorial 1: Getting Started by Matthijs Hollemans.

In addition to the free tutorial you can get by signing up for the newsletter, you may have purchased tutorials 2 & 3, which are for sale on the raywenderlich.com store.

So far, the iOS Apprentice has been a massive success. We’ve received a ton of happy feedback from customers, several teachers have decided to base coursework around the series, and the series has had over 1,000 customers so far!

If you enjoyed these tutorials, we have some good news – today a new iOS Apprentice Tutorial is available for purchase! Keep reading to find out what it’s about, how you can get it, and what to do if you previously purchased the iOS Apprentice 1-3 Bundle.

iOS Apprentice Tutorial 4: StoreSearch

So far in the iOS Apprentice, you learned how to use Xcode, Interface Builder, and Objective-C to make apps ranging from a very simple game, to Storyboard-driven apps with multiple screens and Core Data models.

In this tutorial, you’ll take things to the next level by learning how to integrate your apps with web services! In this tutorial, you’ll learn how to upload and download data from web services with HTTP requests and how to handle JSON data.

You will build an app that lets you search the iTunes store, that looks something like this:

In this tutorial you will connect to a web service to pull down a list of items for sale on the iTunes store and their images. To make navigation easy, you’ll add search capability to your old friend, the table view. You’ll also create an animated popup with extra information when you tap an item in the table. and when you flip the iPhone over to landscape, the layout of the app will completely change to show the search results in another way.

You’ll also create an iPad version of the app:

And as you can see, you’ll learn how to make the app look quite stylish! :]

Here’s what you’ll learn in this tutorial:

• How to use a web service from your apps and how to download images
• Integrating third-party libraries such as AFNetworking
• View controller containment: how to embed one view controller inside another
• The rules for memory management so you can use older code in your ARC-enabled apps
• Showing a completely different UI after rotating to landscape
• Cool effects with keyframe animations
• How to use scroll views and the paging control
• Internationalization and supporting multiple languages
• Changing the look of navigation bars and other UI elements
• Making iPad apps with split-view controller and popovers
• Using Ad Hoc distribution for beta testing
• And finally, submitting your apps to the App Store!

Just like the other tutorials in the iOS Apprentice series, this tutorial has easy to follow step-by-step instructions, and consists of more than 200 pages and 150 illustrations! You also get full source code, image files, and other resources you can re-use for your own projects.

How Can I Get It?

If you’re interested in purchasing the iOS Apprentice 4: StoreSearch, click here to visit its page on the raywenderlich.com store.

Note you have two options: you can purchase the tutorial individually ($24), or purchase all 4 tutorials for $54, which gives you a sweet discount ($18 in savings)!

What If I Purchased the iOS Apprentice Tutorials 1-3 Bundle?

If you purchased the iOS Apprentice Tutorials 1-3 Bundle in the past, we have good news for you!

To thank you for supporting the development of the iOS Apprentice and this website, you will get a massive discount on the iOS Apprentice Tutorial 4. Individually the iOS Apprentice costs $24, but you can get it for just $9!

To get this special discount, check out the iOS Apprentice private forums for more details. If you do not yet have access to the iOS Apprentice private forums, you can sign up for access here.

I am also trying to set up a mailing list for iOS Apprentice customers to make future communication easier, but in the meantime just check out the forums.

Thank You!

Again, if you are interested in the iOS Apprentice, just click here to visit its page on the raywenderlich.com store.

Thank you all for your support – purchasing products like this is what makes everything we do on this site possible.

If you have any questions or comments, please join the forum discussion below – Matthijs and I would be glad to help you out! :]

iOS Apprentice Tutorial 4 Now For Sale! is a post from: Ray Wenderlich

This is a post by special contributor Bogdan Vladu, an iOS application developer and aspiring game developer living in Bucharest, Romania.

Create a game like Jetpack Joyride with LevelHelper and SpriteHelper!

Hello again, and welcome to the fourth and final installment of the tutorial series on LevelHelper and SpriteHelper. I said by the end of this series you would have an exciting game to play, and we’re almost there!

Last time, in part three, we came close to completing our game. We fully implemented collisions between the player and the other game elements, enabling the player to die and score points. We also made the player fly and added some nice sounds and animations.

But there are still a few improvements we can make. For one thing, we need a way to keep track of the score, and while we’re doing that we might as well add some cute moving bunnies that will be worth more points.

Our game looks nice, but I’ll take you through adding a background layer to give the illusion of a never-ending outdoor scene visible through the windows. We’ll make the background layer move so that the scene through the windows is always slightly different.

And wouldn’t it be interesting if we made some of our lasers rotate? Keep reading to complete the game!

Getting Started: Rotating Lasers

We’re picking up with the project as we left it at the end of Part Three. You can download that version of the project here.

The first thing we’re going to do is make our lasers rotate. We can’t have this game be too easy! So open up your project in LevelHelper, and make sure you have the latest version of your level open.

The first step is to go to Define Tags and define a new tag. Call it ROTATING_LASERS.

We will use this new tag to reference the lasers we select to rotate (not all of them… we’re not that evil, are we?) when we implement the rotation via code.

Now select a couple of the lasers in the level. Make sure the lasers you select have room to rotate. Assign the ROTATING_LASERS tag to these lasers.

Once you’re done tagging the lasers, save the level and open your Xcode project. Navigate to HelloWorldScene.h and add the following in the class definition:

NSArray* rotatingLasers;

Then place the following at the end the retrieveRequiredObjects method in HelloWorldScene.mm:

rotatingLasers = [lh spritesWithTag:ROTATING_LASERS];
[rotatingLasers retain];

Here we take reference to all the sprites that have the tag ROTATING_LASERS. Because the array returned by this method is autoreleased, we need to retain it. In order to not forget to release this retained array, go to the dealloc function and add the following before the LevelHelperLoader object release:

[rotatingLasers release];

Now that we’ve grabbed the lasers that we want, let’s make them rotate! Go inside your tick method and write this at the end:

for(LHSprite* laser in rotatingLasers)
{
    [laser transformRotation:[laser rotation]+1];
}

If you run the game now, the chosen lasers will rotate, but the player won’t die when it makes contact with them. This is because we haven’t registered a collision event for the ROTATING_LASERS tag. To do that, add the following inside the setupCollisionHandling method:

[lh registerPreCollisionCallbackBetweenTagA:PLAYER andTagB:ROTATING_LASERS idListener:self selListener:@selector(mouseLaserCollision:)];

Running the game now, the lasers will rotate and kill the player just as the non-rotating lasers do. Congrats, you have just added another layer of difficulty to our game. That said, you may want to play-test the game some more at this point to make sure the player can still get through the level!

Moving Bunnies

Running and flying over sleeping cats and dogs and dodging rotating lasers is all fun, but let’s add another reward component to the game to give it more complexity. I have just the ticket: bunnies. Cute, helpless bunnies that our player can kill for points.

Open SpriteHelper, and go to File\New. Then open Finder and navigate to the ArtPack folder (download it from Part One if you don’t have it), select the bunnies images and drag them into the SpriteHelper window. Then click the “Pack Sprites” button.

Now select all the sprites in the list and enable the “Is Sensor” option from the Physic Properties menu. (Note that our other reward component, coins, are also sensors.)

Next, create the following two animations using the bunny frames:

Animation Name: BunnyRun
Speed: 0.400
StartAtLaunch: YES
LoopForever: YES
Frames: bunny_1, bunny2

Animation Name: BunnyDie
Speed: 0.400
StartAtLaunch: YES
LoopForever: NO
Frames: bunny__die_1, bunny_die_2

When you’re done creating the animations, save the scene inside the Images folder of your Xcode project.

Going back to LevelHelper, we can see the bunny animations inside the Animations section. Select the BunnyRun animation and drag it into your level.

We now have a bunny in the level, but it will not be visible because we need to move him with the
parallax.

To add the bunny to the parallax, go to the Parallax tab, select our parallax and add the bunny sprite to it. Set the x component of the movement ratio to 1 so that the bunny moves at the same speed as our level.

If we run the level in Scene Tester we cannot see the bunny. This is because we need to set the batch z order on the bunny image.

Navigate the the Images section and set the batch z on the bunny image to 3. This will put the bunny in front of everything except the player.

Running the level again in Scene Tester, we can see the bunny moving with the parallax, but the bunny appears to be moving in place. We want the bunny to move from right to left and from left to right. To do this, we have to make him move on a path.

Navigate to the Beziers section and click NEW to create a new bezier that will describe the path of the bunny.

Click within the level view to draw the bunny’s path, and click the Finish button when you’re happy with the bezier.

Now select the “Path” option in the bezier properties to tell LevelHelper to treat that bezier as a path.

Note:

• By default, beziers are a simple line. You can make them true beziers by deselecting “Line” in the properties menu.
• You can edit a bezier by pressing the Edit button and then dragging the points.
• While editing the bezier, you can create a new point by holding COMMAND and clicking on a line of the bezier.
• While editing the bezier you can remove a point by holding ALT (Option) and clicking on a point.

Well, now we have our path defined, but the bunny sprite doesn’t know that it should move on that path. Let’s make the bunny aware of this.

Select the bunny, then in the General Properties section, click on Path.

In the Path Settings dialogue, select the bezier that describes the path from the list, then make the motion cyclic by selecting “Cyclic Motion.”

Set the amount of time you want the bunny to take to move from one end of the bezier to the other. Then select “Flip Sprite X At Ends” so that the bunny is always facing in the direction it is moving. Otherwise, it will appear to be moving backwards half the time.

If you run the level inside Scene Tester now, the bunny should move on the path and also move with the parallax. This is cool, eh? LevelHelper is the only editor that lets you move sprites on a path and with a continuos scrolling parallax at the same time.

The last step in LevelHelper is to define a new tag called “BUNNY” and assign it to the bunny sprite. Once you’ve done this, save the level.

Time to move back to our Xcode project. We have created a new image: the bunny. So we have to add the new image files to the Images folder inside Xcode.

The contents of your project’s Images folder should now look like this:

Now let’s write some code that will make the bunny die when the player collides with it.

Add the following at the end of the setupCollisionHandling method:

[lh registerBeginOrEndCollisionCallbackBetweenTagA:PLAYER andTagB:BUNNY idListener:self selListener:@selector(mouseBunnyCollision:)];

This informs LevelHelper of the collision callback, but we also need to define the method for the callback. Add the following before the setupCollisionHandling method:

-(void)mouseBunnyCollision:(LHContactInfo*)contact
{    
    if(playerIsDead)
        return;
 
    LHSprite* bunny = [contact spriteB];
 
    if(nil != bunny)
    {
        if([[bunny animationName] isEqualToString:@"bunnyRun"])
        {
            [self scoreHitAtPosition:[bunny position] withPoints:500];
            [[SimpleAudioEngine sharedEngine] playEffect:@"bunnyHit.wav"];
        }
 
        [bunny startAnimationNamed:@"bunnyDie"];
 
        [[bunny pathNode] setPaused:YES];
    }
}

In the above code, we test for a dead player and do nothing if that’s the case. We then take the bunny sprite from the contact and test if it’s valid and whether it’s running the “bunnyRun” animation.

If the bunny sprite meets both conditions, we give 500 points to the user and play the bunny hit sound (part of the sound pack downloaded in Part Three of this series). We then start the bunnyDie animation on the bunny sprite and stop the sprite’s movement on the path.

If you run the game now, you’ll see that the bunny dies when he collides with the mouse. But if you loop through the entire level, you’ll see that the bunny you killed doesn’t reappear in the level: it stays dead! So let’s do the same thing we did with the coins in Part Three and reset the bunny.

Find your spriteInParallaxHasReset method and modify it to look like this:

-(void) spriteInParallaxHasReset:(LHSprite*)sprite
{    
    if(COIN == [sprite tag]){
        [sprite setVisible:YES];
    }
    else if(BUNNY == [sprite tag]){        
        [sprite startAnimationNamed:@"bunnyRun"];        
        [[sprite pathNode] setPaused:false];
    }    
}

Above, we simply check for the BUNNY tag, and when we find a sprite that is a bunny, we set its animation to bunnyRun and unpause its path movement.

The complete project up to this point can be downloaded here.

Displaying the Score

We’re going to implement a dynamic way of showing the score. Instead of having a fixed display at the top or bottom of the screen, we’re going to show the score in a temporary pop-up window each time the user scores.

Begin by adding the following inside HelloWorldScene.h:

CCLabelTTF *scoreText;

Now define this new method somewhere before the init method inside HelloWorldScene.mm:

-(void) setupScore
{
    score = 0;
 
    CGSize winSize = [[CCDirector sharedDirector] winSize];
    scoreText = [CCLabelTTF labelWithString:@"Score: 0" dimensions:CGSizeMake(200, 50) alignment:UITextAlignmentLeft fontName:@"Arial" fontSize:22];
    scoreText.color = ccWHITE;
    scoreText.position = ccp(100, winSize.height-25);
    [self addChild:scoreText z:20];    
}

Here we create a new label and assign it to our scoreText variable. We then add this label to the Cocos layer, in our case “self.” And we set the label position to be the top left corner.

Now call this new method inside the init method right after the call to setupAudio:

[self setupScore];

This is good, but right now we’re not showing the actual score to the user. We’re just showing some text. Let’s make the text change when the user gets points.

Modify your scoreHitAtPosition method to look like this:

-(void)scoreHitAtPosition:(CGPoint)position withPoints:(int)points
{
    score += points;
    [scoreText setString:[NSString stringWithFormat:@"Score: %d", score]];
 
    NSString* curScoreTxt = [NSString stringWithFormat:@"+ %d", points];
    CCLabelTTF *curScore = [CCLabelTTF labelWithString:curScoreTxt fontName:@"Marker Felt" fontSize:24];
    curScore.color = ccWHITE;
    curScore.position = position;
    [self addChild:curScore z:20];
 
    id opacityAct1 = [CCActionTween actionWithDuration:1 key:@"opacity" from:255 to:0];
    id actionCallFunc = [CCCallFuncN actionWithTarget:self selector:@selector(removeScoreText:)];
    id seq = [CCSequence actionOne:opacityAct1 two:actionCallFunc];
    [curScore runAction:seq];
}

Here we add the new points to the score variable. Then we set the text of our score label to be the newly updated score.

We then create a new label that will be displayed at the position we get in the attribute of this method. As shown in the code, this is the position of the coin or bunny triggering the score update. The coin or bunny vanishes upon collision with the player, and a score display temporarily appears in its place.

We add the new label to the layer (in this case self). We then create two actions. The first action makes the new score label disappear in one second by changing the opacity property of the sprite from 255 (full visibility) to 0 (not visible). The second action calls a new method, removeScoreText.

Lastly, we create a sequence using the two defined actions and run that sequence on the new label sprite.

We still need to define the removeScoreText method called by the second action. Add the following above the scoreHitAtPosition method:

-(void)removeScoreText:(CCLabelTTF*)scoreLabel
{
    [scoreLabel removeFromParentAndCleanup:YES];
}

This new method just removes the score display from the layer.

Run the game now and see how nicely this works. Every time the player makes contact with a coin or a bunny, a label pops up showing the updated score, displays for one second, then disappears.

Adding An Outside Layer

Now for our last tweak: an “outdoor” scene that will be visible scrolling through the windows in the level, adding a nice sense of depth to the gameplay.

Open SpriteHelper and create a new scene with File\New. Then open Finder, navigate to the ArtPack folder, select the bgWindow, window_background, and window_foreground images, and drag then on the SpriteHelper window.

Press Pack Sprites to pack the new sprites. Because one of the images doesn’t have alpha, a new window will ask you if you want to crop the image using a selected color. Choose Don’t Crop.

Select all the sprites and set the “No Physics” option from the Physics tab. Save the scene as “outside” and place it in the Images folder.

Back in LevelHelper, let’s create a new level in order to see the steps. With level03 opened, press Command-Shift-S to save the level as a new level. Give it the name level04 and save it inside the Levels folder.

Now inside the level view, select all the window sprites as well as all the background sprites from under the windows.

Delete the sprite by pressing the Delete key or clicking the red minus sign button on the left.

After the removal of these sprites, the scene should look something like this:

Double-check that you’ve removed all of the window and under-window background sprites, and save the scene.

Now filter the outside sprites by checking the “filter” option next to outside.png. This will make it so that we only see the sprites from that image in the list above. Set the batch z order for outside.png to -1 to put all the sprites in outside.png behind everything else.

Next, drag the bgWindow sprite and place it in the empty spaces left when you removed the windows and background sprites.

When you’re ready, select all the new sprites with the window cut (all bgWindow sprites) and set their Z Order to 1.

Add these new sprites to the parallax and set the x component of the movement ratio to 1. Save the level.

Press the Test Level button to run the scene in Scene Tester. You may notice some of the new sprites have “noise.” That’s because some of the positions of the new sprites aren’t lining up correctly with the old sprites.

There are two ways to fix this problem:

1. Adjust every mismatch individually by selecting each sprite and moving the sprite using the arrow keys until it lines up correctly with the other sprites.
2. Select all of the misaligned sprites and set Scale X in the General Properties menu to 1.01, or a value that cancels the noise.

Save the level when you’re satisfied with how the sprites are positioned.

Now that everything is in place, let’s create a background that will move at a different speed from the rest of the parallax.

First let’s lock the sprites already in the level so that we don’t accidentally move them. To do this, select all the sprites from the list on the left, and click the Lock button.

Note: To unlock sprites, select them in the list and press the Lock button again.

With the sprites locked, drag the window_background sprite into the scene and place it above the main screen. Make sure that the left vertical border of the window_background sprite is lined up exactly with that of the main screen.

Now make sure the window_background sprite is selected, and duplicate it to the right until the end of the game world by using the green + button (or pressing Command-D). Make sure that you have the correct anchor point selected.

The level should look like this when you’re finished:

Now select all the new window_background sprites and add them to the parallax. Set the x component of the movement ratio to 0.3.

Repeat this process for the window_foreground sprite.

Drag it into the scene and position it above and in alignment with the window_background sprites:

Clone it until the end of the game world:

Add it to the parallax and set the x component of the movement ratio to 0.7:

Now select all the window_background sprites and drag them down onto the main scene so that you can see them through the window.

Repeat the process for the window_foreground sprites. Drag all of the sprites down until you can see them through the window.

Save the level when you’re done.

Running Scene Tester now, you should see the outside world moving at a different speed than the inside world. This makes it seem to the user that they are never seeing quite the same outside image through the window, making the game world feel more three-dimensionally “real.”

The last thing we have to do is add the new level and images to our Xcode project. Drop the new level (“level04”) into the Levels folder in Xcode. Your new Levels folder should look like this:

Then add the new image files (outside.png, outside-hd.png, outside.pshs) to the Images folder. Your new Images folder in Xcode should look like this:

Inside HelloWorldScene.mm, change the loading level code so that it loads the level04 file:

lh = [[LevelHelperLoader alloc] initWithContentOfFile:@"level04"];

There’s nothing left but to run the game and enjoy!

Where to Go From Here?

Congratulations, you’ve finished the game! It’s been a long journey. I hope you enjoyed creating this wonderful game with me, and hardly noticed you were learning in the process. Thanks for reading!

An example project with all of the code from the entire tutorial series can be downloaded here.

As always, I am available to answer questions in the forums for this tutorial series, both here and on the LevelHelper forum.

This is a post by special contributor Bogdan Vladu, an iOS application developer and aspiring game developer living in Bucharest, Romania.

How to Make a Game Like Jetpack Joyride Using LevelHelper & SpriteHelper – Part 4 is a post from: Ray Wenderlich

This is a post by special contributor Bogdan Vladu, an iOS application developer and aspiring game developer living in Bucharest, Romania.

Create a game like Jetpack Joyride with LevelHelper and SpriteHelper!

Welcome back to our Jetpack Joyride tutorial series! In this tutorial series, we are making a game similar to Jetpack Joyride using Cocos2D and Box2D, and the LevelHelper and SpriteHelper tools.

So far, we’ve got a mouse that can use his jetpack to fly through a scrolling level, complete with animations and endless scrolling. Check out how we did it in part one and part two.

I hope you enjoyed the first two parts, but, psst… part three is where we get to the really fun stuff!

In this part of the series, we’ll make our game fully capable of handling collisions.

In other words, by the end of this part we’ll be able to reward and kill the mouse! :]

We’ll also add sounds, more sophisticated animations, and we’ll iron-out some problems with game play.

So what are you waiting for – time to give our mouse the ride of his life!

Getting Started

To continue with this part of the tutorial series, first make sure that you have the complete project from Part Two, available here.
You will also need to download this sound pack, which we will be using later on.

To open our project in LevelHelper, navigate to your last project folder in Finder and double click on the file RocketMouse.lhproject.

LevelHelper should open the last level we were working on. If for some reason LevelHelper opens an earlier version of the level, just go to the Levels section to find and open the latest version.

Implementing Collisions: Overview

Our game has a flying mouse and shooting lasers (with the help of animations), and it also has coins for the player to collect. However, if you run into the coins or lasers nothing happens – so it’s time to add some gameplay for that!

Before we do so, however, let’s take a look at how things are currently set up.

In LevelHelper, right click the coin in the right sidebar (first tab) and select Open SpriteHelper Scene. Select the coin in SpriteHelper, and you’ll see that in the physics section, we have the “Is Sensor” option checked:

We have this checked because we want the player to trigger a collision response when it touches a coin, so that we know to give points to the user, but we don’t want the mouse to behave like it’s colliding with the coin.

What about the laser? If we look at the laser property, this sprite does not have the “Is Sensor” option selected:

Why? Don’t we want the same behavior? We do, but our need to keep track of our lasers’ animation requires us to to handle them differently.

If a sprite has Is Sensor selected, the collision will be triggered only when the mouse first touches the sprite. But for our lasers, we need the possibility of continuous collisions (every frame), because from one frame to another the animation of the laser might change (from off to on, for example) while the player is still in contact with the laser.

If we have Is Sensor enabled for the lasers, and the player makes contact with a laser when the laser is off, we have a collision response – but we wouldn’t fry the mouse, because after all, the laser is off.

But then the laser turns on. But because the collision already has been performed, we have no way of knowing if the player is still touching the laser.

How can we solve this? Well, it’s easy. Using LevelHelper’s collisions behavior together with Box2d, we can disable the collision response so that the mouse will move over the laser without behaving like it’s colliding with it. This way we will have collision trigger on every frame, and we’ll know if we need to kill the player.

Implementing Collisions: Coins

OK, finally time to code! Open up your Xcode project, navigate to HelloWorldScene.mm and declare this new method before init:

-(void) setupCollisionHandling
{
    [lh useLevelHelperCollisionHandling];
    [lh registerBeginOrEndCollisionCallbackBetweenTagA:PLAYER andTagB:COIN idListener:self selListener:@selector(mouseCoinCollision:)];
}

Next, call this new method at the end of init (right after the call to retrieveRequiredObjects):

[self setupCollisionHandling];

So what have we done here?

In the setupCollisionHandling method, we first tell to the LevelHelperLoader instance that we want to use its collision handling and not create our own collision handling. My advice is: always use this, because its fast, easy and painless.

On the second call, we register a method that we want LevelHelper to call whenever a collision between a sprite with the tag PLAYER (in our case the mouse sprite) and a sprite with the tag COIN (in our case any coin sprite) happens.

Remember how we set up collision tags for these in part two? Well LevelHelper automatically generates constants for these so we can use them in code! You can control-click on one of them and choose “Go to definition” if you’re curious where they are defined.

LevelHelper collision handling has multiple types of collision but here we use beginOrEnd because our coin sprites are defined as sensors and Box2d handles collision for sensor objects only on “begin” collision types.

Now let’s define the methods that will be used for collision responses between the mouse and coin. Add this new method right before setupCollisionHandling:

-(void)mouseCoinCollision:(LHContactInfo*)contact
{        
    LHSprite* coin = [contact spriteB];
 
    if(nil != coin)
    {
        if([coin visible])
        {
            [self scoreHitAtPosition:[coin position] withPoints:100];
        }
 
        [coin setVisible:NO];
    }
}

As you can see, this method gets a LHContactInfo* object as an argument. This is a special class that will give us info about the collision.

So how do we get the coin sprite from this collision? Well, we register the coin sprite as being tagB in a call to registerBeginOrEndCollisionCallbackBetweenTagA andTagB. So if tag B is the coin, then we take the sprite using [contact spriteB].

If you want to learn more about the LHContactInfo class, check out the official LevelHelper documentation.

Next, we make sure the coin is not nil. This is not strictly necessary, but it’s a good way to avoid errors. As a general note, it’s always good to check against nil.

If the coin is visible, we call a method that we’ll write in a minute to give points to the user for taking the coin. We then make the coin invisible in order to hide it from the screen and give visual feedback to the user that he now has the coin in his virtual wallet.

Compiling now will give an error, because we did not define the scoreHitAtPosition method. Let’s define it now. Put the following before the mouseCoinCollision method:

-(void)scoreHitAtPosition:(CGPoint)position withPoints:(int)points
{    
    score += points;
}

Declare the variable score inside the HelloWorldScene.h:

int score;

Compile and run the game, and you’ll see that when the mouse collides with the coins, the coins disappear!

Implementing Collisions: Lasers

The next step is to handle the collision between the lasers and the mouse.

Inside the setupCollisionHandling method, add the following at the end:

[lh registerPreCollisionCallbackBetweenTagA:PLAYER andTagB:LASER idListener:self selListener:@selector(mouseLaserCollision:)];

Here we’ve registered a pre collision callback between the player and the lasers. Now we need to define the mouseLaserCollision method.
We did this because the laser sprites are not sensors and we want to receive notification about this collision on every frame in order to kill the mouse when the laser has become active.

Put the following after the mouseCoinCollision:

-(void)mouseLaserCollision:(LHContactInfo*)contact
{        
    LHSprite* laser = [contact spriteB];
 
    int frame  = [laser currentFrame];
 
    // If we make the laser a sensor, the callback will be called only once - at first collision.
    // This is not good as we want to kill the player when the laser changes to active.
    // So we disable the contact so that the player and laser don't collide, but trigger a collision.
    // Disabling the contact is only active for one frame,
    // so on the next frame the contact will be active again, triggering the collision.
 
    b2Contact* box2dContact = [contact contact];    
    box2dContact->SetEnabled(false);
 
    if(playerIsDead)
        return;
 
    if(frame != 0)
    {
        [self killPlayer];    
    }
}

In the above code, we take the sprite B from the contact info. In our case sprite B is the laser. Then we take the current frame from the sprite, because we need to test if the laser is active and kill the player if it is.

We then take the Box2d contact information from the LevelHelper contact object and disable the contact so that no collision behavior will occur. We check if the player is dead. If so, we do nothing.

Finally, we test if the frame number is not 0. If it is 0, then the laser is not on, so we don’t need to kill the player. If it’s not 0, it means we need to kill the player. We cancel the collision callback because we don’t need it anymore, and kill the player.

Notice we’re using two things that we have not yet defined: the killPlayer method and the playerIsDead variable. So let’s define them.

Inside HelloWorldScene.h, put the following in the class declaration:

bool playerIsDead;

Then define the killPlayer method inside HelloWorldScene.mm (add after mouseCoinCollision):

-(void)killPlayer
{     
    playerVelocity = 0.0;
    playerShouldFly = false;
    playerIsDead = true;
    playerWasFlying = false;
    [rocketFlame setVisible:NO];
    [player startAnimationNamed:@"mouseDie"];
 
    [paralaxNode setSpeed:0];
 
    CGSize winSize = [[CCDirector sharedDirector] winSize];
    CCLabelTTF *label = [CCLabelTTF labelWithString:@"Game Over" fontName:@"Marker Felt" fontSize:64];
    label.color = ccRED;
    label.position = ccp(winSize.width*0.5, winSize.height*0.75);
    [self addChild:label];
 
    CCMenuItem *item = [CCMenuItemFont itemFromString:@"Restart" target: self selector:@selector(restartGame)];
    CCMenu *menu = [CCMenu menuWithItems:item, nil];
    [menu alignItemsVertically];
 
    [self addChild:menu];
}

In the killPlayer method above, we set the velocity of the player to 0. If the player was flying, it will now fall to the ground.

We then set the playerIsDead variable to true so we know the player is dead in the methods where this information is a factor. We hide the rocket flame.

Finally, we start the death animation on the player sprite by using a LevelHelper method that will take as arguments the animation’s unique name and the sprite on which we want to perform the animation. We can take the animation name from the Animations section inside LevelHelper.

For more details on using animations with LevelHelper, check out the official LevelHelper documentation.

After that, we stop the parallax from moving by setting its speed to 0.

Now we need to create a Cocos2d menu so that we can restart the game if the player dies. Let’s define the restartGame method before the killPlayer method as follows:

-(void)restartGame
{
    [[CCDirector sharedDirector] replaceScene:[HelloWorldScene scene]];
}

Compile and run, and now your mouse can die if he collides with a laser!

Gratuitous Sound Effects

If you’ve read game tutorials on this blog before, you know we’d never leave you hanging without some gratuitous (and awesome) sound effects! :]

Navigate to your Xcode Resources folder in Finder. Then, open a new Finder window and navigate to where you saved the sounds pack that you downloaded at the beginning of this tutorial.

Inside the Resources folder, create a new folder called Music, and drag all the sound files from the sound pack into this new folder.

Now go back to Xcode and include the music folder inside your Resources by right-clicking (or Control-clicking) on the Resources folder and choosing “Add Files to RocketMouse.”

In the new window, navigate to your Resources folder, select the Music folder, and click the Add button.

Your new Resources folder inside Xcode should look something like this:

Now that we’ve added our sound files to our project, let’s code the sound so we can make some noise!

At the top of HelloWorldScene.mm import the audio engine:

#import "SimpleAudioEngine.h"

Then add this new method that will load our sounds (put this right above the init method):

-(void) setupAudio
{
    [[SimpleAudioEngine sharedEngine] playBackgroundMusic:@"backgroundMusic.m4a"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"coin.wav"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"fly.wav"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"ground.wav"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"hitObject.wav"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"laser.wav"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"lose.wav"];
    [[SimpleAudioEngine sharedEngine] preloadEffect:@"bunnyHit.wav"];
}

Then call this method in init (right after the call to setupCollisionHandling):

[self setupAudio];

This is where we load all the sounds in the pack. We load backgroundMusic.m4a as a music asset and we preload the rest of the files as effects.

Now we have to match the effects with the methods that will generate them. In the mouseCoinCollision method add the following:

[[SimpleAudioEngine sharedEngine] playEffect:@"coin.wav"];

In the mouseLaserCollision method add the following inside the if(frame != 0) statement:

[[SimpleAudioEngine sharedEngine] playEffect:@"laser.wav"];

Let’s also add the flying sound. Inside the tick method, add the following inside the if playerShouldFly block:

[[SimpleAudioEngine sharedEngine] playEffect:@"fly.wav"];

Compile and run the game, and enjoy the new music and sound effects! :]

The complete project up to this point can be downloaded here.

Collisions Between Mouse, Cats and Dogs

So far our mouse can die if he hits a laser, but he’s getting off to easy when it comes to the cats and dogs! So let’s add some collision handling for them as well.

Add the following at the end of setupCollsionHandling method:

[lh registerPreCollisionCallbackBetweenTagA:PLAYER andTagB:DOG idListener:self selListener:@selector(mouseDogCatCollision:)];    
[lh registerPreCollisionCallbackBetweenTagA:PLAYER andTagB:CAT idListener:self selListener:@selector(mouseDogCatCollision:)];

Let’s now define the method for the callback. Because our game will perform the same action for collisions with cats and dogs, we only need one method. Add this somewhere before the setupCollisionHandling method:

-(void)mouseDogCatCollision:(LHContactInfo*)contact
{    
	[[SimpleAudioEngine sharedEngine] playEffect:@"hitObject.wav"];    
    [lh cancelPreCollisionCallbackBetweenTagA:PLAYER andTagB:DOG];    
    [lh cancelPreCollisionCallbackBetweenTagA:PLAYER andTagB:CAT];    
    [self killPlayer];
}

Here we play the needed sound, then we cancel the callback between the player and the cat or dog, because we no longer need them. Then we kill the player.

Compile and run the game, and now your mouse can die when he hits a cat or dog too – so watch out! :]

Tweaking Gameplay

Our game is looking good so far, but there are still a number of problems.

The first of these problems is that if you touch the screen after the mouse dies, he starts flying around like he’s been resurrected! Although “Zombie Mouse” might make for a popular game on the App Store, this is not the effect we’re going for ;]

Let’s put a stop to this zombie behavior before it gets out of hand! Just add the following check to the beginning of ccTouchesBegan:

if(playerIsDead)
    return;

The only thing we’re doing differently here is testing to see if the player is dead. If they are, then we do nothing.

If we run the game now, the zombie behavior won’t occur anymore. But there are other issues.

For example, in my level there are places where the player can’t get past a laser because it’s active, but he can’t go under it because there’s a cat in the way. Your level may have similar problems.

It’s time to play-test the level and make any necessary modifications to be sure it’s possible for the player to successfully finish the game.

Open up LevelHelper with our level03 level, and drag the cats, dogs and laser sprites as necessary so that the player has a way through. (But don’t make it too easy!)

Make sure to save the level!

Since we’re modifying the level anyway, let’s create a way to know when the player touches the ground. To do this we’ll define a new tag and add that tag to the bottom border of the physic boundary. Click the Define Tag button (as we did in Part Two) and add the tag “GROUND.”

Now that we have this new tag, let’s assign it to the bottom part of the Physic Boundary shape.
To do this click the Physic Boundaries button.

Save your level in LevelHelper.

We still have to define the collision callback between the player and the ground. Add the following at the end of setupCollisionHandling method:

[lh registerPreCollisionCallbackBetweenTagA:PLAYER andTagB:GROUND idListener:self selListener:@selector(mouseGroundCollision:)];

Define the mouseGroundCollision method somewhere above the setupCollisionHandling method, as follows:

-(void)mouseGroundCollision:(LHContactInfo*)contact
{
 
    if(playerIsDead)
        return;
 
    if(playerWasFlying)
    {
        [[SimpleAudioEngine sharedEngine] playEffect:@"ground.wav"];
 
        [player startAnimationNamed:@"mouseFall" 
                     endObserverObj:self 
                     endObserverSel:@selector(fallAnimHasEnded:animName:) 
          shouldObserverLoopForever:FALSE];
 
    }
    playerWasFlying = false;
}

We test if the player is dead so we can return if they are. We then test if the player was flying when they touched the ground. If they were, we play landing sound.

Then we start the mouseFall animation, but we start it using a notification. That way when the animation ends, we get notified so that we can set another animation on the player sprite.

So let’s define the method that gets called when the mouseFall animation ends. Add it above mouseGroundCollision, as follows:

-(void) fallAnimHasEnded:(LHSprite*)spr animName:(NSString*)animName
{
    [player startAnimationNamed:@"mouseRun"];
}

This new method takes as arguments the sprite that had the animation and the animation name. It then starts the animation “mouseRun” on the player sprite the normal way.

Playing the game now, it looks like we have almost everything in place. But there is still one thing we need to fix!

You may have noticed that if we run the game now, coins taken from the level don’t reappear when the parallax restarts. We hid them, remember, after player collisions, so we need to add a way to make them visible again when the parallax starts over.

Inside the retrieveRequiredObjects method declaration, add the following line, after you’ve taken the pointer to the parallax node:

-(void) retrieveRequiredObjects
{
    // existing lines
    paralaxNode = [lh paralaxNodeWithUniqueName:@"Parallax_1"];
    NSAssert(paralaxNode!=nil, @"Couldn't find the parallax!");
 
    // add this new line
    [paralaxNode registerSpriteHasMovedToEndListener:self 
        selector:@selector(spriteInParallaxHasReset:)]; 
 
    // rest of code...

This new method registers on the parallax another new method (spriteInParallaxHasReset) that will be called whenever a sprite in the parallax is reset to the back of the parallax. This method gets called when the sprite exits the view.

Define spriteInParallaxHasReset before the retrieveRequiredObjects declaration:

-(void) spriteInParallaxHasReset:(LHSprite*)sprite
{    
    if(COIN == [sprite tag]){
        [sprite setVisible:YES];
    }
}

Here we test the tag of the sprite that was reset by the parallax, and if it’s tagged as a COIN we make it visible again.

Compile and run your game, and see how long you can play without dying! :]

Where to Go From Here?

If you’ve followed along this far, you should have a smoothly-functioning game that is very similar to Jetpack Joyride! It’s not quite complete (stay tuned for Part Four), but very close, with animations, collisions, sounds, and correct gameplay.

In case you need it, here is an example project that includes all of the code for this tutorial series up to this point.

In the fourth and final part of this tutorial series, we’ll increase the difficulty of the game by making some of the lasers rotate. But we’ll also add another point-scoring opportunity in the form of bunnies running through the level that the player can kill, and display the score as it increases.

Finally, as the crowning touch for our game, we’ll create a second scene in SpriteHelper and add it to our level as a background, so that the user will be able to look through the windows at the “outside” world.

Until then, feel free to participate in forum discussion both below and on the LevelHelper site.

This is a post by special contributor Bogdan Vladu, an iOS application developer and aspiring game developer living in Bucharest, Romania.

How to Make a Game Like Jetpack Joyride Using LevelHelper & SpriteHelper – Part 3 is a post from: Ray Wenderlich