The Ultimate Cocos2D Project: Kobold2D

On March 19, 2011, in Kobold2D, by Steffen Itterheim

What is Kobold2D?

It’s the Ultimate Cocos2D Project, of course. Or more precisely, the official name for it. Right now, the website is only a “coming soon” page while development is under way.

What’s in a name?

Calling it “The Ultimate Cocos2D Project” all the time would have become tedious rather quickly. I wanted a name that is reminiscent of Cocos2D yet completely different. As luck would have it, I’ve recently watched a lot of Battlestar Galactica episodes. You might remember that in this show humanity’s home planet is called Kobol. I couldn’t help but think of COBOL all the time. 😉

From there it was a small step to Kobold, which in germany is widely associated with a famous cartoon Kobold called Pumuckl. As a kid, I was a big fan of Pumuckl, so picking Kobold2D as the name was a no brainer. Even more so since it has the same ring to it than Cocos2D.

Why create a new brand name?

For one, giving the project a name of its own clearly makes it more attractive. It expresses a certain dedication to the project. It should also signal that it’s no longer just about Cocos2D. With all those extra libraries and additional glue code, plus an experimental project I’m working on, I’m tempted to call it a Game Development Kit (GDK). That’s the long term vision for Kobold2D: more power, easier – for everyone!

Speaking of long term, that’s another reason to give it its own brand name. The visionary thought being that ultimately, something like Kobold2D could be implemented for other game engines as well, with the same core values: give the developers more power, greater flexibility but at the same time make it easier for them to get started.

The Kobold Team

I’m not the only developer who is aching for a more professional work environment. Kobold2D is a joint-venture with another senior software developer and a couple helping hands who help out wherever and whenever they can. We agreed to share the development burden on a voluntary basis. We all have different stakes and interests in the development of Kobold2D.

For me personally the most important aspect is my ambition to develop a project for its users, both professional and casual. I know I can build professional systems that are easy to use, well documented and thus get the job done painlessly. This basically sums up what I’ve been doing for the past 10 years.

What we’re not doing …

There’s one issue I think i going to come up, which might confuse some people, so I want to be clear about this: we are not creating a branch of Cocos2D. We have no intention to do so. We use the library as is, and we stick to the stable builds. The same goes for all other libraries of course.

At the same time, we don’t push each and every line of our additional code back or even contribute to the development of the libraries in Kobold2D. That’s not what we set out to do, and we simply don’t want to spend too much time consulting with and compromising on changes with others when our code is already there and working for us. Our code uses the MIT License, so it’s there for the taking.

In very few cases we can’t get around to modify library code. We only do this where necessary, for example if it breaks our build and the fix is rather simple. Other than that, if a library doesn’t work to our satisfaction, we try to add our fixes and improvements on top, either by subclassing or by making use of Objective-C categories. So far this has been working very well and allows us to keep updating the underlying libraries with far fewer hassles.

Next steps

One big task that I set myself out to complete before continuing with Kobold2D is figuring out the Xcode 4 template format for File Templates and Project Templates. I almost have everything together after spending practically the whole week on it. I’m also documenting all my findings and I’m going to publish the Xcode 4 Template Tutorial / Reference / Documentation / Manual (not sure about the name yet) by the end of the month.

The goal for Kobold2D is to have various project templates, which is why I’m doing extensive research on the new Xcode 4 template format. Unfortunately at the moment it seems that it will not work satisfactory with cross-referenced Xcode projects, but I remain positive that I can find a solution.

Kobold2D private beta!

There will also be a private beta test for Kobold2D starting in a couple weeks (couple == definitely more than 2 weeks). Reply to the private beta sign-up thread if you want a chance to be picked for the private beta test.

Tagged with:  

The Ultimate Cocos2D Project: Libraries

On March 4, 2011, in cocos2d, Kobold2D, by Steffen Itterheim

The Ultimate Cocos2D Project is: Kobold2D!

Put simply: Kobold2D is designed to make Cocos2D developers more productive.

Original Post

Last week I wrote that I’m Building The Ultimate Cocos2D Xcode Project. In today’s weekly update I wanted to give you some more details on the use of libraries in that project.

Cocos3D included

So there happens to be a Cocos3D now. Rather than being part of the Cocos2D distribution, it’s an extension project. Guess what that means? Right, installing Cocos3D means fumbling with the dreaded script (see this Cocos3D tutorial). Of course the first user reactions were: how do I install it? Installation failed, what am I doing wrong? And so on …

