Cocos2D Tutorial for iOS: How To Create A Mole Whacking Game: Part 1/2

Ray Wenderlich

This post is also available in: Japanese

Whack this Mole!

Whack this Mole!

One of the students in the iOS Programming 101 workshop that Shawn Grimes and I recently offered requested that I write a Cocos2D tutorial on how to write a mole whacking game.

I thought this was a great idea for a Cocos2D tutorial for three reasons:

  1. We’ve had a lot of Cocos2D tutorials on this site, but it might be hard to see how to combine everything together to make a game. So this Cocos2D tutorial does exactly that!
  2. It will be a good opportunity to cover a new topic: how to make a game that works on the iPhone, iPad, and iPhone retina display.
  3. And of course the most important reason – whacking moles is fun!

This Cocos2D tutorial builds on the following Cocos2D tutorials:

If you have not reviewed these Cocos2D tutorials already (or have similar knowledge), I recommend you go through them first.

This is a two-part Cocos2D tutorial series. In this first part, we’ll create the basics of the game – cute little moles popping out of holes. We’ll spend a lot of time thinking about how to organize the art and coordinates so that the game looks good on the iPhone, iPad, and Retina display – and be efficient too! (Jump to the second part.)

Planning the Art: Overview

Since we want this app to work on both the normal iPhone, retina-display iPhone, and the iPad, we need to take some time to carefully plan out how the art is going to be set up before we proceed any further.

In order to understand how to propery size and set up the art, we need to cover three topics first:

  • Retina Display and UIKit
  • Retina Display and Cocos2D
  • iPad, iPhone, and Aspect Ratios

So let’s get started!

Retina Display and UIKit

The difference between a normal iPhone and a retina-display iPhone is the Retina display can show double the pixels. So (in landscape) instead of the display size being 480×320 px as it is on a normal iPhone, it’s 960×640 px on a Retina display.

iPhone vs Retina Display

“But wait a minute”, you may think, “wouldn’t doubling the number of pixels break all of the apps that were written assuming the 480×320 display size?” It would have (especially since when you’re programming with UIKit it’s common to hard-code frame sizes etc), except when you specify frame sizes in UIKit, you’re actually setting the sizes in points, not pixels.

On a normal iPhone, a point is defined to be exactly one pixel. But on a retina-display iPhone, a point is defined to be two pixels. So when you specify a location as (10,10) in points, it will be (10,10) on a normal iPhone, and (20,20) on a retina-display iPhone, so will appear to be at the same relative offset. Cool, eh?

When you’re using Apple’s controls or Core Graphics, Apple has already written the code to make things look nice and crisp on the Retina display.

The only trick comes into play when you use an image. Say you have a 200×200 image in an iPhone app. If you don’t do anything, on the Retina display it will just scale the image to be 2x larger – which won’t look that great because you aren’t taking advantage of the extra resolution available to you.

Zoomed image not saved in HD resolution

So what you need to do is provide another version for all of your images: a normal version, and one that is double the size. If you name your image with double the size with an “@2x” extension, whenever you try to load an image with [UIImage imageNamed:...] or similar APIs, it will automatically load the @2x image instead on the Retina display.

So making a UIKit app use the Retina display is pretty easy – just add @2X images and you’re done for the most part.

But what about Cocos2D?

Retina Display and Cocos2D

Well, there’s good news – the latest version of Cocos2D contains full support for the retina display, and makes it as easy as 1-2-3!

  1. Call enableRetinaDisplay on CCDirector to enable retina display support when your app starts up. If you’re using the Cocos2D project templates, you can just uncomment the lines that do this in your app delegate.
  2. Add double-sized sprites to your app, but instead of using the “@2x” extension, you use an “-hd” extension for Cocos2D. When loading your sprites, use hte normal name (without the “-hd” extension) – Cocos2D will automatically load the hd images on the Retina display.
  3. Now you can use points instead of pixels when positioning your sprites in Cocos2D. Note some APIs (but not many of them) still have to deal with pixels – when that is the case, they will have pixel in the method name to make it clear, otherwise assume points.

When the rubber hits the road, the easiest thing to do is to have your artist make images at the highest-necessary resolution (i.e. the 2X size for the Retina display), and you can easily scale down the images for the normal iPhone yourself from there.

