I've heard that you have to convert it to make it operational and that may lead to slower and heavier programs etc.

Convert what? I've used Unity for a couple years now at work and nothing really rings a bell...

Maybe converting is not the expression I was looking for but I've heard that the user may need some Unity plugin to be able to play the game in their mobile device.

The Unity plugin only applies to running Unity games in a web browser. On mobile devices, the only thing the user needs to do is install the game itself.

The Unity engine works very well on mobile devices. Assuming you write high-quality code, your game will also work well across all mobile devices. The supported languages are C#, UnityScript (a very slightly modified version of JavaScript), and Boo (a slightly modified version of Python).

Yes, that I do know, as I have learnt some stuff about Unity in the past, thank you. But what do you mean with "high-quality code" exactly?

Just because Unity works cross-platform does not mean your code will too.

The Unity developers invest heavily in testing on all platforms, and over the years they have fixed most of the major issues. Now you need to not write buggy software.


For example, you might assume specific screen resolutions or ratios (Apple devices use only a small number of ratios, Android devices have many ratios), or you might assume the presence of limited-availability functionality like phone vibration or accelerometers. Unity offers features to help you correctly build programs, but most programmers -- including me -- will occasionally introduce errors.

It doesn't matter how good Unity is if you as the game programmer introduce code that crashes or has serious problems on some devices. You need to write high-quality code too.

Unity (in most cases because they're using an old version of Mono) has some quirks which cause otherwise "perfect" code to crash in certain circumstances:

- The Ahead-Of-Time (AOT) compilation may cause certain totally legitimate C# constructs like IEnumerable<T>.GetEnumerator to crash at runtime.

- On iOS, the default List<T>() constructor will set the internal array reference to a common static empty array, which is used until you add to the list. For some reason, performing .Add at the same time on multiple threads when each (distinct!) list is empty can crash even though the common static array is immutable. (Normally this is completely safe to do in C#.)

- We've seen interface properties become "corrupt" on Android. They will occasionally, for no apparent reason, start calling a different property's getter instead, returning garbage. Normally this is impossible, so I suspect there's a problem either in one of our native libraries corrupting memory, or in mono's ARM JIT compiler.


Normally you won't encounter these issues unless you're doing very specific things in your code, but they're something to take into account - you have to write code *slightly* differently from normal C# when using Unity.

There are some things that you can logically prove *cannot* crash by itself on .Net, but that same code can *totally* crash if you put it in a Unity project with a bunch of native plugins that play fast & loose with memory.

Yeah, there are bugs in Mono, but mostly they are easily resolved.

For the IEnumerable issue, we have found other issues in the Mono implementation that break nested IEnumerable items. It is a serious problem for things like serialization of the entire mono simulator, and since we need to do that, using the enumerables (including foreach) are forbidden on the team. This actually works out to be a good thing, since enumerables also consume far more memory than most programmers expect, they lock containers, and they cause several other issues. The theory is good, but the implementation is less so.

We also avoid "getters and setters" (even as a quote I hate typing that: they are accessors and mutators). Mobile devices are slow, and the extra overhead of function calls adds up. If there is a reason to expose the raw data, just expose it publicly. If the design means you shouldn't be exposing it directly it probably means you should probably be using action verbs rather than direct access. Consequently I haven't ever tripped over incorrectly-linked accessors.

In any event, no program is perfect. Do your best, don't introduce new bugs, and QA until everything works good enough. As a co-worker used to frequently remind everyone, a game doesn't need to be perfect, it just needs to delay crashing long enough to satisfy the player.

Be carefull if you go with Unity - the 2D is not yet matured, there are some bugs that can be quite hard to work around. So if you run in a problem you can't work your way around, you'll have to wait for update.

We have released several games made in Unity 3D so for our new 2D game we went with Unity. For initial prototype it was very fast to develop, mostly because of teams' expirience with the engine. But it feels sometimes like killing flies with a cannon - if your game does not need all the shiny stuff Unity engine offers, go with C++ or MonoGame or whatever floats your boat.

Also, Unity has a lot of plugins and middleware integration, plus you can get some usefull stuff from the asset store. Cuts down dev time on non-gameplay related stuff alot.