The most frequent questions I get from readers of my Learn Cocos2D book:
- “Where can I download the source code?”
- “Why do I get compile errors in CCLabel?”
- “Is there an updated version of CCAnimationHelper?”
They all boil down to the fact that the book was written against cocos2d-iphone v0.99.5 with some projects using v0.99.4 and a few even had used v0.99.3.
Unfortunately this is also why some readers deducted one or more stars in their Amazon book reviews. Even more unfortunate because the changes that break the code were entirely cosmetic (renamed classes, function parameters removed or re-ordered, deprecated functions in favor of others). All changes required only fixing the lines using one of these outdated classes (CCLabel, CCLayerColor) or functions (bitmapFontAtlasWithString, frameWithTexture, …).
Quick List of Changes
I kept track of the changes I made to the source code. This is what it boils down to:
- remove: EAGLView viewWith… -> remove last parameter: preserveBackBuffer:NO
- remove: CCSpriteFrame: frameWithTexture -> remove last parameter: offset:CGPointZero
- remove: CCAnimation: animationWithName -> animationWithFrames & remove last parameter: frames
- rename: CCLabel -> CCLabelTTF
- rename: CCBitmapFontAtlas -> CCLabelBMFont
- rename: CCBitmapFontAtlas: bitmapFontAtlasWithString -> labelWithString
- rename: CCXxxxxTransition -> CCTransitionXxxxx
- rename: CCColorLayer -> CCLayerColor
- rename: CCQuadParticleSystem -> CCParticleSystemQuad
- rename: particle system: centerOfGravity -> sourcePosition
- change: particle system: use NSUInteger instead of int for initWithParticleCount
These are the changes affecting the book’s source code. There were some more changes in the cocos2d-iphone engine, for example some actions have been renamed as well.
Good News: Updated Source Code for v1.0
I updated the book’s source code to use cocos2d-iphone v1.0.0 rc2. Once the v1.0 final is released I’ll make another update.
You can get the book’s source code from the Learn Cocos2D Book product page (scroll to the bottom), or via this direct download link. The download is about 100 MB and contains all the chapter’s source code plus some extra projects not mentioned in the book, and all of them (over 70!) are now using cocos2d-iphone v1.0.
Note: This code obviously differs slightly from the code described in the first edition of the Learn Cocos2D book, so you should get the unmodified v0.99.x book source code as well.
Upgrading to Cocos2D v1.0
I also recently wrote a tutorial outlining the steps to update an existing cocos2d-iphone v0.99.x project to v1.0 in case you have an existing project that you’d like to upgrade to the latest Cocos2D version.
Learn Cocos2D: Second Edition
All these changes will be reflected in the second edition of the Learn Cocos2D book.
The second edition will be released summer 2011, likely around July to August. This is my estimate based on the fact that my work is scheduled to be completed on June 27th, and I’m working hard to keep that (tight) schedule.
Actually, make that we are working hard. The second edition of the Learn Cocos2D book will have contributions from a co-author. Someone who is well-known in the Cocos2D community! To be unveiled. 
Chapter 5 - Getting bigger and better
The gist of this chapter will be to discuss the simple game project from the previous chapter. I threw everything into one class, clearly not what you want to do for bigger games. But getting from one-class to real code design is a big step which some hesitate to take. I’ll make that easier and discuss common issues and their solutions, such as what to seperate, what to subclass from and how you can have all the seperated objects communicate with each other and exchange information in various ways.
A big topic will of course be how to take advantage of cocos2d’s scene hierarchy and which pitfalls it may have when moving from a single-layer game to one which has multiple layers and even multiple scenes.
As for the chapter title I’m not so sure if that’ll be it. Maybe along the way while I’m writing I’ll change it. Suggestions welcome!
The chapter will be submitted on Friday, July 30th.
What’s your take on good cocos2d code structure?
Did you ever struggle with cocos2d design concepts? Or the cocos2d scene hierarchy? Or how to layout a scene and divide your game into logical parts? Tell me about it.
I know theses questions are somewhat generic to ask. It’s about the things that don’t feel right but there doesn’t seem to be a better, more obvious way. I think we all know some of those, if you do, be sure to tell me! Leave a comment or write me an email.
Summary of working on Chapter 4 - First simple game
The game I chose to make is called Doodle Drop and features dropping spiders and an accelerometer controlled alien trying to avoid the spiders. All in all it got divided into 8 concrete steps. Lots and lots of code comments, too.
It starts simple enough, adding resources to Xcode and adding sprites. It gets more gameplay-esque when the accelerometer-driven player controls got tweaked to provide acceleration and deceleration of the player object. In contrast, the spiders movements are driven only by actions.
I introduce you to two undocumented features of cocos2d, namely CCArray which is since v0.99.4 used to store all children of a node. The other are the CGPointExtension class which has all the functions normally provided by a physics engine, however not every game should link a physics engine just because one needs those math functions. That’s why CGPointExtension comes in handy.
With the ccpDistance method the collision checks are done. Simple radial collisions, and in debug mode the collision radii are drawn too.
In between the CCLabel for the score got replaced with a CCBitmapFontAtlas, because it killed the framerate. I shortly mentioned Hiero and how to use it in principle but for all the details there was no room. But while I was at it I created the Hiero Tutorial.
At the end of the project I added some polish which isn’t described in the book (too many details) but really adds to the game’s look and feel. The spiders drop, hang in there, then charge before dropping down, all done using actions. I’ve also added the thread they’re hanging from using ccDrawLine. And then there’s a game over label which shows even more action use.
One of the principles I followed is to stay away from fixed coordinates as much as possible. So the project, once finished, did run just fine on an iPad. Although the experience is a different one, there’s more spiders dropping and they drop faster but there’s also more safe space to maneuver to.
Oh and, the game art is all mine. Yes, I know … but Man-Spiders do have just six legs!
Chapter 4 - First Simple Game
After Chapter 3 covered the fundamentals of the cocos2d game engine, this chapter will put to use what you’ve learned. The simple game is all about droping enemies that you have to avoid via accelerometer controls. Sort of like an inverse Doodle Jump. But it’s not just about the gameplay itself, I want the game to be reasonably complete with a main menu, scene transitions, game over and of course audio.
The chapter will be submitted on Friday, July 23rd.
Do you have any suggestions for the game?
What do you think should be in a first cocos2d game? Let me know!
Summary of working on Chapter 3 - Essentials
When I started the chapter I wasn’t really sure about its focus and progress was a little slow. Eventually it clicked and I found myself ending up having written more pages than needed and still having a great number of things left untold. The key was looking at the cocos2d API reference documentation and remembering what it was like when I was a beginner. Sure, every class, method and property is there but for a beginning cocos2d developer the API reference is just a huge list of names. In other words, if your experience was or is anything like mine was, it’s frustrating to work with the API reference.
I ended up writing about the cocos2d engine design and its scene graph first, the remaining 80% of the chapter explain in detail with lots of code samples how to use those darn CCNode classes. All the important ones are covered: CCNode, CCScene, CCLayer, CCSprite, CCLabel, CCMenu, CCMenuItem* as well as the Director, Transitions and Actions. Besides the code samples and how-to I’ve added numerous caveats, common mistakes, best practices and other nodes which are so very much needed to make any documentation complete.
For example, how Layers are best used for grouping other nodes together and of course how to enable touch and accelerometer input by adding the required functions which aren’t mentioned in the API reference since they are part of the iPhone SDK API. There’s also some weird recommendation floating around not to use too many Layers because they’re slow. I can’t find the source but what I did find was that this is only true if the Layers enable touch or accelerometer input, because that’s what costs a lot of performance. So what you don’t want to have is several layers accepting input, otherwise use as many Layers as you need - which shouldn’t be many anyway. And if you do need multiple Layers accepting input, why not just use one master Layer (possibly using a Targeted Touch handler) which forwards the input events appropriately to the other Layers?