The Ultimate Cocos2D Project wouldn’t be ultimate if it didn’t include Cocos3D out of the box. And unmodified of course, as with all included libraries I want to make it as simple as possible to replace one library version with another. Once you get to half a dozen of included libraries, maintaining them all can become a hassle, so the very least I can do is to make it easy for everyone to upgrade specific libraries.

Obviously: Cocos2D included

Of course Cocos2D is also included as a static library as opposed to cluttering your project with all of its source files. Xcode project references make it very convenient to add external code and keeping it seperate. I’ve described the process in detail in my Cocos2D Xcode Project tutorial but since then I’ve learned a couple more things about how to make this even better.

For example, I no longer include cocos2d-iphone directly, instead there’s a seperate Xcode project in between so that I have full control over build settings (using XCConfig files) and make it possible to build both iOS and Mac OS targets in the same Xcode project. I will also include the current version of Cocos2D in the download because my goal is to make everything work out of the box.

No fumbling with install scripts, no additional downloads necessary, no need to modify any Xcode build settings – including developer certificates and header search paths. Build configurations for Ad Hoc and App Store release builds are also included, which will create .IPA and .ZIP files for you ready for Ad Hoc distribution respectively upload on iTunes Connect.

Popular libraries included

Now let’s get to the juicy part. Early on I realized that Cocos2D users often needed (or wanted) to include other libraries. Some of them have become so popular among the Cocos2D crowd that they could as well be part of the official distribution. Alas, they’re not. That’s a service I want to provide.

Often those libraries require special and non-obvious steps to successfully add them to an existing project. All too often those steps are either undocumented, untested, hard to follow, refer to outdated versions of Xcode, iOS SDK, etc. and generally require technical expertise of project configuration and compiler settings.

This is all taken care of for you. Here’s the list of libraries that are already included in the Ultimate Cocos2D Xcode Project:

That is quite a list. All you need to do to use these libraries is to either enable them in code or merely include the header file and start using them. If you worry that all these libraries will bloat your App, rest assured that Xcode is very clever: if you don’t actually make use of a static library (eg don’t include any of its header files), it will not be linked with your App and not waste any space or performance. I verified that.

Update policy

These are a lot of libraries to keep up to date. I plan to make about 4-8 point releases each year, usually triggered by a major (speak: non-beta) release of Cocos2D. If updating other libraries justifies an update depends on the library’s importance and the significance of the update.

Your libraries

Adding your own libraries to the project will be easy and the process will be documented. This will encourage code-sharing because your library will just work with other user’s project, it only needs to follow a few simple guidelines to become plugin-capable. This opens the door for better and tighter integration of 3rd party code into your projects. Even if you don’t intend to share your code, you’ll still benefit because your code will be easier to re-use and maintain.

Also, if you like you can make a request for a specific library or additional source code that should be included in the project, please leave a comment. I’ll see what I can do. :)

I almost forgot about the Cocos2D-Project on github. While it works flawlessly with the latest v0.99.5 stable release of Cocos2D, it was still bundled with only the RC1 (release candidate). So I’ve updated the cocos2d version in the repository.

In case you don’t know what Cocos2D-Project is:

Cocos2D-Project is a great way to start any Cocos2D-iPhone based project.

It eases up- and downgrading the Cocos2D game engine at any time. It includes additional source code as well as multiple targets and build configurations for Ad Hoc & App Store distribution (creates the necessary IPA/ZIP files) and debugging of memory leaks and related issues.

Cocos2D-Project is free, open-source, uses the MIT License and comes already bundled with the cocos2d-iphone version that it currently works with “out of the box”.

It’s not affiliated with or endorsed by and Ricardo Quesada. You will get support for Cocos2D-Project on Cocos2D Central.

Future updates

With the help of others, the Cocos2D-Project development has taken on a life of its own. The current work in progress is much more than a simple Xcode project referencing just the Cocos2D game engine. I’m looking forward to announce a big update in a couple weeks. Stay tuned.

Tagged with:  

How to properly install the Cocos2D Xcode Project Templates

On January 4, 2011, in cocos2d, support, Xcode, by Steffen Itterheim

You can get Kobold2D from which is an easy to use wrapper (and installer) for cocos2d and related libraries plus many example projects. If you want to support development of the new, modernized version of Kobold2D then please consider joining KoboldTouch.

Installing Cocos2D Xcode Templates

If all you want to do is to install one of the latest cocos2d version’s Xcode templates, type this in a Terminal window:

