The Mobile 2D Game Engine Popularity Index - November 2013

On November 14, 2013, in idevblogaday, by Steffen Itterheim

Topics: Overall interest in cocos2d is waning. Unity and libgdx fighting for 1st place. Sprite Kit skyrocketing from day one.

This sums it up. Now for the details. Since my last game engine popularity measurement I tried to improve and streamline the process.

Game Engine Popularity on Stackoverflow.com

For stackoverflow.com data I’m searching for tagged questions created in a specific month. The search query looks like this:

[cocos2d-x] is:question created:2013-11

I repeated this for every tag for every month as far back as there were questions with the given tag.

Continue reading »

Measuring Game Engine Popularity

On July 25, 2013, in idevblogaday, by Steffen Itterheim

How do you measure the popularity of a game engine and compare it with others?

Reminded of the TIOBE Programming Language Index and the Transparent Programming Language Popularity Index I couldn’t find a comparable site measuring game engine popularity.

So I sat down and concluded that I can do a simple manual test rather quickly. These are the measurements anyone can take easily:

Popularity of Cocos2D Variants

Let’s begin by comparing the popularity of the various Cocos2D variants. The difficulty here lies in properly excluding all the other cocos2d variants. That cocos2d-iphone is commonly referred to as just “cocos2d” makes it difficult to measure just the cocos2d-iphone popularity and to remove that number from all other engine variants.

I tried to overcome this by including or excluding specific tags in Stackoverflow and Gamedev searches:

  • cocos2d-iphone: [cocos2d-iphone] or [cocos2d] -[python] -[java] -[javascript] -[c++] -[html5]
  • cocos2d-x: [cocos2d-x] or [cocos2d] [c++] -[python] -[java] -[javascript] -[html5]
  • cocos2d-android: [cocos2d-android] or [cocos2d] [android] -[cocos2d-x] -[c++] -[python] -[objective-c] -[html5]
  • cocos2d-javascript: [cocos2d-js] or [cocos2d-javascript] or [cocos2d] [javascript]
  • cocos2d (python): [cocos2d-python] or [cocos2d] [python]
  • cocos2d-xna: [cocos2d-xna] or [cocos2d] [xna]
  • cocos2d-html5: [cocos2d-html5]
  • cocos3d: [cocos3d]
  • kobold2d: [kobold2d]
  • cocosbuilder: [cocosbuilder]

Stackoverflow.com tag search results:

Screen Shot 2013-07-25 at 14.48.31

Okay, let’s try that again with cocos2d-iphone removed so the other variants can be compared in relation to each other:

Continue reading »

Looking for a Sprite Kit Game Engine? Check out Kobold Kit!

In case you missed the news: Sprite Kit is Apple’s 2D rendering engine for games, announced with iOS 7 at WWDC 2013 by merely mentioning it among other new APIs. A small step for Apple, a giant leap for gamedeveloperkind. This changes everything!

Many compare Sprite Kit with cocos2d-iphone. Don’t ask me why, they just do. 😉

If you’re a registered Apple developer you can check out the Sprite Kit Programming Guide and the SpriteKit.framework reference yourself.

Sprite Kit is under NDA, like the rest of iOS 7, so I won’t spell out any details here. I posted my list of strengths and weaknesses of Sprite Kit on the developer forum, where we can freely discuss such details.

Here let me just try to answer the questions: why did Apple create Sprite Kit, and why now?

The Biggie: Apple acknowledges games!

Apple finally understands the significance of games for their platforms! Sprite Kit is acknowledgement of that fact. Rejoice!

Especially if you consider the rumored Apple TV set: imagine a television set that runs iOS with an App Store to download and buy YOUR games. Interestingly, iOS 7 also adds an API for 3rd party game controllers, think of joypads, like those you get with an Xbox or Playstation.

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.

Continue reading »

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.

Tagged with:  

Prefer Composition over Inheritance

On June 11, 2010, in Programming, Speaking From Experience, by Steffen Itterheim

When the question came up whether to subclass CCSprite or use some model class to build your game entity hierarchy in the cocos2d forum, i stressed that one should try not to use inheritance and keep the inheritance hierarchy to as few levels as possible. I’ve worked with codebases with hundreds of thousands of lines of code, and hundreds of different types of actors in the world. Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

The answer lies in composition, often referred to as Game Components by engines like TorqueX and the PushButton Engine (a Flash game engine from the original Torque developers). This video from the PushButton lead developer Ben Garney explains it very well and also illustrates the problem with inheritance over-use in game engines. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use - i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

You can read more about PushButton’s Components system in their documentation. How they implemented Components in TorqueX and what the differences are to XNA Game Components further enhances understanding of the concept.

For further reading and arguments read the Wikipedia article on component based software engineering. As a matter of fact, the Objective-C language was invented to be able to create re-usable software components!

Scott Bilas’ GDC 2002 talk about A Data-Driven Game Object System (PDF) as used by Dungeon Siege contains more pointers on why inheritance fails for game developers and what the advantages (but also some caveats) are with component-based game engines. The talk may be old but it’s still as valid today as it was back then. In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

During GDC 2009 a similar presentation was held by Radical Entertainment’s Marcin Chady. The talk was called Theory and Practice of Game Object Component Architecture (PPT).

Mick West wrote an article Refactoring Game Entities with Components which describes the challenges and benefits of changing the Tony Hawk codebase from an inheritance model to a game component system.

A somewhat more advanced read on component use is a collaborative paper called Dynamic Game Object Component System for Mutable Behavior Characters which talks about components in context of finite state machines and NPC behaviors with a rule-based activation system.

The Game Architect blog calls it an Anatomy of Despair and sums up very good what the cons of inheritance-based class design is and how composition solves them.