You might wonder why even bother having two different sized images – why not just always load the bigger image and just scale it programatically? Well, loading textures into memory is one of the most memory intensive aspects of an app, so if you’re running on a device that isn’t going to take advantage of the higher resolution images, it’s a big saving to load the smaller images that are intended for the device.

But don’t worry – you don’t need to be constantly scaling images down in Photoshop. Texture Packer actually has a nice feautre that makes it easy to create scaled down images given a full-resolution image, and that’s what we’ll be using in this Cocos2D tutorial.

iPad, iPhone, and Aspect Ratio

OK so dealing with the retina display is pretty easy, but what about the iPad?

Well, it turns out that there is a very annoying thing about making a game that works on both the iPhone and the iPad – the aspect ratio between the devices is different!

The iPhone is 480×320 or 960×640 – a 1.5 aspect ratio. However, the iPad is 768×1024 – a 1.33 aspect ratio.

This means that if you have an image that fills up the entire background of the iPad (768×1024) and want to re-use it for the iPhone too, it’s not going to fit exactly. Say you scale it down so it fits the width of the iPhone (multiply by 0.9375): you’ll get 720×960, so there will be extra stuff to the side that will get cut off!

Aspect Ratio of iPhone vs. iPad

This makes things kind of annoying, because not only do you run into problems with background images, but the aspect ratio also makes it difficult to use the same coordinates across devices.

There are several strategies for how to deal with this, here are a few I’ve seen/heard/used (feel free to chime in with any of your own solutions in the comments):

  • Have a “playable area” in the middle of the screen that is the size of the iPhone retina display (640×960). This will leave a little extra are around the edges – you can just cover that with a background and the player probably won’t even notice. This allows you to easily convert coordinates between devices and re-use art (high res used on iPad and retina, and normal res used on normal iPhone). This is what we’ll be doing in this Cocos2D tutorial.
  • You can make the iPad have a similar aspect ratio to the iPhone if you take 42 pixel gutters on each side of the iPad screen, and put the “main content” inside as 684×1024. If you make your content to fit within the 684×1024 box, you can scale down images for each device from there.
  • You could have different images for the iPhone, iPad, and Retina display (i.e. 3 sets) and different coordinates too. This allows maximum flexibility, but larger binary sizes and having to redo the positions of objects on different devices.

On and another complication – Cocos2D doesn’t currently have any helpful support for the iPad, in terms of loading images with the “-hd” extension automatically, converting coordinates, etc. That is up to you!

Planning the Art: Conclusion

OK, so based on the above discussion, here is the plan for this Cocos2D tutorial.

  • The art has been designed to be within a 960×640 “playable area”, used full-screen on retina-display iPhones, and centered in the iPad screen.
  • The art will then be scaled by Texture Packer to be 1/2 the size for normal iPhones.
  • The full sized-art will be named with the “-hd” extension, and the half size without, and Cocos2D will load the appropriate art based on whether the Retina display is enabled.
  • Backgrounds are a special case because they need to be fullscreen always. The backgrounds will be made to the 1024×768 size (iPad size) so the entire screen is filled. The same images will actually be used on the iPhone too since it’s close enough. Some of the background will be offscreen, but that doesn’t matter for this particular background.
  • The iPad version will contain code to use the “-hd” images, convert coordinates to inside the “playable area”, use the appropriate font sizes, etc.

Go ahead and download the art for this Cocos2D tutorial, made by my lovely wife. Unzip the file and take a look at how things are set up:

  • In the “foreground” folder, the foreground is 1024×768 (the size of the iPad), but it is actually split into two parts: the lower part, and the upper part. It’s split into two parts so we can place the mole in-between the lower and upper parts, to make him look like he’s going underground.
  • In the “background” folder, the background has the 1.33 aspect ratio of the iPad, but is actually half sized (512×384). This is becase the background barely shows (just through the three mole holes), so it’s not worth the cost of a large 1024×1024 texture load. Instead a small texture is loaded and scaled up.
  • In the “sprites” folder, all sprites were sized to fit nicely within the 960×640 “playable area”. Note there’s a mole, and two animations for him (the mole laughing, and the mole being hit).

Ok – enough background info – it’s time to get started!

Getting Started

Open up XCode, select “File\New Project…” from the main menu, choose “User Templates\cocos2d\cocos2d Application”, and click “Choose…”. Name the project WhackAMole, and click Save.