First, change to the cocos2d-iphone directory using the cd command, for example if you unpacked cocos2d to ~/Documents the command would be:

Then run the Xcode templates installer script, -f forces overwrite of any existing cocos2d templates:

You can find more details in my blog post about enabling ARC in a cocos2d project.

If you’re new to cocos2d or Objective-C programming, make sure you enable ARC in all your projects! Not using ARC will be a painful experience, it makes it harder to write correct Objective-C code, it will slow you down, it might even demotivate you. Use nothing but ARC. Please. I still see way too many cocos2d related questions on which would not be an issue if the users had simply enabled ARC.

Tagged with:  

Linkvent Calendar, Day 14: Box2D Top-Down Car Demo

On December 14, 2010, in Cocos2D Linkvent Calendar, by Steffen Itterheim

Jeff Hodnett has ported a popular Flash ActionScript Box2D Car demo to Cocos2D:

Box2D Car Demo

The car uses two revolute joints for turning the car and two prismatic joints to add driving force (torque?) to the car. The Xcode project is available for download and the virtual thumbstick controlling the car is provided by the popular SneakyInput library.

The Art of Assertion (as it pertains to Xcode)

On November 9, 2010, in Programming, Xcode, by Steffen Itterheim

Recently, I’ve changed all my project’s source code files from .m to .mm file extensions. This is telling the compiler to compile the files as Objective-C++/C++ code instead of the default Objective-C/C. I needed to do so because I’m using Box2D, and as a habit I intend to use .mm from now on for every source file I create.

However, beware the subtle differences. Previously, if an NSAssert was triggered, it halted the program execution. But in .mm files it simply prints the assertion message to the console while the App continues execution. This leads to overlooked assertions, or continuously dumping assertion messages to the console. Clearly not what I wanted. Changing the file extension from .mm back to .m fixed the problem, but that’s not an option I have for all files.

I looked around and found a blog article by Vincent Gable mentioning that NSAssert is considered harmful. That caught my attention, because it described the same problem that I experienced (NSAssert not halting execution) while basing the argument on Voodoo (“Sometimes it does, sometimes it does not …”) respectively no argument at all, it’s just telling you “NSAssert is unreliable, therefore dangerous”.

It’s as if he wants me to prove him wrong. :)

In Vincent’s defense, the wrong he’s done unto NSAssert he makes up for by having written a great logging method which I’m going to add to gocos because it’s so handy.

Why assert() is less useful than NSAssert

First of all, the assert() function has one big problem: it doesn’t allow parameters to be added to the output string, since the output string can only be a constant string, like in this example:

[cc lang=”objc”]
assert(value < maxValue && @"value too big!"); [/cc] With NSAssert you can actually embedd some values into the assertion message: [cc lang="objc"] NSAssert2(value < maxValue, @"value %i too big (max:%i)!", value, maxValue); [/cc] It is tremendeously helpful in many cases to actually see the offending or interesting values in the error message, without having to fire up the debugger. Especially when it comes to filenames, and even more so if end users might see those assertions. Not a problem on the iOS, but think of developing desktop Apps.

Why NSAssert isn’t harmful, and how to fix it

So then, why did my App not stop execution when an NSAssert triggered? I can’t really answer you that, Apple’s docs say that NSAssert will raise an NSInternalInconsistencyException. So that should stop the App from running? It does not seem to be the case when you’re using the Objective-C++ compiler, and I’m not running the code on a different thread either. Maybe someone can shed some light as to why NSAssert in C++ code doesn’t automatically stop the App from running.

The good thing is, there’s an easy way to fix that. In Xcode choose Run -> Show -> Breakpoints from the menu, to bring up the breakpoints list. In the breakpoint list you only need to add the symbol objc_exception_throw. Next time an NSAssert triggers, the App will stop immediately and bring up the debugger.

Some places (for example: here) will also tell you to add [NSException raise] to the breakpoints list. That’s not necessary, this has been replaced with objc_exception_throw since Mac OS X 10.5.

Turning off assertions

I must admit, I’m totally spoiled by Visual Studio. Why Xcode requires you to add NS_BLOCK_ASSERTIONS as a macro to your project’s build settings in order to not compile NSAssert in release builds is beyond me. If you’re using NSAssert in your code, make sure that your release and/or distribution builds define the NS_BLOCK_ASSERTIONS macro.

If you do use the assert() macro however, or if you’re using a 3rd party library that uses assert(), make sure to also define NDEBUG for release/distribution builds.

