Kobold2D Meets Cocos2D-X

On June 17, 2011, in cocos2d, Kobold2D, by Steffen Itterheim

Kobold2D is well and alive. Actually so much so that I thought: “Hey, it’s crazy, but maybe not … I’ll give it a shot and see how far I get.”

The thought was to try and add the cocos2d-x engine (cocos2d in C++) together with the Hello World example project to the Kobold2D workspace. The result: it took about 90 minutes, most of that figuring out the correct build settings and header search paths. And it just worked.

Surprise! 😀

Right now this is just the iOS version. A cocos2d-x Mac project will be added as soon as the Mac platform is officially supported by cocos2d-x (or does it already and I missed that?). Then developers would have the choice between using either Objective-C or C++ as the primary language for developing their iOS & Mac OS X games.

It also made me think: “Hey, there’s this other open source 2d game engine … hmmm….” :)

Tagged with:  

cocos2d Book, Chapter 3: Essentials

On July 10, 2010, in Announcements, book, cocos2d, by Steffen Itterheim

Chapter 3 – Essentials

This chapter is a reference about the fundamental classes of cocos2d and how to use them. Nodes, Layers, Scenes, Labels, Sprites, Transitions, Actions, you name it. Also CCDirector, SimpleAudioEngine and other often used singleton classes as well. More advanced concepts will be discussed in a later chapter, Spritesheets for example.

The submission of the first chapter draft is due next Friday, July 16th.

What do you think should be in Chapter 3?

Do you know a cocos2d class or process that you think is essential and should be discussed in this chapter? Let me know!

Summary of working on Chapter 2 – Getting Started

For one I detailed the Hello World sample project and made a simple modification using touch input. At the same time at least some basic level of understanding about cocos2d classes was introduced but the gist of it is done in Chapter 3. In addition, there were a lot of theoretical aspects I wanted to discuss as well, most of all Memory Management and available memory as well as setting expectations on testing on Simulator vs. a device. And of course the devices and their subtle differences. I do hope that those kind of details are appreciated even if they’re not 100% related to cocos2d. I regularly see cocos2d developers struggling with memory issues, with unexpected differences on the device vs the Simulator, or comparing framerates of the Simulator and possibly even Debug builds. That made me want to stray off the beaten path for a moment to hopefully save the readers some misconceptions and the pain associated with them.

I also realized how many steps a new developer has to go through and how much there is to learn in case you’ve never been working with the iPhone SDK before. It starts with registering as iPhone developer and doesn’t end with installing the SDK because you also need the provisioning profiles, a much discussed and troublesome feature. For all of this I refered to existing (and excellent) Apple documentation. Typically the processes change with each new iPhone SDK or may even be under NDA, so discussing how all of this works with iPhone SDK 4 wouldn’t be a good idea since shortly after the book is out iPhone SDK 5 may be coming, introducing changes to the Developer Portal and iTunes Connect with it. It did get me the idea, and I know others have it too, that we need some holding-hands Tutorial which takes one through the steps from registering as iPhone Developer to publishing one’s first App, by referring to the correct official documentation for each step while not forgetting about common pitfalls that are not in the official docs.

I also noticed how easy it can be to overlook how you suddenly introduce a new concept without explaining it first. And then you have to decide how much information is necessary to introduce the concept without straying too far away from what you want to talk about in the first place. It’s especially hard for me because I tend to want to explain everything in detail but some things have to be left for a later discussion. I’m looking forward to editorial feedback now. It has helped tremendeously for the first chapter and I learned a lot from the Apress editorial staff, so I find it exciting that the experts point me to the flaws and make suggestions, I go in to fix them and then see how much better it is. That’s how I like to learn things and it’s going to be one of the core concepts of the book. Show how it’s done, how it shouldn’t be done (if it’s often done wrong) and how it can be done even better if you want to avoid trouble in the long run, while explaining why.