Cocos2d-iphone is rebooting … please stand by.
Loading…
Loading…
Loading…
Done.
Click any link to develop!
Today marks a new beginning: SpriteBuilder v1.0 is now available on the Mac App Store for free and it goes together with the release of cocos2d-iphone v3.0.
SpriteBuilder is the successor of the design tool formerly known as CocosBuilder. It is specifically designed to work with cocos2d-iphone v3. SpriteBuilder now has its own website with a dedicated SpriteBuilder forum that you should use for any questions about and suggestions for SpriteBuilder. Continue reading »
A preview version of cocos2d-iphone v3 has been available for a couple days now. I thought I’ll take a closer look and summarize what’s been done, what’s working and what isn’t, what’s new and what’s old but revamped.
Installation
The installer script has been revamped. It has a different name (install.sh) and different parameters (-force instead of -f).
The first thing I noticed is that the installer is downloading Chipmunk2D. Made me wonder why, so I double-checked to confirm: Chipmunk isn’t included in the archive. This means no offline installation.
I’ll explain later why Chipmunk isn’t included.
Project & File Templates
In the preview there’s only one project template. It doesn’t demo any physics features, it’s your typical “Hello World” example with buttons.
There seems to be an issue with the template where any attempt to save it to a custom location caused Xcode to crash. In fact every time the “Save File” sheet came up and I didn’t click on “Create” right away, Xcode would crash. That’s just one of the reasons why it’s still a preview.
The CCNode File Template isn’t worth mentioning at this point, it creates an empty Objective-C class and is barely different from the regular Objective-C class template at this time.
Hello World v3
Continue reading »
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.
I got a lot of questions in the past why I’m not contributing my work to the cocos2d-iphone project.
One of the obvious reasons being that what I did is simply too radical technically and I don’t want to compromise. Another reason being a fundamental difference in attitude towards developing and managing open and closed source projects.
These questions made me wonder - in particular because there was often a notion associated with these questions: because I do so much with cocos2d-iphone I should somehow be obliged to contribute back to it. Weird, right? I am contributing a lot already, just not code to the repository.
So if I don’t contribute (code), why don’t you? Or generally speaking, why aren’t we all contributing more (code) to open source projects?
I have been using open source software for as long as I can remember doing programming work. Yet I’ve probably contributed no more than a few dozen lines to all projects together. And realizing this it’s easy to see that this is the case for 99.9% of the developers out there.
So why aren’t we contributing more to open source projects? What is stopping us? I’ll give you some probable causes and ideas how to improve it for your own open source project. Continue reading »
I frequently see questions like Should I use game engine A or game engine B? Sometimes the question is slightly more specific like Is game engine A right for this game?
These questions are not unlike giving a list of features or requirements and then asking Is potential partner A better for me than potential partner B? And some are closer to asking the general public a very subjective question that requires intimate knowledge about the person who is asking: With whom will I have better sex, A or B?
Well … while there’s a checklist of features that A and B may or may not have that might have some influence on the decision, more often than not your choice depends a whole lot more on whether it just feels right.
You may feel attracted to A because A is so reasonable and the support is responsive and helpful, or you may simply find yourself attracted to how B is open to everything and free of charge. You may also find that despite A or B lacking a specific feature you crave, other aspects that you didn’t even think of more than make up for it. Features aren’t everything, more important is the spirit and ease of use.
Not uncommonly a fully featured game engine (or partner) with all bells and whistles may turn out to have a really steep learning curve, many restrictions, limitations, policies, quirks while “free” may cost you a lot more than you bargained for.
Following is my game engine dating advice that you can take to places like MobileGameEngines.com to make your pick. These are the things that I consider the most important when choosing a game engine for small projects, and that is irregardless of the type of game I might want to develop.
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….” 
