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!
Therefore I decided to enable ARC in all twelve standard cocos2d Xcode project templates for both cocos2d versions (v1.1 and v2.0), both platforms (iOS and Mac OS), both physics engines (Box2D and Chipmunk) and publish them on github.
Time to add another project to my github repository. This time I’m answering the frequently asked question (in some form or another) how to zoom in on a particular node. For example zooming in on the player when he dies.
That’s not as trivial as it sounds, but you can make it easy if you follow some guidelines.
First, you want to put all nodes that should be affected by the zoom in the same layer. Then you should avoid changing the position or anchorpoint of the layer – if you still want to change the position of the layer I suggest to add this layer into another, toplevel layer and then only change the position of the toplevel layer. Use the cocos2d node hierarchy to your advantage. And don’t use the CCCamera.
The behavior of this example project is best observed with your own eyes. You can get the ZoomInOnMe project on github.
After a holiday-season hiatus (Happy New Year btw!) LearnCocosTV is back. This episode is somewhat shorter because I had a lot of catching up to do and a lot of chores which aren’t exactly show-worthy. But I did manage to port most of the Kobold2D projects to Cocos2D 2.0 beta. Too bad they look just the same as before.
A bi-weekly Show & Tell about Cocos2D, Kobold2D and iOS/OSX development by Steffen Itterheim.
Episode #3 – Two And A Half Nuts
• Updating Kobold2D to use Cocos2D v2.0 (beta)
• iDevBlogADay: Tips for updating to Cocos2D v2.0
• iDevBlogADay Source Code available on github
Most developers have heard of the phrase “Eat your own dog food”. It refers to the habit of actually using what you’re creating.
A typical example would be a company building Yet-Another-Issue-Tracking-Tool™ while using said issue tracker to manage their Yet-Another-Issue-Tracking-Tool™ project. And you’ll surely have heard of a game engine that was initially only developed as a necessity to build a game, then polished and released to the public to great success, while the developer continued to create games with his own engine.
Dogfooding is considered a good practice, actually a best practice. You know that the tool you’re building works, and that it satisfies your needs.
But “your needs” is also the achilles heel of dogfooding, and it’s just a small step away from forever “perfecting” your product (known as “gold plating”). So sooner or later, you’ll have to do some catfooding, too. Meaning: to feed the user’s needs. Continue reading »
Continue reading »
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”.
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.
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:
local config =
UpdatesPerSecond = 60, – 60 Hz
Responsiveness = 0.997,
SensitivityX = -2,
SensitivityY = 2,
MaxVelocity = 100,
And this line of code loads these values and assigns them to the correspondingly named properties of the target class:
[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.