Ramblings about the Cocos2d Director class

All Cocos2d based applications use 2 core classes above all others, Director and CocosNode(Sprite,Scene,Etc..). I want to give these 2 objects some special attention up front as you will interact with them most often in your initial Cocos2d projects. In this post we will focus in on the Director class.

Director is the class that acts as a binding agent linking the Cocos2d Scene management system to the UIKit framework. It takes over control of application flow, most commonly, in the UIApplicationDelegate applicationDidFinishLaunching function override. There are 2 different "types" of Director. The normal director and a higher performance fast director. The director maintains the applications main run loop, runs the initial scene and houses the functions that start and stop the main run and animation loops.

Encapsulated in the Director is the one and only EAGLView instance. This our rendering surface and is where all of the drawing for our Cocos2d based application happens. The EAGLView is backed by CAEAGLLayer which is an especially talented core animation layer that has an OpenGL ES rendering context. As I stated in the previous post this is not an OpenGL ES tutorial. Being satisfied in the knowledge that Cocos2d will be handling all of the OpenGL ES kung fu for you will allow you to focus on the specifics of your particular project. After a while using Cocos2d for IPhone go back and optimize the parts that require special attention for usage in your application. The whole point is not to reinvent the wheel.

The simple sample code below sets up a director for an application in landscape mode, that shows the frames per second and runs with a Scene. Also observe the main loop control functions being called in the application delegates applicationWillTerminate, applicationWillResignActive, and applicationDidBecomeActive functions.

Next post I will be focusing on the CocosNode class and Node inheritance hierarchy. I will also discuss scene graphs and how the Cocos2d Nodes realize the composite design pattern.

BTW

I'll be announcing new blog post on twitter when they are done.

Cocos2d for IPhone Ramblings: Pref

I, for the most part, am not the type to write long drawn out blog entries about specific development technologies. That being said I am going to break character a bit and write a little about Cocos2d for IPhone. I have experimented with a few different game development APIs/Frameworks for the IPhone & IPod Touch and have come to the assertion that for me Cocos2d is the easiest and quickest way to get a nonstandard Touch application up and running.

BTW: I wont be giving any sort of C, Obj-C or XCode primer so before I start my second post on this thread go out and google up some Obj-C and XCode goodness. I will also not be going into introduction of OpenGL ES because there are volumes written on the subject. I like Jeff Lemarche's OpenGL ES from the ground up series. It is a great introduction to OpenGL ES written specifically for IPhone/IPod Touch by someone who writes books on the subject of IPhone development specifically.

Cocos2d for IPhone is an open source project under the GNU LGPL hosted on google code at cocos2d-iphone. It is a port of the Cocos2d Python framework re-implemented in the Objective-c programming language for use on the IPhone and IPod Touch by Ricardo Quesada and company. Go thank them and contribute, they deserve it.

Cocos2d sits on top of OpenGL ES abstracting away most of the more tedious time consuming aspects of OpenGl based 2d programming. Fact is you can use the framework without writing a lick of OpenGL rendering code. You can also dip down into the lower levels of the framework and change the underlaying OpenGL calls as all of the source code for the framework is at your disposal in the distribution.

My little ramblings about Cocos2d do not live in a vacuum. There are many other blog based Cocos2d programming tutorials covering basic usage, project creation and XCode integration, and even some fully implemented game source code to learn from. They are written by much more notable IPhone dev community members than I (The list of links above is not exhaustive). I will cover some of the same material but will be more concerned with looking at the architecture, object model and implementation details of the framework than creating an operational game. I will try to post at least once a week day job, side job and family permitting.

As you can probably see by this initial post I am a little hyperlink happy. I have a preference to linking directly to content specific to subject matter rather than paraphrase some other persons more thorough explanation. Please forgive this habit in advance.

Kenneth A. Barber