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. 
The Learn Cocos2d Alpha Book’s page now lists the source code for download. It’s 44 MB, contains the source code for the first 9 (!) chapters as zip files.
I’m not sure if everyone can download the source code, or only eBook purchaser. I wasn’t asked to login, so I think it may be available for everyone. Try it out! Here’s a direct download link:
Direct Download: Learn Cocos2d Alpha Book Source Code
Before you ask: no, Chapter 6 and beyond are still not available yet. They will have to wait until they have gone through the editorial process. I believe Chapter 5 is currently in this process so it will still take at least a week, maybe 2-3, before you’ll get your hands on Chapter 6. But I hope that once the editorial process has caught up with the already available 5 chapters, new ones should be available on a regular basis. Every 1-2 weeks I hope, but no guarantees. This process is very new to me too so I try to be very careful making any assumptions.
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?
On May 27th, the whole world saw the future. Because i told you so!
Line-Drawing Game Starterkit -> June 1st!
What’s that you ask?
It is the ideal starting point for your own Line-Drawing game! (like Flight Control and Harbor Master) It is a cocos2d source code project that will be available for sale. But not sight unseen, no. It will appear on the App Store for you to try out. And you get more, the full doxygen-generated source code documentation is available for browsing right now! Just so that you can assess the scope of the project.
What will it cost?
I admit i haven’t decided on that yet.
Show me your license!
Alright, alright. I’ll be fair: Free lifetime upgrades! Unlimited number of developers!
Each license is good for one published game. Additional licenses for follow-up games come at a discount. “Lite” versions do not require an extra license since they are essentially the same game. There will also be a commercial license for developers or studios who make more than $6,000 per month in revenue and can easily afford a higher price.
Why, please tell me why?
Because i can. I like technology and i like programming games. I’m also an enabler and i would love to see others build something unique based on game development technology i provide.
Anything else?
Yes. Today sees the premature end of the best new show of last year. RIP Flash Forward.
I stumbled across this AppBoy Blog Post about Android and its Market. And it reminded me of what i think when i hear people swearing by the Android: the Android is not going to rule the world. Period.
The reasons are not many but they are crucial. First, Open Source is not a Feature! I hear that very often. “Yeah but Android is Open Source, you can’t compete with that!”. Uh-huh. As a matter of fact, i do not want to compete with Open Source if that means low-quality crap. There is no quality control on the Android Market. For some this spells freedom of choice and what not. And yes, Apple has made some decisions to pull apps from the App Store that a lot of people didn’t like. But let’s not forget that 99% of iPhone OS users just don’t care. There’s still enough diversity, and it’s not like Apple has pulled the Facebook App, Twitterific, Doodle Jump or Angry Birds. Apps that people really use and like. Keep in mind that whenever Apple decides to pull an App, recently that was because of mature content while allowing a big player in that market to keep his Apps online, people talk about that because (a) they like to get upset and (b) the blogosphere and news outlets need something to talk about. In the end it’s just hot air.
Let’s get back to Android though. So it’s open source. What does that even mean? The OS itself is open source. Great for the companies who build their own devices on that software. Bad for the consumer: you still have the same problem all mobile phones have. It’s like switching from Nokia and it’s hundreds of different devices united by the Ovi Store to Android, with its hundred and more and more diverging devices and a united App Store. Where does that lead us? A huge pile of free choice no one really wants if you so will. For developers it gets increasingly harder to develop Apps that run on all Android devices and what’s more, even if you manage to support 99% of all devices right now, tomorrow there will be a new device coming out that won’t run your app. As an independent developer this is hell. You have no way of telling whether supporting a specific line of Android devices will get you a significant sales boost. So how do you calculate how much time you’ll spend on each? It’s pure guesswork. I pity Android developers.
The iPhone market itself is hard but there’s one thing you can and should put all your efforts in: Marketing. You develop for one device (well, ok make that 3) while in the meantime you figure out which websites to target, what to blog, which communities to join, where to apply for App reviews, what Press Releases to send out, etc. The code is already done, Marketing your App is the hard part. It’s the same with the Android, except that the code part with its diverging devices is just as hard to do. And it’s just not fun adapting the same app to different devices. It’s one of the things i wouldn’t mind not doing.
Most of the outspoken people who choose Android choose it because they don’t like Apple (fair enough), or they don’t like closed ecosystems and enjoy (really?) everything that has the label “Open Source” attached to it. However, they’re a minority on the Android market. Most Android users just got what they needed: a working mobile phone. They have no idea, and no clue and don’t care about Open Source. For them, the label “Open Source” has no meaning.
