Top Game Development Tools: Pros and Cons

According to our survey, a surprisingly high [tweetable]29% of games developers are primarily building their apps without a third party engine[/tweetable]*. They have either written their own engines, or are building everything from scratch. Large games studios very often build their own engines and tools, or customise open source solutions to suit their own internal processes and workflow. However, two of the most popular developer segments going for this option are Hobbyists and Explorers. It doesn’t make much sense for part-time game developers, or even small studios, to spend a lot of time working on their own tools rather than building games. In this post I’ll take a look at some of the most popular tools they could be using instead.


Which are your favourite tools for games development? Let us know in our new Developer Economics Survey and you might win an Occulus Rift Pro and other hot prizes.

Unity – the people’s champion!


As developer tools go, Unity is incredibly successful. A massive [tweetable]47% of developers in our survey use Unity for some of their projects and 29% use it as their primary development tool[/tweetable]. This is not just Hobbyists taking advantage of the free licensing options, Unity is more popular with professionals in general and most popular with the Hunters (53% of them) who are trying to earn their living from the app stores.


Unity supports both 2D & 3D game development, which is quite unusual for a game engine. That said, Unity was really designed for 3D games with 2D support bolted on afterwards; the 2D features were initially just for building menus and other 2D screens needed in a 3D game, to avoid the need for an external tool. The features were quite generic and developers started building games with them; probably due to the broad cross-platform support. To their credit, Unity have supported this and continue to invest in the area.

Supported languages

Three development languages are officially supported: C#, UnityScript (basically JavaScript with type annotations) and Boo. The last of these, Boo is not widely used and probably best avoided. Given its name, you’d be forgiven for thinking that UnityScript is the main development language, it’s not. The Unity community has widely adopted C# and you’ll find the majority of plugins and examples use it. If you prefer JavaScript and only have a very simple project in mind then UnityScript is a good option. Once you start using plugins written in C# that potentially need to call back into your UnityScript you’ll find issues with compilation order and wish you’d gone with C# from the beginning.


Unity has a lot of great features:

  • Unity has a very strong community of asset and plugin creators – there’s lots of free and reasonable priced content available.
  • Unity’s visual editing tools are excellent and the editor can be extended with plugins.
  • It supports a wide range of asset formats and converts automatically to optimal formats for the target platform.
  • It supports a very wide range of platforms, mobile, desktop, web and console.
  • Deployment to multiple platforms is very easy to manage.
  • The 3D engine produces high quality results without any complex configuration (I’ve personally written a licensed game with Unity that Apple has featured in lots of countries).
  • There is a free license that covers the majority of features.
  • Paid licenses are very affordable for most professional developers, available on subscription for $75 per platform currently (some platforms are free).


There are a few issues which are worth considering before choosing to go with Unity:

  • Collaboration is difficult. Unity has an expensive asset server product to help teams collaborate. If you don’t use it, sharing code and assets between team members can be painful. The best option is to enable and use external source control but there are several binary files (which don’t need to be) that can’t be merged and updating assets often causes them to break things in scenes, losing connections to scripts and other objects.
  • Performance is not great – until very recently Unity ran almost entirely in a single thread and made almost no use of the extra cores in most mobile devices – this is improving in Unity 5. The compilers are not at all well optimised for the ARM processors in almost all mobile devices – Unity have decided to transpile to C++ and use LLVM to get a more optimised build rather than solve this problem directly in future releases.
  • The engine source code is not available. Even paying users don’t get to see the Unity source code, which means if you come across a bug in the engine you have to wait for them to fix it or work around it. It’s always going to be more critical for you than it is for them. This also limits the ways in which you can extend or customise the engine.

Overall, Unity is a great choice, particularly for solo developers who aren’t trying to push the limits of what the platforms can do.

Cocos2d – perfect for casual games


Cocos2d is, as the name suggests, a 2D games engine. It originated around the same time as the iPhone SDK and quickly switched to Objective-C, growing in popularity as the best free and open source option for mobile games. However, Apple released their own highly performance optimised 2D engine for Objective-C developers called SpriteKit. That, along with the rise of Android, has caused the focus of Cocos2d development to shift towards the cross-platform Cocos2d-x branch written in C++. The Cocos2d family of engines is the most popular open source option in the world, used by 19% of game developers in our survey and by 8% as their primary tool.

Supported languages

There are different versions of Cocos2d available in Objective-C, C++, C#, Java, JavaScript and Ruby. As mentioned above, the C++ version is the most actively maintained, it also has the widest range of supported platforms. There are also scripting language bindings to the C++ version in both Lua and JavaScript, enabling developers to write in their preferred scripting language but get the full native performance of the underlying engine.


As with most thriving open source products, there’s a lot to like about Cocos2d:

  • Broad range of supported platforms, particularly mobile ones.
  • Free and open source (MIT license).
  • Wide range of extensions, tools and open source code available.
  • Lots of community created examples and learning resources.
  • Large peer support community.
  • Hardware accelerated graphics and good performance.
  • Audio support (in most versions).


