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 »
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.
This Kobold2D FAQ article explains the difference between Corona SDK and iPhone Wax library, and evaluates the existing and future options for Lua scripting in Kobold2D.
A new episode of the Cocos2D Podcast is now live. This time we’re joined by Daniel Sperl, author of the Sparrow Framework Objective-C game engine for iOS which is based on the ActionScript (Flash) API design.
Note: the Sparrow website is currently reported as “possibly malware” by Safari and Google. The culprit has been removed and the site is safe to visit. Read this blog post for more info about what happened.
Daniel has a secret he shared with us even though he couldn’t really say any details until the official announcement in a few weeks. Cocos2D also gets a couple honorable (or dishonorable) mentions as we compare it with Sparrow Framework, and come to the conclusion that documentation-wise it is leaps and bounds ahead of Cocos2D.
Cocos2D Podcast: Daniel Sperl (Sparrow Framework Developer)
Previous Cocos2D Podcast: Marketing your App
I forgot to blog about the previous Cocos2D Podcast in which Azam and I talk about marketing your iPhone app.
Cocos2D Podcast: Marketing your iPhone App
Unrelated but important: Steve Jobs resigns
In case you haven’t heard, Steve Jobs has resigned as CEO of Apple on August 24th, 2011. Here’s Steve’s (short and to the point) letter to the Board of Directors. Tim Cook was named as his successor. Read the press release.
I never really cared for who’s boss of a big company, just enough to get the ridicule. But Steve Jobs leaving .. I can’t help but feel sad.
I believe this is for one reason in particular: very, very few CEOs actually have a vision and follow it through. Or have the (will)power to follow it through without being bent or influenced through challenges and oppositions by corporate and outside politics. Steve was able to retain all of the drive, dedication and willpower that you have when you just start out as a company or individual trying to make a really great product that you believe in and want to be proud of.
Most large companies are simply unable to create such products because too many people work on each product, and there’s lots of money and risk involved in the process which, more often than not, turns potentially great companies into conservative, boring companies making lackluster products, following consumer trends. Apple under Steve Jobs has been the exception. Steve has repeatedly anticipated consumer trends, even created them through the power that is the Apple brand.
The really, really sad part however is what hasn’t been said. Steve being unable to meet his duties paints a grim outlook on his health. Not mentioning his health in his letter and Apple’s press release even more so. I just wish for him that it’s not as bad as one can imagine it to be if it forces someone of Steve’s caliber to resign from his position. Good luck and all the best, Steve!
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….” 
I took some time to research the various ports which carry the Cocos2D name or are Cocos2D in spirit if not by name. The following list is - to the best of my knowledge and at the time of writing - complete and accurate. I counted a total of eight ports.
The dates are based on the earliest public record I was able to find. Of course the project might have been in development for longer, but not publicly or not where I’ve been looking (mostly google code and github). I usually checked the source code commit history, the first issue being tracked, the first post made on the forum or wiki, the history of downloadable files, and similar things. The list is sorted by date of inception. Underneath you’ll find my analysis of the state of the Cocos2D game engines, as I perceive it, and I try an outlook into the future.
The Complete List of Cocos2D Game Engines
Cocos2D
Language: Python
Platform(s): Mac OS, Windows, Linux
Around since: March 2008
Latest update: September 2010
Cocos2D for iOS
Language: Objective-C
Platform(s): iOS Devices, Mac OS X
Around since: June 2008
Latest update: November 2010 (Latest Stable: July 2010, Latest Commit: December 2010)
ShinyCocos
Language: Ruby
Platform(s): iOS
Around since: April 2009
Latest update: April 2010
CocosNet
Language: C#
Platform(s): iOS (MonoTouch)
Goal: to also support other .NET platforms like Windows, Windows Phone and Xbox 360
Around since: October 2009
Latest update: September 2010
Cocos2D for Android
Language: Java
Platform(s): Android
Versions: cocos2d-android (code on github), active branch: cocos2d-android-1 (code on github)
Notable: cocos2d-android-1 was branched off of cocos2d-android in October 2010 because some developers were dissatisfied with its slow progress. Apparently source code commits had stopped in June.
Around since: January 2010
Latest update: June 2010 (cocos2d-android), December 2010 (cocos2d-android-1)
Cocos2D for Windows
Language: C++
Platform(s): Windows, Windows Mobile
Notable: this project was apparently short-lived. One big code push, one blog post, no updates since, neither code nor blog or anything else. I believe we can consider this port dead, especially in light of Cocos2D-X.
Around since: April 2010
Latest update: May 2010
Cocos2D for Web
Language: Javascript
Platform(s): Web Browsers
Website with online demo: http://cocos2d-javascript.org/
Around since: June 2010
Latest update: December 2010
Cocos2D X
Language: C++
Platform(s): iOS, Android, uPhone, Win32, others
Notable: although the project started in July 2010 (from what I can tell) the project was not widely known until November 13th by announcing it on Twitter.
Around since: July 2010
Latest update: December 2010
The State of Cocos2D Game Engines
In my opinion, we currently have only two serious contenders: Cocos2D for iOS and Cocos2D X.
The former has a history of regular updates for over 2.5 years and a strong community, the latter is growing fast because there’s a whole team behind it which is sponsored/financed by China Unicom. If I extrapolate what has happened in recent months with these two game engines, I’m convinced that rather sooner than later Cocos2D X will be on par or overtaking Cocos2D for iOS in terms of maturity, stability and general applicability. You just have to consider a team of paid (?) developers vs. (for the most part) a single developer, and my guess is they don’t have a problem with and may even be supportive of 3rd party commercial add-on products. I do agree that Cocos2D for iOS will remain the most interesting platform for beginning developers, developers with a strong background in Objective-C programming and those who simply don’t want to take their games and apps to multiple platforms. For everyone else: keep a close eye on Cocos2D X. It certainly had a lot of developer’s eyebrows raised.
There’s one strong follow-up and that is Cocos2D for Web (cocos2d-javascript). Frequently updated and in a well protected niche that can’t be covered by the aforementioned Cocos2D versions. Plus, and this is freaky, you could even make web-based Cocos2D games that also run on the iPhone’s browser - think of the opportunities! It’s iRepetetiveWebBasedGameMakingTonsOfMoney time. Just kidding, except that I’m not. I think Cocos2D for Web stands a good chance at becoming relatively popular and seeing actual use, and with continued and relatively frequent updates this might be happening over the course of 2011. Keep at it!
Cocos2D (Python), the grandparent, is a niche project and it’ll remain a niche project. Too long has it been a niche, too seldom do we see updates, too low is its version number still (v0.4 after 2.5 years), too little interest is there in general for entirely Python based game engines, too strong are the contenders both from the same language (specifically PyGame) as well as most other game engines with a focus on 2D games. The same goes for ShinyCocos - who would want to write iPhone games in Ruby? Don’t kill me, I know you’re out there, but you have to admit that you’re just a little too freaky for your own good. 😉
Cocos2D for Android and CocosNet are both ports I wish I could believe in, but I don’t just yet. For the former, the recent branch has made it more interesting and actively supported, but who knows for how long? And then there’s Cocos2D X which takes some wind out of both, but especially the Android version. Unless you’re Java-esque through and through. For CocosNet I wish it’ll one day reach its goal and hopefully be based on or ported to the XNA platform, and not Mono (yikes!), so that we can write Cocos2D games for the Xbox 360, Zune, Windows and Windows Phone 7 and publish them through/on Microsoft’s AppHub. That would rock! Count me in if that ever happens.
Which leaves Cocos2D for Windows. This is a project that’s so typical of a certain type of open source projects. I dub these occurrences “open source dumps”. It’s literally some programmer coming out of his apartment after months of hard work, telling the world “Hey guys, look, I’m bringing my trash out!”. Except that the trash is actually quite interesting, yet it’s incomplete, unfinished and de facto unusable so it stays in the trashbin and everyone stopping by and taking a sniff is going “Ewwwww!!!”. Well, and said developer goes back to his apartment, probably working on his next trash dump. If we’re lucky, it’ll be an update to the former project - but by the time the second update appears, most developers with an interest have lost faith in the project. But more often than not, we’ll never see or hear of this developer again. In other words: Cocos2D for Windows was practically dead the day it started. And now with Cocos2D X I seriously doubt we need it anymore. It’s a shame.
Add your link to the Cocos2D Linkvent Calendar
Do you have something to share with the Cocos2D community? I haven’t received enough submissions to fill all the days until Xmas, although I do have enough links to post one each day, I’d rather post a link to your website or blog post.
Chapter 4 - First Simple Game
After Chapter 3 covered the fundamentals of the cocos2d game engine, this chapter will put to use what you’ve learned. The simple game is all about droping enemies that you have to avoid via accelerometer controls. Sort of like an inverse Doodle Jump. But it’s not just about the gameplay itself, I want the game to be reasonably complete with a main menu, scene transitions, game over and of course audio.
The chapter will be submitted on Friday, July 23rd.
Do you have any suggestions for the game?
What do you think should be in a first cocos2d game? Let me know!
Summary of working on Chapter 3 - Essentials
When I started the chapter I wasn’t really sure about its focus and progress was a little slow. Eventually it clicked and I found myself ending up having written more pages than needed and still having a great number of things left untold. The key was looking at the cocos2d API reference documentation and remembering what it was like when I was a beginner. Sure, every class, method and property is there but for a beginning cocos2d developer the API reference is just a huge list of names. In other words, if your experience was or is anything like mine was, it’s frustrating to work with the API reference.
I ended up writing about the cocos2d engine design and its scene graph first, the remaining 80% of the chapter explain in detail with lots of code samples how to use those darn CCNode classes. All the important ones are covered: CCNode, CCScene, CCLayer, CCSprite, CCLabel, CCMenu, CCMenuItem* as well as the Director, Transitions and Actions. Besides the code samples and how-to I’ve added numerous caveats, common mistakes, best practices and other nodes which are so very much needed to make any documentation complete.
For example, how Layers are best used for grouping other nodes together and of course how to enable touch and accelerometer input by adding the required functions which aren’t mentioned in the API reference since they are part of the iPhone SDK API. There’s also some weird recommendation floating around not to use too many Layers because they’re slow. I can’t find the source but what I did find was that this is only true if the Layers enable touch or accelerometer input, because that’s what costs a lot of performance. So what you don’t want to have is several layers accepting input, otherwise use as many Layers as you need - which shouldn’t be many anyway. And if you do need multiple Layers accepting input, why not just use one master Layer (possibly using a Targeted Touch handler) which forwards the input events appropriately to the other Layers?
