What goes into a game engine? A long list.

On June 17, 2013, in Kobold Kit, by Steffen Itterheim

Cocos2D is a rendering engine. Note the emphasis. 90% of what it does is draw stuff onto the screen and animate it. It adds some input processing and scheduling and the rest is up to you.

A game engine is to cocos2d what cocos2d is to OpenGL. The list of things I want in an actual game engine is long.

The iOS mobile platform has advanced far enough that a pure rendering engine just isn’t that much of a help anymore. We’re effectively moving back towards where we were back in 2008 if we don’t start pushing the boundaries, hard.

Here are some ideas I have for and would like to see in a 2D game engine, in no particular order. It is not a feature list for Kobold Kit, but it does reflect what I want to make possible with / encourage for Kobold Kit.

Continue reading »

KoboldTouch – 2D Game Development

On September 14, 2012, in , by Steffen Itterheim


KoboldTouch brings you the best 2D game development experience for Apple’s platforms!

KoboldTouch is the only Objective-C, ARC-enabled 2D game engine built on the Model-View-Controller (MVC) design pattern. Write ambitious games with greater ease!

KoboldTouch is also a continuously evolving, customer driven game development framework for iOS & Mac OS X, designed by game industry veterans to incorporate game development best practices and decades of experience.

Learn more about KoboldTouch features and what’s in it for you:

Open the “About KoboldTouch” Page for Details

Not quite ready for KoboldTouch yet?

Fill out the KoboldTouch Survey. Let us know what you think of KT and how to make it better.

Get KoboldTouch!

KoboldTouch is available as a subscription program that entitles you to updates and support.

Choose Your Support & Updates Plan

Recurring billing may be cancelled at any time. The yearly plan is non-recurring.



You will be charged $14.95 every month.



You will be charged $39.95 every 3 months.

One Year


You will be charged $119.95 once. No automatic rebills.


60-Day Money Back Guarantee

If you’re not satisfied you can request a refund within 60-days from the date of purchase, directly via Clickbank.

LearnCocosTV 6: One Small Script for Man

On February 27, 2012, in LearnCocosTV, by Steffen Itterheim

In this episode of LearnCocosTV I demonstrate how to write and animate a Cocos2D scene with KoboldScript.

KoboldScript is more than just writing the same Cocos2D code but with a scripting language. Most other scripting language bindings for game engines simply translate the game engine’s C/C++/Objective-C API 1:1 (more or less) without introducing new concepts, adding more comfort by simplifying common tasks, or utilizing the powerful features of whatever the scripting language has to offer.

KoboldScript goes three steps further than that – one by tightly integrating the setup of scenes via defining the node properties in a tool-friendly tree structure (Lua table) that you can both write manually or create programmatically using Lua’s built-in features.

Two, by using Statemachines to drive game logic while also providing free Lua scripting via user-specified Lua callback functions. And three, by adding a (MVC-ish) component system with re-usable abilities and behaviors to all Cocos2D nodes.

Unfortunately I ran out of time at the end so I couldn’t even say goodbye. I hope you don’t mind. :)

Episode #6 – One Small Script for Man …

• KoboldScript Demonstration
o How to create Scenes with Sprites, etc
o How Abilities & Behaviors work
• iDevBlogADay: Asynchronous Texture Loading
o Cocos2D Webcam Viewer speedup

Affiliate Store Opened

On November 13, 2011, in Announcements, by Steffen Itterheim

I opened an Affiliate Store page to be able to promote and sell other developer’s products.

Recently I decided to write one big post every other week (bi-weekly on Thursdays) as my iDevBlogADay post. I also wanted to create something exceptional each time. In particular the Compiler Directives list worked great. It bothered me that there was no such list. And apparently I wasn’t the only one looking for that.

That made me start regarding the iDevBlogADay posts essentially as paid writing jobs. Regardless of how little that payment may be, it is adding to my bottom line and it is a welcome additional incentive to put my best efforts into it.

Continue reading »

Tagged with:  

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:  

cocos2d Book, Chapter 9: Particle Effects

On August 21, 2010, in Announcements, book, cocos2d, by Steffen Itterheim

Chapter 9 – Particle Effects

Those tiny specks which you can see on your touchscreen after a sneeze.

Not exactly. Of course I mean the cocos2d particle system and its built-in particle effects which will be the focus of this chapter. And no discussion of particles would be complete without describing the workflow revolving around the Particle Designer tool.

Summary of working on Chapter 8 – Shoot ’em Up

This certainly wasn’t the easiest chapter for me to write. I had very ambitious goals, maybe too ambitious for 27 pages. I did manage to sneak in quite a lot though, here’s a partial list:

  • how to refactor existing code to make it work better with the new features
  • how to pool bullets and enemies together for easier access and better performance
  • how to not use too many subclasses, instead relying on type switches
  • how to use cocos2d’s node hierarchy as a simple component system for writing reusable game logic components
  • how to implement basic movement, shooting and a healthbar as components
  • how to detect collisions between bullets and enemies

The not so easy part was striking the right balance. Not going too technical. Not doing too much at once. Not dividing things into too many tiny pieces. But most of all I frequently encountered various bugs in the code, or just unexpected behavior of cocos2d which forced me to spend more time debugging and sometimes backtracking changes than I was prepared for.

After a long and hard work week, paired with physical exhaustion and an late-summer allergy burst, my concentration didn’t allow me to work at 100% capacity. In the end I did manage but it took longer than I had planned, I’m over a day late to submit this chapter. The next one will be easier though, and it has to be as I’m preparing for a short trip near the end of next week. I certainly am looking forward to a couple days off now. :)

Prefer Composition over Inheritance

On June 11, 2010, in Programming, Speaking From Experience, by Steffen Itterheim

When the question came up whether to subclass CCSprite or use some model class to build your game entity hierarchy in the cocos2d forum, i stressed that one should try not to use inheritance and keep the inheritance hierarchy to as few levels as possible. I’ve worked with codebases with hundreds of thousands of lines of code, and hundreds of different types of actors in the world. Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

The answer lies in composition, often referred to as Game Components by engines like TorqueX and the PushButton Engine (a Flash game engine from the original Torque developers). This video from the PushButton lead developer Ben Garney explains it very well and also illustrates the problem with inheritance over-use in game engines. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use – i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

You can read more about PushButton’s Components system in their documentation. How they implemented Components in TorqueX and what the differences are to XNA Game Components further enhances understanding of the concept.

For further reading and arguments read the Wikipedia article on component based software engineering. As a matter of fact, the Objective-C language was invented to be able to create re-usable software components!

Scott Bilas’ GDC 2002 talk about A Data-Driven Game Object System (PDF) as used by Dungeon Siege contains more pointers on why inheritance fails for game developers and what the advantages (but also some caveats) are with component-based game engines. The talk may be old but it’s still as valid today as it was back then. In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

During GDC 2009 a similar presentation was held by Radical Entertainment’s Marcin Chady. The talk was called Theory and Practice of Game Object Component Architecture (PPT).

Mick West wrote an article Refactoring Game Entities with Components which describes the challenges and benefits of changing the Tony Hawk codebase from an inheritance model to a game component system.

A somewhat more advanced read on component use is a collaborative paper called Dynamic Game Object Component System for Mutable Behavior Characters which talks about components in context of finite state machines and NPC behaviors with a rule-based activation system.

The Game Architect blog calls it an Anatomy of Despair and sums up very good what the cons of inheritance-based class design is and how composition solves them.