Nothing’s perfect, here are a few issues with Cocos2d:

  • There’s no large commercial entity providing support and bug fixes. It’s great that you can fix it yourself, or hire someone who knows how. The community might even fix your issue for free but sometimes when a big project hits a bug or performance issue close to a deadline you just want to be able to pay someone to make it go away.
  • The APIs are somewhat unorthodox. The history of the project is such that it started in Python and moved to Objective-C very early. The Objective-C wasn’t exactly following standard practices and then that got ported to C++, retaining the Objective-C idioms.
  • It doesn’t do much to encourage good structure. Some developers like frameworks that don’t impose a style on their apps but Cocos2d goes a bit far. It’s possible to write code that’s hard to maintain in any system but it’s easy to find examples of Cocos2d games with really long functions and a lot of global state.

OK, the cons are nit-picking and more warnings that really negative points. After all, poorly structured code and unusual APIs are not exactly barriers to success. I’ve ported a game from iOS that was written with Cocos2d (the Objective-C version, before the C++ variant existed) and almost one giant method with tens of global variables. At one time it was the number 1 paid download on iOS in several countries. Cocos2d-x is an excellent choice for a 2D game.

Adobe AIR – what remains of Flash

Adobe AIR

In 2007 Adobe seemed to be winning the casual games runtime battle, with Flash having become the defacto standard for games on the web and Flash Lite almost ubiquitous on more advanced mobile devices. Then the iPhone came along and Steve Jobs said it wasn’t going to support Flash. This knife wound wasn’t immediately fatal but Flash has been slowly bleeding to death ever since. By 2011 Adobe eventually produced a version of AIR that compiled Flash to native iOS apps but by then the damage was done. Android initially supported Flash, poorly, in the browser but Adobe eventually gave in and stopped developing the browser plugin to focus on AIR. There are still a lot of Flash developers in the world, 15% of mobile game developers use it and 6% of them as their primary tool. It’s also still, just about, the only way to target rich gaming experiences to the majority of the world’s desktop web browsers. Adobe is now focussing on tools for HTML5 developers and Flash/AIR has not really evolved in a long time. Given this background, I won’t focus on detailed technical pros and cons as with the other tools.

Supported languages

Adobe AIR applications are developed in Flash, coded using ActionScript. There’s an integrated web view which can be targeted with HTML, CSS and JavaScript. It’s also possible to build native extensions for AIR apps, individually for each targeted platform.


Flash is still a capable environment for simple 2D games. If you already know Flash it’s one of the fastest ways to build a mobile game.


The platform is a dead end. I couldn’t recommend anyone who doesn’t already know Flash to learn it. Those who are fans of ActionScript but don’t like HTML5 should probably look at Haxe.

Unreal Engine 4 – the AAA king goes mass market


The Unreal Engine has a long history as one of the top 3D games engines for PC and console platforms. The 3rd generation of the engine supported mobile platforms but it was really only for hobbyist developers tinkering with their limited UDK or the multi-million dollar licensees of the engine for console games porting their titles to mobile devices. In March this year, Epic Games released the Unreal Engine 4 to anyone for $19/month plus 5% revenue share. This offering includes full access to the engine source code and their suite of tools. This change was not long enough before our survey was launched to see significant adoption by developers but 13% were using it with only 3% as their primary tool.

Supported languages

The Unreal Engine is written in C++ and that’s the only supported development language. However, it’s possible to do a lot of development without writing any code using Blueprints – a visual programming environment where nodes are connected with lines.


The Unreal Engine is AAA game quality:

  • Incredible performance. The Unreal Engine was demoed using Apple’s new Metal graphics interface at WWDC. It can produce the most realistic graphics ever seen on an iOS device. The same will be true for (high end) Android devices.
  • They have state of the art tools for all aspects of game development.
  • Full source access enables extension, customisation and engine bug fixing.
  • The pricing model is an excellent match for the high risks of failure on the App Store.


The Unreal Engine is designed for professionals:

  • Development is in C++, not a beginner friendly language.
  • The learning curve for the tools and engine is significant, greater than Unity.
  • The engine has limited support for older devices.
  • The pricing model is very expensive for a successful title, unless you expect significant success and use the engine under a different licensing model.

The Unreal Engine is an excellent option for high quality 3D games on high end mobile devices but it won’t be for everyone. I expect to see increasing adoption across the next couple of years. If you’d like a free 3D engine with scripting language support it might be worth checking out Project Anarchy by Havok. It’s effectively subsidised by Intel (owners of Havok) for mobile devices. There’s a co-marketing option in the license and you have to build an x86 variant if you build for Android (or Tizen, if that ever happens), otherwise it’s completely free, only the PC version is paid.

* Apple’s SpriteKit on iOS is actually a fully functional 2D game engine but as it’s part of the platform, developers may legitimately have said they were only using native code. If this is popular then it may significantly reduce the 29% figure.

Which are the best and worst aspects of each tool? Here’s your chance to have your say. Take the survey.