I came to the games industry from a web development background, originally as an Actionscript 3.0 programmer. Over the last couple of years the casual games industry I got started in has become less and less web-focused. Mobile is where the market is now. Working at a game studio that has traditionally made Flash games for the web, I find myself participating in a huge amount of discussion about different game development platforms, and which ones are the best / most suitable / most productive etc. Is it Unity? Is it C++? HTML5? Should we write custom code or use a pre-existing engine or framework?
For my personal game development, there are several factors that define my decisions:
– Strong preference for open source technologies.
– Extreme lack of time to waste re-inventing the wheel, or doing anything other than making a game.
– Need to deploy to multiple platforms, both desktop and mobile.
– The goal of building a long-term body of game code that I can re-use and iterate for future work.
This article is a comparison between the various game development platforms that I’ve considered over the last few years.
Note: Since I’m primarily interested in making 2D games, I’m not mentioning any 3D engines at all.
Projects like Node-Webkit, Crosswalk, CocoonJS, Ejecta, and XDK, make it possible and practical to deploy applications to every major platform as “native” apps. Certainly for desktop applications the runtime is sufficient to build many or most of the indie games that I love the best. Using WebGL frees the cpu to do important game logic, and V8/Chromium based wrappers have very good performance everywhere but on iOS, where JIT is disabled.
– Effortless deployment to many platforms.
– Great libraries like PIXI.js help you get stuff done.
– Performance is an issue, especially on iOS.
A lot of people really seem to love Unity. I have not really used it, but from the stories I hear I can see why it is an excellent choice for a lot of teams. The artists can get involved straight away, and the integration between editor and code ide has a lot of benefits. However, I have always had a strong resistance to using it. It just isn’t compatible with my obsession with open technologies. I don’t like the idea of being locked in to proprietary technology, or of developing in C#. I want to iterate my code base over the course of my lifetime, and C# simply isn’t the language I want my code to be written in. For an individual or company who really wants to get the job done and ship a product for multiple platforms, Unity is probably the best choice, and worth the price tag. For my personal projects I’m just not interested in it.
– Effortless deployment to many platforms.
– Well integrated editor / ide.
– Unity store for pre-built components. (Avoid re-inventing the wheel).
– Proprietary technology (lock in).
– Support for 2D games is very new.
HAXE/NME / OpenFL
HAXE/NME, now rebranded as the OpenFL platform, is another option for developers who want to deploy to multiple platforms. HAXE is a nice programming language, especially if you are already coming from an ActionScript and Flash background. When I evaluated OpenFL I found it easy to set up and build the test projects to the various targets, including directly to an Android device. I’ve heard that things can get fiddly at times with it, and you have to be aware of which apis will perform well on your target platforms, since they all handle the apis differently.
I’ve always thought HAXE was really cool, but when I weigh up using any language or technology over the long term, I’m not willing to spend my time on it unless it is widely used and backed by at least one large company with a big investment into its success. For the right project it could be a great choice, especially if you know ActionScript well.
– Easy to set up.
– Cool language with good balance between power and ease of use.
– Deploy to many targets.
– Use familiar apis if you have an ActionScript background.
– Enthusiastic scene.
– Not widely used enough (at least for my liking).
I recently evaluated SFML, and initially really liked it. It has a very clean and simple api, that reminded me a little of PIXI.js. It supports Gamepads out of the box, as well as Audio, Networking, and of course Graphics rendering.
SFML is nicely broken down into several modules for doing separate things. This seems like a great design choice.
One of the deal breakers for me was the lack of batch rendering support. There is supposedly implicit batch rendering planned behind the scenes, but it felt like a missing feature not to allow explicit batching. It would be possible to set up your own batching if you liked the framework enough to invest the time. There was also no built in support for sprite atlases or animations, so you would have to write those yourself. Another feature that would require implementation is a Scene Graph, if you are used to having one. (As flash developers often are.)
SFML does not currently support mobile, but this is planned in the near future. (Version 2.2)
– Clean, simple API.
– Very well documented.
– Modular design.
– Does most of what you want without telling you how you should do things too much.
– Great starting place for building your own engine.
– Missing a few key features you need if you want to actually make a game.
– Mobile support not quite there.
– Small dev team – who knows when feature X will come out?
I haven’t personally used SDL much, but it is often compared to SFML in terms of the features it offers. It is a good place to start if you are interested writing a game engine, but probably not the best choice if you really want to make a game. I believe it is a bit more widely used than SFML, so you might have more luck finding open source classes that can be used with it.
– A good starting place.
– Only a starting place.
For those willing to work in C++, the big player in open source / cross platform game development is Cocos2d-x. Like Unity, it does in some ways force you do to things the “Cocos2d way”, but in terms of the features it supports it is not really lacking. It is widely used, and shares many apis with its Objective C cousin, Cocos2d, which has been used for hundreds of commercial games.
Because the engine is focused on mobile it does lack a few features on desktop, most notably support for Gamepads and Keyboard input. Luckily it turned out to be easy to integrate SFML into the desktop build to get these features.
The original developer of Cocos2d in Objective C, Ricardo Quesada, appears to have left Zynga, where he was hired to work on the Objective C version. He has moved to work at Chukong Technologies, who are responsible for making Cocos2d-x in C++. I think this is a great sign for the engine, and indicates that the C++ version is likely to overtake the Objective C version as the leading open source engine for mobile games. After all, why would you develop for iOS only, when you can get all of those extra platforms for only a little more effort?
Chukong Technologies is a very successful company, at one point earning 6 million a month on their game Fishing Joy, made with Cocos2d-x. It’s good to know that the engine is backed by a successful company.
– Very complete feature set.
– Good support for multiple platforms.
– Backed by a successful company.
– Widely used, with growing user base.
– Code base written in C++ may have the most ongoing value.
– Emscripten deploy to Web mostly functional.
– C++ is a more challenging and less productive language to develop in.
– Much more work to maintain a multi-target build.
My feeling is that programming always involves a bit of pain. You just have to decide which kind of pain you find the most tolerable. Development pain, deployment pain, porting pain, debugging pain, every technology has weaknesses you’ll have to work with. You have to decide what your objectives are, both in the short and the long term.