Why I stopped using Unity3D after two months and a working prototype

Two years after my previous mobile game, I decided to start a new 2D puzzle game. I wanted to try a new technology and chose Unity. In this article, I’ll explain why I chose Unity in the first place, and describe what I liked and disliked. After developing a fully working prototype of my new game in about two months (not my full time job, working when kids are sleeping), I finally came back to a framework I used previously: cocos2d-x.

Why choosing unity

unityMobile game developement is a hobby, and I love learning new things. Unity had new features for 2D games since v4.3 (Sprites), and became free for small teams with the personal edition. I knew C# quite well already from experience of previous XBLIG games.

What I liked in Unity

Here are some of the great features in Unity that I used while developing my prototype. Keep in mind that I’m focused on simple 2D games, and not on huge 3D FPS. Also, I’m single developer on the project, doing both programming and game design.


A prefab is a set of objects tied together. It’s easy to instantiate prefabs programmatically in real time in the game. For example, to create a pack selection screen such as this one from a previous project, I made a prefab and modified by script the values of each pack. If you want to change the layout or overall look of the prefab, there’s nothing to change in the code, everything is done in the editor.

Editor customization

The editor is very well done and it’s easy to add properties to game objects. You can also add specific features. Here is a small list of stuff that helped me debugging and developing my game:
* showing game object bounds (see tweet below)
* showing mouse position on screen
* logging debug information on screen
* changing language in real time

Running in the editor

When you run the game in the editor, you still have access to variables and exposed settings of your game objects. You can also view objects outside the window. It’s handy when you don’t see an object on screen to know whether it’s invisible or simply out of screen.
The editor also lets you try some new layouts while the game is running by simple moving your instances.


Profiling is another great feature recently made available for free in Unity 5. You can see in real time memory allocations, rendered meshes and CPU usage of any script. Sorting scripts by CPU usage helps to understand where to optimize first.


This is one of the feature that made me try Unity in the first place. Being able to deploy on all platforms with a single click. It’s not as simple as that in reality, because sometimes you need to create projects and build them with external tools (iOS, Windows 8.1 for example). With my prototype, I built Windows, Linux, WebGL, Android and Windows Phone 8.1 builds very quickly and without major issues.

Visual Studio Integration

I initially used MonoDevelop and honestly didn’t like it. However, I discovered Visual Studio Tools for Unity and used it with Visual Studio Community 2015 and now I have a great dev environment. Unity recently included the plugin in the editor package directly. You can even set breakpoints and step into your code directly in Visual Studio.

What I didn’t like in Unity

Let’s look now at the issues I had with Unity.


I found the 2D features not good enough for my needs. There was a promising new UI system, but it’s slow and not recommended on mobiles. I also had to play with texture tiling (repeating UVs) and there is no support natively in the 2D sprite game objects. I had to re-code a sprite using a 3D quad to have access to UV settings. And last but not least:

Resources transformation

When working with artists, I find it useful to send them a desktop version of the game so that they can change the raw resources files and see their work in game. Unfortunately, there is no easy way to do that in Unity without sending the whole project with assets and source code. I had to develop a specific function to load custom files at startup. See this reddit thread if you want more information and sample code on this topic.

Big packages

Because Unity has to include the C# libraries in your packaged game, games take a lot of space: A simple empty game without resources and only displaying a white screen takes 28.5 Mb on Windows and 18.4 Mb on Android (EDIT: I didn’t realize you could create ARM only binary, in this case the size is 9.5 Mb)! My latest mobile game (made with cocos2dx) takes 4.7 Mb, code, resources and art included. It’s not a problem for big productions but it is for smaller games.

Visual Studio Tools instability

I told above that I loved Visual Studio integration but the stability is for from perfect. I had to kill Unity and Visual Studio at least twice a day because they stopped responding. When it happened middle of a big debugging session, it’s very frustrating.

Memory allocations

I raised the issue in the 2D section, but it also happened with mandatory function: this tweet sums it all:

Splash screen