Next, take the “Art” folder that you downloaded earlier and copy it into your WhackAMole project directory using Finder. It should be a sibling to the build and Classes folders, as you can see below:

Directory Structure for Project

Next, make sure you have Texture Packer installed and ready to go on your machine. If you don’t have it already or know how to use it, check out this tutorial for more information.

You will now set up TexturePacker to create the sprite sheets you’ll need for this project. You’ll be doing everything by TexturePacker’s command line tools and XCode integration, so no need to use the TexturePacker GUI at all!

Right click on Resources, choose “Add\New File…”, choose Mac OS X\Other\Shell Script, and click Next. Name the file PackTextures.sh, and click Finish.

Then replace the contents of PackTextures.sh with the following:

#!/bin/sh

TP="/usr/local/bin/TexturePacker"

if [ "${ACTION}" = "clean" ]
then
    echo "cleaning..."

    rm resources/background*
    rm resources/foreground*
    rm resources/sprites*

else
    echo "building..."

    ${TP} --smart-update \
          --format cocos2d \
          --data resources/background-hd.plist \
          --sheet resources/background-hd.pvr.ccz \
          --dither-fs \
          --opt RGB565 \
          Art/background/*.png

    ${TP} --smart-update \
          --format cocos2d \
          --data resources/background.plist \
          --sheet resources/background.pvr.ccz \
          --dither-fs \
          --scale 0.5 \
          --opt RGB565 \
          Art/background/*.png

    ${TP} --smart-update \
          --format cocos2d \
          --data resources/foreground-hd.plist \
          --sheet resources/foreground-hd.pvr.ccz \
          --dither-fs-alpha \
          --opt RGBA4444 \
          Art/foreground/*.png

    ${TP} --smart-update \
          --format cocos2d \
          --data resources/foreground.plist \
          --sheet resources/foreground.pvr.ccz \
          --dither-fs-alpha \
          --scale 0.5 \
          --opt RGBA4444 \
          Art/foreground/*.png

    ${TP} --smart-update \
          --format cocos2d \
          --data resources/sprites-hd.plist \
          --sheet resources/sprites-hd.pvr.ccz \
          --dither-fs-alpha \
          --opt RGBA4444 \
          Art/sprites/*.png

    ${TP} --smart-update \
          --format cocos2d \
          --data resources/sprites.plist \
          --sheet resources/sprites.pvr.ccz \
          --dither-fs-alpha \
          --scale 0.5 \
          --opt RGBA4444 \
          Art/sprites/*.png

fi
exit 0

This script runs TexturePacker to create a sprite sheets for the background image, the foreground images, and the sprite images – an HD and regular-quality image for each.

Note that each image is saved in the pvr.ccz format since it is the most efficient in terms of memory and disk space usage. Also the pixel format and dithering options were chosen to get a good tradeoff of quality and memory usage for each set of images.

If you’re unsure what the TexturePacker options do, load up Terminal and run TexturePacker –help to get a full description of each option.

Next, you need to set up your project to run this shell script when you compile. Right click on Targets, choose “Add\New Target…”, and choose “External Target” (not Shell Script Target!), and click Next. Name the Target TexturePacker, and click Finish.

Then double click on your TexturePacker target and set up the settings as follows:

Texture Packer Target Settings

The final step is to set this target as a dependency of your app. Double click on your TextureFun target, go to the General tab,click the + button in Direct Dependencies, choose Texture Packer from the list, and click Add Target.

Project Dependencies

Compile your app, and you should see the output from Texture Packer from your build results if everything is working OK.

Texture Packer Results

Next, add the newly generated sprite sheets and property lists to your project. Right click on Resources and choose “Add\Existing Files…” and select the background, foreground, and sprite files (12 files total) from Resources and click Add, and then Add again. When you’re done your Groups & Files tree should look similar to the following:

Project with Sprite Sheets Added

If you’d like, you can double click on any of the .pvr.ccz files to load up a preview of what’s inside. This is a new (and handy) feature of Texture Packer!

Setting the Background

Next, open up HelloWorldScene.m and find your init method. Remove the four lines of code that create the Hello World label, and replace those lines with the following:

// Determine names of sprite sheets and plists to load
NSString *bgSheet = @"background.pvr.ccz";
NSString *bgPlist = @"background.plist";
NSString *fgSheet = @"foreground.pvr.ccz";
NSString *fgPlist = @"foreground.plist";
NSString *sSheet = @"sprites.pvr.ccz";
NSString *sPlist = @"sprites.plist";
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
    bgSheet = @"background-hd.pvr.ccz";
    bgPlist = @"background-hd.plist";
    fgSheet = @"foreground-hd.pvr.ccz";
    fgPlist = @"foreground-hd.plist";
    sSheet = @"sprites-hd.pvr.ccz";
    sPlist = @"sprites-hd.plist";            
}
 
// Load background and foreground
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:bgPlist];       
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:fgPlist];
 
// Add background
CGSize winSize = [CCDirector sharedDirector].winSize;
CCSprite *dirt = [CCSprite spriteWithSpriteFrameName:@"bg_dirt.png"];
dirt.scale = 2.0;
dirt.position = ccp(winSize.width/2, winSize.height/2);
[self addChild:dirt z:-2]; 
 
// Add foreground
CCSprite *lower = [CCSprite spriteWithSpriteFrameName:@"grass_lower.png"];
lower.anchorPoint = ccp(0.5, 1);
lower.position = ccp(winSize.width/2, winSize.height/2);
[self addChild:lower z:1];
 
CCSprite *upper = [CCSprite spriteWithSpriteFrameName:@"grass_upper.png"];
upper.anchorPoint = ccp(0.5, 0);
upper.position = ccp(winSize.width/2, winSize.height/2);
[self addChild:upper z:-1];
 
// Add more here later...

OK let’s go over this section by section, since there is a good amount of new material here.

  • Determine names of sprite sheets and plists to load. This section lists the names of the sprite sheets and plists generated by Texture Packer to be loaded. Note that on the iPhone, Cocos2D will automatically choose between the “-hd” versions and the normal versions based on whether the Retina display is enabled. However, the iPad won’t load the “-hd” version unless you tell it to, so we check if it’s an iPad and use the “-hd” versions if so.
  • Load background and foreground. The next step is to load the information about each sprite for the background and foreground into the sprite frame cache so that they can be used later. Note that these sprites won’t actually be added to a CCSpriteBachNode anywhere – since these images are just used once each it would be kind of pointless.
  • Add background. The background image is added as a child of the layer (with a z of -2 so it appears beneath everything else) next. It scales the image by 2 because we made it smaller on purpose to conserve space, and centers the image.
  • Add foreground. The foreground is added in two parts. As an easy way to place the image, it sets the anchor point to the middle/bottom for the top image, and the middle/top for the bottom image, and matches that anchor point up to the center of the screen. That way you don’t have to do any complicated math, and it shows up in the right place on all devices. Note that part of the background will be offscreen for iPhones, but that is OK for this background and barely even noticable. Also note that the images are added with different z values, so the lower image appears on top.

Compile and run the code, and you should now see the background and foreground on the screen! Give it a try on both the iPhone and iPad simulators to make sure that it appears OK on both devices.

Mole Background

If you try the code on the retina display and zoom in, however, you’ll notice that it’s still using the normal artwork:

HD vs Normal Images in Cocos2D

That’s because we still haven’t done step 1 from the “Retina Display and Cocos2D” section earlier: call enableRetinaDisplay on CCDirector to enable retina display support when your app starts up.

To do this, open up WhackAMoleAppDelegate.m, and inside applicationDidFinishLaunching uncomment the following three lines:

if( ! [director enableRetinaDisplay:YES] )
    CCLOG(@"Retina Display Not supported");

Compile and run your code, and now when you try it on the retina display you should see it automatically make use of the HD files, due to Cocos2D’s built in retina display support!

Placing the Moles

For this game, you’re going to add three moles to the scene – one for each hole. The moles will usually be “underground” beneath the lower part of the grass – but occasionally they will “pop up” so you can try to whack them.

First, let’s add the moles to the level underneath each of the holes. We’ll temporarily make them appear above all the other art so we can make sure they’re in the right spot, then we’ll put them underground once we’re happy with their position.

Open up HelloWorldScene.h and add an array to keep track of the moles in the level, as shown below:

// Inside @interface HelloWorld
NSMutableArray *moles;

By storing the moles in this array, it will make it easy to loop through each of the moles later on.

Next, add the code to place the moles at the end of your init method (where it says “Add more here later…”), as shown below:

// Load sprites
CCSpriteBatchNode *spriteNode = [CCSpriteBatchNode batchNodeWithFile:sSheet];
[self addChild:spriteNode z:999];
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:sPlist];      
 
moles = [[NSMutableArray alloc] init];
 
CCSprite *mole1 = [CCSprite spriteWithSpriteFrameName:@"mole_1.png"];
mole1.position = [self convertPoint:ccp(85, 85)];
[spriteNode addChild:mole1];
[moles addObject:mole1];
 
CCSprite *mole2 = [CCSprite spriteWithSpriteFrameName:@"mole_1.png"];
mole2.position = [self convertPoint:ccp(240, 85)];
[spriteNode addChild:mole2];
[moles addObject:mole2];
 
CCSprite *mole3 = [CCSprite spriteWithSpriteFrameName:@"mole_1.png"];
mole3.position = [self convertPoint:ccp(395, 85)];
[spriteNode addChild:mole3];
[moles addObject:mole3];

This first creates a CCSpriteBatchNode for the sprites, so that drawing the three moles is done more efficiently, and adds it as a child of the layer. Note it’s setting the z value to 999 temporarily, so that the moles apepar on top so we can make sure they’re set up OK.

It then loads all of the sprite frames from the property list to the cache, so they can be pulled out later.

Then it goes through and creates a sprite for each mole, places them in the scene, and adds them to the list of moles. Note the coordinate for each mole is within the 480×320 “playable area” of the game (the size of the iPhone). For the iPad, these points will need to be converted, so it calls a helper function convertPoint which we’ll write next.

Add the following method right above the init method:

- (CGPoint)convertPoint:(CGPoint)point {    
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
        return ccp(32 + point.x*2, 64 + point.y*2);
    } else {
        return point;
    }    
}

This method converts a point in the “playable area” to the appropriate screen positionon the iPad. Remember that:

  • We’re using the HD graphics on the iPad, so all points are doubled.
  • We’re centering that 960×640 area in the 1024×968 iPad screen, so that leaves 32 pixel margins on the left and right, and 64 pixel margins on the top and bottom.

So this method simply does that math to give the right position on the iPad.

One more thing – before we forget, add the following lines to clean up the memory we allocated for the moles array in the dealloc method:

[moles release];
moles = nil;

Compile and run your code, and you should see the three moles happily in the scene at the correct spots! You should try the code on the iPhone, iPhone Retina, and iPad to make sure that they’re in the right spot on each device.

Moles placed in correct positions

Popping the Moles

Now that we’re sure the moles are in the right place, let’s add the code to make them pop out of their holes.

First things first – switch the z-value of 999 for the mole sprite sheet back to 0 so the moles are underground.

Once that’s done, add the following line of code to the bottom of your init method:

[self schedule:@selector(tryPopMoles:) interval:0.5];

If you haven’t seen this before, you can run the schedule method on a node to tell Cocos2D to call another method every so many seconds. In this case, we want to try popping some moles out of their holes every 1/2 second.

Next, add the implementation of tryPopMoles:

- (void)tryPopMoles:(ccTime)dt {
    for (CCSprite *mole in moles) {            
        if (arc4random() % 3 == 0) {
            if (mole.numberOfRunningActions == 0) {
                [self popMole:mole];
            }
        }
    }     
}

This method will be called every 1/2 second, and each time it will loop through each mole and give it a 1 in 3 chance of popping out of its hole. But it will only pop out if it isn’t moving already – and one easy way to check for this is to see if the numbef running actions is 0.

Finally, add the implementation of popMole:

- (void) popMole:(CCSprite *)mole {          
    CCMoveBy *moveUp = [CCMoveBy actionWithDuration:0.2 position:ccp(0, mole.contentSize.height)]; // 1
    CCEaseInOut *easeMoveUp = [CCEaseInOut actionWithAction:moveUp rate:3.0]; // 2
    CCAction *easeMoveDown = [easeMoveUp reverse]; // 3
    CCDelayTime *delay = [CCDelayTime actionWithDuration:0.5]; // 4
 
    [mole runAction:[CCSequence actions:easeMoveUp, delay, easeMoveDown, nil]]; // 5
}

This code uses some Cocos2D actions to make the mole pop out of it’s hole, pause for half a second, then pop back down. Let’s go through this line by line to make sure we’re on the same page:

  1. Creates an action to move the mole move up along the Y axis as much as the mole is tall. Since we placed the mole right below the hole, it will look right.
  2. To make the movement look more natural, it wraps the move action with a CCEaseInOut action. This causes the action to go slower at the beginning and end, as if the mole is accelerating/decellerating, as it naturally would.
  3. To create an action to move the mole move back down again, an easy way is to call the reverse method on an action, which will give its opposite.
  4. Creates an action to pause for one second after the mole pops out.
  5. Now that the actions are ready to go, it runs them on the mole in a sequence: move up, delay, and finally move down. Note it has to terminate the sequence with a nil to show it’s done.

That’s it! Compile and run the code, and you’ll see the moles happily popping out of their holes!

Moles popping out of holes

Where To Go From Here?

Here is a sample project with all of the code we’ve developed so far in this Cocos2D tutorial series.

Next check out Part 2, where we’ll add some cute animations to the mole as he laughs and gets whacked, add gameplay so you can do the whacking and earn points, and of course add some gratuitous sound effects as usual.

Please add a comment below in if you have any thoughts, advice, or suggestions for future tutorials!

Ray Wenderlich

Ray is an indie software developer currently focusing on iPhone and iPad development, and the administrator of this site. He’s the founder of a small iPhone development studio called Razeware, and is passionate both about making apps and teaching others the techniques to make them.

When Ray’s not programming, he’s probably playing video games, role playing games, or board games.

User Comments

40 Comments

[ 1 , 2 , 3 ]
  • An app can't just write to anything it has as a resource, generally it has to be in the app's documents directory. Can you check the actual path?

    It is a common thing to prepare a base core data file that will be copied into the documents directory when no data file is detected. Then the app can always start from a known state with a writeable database but maintains a write-protected copy.
    aeberbach
  • Thanks for the response,
    Actually I figured it out. All of the paths in the TP script were assuming that the resources folder was in the top level of the WhackAMole Directory. With xCode 4 the directory actually looks like WhackAMole/WhackAMole/Resources instead of WhackAMole/resources. So for the --data and --sheet I used WhackAMole/resources/foreground-hd.plist and WhackAMole/resources/foreground-hd.pvr.ccz respectively. Also I changed the source file path to WhackAMole/Art/foreground/*.png
    So now it looks like this and everything works fine. Silly thing staring me in the face the whole time.

    ${TP} --smart-update \
    --format cocos2d \
    --data WhackAMole/resources/background-hd.plist \
    --sheet WhackAMole/resources/background-hd.pvr.ccz \
    --dither-fs \
    --opt RGB565 \
    WhackAMole/Art/background/*.png
    swinginsamurai
  • So, Retina textures. They work as expected if I try it on the iPad and the iPhone, but I get a warning message when running in iPhone Retina, and never end up using the Retina textures. Specifically:
    Code: Select all

    NSString *fgPlist = @"foreground.plist";
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:fgPlist];

    dumps out this warning:
    Code: Select all
    cocos2d: Filename(foreground-hd.pvr.ccz) contains -hd suffix. Removing it. See cocos2d issue #1040

    Checking the textures being used, the rect also returns sizes from the normal version, not the textures in the -hd.

    Tracing through the code, the adddSpriteFramesWithFile at one point does add the -hd extension (which is the expected case because we're looking going to use the retina textures), but that warning comes from "ccRemoveHDSuffixFromFile" which strips the -hd textures.

    How is it using the -hd textures if they aren't loaded?
    AlphaTwo
  • Hello,

    I have been a fan of your blogs and tutorials and it helped me a lot understand cocos2d.

    I am just wondering how to tweak your mole whacking game example where only one mole is shown at a time from the ground.

    I can see that popTrymoles holds the logic but i don't understand it that much.


    thanks,
    Cha
    topsyturvy261
  • Hello Ray,

    I got some error to run this part1 tutorial.

    Code: Select all
    mole1.position = [self convertPoint:ccp(85, 85)];

    xcode would tell me "Instance method '-convertPoint' not found (return type defaults to 'id')
    Seems the convertPoint is not the instance method of current object. How should I solve it? Can you helps on this?
    ayeteng
  • Hi Ray,

    I really like your explanation and (graphics) strategy for handling both the iPhone and iPad (universal) in one app.

    In the app I'm creating it will work best if the iPhone version is forced landscape mode and the iPad version is forced portrait mode. I've tried setting a few things in the App Delegate but haven't been able to get it working yet.

    Any recommendations?
    mijator
  • I am trying to build this project but I am stuck on the following two steps becuase I have the new version of Xcode. I have already created the script and have already installed the texture packer and don't know how to set this up Target Texture Packer or Texture Fun target. Can you help? Also I am using a computer at my college campus to build the project, would the (build tool, arguments, and directory) perameters be set up differently since I am under the student directory? I have my files on the desktop.

    Next, you need to set up your project to run this shell script when you compile. Right click on Targets, choose Add\New Target, and choose External Target (not Shell Script Target!), and click Next. Name the Target TexturePacker, and click Finish.
    Then double click on your TexturePacker target and set up the settings as follows:

    The final step is to set this target as a dependency of your app. Double click on your TextureFun target, go to the General tab,click the + button in Direct Dependencies, choose Texture Packer from the list, and click Add Target.

    Thanks in Advance!
    Brenda
  • Hi
    I'm using iOS 5.1.1 and I'm not seeing exactly the same things that are being outlined, beginning with the section where we add a new external target. When I click on the "WhackAMole 1Target..." directory at the top left of the UI, I see the "Add Target +" button on the lower left side of the screen. Then I get the "Choose A Template for your New Target" window drops down. Under iOS, the only "Target" option is under the "Other" and that's an aggregate Target. There's a "External Build System" Target available under Mac OSX. In either case, I get lost from then on because I can't match the directions with what I'm seeing on this side...any help will be great.

    Rick
    rickemiranda
  • Hi,

    I tried to run your demo on my iPad 3rd Generation, with 6.01 Software version.

    It displays a black screen, with the music in the background.

    I am having the same problem with my apps that I am trying to convert to Universal.

    I think a lot of people are having the same issue.

    Could you tell us how to fix it?

    Cheers

    Shane
    ShaneT
  • rwenderlich wrote:@Jonathan: Yeah things are switched around a bit in Xcode 4. Here are some updated instructions to get the Texture Packer step working for Xcode 4:


    • To add a target, you have to click on the WhackAMole project line at the top of your groups and files tree. There will be a button in the lower left that says "Add Target" that you can click.

    • You need to choose the Mac OSX\Other\External Build System and name it PackTextures

    • In the Info tab for PackTextures target, set the build tool to /bin/sh, arguments to "$(SRCROOT)/WhackAMole/PackTextures.sh" and the directory to $(SRCROOT)/WhackAMole

    • Click on your WhackAMole target, to to Build Phases, expand Target Dependencies, and click + to add a dependency to the PackTextures target


    Hope this helps!


    Hi Ray, another great tutorial btw. I'm using Xcode 4.6 and following your advice above. When I build the app the shell script seems to run, but then I get this message

    "Xcode cannot run using the selected destination. Choose a destination with a supported architecture in order to run on this system."

    I'm new to Xcode and iOS and I'm not sure what this means. I'd be really grateful if you could help me out here. Thanks.
    ptc79
[ 1 , 2 , 3 ]

Other Items of Interest

Ray's Monthly Newsletter

Sign up to receive a monthly newsletter with my favorite dev links, and receive a free epic-length tutorial as a bonus!

Advertise with Us!

Hang Out With Us!

Every month, we have a free live Tech Talk - come hang out with us!


Coming up in May: Procedural Level Generation in Games with Kim Pedersen.

Sign Up - May

Coming up in June: WWDC Keynote - Podcasters React! with the podcasting team.

Sign Up - June

Vote For Our Next Book!

Help us choose the topic for our next book we write! (Choose up to three topics.)

    Loading ... Loading ...

Our Books

Our Team

Tutorial Team

  • Martin Walsh
  • Riccardo D'Antoni

... 55 total!

Editorial Team

... 22 total!

Code Team

  • Orta Therox

... 1 total!

Translation Team

  • Cosmin Pupaza

... 38 total!

Subject Matter Experts

  • Richard Casey

... 4 total!