There are many Cocos2D + Storyboard tutorials, it’s about time to do another one that’s done right. Also, this one’s backwards: we’ll start with a Cocos2D template and then add Storyboards to it. The tutorial will work for existing Cocos2D projects to which you wish to add Storyboards, too!
I’ll show you how to add Storyboards to a Cocos2D v2.1 project, with ARC enabled of course. This approach will take a little more work, but the solution will be complete and you gain a fair understanding of how things work together. Plus two custom but reusable View and Navigation controller classes, and I’ll show you what changes you need to make to the AppDelegate.
The resulting project will work with iOS 5 and iOS 6 and autorotation. The navigation and cocos view controllers are separated, and you will be able to subclass them for code customizations as is customary in Cocoa. Cool? Cool, cool, cool!
As usual you can grab the example project (Cocos2D + Box2D + Storyboards with ARC enabled) from github. I’ll also be adding a Storyboards template project to KoboldTouch in the next update, and document what’s special about the KoboldTouch solution.
Oh, only one thing … this tutorial is part of Essential Cocos2D. Head on over and enjoy!
In order to write Tiled’s TMX file format I needed to do exactly this: figure out how to compress data, encode it as a string, and write it to XML.
I wrote down what I learned from using zlib, base64 and xswi - XML Stream writer for iOS (a single Objective-C class) while writing KoboldTouch‘s TMX writer.
I split it into two articles in the Essential Cocos2D section of the www.KoboldTouch.com homepage:
- How to compress and encode data with zlib and base64
- How to write XML on iOS with xswi (XML Stream Writer)
I was positively surprised how relatively painless zlib and base64 encoding worked (I expected the worst!) and how simple and effective xswi is for writing XML compared to any other XML library.
I’ll probably continue to add those articles to Essential Cocos2D rather than posting them on this blog. Confluence is just so much more convenient for writing technical documentation than WordPress.
Final word: Enjoy! 
It’s hard to find the right words to describe the launch of KoboldTouch. I can’t think of anything else but WOW! right now.
I can’t wait to hear what you have to say about KoboldTouch, and then act on your feedback.
For those who were just waiting for the launch:
Sign up on the KoboldTouch product page to get access to KoboldTouch and Essential Cocos2D.
The rest of this post is a summary of what I wrote before on these two-products-in-one. Actually, I think of KoboldTouch & Essential Cocos2D as being much more a service than products. And it’s a full time commitment from myself.
This calls for music!
I like to take a moment and explain what the development process of KoboldTouch will be, and how you will influence the direction of KoboldTouch. But first, let’s have a look what I have planned for the initial version:
UPDATE: KoboldTouch is now available!
First Goal: KoboldTouch equals Cocos2D
To be completed in November, the main goal is to allow users to use the MVC framework of KoboldTouch with all features of Cocos2D, minus a few exceptions (odd features like CCMotionStreak).
You should be able to write Cocos2D apps with Cocos2D features entirely within the KoboldTouch framework. You’ll experience the KoboldTouch API design goal “feels like Cocoa”.
The first version’s features will be:
- Controller/Model Framework wrapping Cocos2D views
- View Controllers for “view” nodes, minus exceptions (see below)
- Scene Transitions
- Scheduled updates (Step methods in KT)
- Touch & Accelerometer input controllers
- Mouse & Keyboard input controllers
- Simple Audio Controller
- Simple Model Classes
- Archiving & Unarchiving Model Classes
- Basic “Hello World++” Example Project
This first version will be KoboldTouch v6.0. Continue reading »
Since I started working on KoboldTouch a couple things fell into place. Mainly that it would:
Provide what Cocos2D leaves up to its users. Fixes what Cocos2D does badly. Adds what Cocos2D doesn’t do at all. Eases development with Cocos2D and accommodates actual developer needs.
While Cocos2D is moving towards cross-platform with their Javascript API, KoboldTouch will focus on adding & improving game design features.
I have a hunch most Cocos2D developers have better iOS/Mac integration and game-specific features higher up on their wish list than cross-platform. Most of you are indies, hobbyists, pragmatists and Apple enthusiasts without the need or resources to do cross-platform development.
UPDATE: KoboldTouch is now available!
KoboldTouch: Spiritual Successor
I first started working on KoboldTouch a few weeks back. I initially undersold it as a “MVC wrapper for Cocos2D”. With what I have in mind spiritual successor of Cocos2D is more like it.
It’s going to be a framework to program iOS & Mac games in, where best practices evolve naturally, where Cocoa programmers feel right at home, where beginners are not left in a void * EXC_BAD_ACCESS … and where Cocos2D is still at the heart of it.
KoboldTouch takes control over Cocos2D, to allows users to implement best practices naturally. Cocos2D provides the view, KoboldTouch provides the controllers, models and the framework to write your code in.
Here’s what I’m working on. Hopefully this answers the questions I’ve been getting, in particular those about KoboldScript. And what’s happening with it, when is it coming, when can we stop using Corona SDK, etc.
UPDATE: KoboldTouch is now available!
Well then, let’s start with …
KoboldTouch
Huh, what?
Well, the short answer is: KoboldTouch is an MVC wrapper around Cocos2D.
The long answer … let me start by saying that Cocos2D is suboptimal. From a code architecture point of view. Cocos2D has no concept of structure besides views (nodes), and doesn’t encourage structure in your own code. It happily lets users subclass views in order to add data and game logic.
I can’t stop but feel helpless to see beginners learning the things we’ve abandoned 20 years ago as bad practice. Yet Cocos2D code is written by subclassing views as if it were the most natural thing to do. It’s also the very thing Apple tells you not to do.
The result are projects lacking in what is called separation of concerns. It’s not just about experience. Without a clear architectural model frequently reminding you to consider separation of concerns, anyone is more likely to end up creating a blend of design patterns at best, or worse:
