How To Create A Mole Whacking Game with Cocos2D: Part 1/2
Whack this Mole!
I thought this was a great idea for a tutorial for three reasons:
- 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 tutorial does exactly that!
- 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.
- And of course the most important reason – whacking moles is fun!
- How to Make a Simple Game with Cocos2D,
- How to Use Animations and Sprite Sheets in Cocos2D
- How to Create and Optimize Sprite Sheets in Cocos2D with Texture Packer and Pixel Formats
- How to Drag and Drop Sprites with Cocos2D
This is a two-part 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!
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
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.
“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.
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!- 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.
- 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.
- 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.
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 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!
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 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.
Planning the Art: Conclusion
OK, so based on the above discussion, here is the plan for this 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.
- 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).
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:
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:
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.
Compile your app, and you should see the output from Texture Packer from your build results if everything is working OK.
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:
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... |
- 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.
If you try the code on the retina display and zoom in, however, you’ll notice that it’s still using the normal artwork:
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"); |
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; |
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]; |
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; } } |
- 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.
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; |
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]; |
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]; } } } } |
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 } |
- 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.
- 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.
- 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.
- Creates an action to pause for one second after the mole pops out.
- 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.
Where To Go From Here?
Here is a sample project with all of the code we’ve developed so far in this tutorial series.Stay tuned for the next article in this series, 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!
No comments:
Post a Comment