Notes on Cocos2d iPhone Development

Recently I've been using the Cocos2d iPhone library for game development on the iPhone, and it's a really fantastic library to work with. There isn't a whole lot of available source to look at though, so I've put together a few snippets and thoughts about usage.

Overview of Cocos2d iPhone

Cocos2d iPhone is Ricardo Quesada's port of the Cocos2d library to Objective-C. The original is actually a Python library, and is intensely awesome. The ObjC port can't be run in a REPL, so it is slightly less intensely awesome, but is still the cure to what ails game development on the iPhone.

When I was working on my first game, Processed Tower Defense, I learned a tremendous amount over the course of the project. I rewrote it a couple of times with better designs, and towards the end felt like I was finally starting to unlock the gates to magical and rare realms of game programming knowledge. As a result, when I started programming a game on the iPhone, my first step was to port my overall design from JavaScript to ObjC. There are certain... mismatches between the two, but it was working out well enough. That is, until we ran into OpenGL, which was something like coming upon a family of skunks blocking your trail while hiking. I mean, you could walk through them. But, damn it, do you have to?

The documentation for OpenGL on the iPhone wasn't copious, and began to hinder progress. I imagine the current docs are sufficient for someone who is already fluent in OpenGL, which is perhaps their intended audience, but it left me floored. Which was something of a problem. Fortunately, the wise Luke Hatcher suggested that we migrate the project from the adhoc framework built by yours truly, to Cocos2d iPhone. And lo, out of the box, Cocos2d already had all my hard-earned game knowledge (and more) thoughtfully integrated into a cohesive package.

The rest is history, albeit not history that anyone knows or cares about.

Key Classes

CocosNode is the most important class you'll be working with.
If an object does any of a) move, b) display or c) change
then you'll want to be using a CocosNode to represent it.

You'll use a lot of these. My experience is that it is
simpler to subclass CocosNode and add Sprites to it,
rather than subclassing Sprite directly. Among other things,
that allow you to combine multiple images into one node and
transform them consistently by transforming their parental
node.

Action are transformations that are applied to CocosNodes.
There are a number of actions, split into two groups: IntervalAction
and InstantAction. As you might imagine, IntervalActions occur
over a period of time (although you can always set that period
to be zero seconds, making the action occur instantly), whereas
InstantActions occur instantly.

Some of the useful actions are:

ToggleVisiblity makes a CocosNode appear/disappear.

RotateBy rotates a CocosNode a number of degrees.

MoveTo moves a CocosNode to a position.

ScaleTo scales a CocosNode by a factor.

FadeTo set a CocosNode's opacity.

They are used like this (some have slightly different parameters
for their constructors, so be sure to check the docs):

Layer is a container of one ore more CocosNodes.
A subclass of CocosNode, they are used for grouping
distinct parts of your application. For example, you'll
have a main menu layer, a game layer (at least one,
possibly many depending on your game's dynamics),
a pause menu layer, etc.

Usage is the same as with CocosNode, except initialize
using [Layer node] instead of [CocosNode node].
This is another class that you may find yourself
subclassing frequently.

Scene is a collection of one or more CocosNodes,
but usually contains Layers. They are
passed to the Director to determine what is currently
visible/occuring in the game.

Override the standard UIEvent touches methods for one
object (probaby a subclass of Layer), and having it
serve as a UI manager for all objects it contains.

The first approach is simpler, but less flexible (more difficult to
manage event propagation and other custom logic). on the other
hand, the second approach is more work, and doesn't fit trimly into the
snippet format.

Roughly, the first approach will look something like this
(in the implementation file for a subclass of CocosNode):

-(void)touchesBegan:(NSSet*)toucheswithEvent:(UIEvent*)event{UITouch*touch=[touchesanyObject];CGPointlocation=[touchlocationInView:[touchview]];// do stuff}-(void)touchesMoved:(NSSet*)toucheswithEvent:(UIEvent*)event{UITouch*touch=[touchesanyObject];CGPointlocation=[touchlocationInView:[touchview]];// do stuff}-(void)touchesEnded:(NSSet*)toucheswithEvent:(UIEvent*)event{UITouch*touch=[touchesanyObject];CGPointlocation=[touchlocationInView:[touchview]];// do stuff}

Well, those are my guiding notes for the time being.
I'll try to write something more comprehensive soon.

Hi folks. I'm Will, known as @lethain on Twitter.
I write about software and management topics,
and love email at lethain[at]gmail.
Get email from me by subscribing to
my weekly newsletter.