In the free version, you have to use Unity’s splash screen on every platform. I knew that from the beginning and understand that, as I use a free version of the tool. But that’s a drawback nonetheless.


I think this is only in the free version, but Unity games connect to Internet and therefore forces Android permissions (INTERNET and ACCESS_NETWORK_STATE). As a user, I don’t like being asked for too many permissions. I’m still unsure if I’ll have ads in my next game (I probably won’t), but if I don’t, I surely don’t want to have extra permissions in my app.

Too expensive

The last two issues can simply be solved by purchasing Unity Pro. As I’m doing this as a hobbyist, I don’t have a big budget to put into gamedev, and I’m really not sure my game sales will be able to cover the costs of Unity Pro (about 171 € per month or 3420 € once if I want support for Windows, iOS, Android and Windows Phone 8.1).

Switching to cocos2dx

cocossmallI considered some of the issues so important (splash screen and big packages, mostly) that I looked for other multiplatform engines and decided to come back to cocos2dx. Since I used cocos2dx v1 a few years ago, there has been many great changes, and I am now using v3. It’s really a powerful framework, and I made my own fork where I can do some specific tweaks. Cocos2d-x is not as “plug’n’play” as Unity and the documentation is sometimes too light, but I don’t feel limited. I have working Android, Windows Phone, iOS and Windows builds for now.


Unity3D is a good tool, but I don’t think it’s suited to small 2D games. Cocos2d-x team have made some great changes and are still very active.

Feel free to comment, tweet or share this article.

Bonus tweets

While actively learning Unity, I made a series of #UnityTips tweets, here are the best ones:


  1. Learn programming not third party game engines!

    I find today’s tools very limited they are how can I put it. Just a bunch of a expensive scene graphs with knobs and turns dials, while building from scratch may seem like a long road. It has self worth and trade offs if you can master actual skills, with game engines like Unity 3D you will never make anything unique. It will always be limited to what the app allows for and lets face it having no source code access to Unity is a big let down. This means you can’t change things.

      1. I disagree. You obviously need much less programming when using tools such as Unity, that are more oriented toward game designers than programmers IMH.

    1. I disagree. Unity is a flexible engine and allows you to do anything you want. While I agree making custom content in Unity if it’s *very* out of the box is more difficult, the notion that it’s impossible is silly. I’ve been a programmer (application development in C++, Java, and C#) for over 10 years now, and I find Unity to be very nice to making games quickly. Being able to see what you change real time is a huge boon, and making UI is a dream since you can see it all happen in front of your eyes.

  2. “2D
    I found the 2D features not good enough for my needs. There was a promising new UI system, but it’s slow and not recommended on mobiles. I also had to play with texture tiling (repeating UVs) and there is no support natively in the 2D sprite game objects. I had to re-code a sprite using a 3D quad to have access to UV settings.”
    Yeah I completely agree with you that the 2D part of unity is pretty weak, but considering it was added only about a year ago you can’t expect much for now. If you maybe saw the Unite at Boston you would see that they are still adding a lot to it. Unity wasn’t intended for 2D games till last year so they can’t make it the best 2D engine in a year.

  3. I think the opposite, I think Unity is perfectly suited for small 2D games (not only of course), as it takes aways a lot of the groundwork that you don’t want to have to make for a smaller game (if the time frame is 3 months, any extra week of development is non-negligible).
    It’s extremely popular with indie devs that make small(ish) 2d games, and that DO code (others that don’t code go for tools that don’t require any code).

    I’ve used cocos2d-x in the past, and liked it, and I understand your points which are all valid. However, having made games full-time with both tools/frameworks, I can say that I am on average twice as fast to implement anything in a game with Unity. It’s partly because of the language (I’m not an expert in C++), but mainly because of the editor, that speeds up tremendously anything that involves graphics.

  4. I’d recommend giving Haxeflixel a shot. It’s pretty powerful, easy to work with, and supports every major platform at no cost.

    The Haxe ecosystem in general is pretty awesome, and as it stands now, is a better 2d multi platform option than Unity for small projects.

    Plus you get flash to deliver your game to old desktop computers on the web!

Comments are closed.