As a side note, when I update my cocos2d-project respectively replace it with gocos, it will have all these settings properly configured.

Catching uncaught exceptions

On a related matter, there’s always the issue of uncaught exceptions simply halting your App, with little chance to debug the actual cause. It happens rarely but when it does, it would be really helpful to also bring up the debugger with the current call stack and everything. You can set a global exception handler to catch uncaught exceptions by calling the NSSetUncaughtExceptionHandler in the applicationDidFinishLaunching method of your AppDelegate:

[cc lang=”objc”]
void onUncaughtException(NSException* exception)
NSLog(@”uncaught exception: %@”, exception.description);

-(void) applicationDidFinishLaunching:(UIApplication*)application


In the onUncaughtException method you’ll simply log the exception and (very important) add a breakpoint. The NSLog message serves the purpose of being able to easily set a breakpoint inside this method. It should not be another NSAssert because that will throw another exception, which will only serve to make debugging more complicated when a simple breakpoint suffices.

Cocos2D Xcode Project on Github

On November 4, 2010, in cocos2d, tools, Xcode, by Steffen Itterheim

My Cocos2D Xcode project is now on Github. Open-source, free, properly MIT Licensed, includes the rootViewController and supports Cocos2D v0.99.5 rc0.

I’m also working on (with) a greatly enhanced version of the Xcode project. It integrates wax (Lua) and a Game Object Component System that i termed “gocos”. Also comes with a lot more useful convenience classes.

But the big idea is to actually upload (or link within github, if I can figure out if and how that works) all dependent projects into one repository, so that you can download everything at once and it works out of the box. Currently there are 3 projects referenced by cocos2d-project: gocos (let’s call it a library of convenience and gameplay code for Cocos2D), wax (Lua support) and obviously cocos2d-iphone. So everything that’s needed is going to be bundled in one big package, which voids all of the version incompatibility issues.

You can still experiment with different versions of these libraries but in that case I think you know what you’re doing and that issues are to be expected. But being a github repository, you can of course clone and commit changes.


Here’s what I’ve done with Lua. I’m currently using it only as a better plist replacement for settings. It’s better than plist because you can comment on each item, you can sort them easily, you can run functions and algorithms to generate values or load additional data, and in general it’s a lot easier to work with than the plist editor. Here’s a reduced config.lua that is loaded at runtime into a hierarchy of NSDictionary objects:

[cc lang=”lua”]
local config =
AccelerometerControls =
UpdatesPerSecond = 60, — 60 Hz
Responsiveness = 0.997,
SensitivityX = -2,
SensitivityY = 2,
MaxVelocity = 100,

return config

And this line of code loads these values and assigns them to the correspondingly named properties of the target class:

[cc lang=”objc”]
[Config loadPropertiesFromKeyPath:@”AccelerometerControls” target:self];

That’s all you need to do to transfer the values from config.lua into a class instance. Huge timesaver! The only drawback is that it currently can’t differentiate between float, int and bool (due to NSNumber), so it currently only supports float properties.

Tagged with:  

Xcode Project for Cocos2D v0.99.5 beta 3

On October 20, 2010, in Announcements, cocos2d, support, Xcode, by Steffen Itterheim

Due to a number of breaking changes in the recent Cocos2D beta versions, including the rename of the Cocos2D project to cocos2d-ios.xcodeproj, I’ve made an update to my Xcode project. You know, the one from this tutorial that allows you to keep Cocos2D completely seperate from your own code, which in turn enables you to easily and safely up- and downgrade Cocos2D by merely replacing the Cocos2D folder.

So now it also works with Cocos2D and here is the download:

Download the Xcode Project (Cocos2D v0.99.5 beta 3 and later)

What you have to do to upgrade the project, in case you already started a project with my older Xcode template but would like to upgrade to Cocos2D v0.99.5 beta 3:

  • remove the cocos2d-iphone project from your Xcode project
  • follow these instructions from Select the Project itself up to and including Drag & Drop Libraries to Target
  • (don’t forget to repeat the instructions for all targets you’re using, not just the current one)
  • clean all targets and build

Note: depending on the iOS SDK version you’re on, you may have to Get Info on the Xcode project as well as the cocos2d-ios project and on the General tab set the Base SDK to iOS 4.x, then close and re-open the project (Xcode should update the SDK version immediately but sometimes it doesn’t).

If you plan to use Cocos2D v0.99.4 then the Xcode project supporting this Cocos2D version is still available here.

Tagged with:  
Page 3 of 41234