For the past two weeks I’ve been running a Cocos2D Developer Survey. As of today, 236 developers started the survey and 189 finished it completely. That’s 80% despite the many questions they had to answer.
Here are the results with my observations. I started the survey also to see if I was on track with KoboldTouch, and whether certain assumptions hold true. Specifically I had a hunch that cross-platform development is only perceived to have great value or appeal. Let’s see if I was right.
Click on each image for full resolution.
Who are you?
I was very curious how many cocos2d developers consider themselves to be hobbyists and indies compared to professionals, who either work for a mobile developer or are taking on freelance jobs as one.
Almost half of those who answered the survey are hobbyists. Nearly 30% consider themselves indies who make a living making mobile games. This is great! Continue reading »
It’s hard to find the right words to describe the launch of KoboldTouch. I can’t think of anything else but WOW! right now. 
I can’t wait to hear what you have to say about KoboldTouch, and then act on your feedback.
For those who were just waiting for the launch:
Sign up on the KoboldTouch product page to get access to KoboldTouch and Essential Cocos2D.
The rest of this post is a summary of what I wrote before on these two-products-in-one. Actually, I think of KoboldTouch & Essential Cocos2D as being much more a service than products. And it’s a full time commitment from myself.
This calls for music!
Since I started working on KoboldTouch a couple things fell into place. Mainly that it would:
Provide what Cocos2D leaves up to its users. Fixes what Cocos2D does badly. Adds what Cocos2D doesn’t do at all. Eases development with Cocos2D and accommodates actual developer needs.
While Cocos2D is moving towards cross-platform with their Javascript API, KoboldTouch will focus on adding & improving game design features.
I have a hunch most Cocos2D developers have better iOS/Mac integration and game-specific features higher up on their wish list than cross-platform. Most of you are indies, hobbyists, pragmatists and Apple enthusiasts without the need or resources to do cross-platform development.
UPDATE: KoboldTouch is now available!
KoboldTouch: Spiritual Successor
I first started working on KoboldTouch a few weeks back. I initially undersold it as a “MVC wrapper for Cocos2D”. With what I have in mind spiritual successor of Cocos2D is more like it.
It’s going to be a framework to program iOS & Mac games in, where best practices evolve naturally, where Cocoa programmers feel right at home, where beginners are not left in a void * EXC_BAD_ACCESS … and where Cocos2D is still at the heart of it.
KoboldTouch takes control over Cocos2D, to allows users to implement best practices naturally. Cocos2D provides the view, KoboldTouch provides the controllers, models and the framework to write your code in.
Here’s what I’m working on. Hopefully this answers the questions I’ve been getting, in particular those about KoboldScript. And what’s happening with it, when is it coming, when can we stop using Corona SDK, etc.
UPDATE: KoboldTouch is now available!
Well then, let’s start with …
KoboldTouch
Huh, what?
Well, the short answer is: KoboldTouch is an MVC wrapper around Cocos2D.
The long answer … let me start by saying that Cocos2D is suboptimal. From a code architecture point of view. Cocos2D has no concept of structure besides views (nodes), and doesn’t encourage structure in your own code. It happily lets users subclass views in order to add data and game logic.
I can’t stop but feel helpless to see beginners learning the things we’ve abandoned 20 years ago as bad practice. Yet Cocos2D code is written by subclassing views as if it were the most natural thing to do. It’s also the very thing Apple tells you not to do.
The result are projects lacking in what is called separation of concerns. It’s not just about experience. Without a clear architectural model frequently reminding you to consider separation of concerns, anyone is more likely to end up creating a blend of design patterns at best, or worse:
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!
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:
Apple Device Sales, accumulated (Q1/2007 – Q3/2012). Y Axis is in millions.
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.
Example ARC project. Pretty awesome.
Therefore I decided to enable ARC in all twelve standard cocos2d Xcode project templates for both cocos2d versions (v1.1 and v2.0), both platforms (iOS and Mac OS), both physics engines (Box2D and Chipmunk) and publish them on github.
You can download the ARC-enabled cocos2d template projects either as ZIP file or TAR file.
Loading ...
