A question I see frequently asked by Cocos2D developers, in simplified form:
"I have this node A, how can I access this other node B?"
Whether it’s executing a message or getting the node itself as a reference, developers have a problem accessing nodes in other parts of the scene. Or the scene itself.
The most obvious is also a potentially dangerous solution: initialize the node with the references to the other nodes it needs. The danger lies in retain cycles, when node A has a retaining reference to node B and vice versa – then neither of them will let go, memory is leaked, strange bugs appear.
From the Cocos2D questions on stackoverflow.com it’s obvious how prevalent retain cycles issues are among Cocos2D developers. Therefore this article with strategies for accessing other nodes in various situations with their benefits and drawbacks.
And an explanation why self.parent.parent.parent… is really terrible practice.
Essential Cocos2D: Free Sample
Today’s iDevBlogADay article is a sample article from the upcoming Essential Cocos2D online documentation. That’s why it’s on a separate page.
More about Essential Cocos2D soon. It’s growing fast. And not to forget: Learn cocos2d 2 is now available!
Learn Cocos2D 2 – Game Development for iOS will finally be available on September 19th 2012. Completely updated for cocos2d-iphone 2.0, Kobold2D 2.0 and ARC.
But that isn’t all!
Essential Cocos2D – The Definitive Reference is an online documentation for cocos2d-iphone 2.0 and Kobold2D. More details soon. In the meantime, here’s a sample chapter about How Draw Order Works in Cocos2D.
What’s the difference?
As a cocos2d user you’ve probably encountered this before: you just added another sprite, a label, a particle effect or some other node to your scene – but it just won’t show up!
This article is an attempt at documenting the possible causes, providing steps you can take to verify and hopefully rectify the situation. You can use this as a checklist to provide help for this exact situation. Bookmark this page because you will have to use it eventually, I guarantee you.
This is an update to the last sales statistics post to include Apple’s Q2 and Q3 2012 results as well as adding Macintosh sales:
I got the Mac sales numbers from Apple’s quarterly Earnings Press Releases dating back to Q1/2007. Nearly all Macs sold from 2007 onwards are capable of running at least OS X 10.7 (Lion). The Mac numbers include both desktop (iMac, Mac mini, Mac Pro) and portable (MacBook series) machines.
This puts things in perspective from sheer numbers. There are now more iPads in the world than there are (relatively up-to-date) Macs!
On the other hand, given that most Macs cost over $1,000 the sales numbers aren’t reflecting revenue. But you can argue that making a Mac OS X (Mountain) Lion app has the potential to reach the same number of App Store users than an iPad exclusive app.
I have a problem with terms that are not clearly defined. Words like “much”, “a lot” or as in this case: “unbelievably high”. If you argue that the problem with Android is its high piracy rate based on one developer’s subjective statement and general hearsay, it’s not an argument.
Before I get to debunk why piracy can’t be that big an issue for Android developers, allow me to restate which developers regularly complain about piracy to begin with. There always seems to be the issue that low selling apps see a much larger percentage of pirated copies being used than high volume apps. This is because some pirates download and try out almost everything that’s available just because they can.
Interestingly, the badly selling app developers seem to be those who complain the most about piracy. Because it’s so easy to blame a failure to sell on piracy. See this fictive graph:
… but not quite out yet. If you can’t wait until August 29 you can always buy the Alpha eBook version now (as PDF) and receive the final eBook version for free (as PDF, ePUB and MOBI) when it’s available.
I’ve updated the book’s product page and included links where you can download the source code for the 3rd edition.
Learn cocos2d 2 (Third Edition)
Release Date: August 29, 2012
Cocos2D v2.0 is used throughout the book. To my knowledge this makes the Learn Cocos2D 2 book the first book to cover cocos2d-iphone v2.0.
ARC (automatic reference counting) is used exclusively in the book. All descriptions and source code projects have been updated to ARC, and 12 Cocos2D ARC-enabled Template Projects are included in the source code download. The book contains a description on how to enable ARC in a cocos2d project. Working with ARC means having to write and learn less code while being able to write faster code with fewer bugs. Win, win, win.
You can now also follow the book while using Kobold2D. Any differences between cocos2d v2.0 and Kobold2D v2.0 are explicitly mentioned in the book. In fact, you’ll have to work through less text and code if you use Kobold2D.
The book’s source code is compatible with Xcode 4.4, Mac OS X 10.8 Mountain Lion and iOS 6. It is of course also tested to work with Xcode 4.3, Mac OS X 10.7 Lion and iOS 5.
Learn more about the Learn Cocos2D 2 book here.
I just released a compatibility update for Kobold2D since there were numerous compiler warnings and errors introduced in Xcode 4.4.
Almost all of the issues were simply the compiler being more adamant about using the correct type specifiers in format strings. For example using %i for an unsigned integer or %u for an unsigned long type would bring up warnings. The solution is to use either the correct format specifier or casting the value. The latter is preferable if the underlying type changes depending on the platform. For example NSUInteger is unsigned int for iOS but on Mac 64-Bit it’s actually unsigned long.