With the release of iOS 7 (ETA: Tuesday, Sept. 10th):
Kobold Kit will be available as open source under the MIT License!
We spent a lot of thoughts on how we like to run an open source project. And also why. I’ll start with an executive summary with more (perhaps too many) details in the text.
The Idea: make the project as open and inviting as possible. Let contributors gain control over and take on responsibility for the project based on their contributions. Provide them with ways to promote their work on their own accord.
The Goal: build the Sprite Kit game engine with the help of many developers.
Kobold Kit is supposed to become the “patron project” under whose roof the most valuable Sprite Kit extensions are combined. Website, forum, wiki, blog and store are extended playgrounds shaped by community members. If you’re part of the project, we want you to proudly present and benefit from it.
In essence: we want to get out of the way as much as possible and enable anyone to find their place in the project. Guidance, not dictating, is our guideline.
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.