Before delving into what I have to say, I want to give you some background.

Many people I talk to on a daily basis looks at me like a freak when I say that I don't like Unity. This is not just an 'I wanna be cool' thing, it's actually a pragmatic thing.

See, I'm not in games to make shitloads of money, creating zillions of games one after the other just to see if some game becomes a hit. I look at games as an art form, I enjoy great video game experiences and want to be a part of that. I don't care about ROI. Also, I'm mostly interested in creating console and PC games.

That said, let's start discussing the issues I find with Unity, and partially with Unreal Engine, or any other non-custom engine.

Unity's Pros

Let's analyze the things that Unity claims as pros:

• It's an industry standard, this means that there is a huge community behind it and it will be easy to find resources.
• It uses C#, a language that is easy to learn, where you don't need to take care of memory so much.
• It is multi-platform, which means that with one click you should be able to publish your game to all the major platforms.
• Fast development
• Asset Store: many issues that you'll find are already solved by someone, so you don't need to "reinvent the wheel".

Now... let's analyze them from my perspective.

Industry standard

There is a HUGE community, that's true, but most of it is amateur and almost all of them are Mobile. I know there are titles that are not mobile and not amateur made with Unity, but I'm talking about the vast majority of the community.

C# as the main language

See below for a detailed explanation of this.

Multi-platform

It's true that they support a lot of platforms, but, since we don't have the code, we can't support just whatever platform I want, and this means I can't ensure that I can release my game wherever I want. This is a problem for me, I'll elaborate on this later too.

Fast development

I'd add one thing: of prototypes. You can actually prototype pretty fast with Unity, but with a game with more than a year of development, you'll start feeling a lot of friction. Unity behaves erratically, crashes a lot, creates integration issues, and lots of problems that make development not that fast when you grow a lot.

Asset Store

The Asset Store may seem like a good idea, but the lack of QA on Unity's part makes this basically unusable. Since the vast majority of Unity's community is amateur this is reflected in the Asset Store. There are zillions of packages that are poorly developed, trash the memory like hell, and they're simply badly designed. I think we only found one or two packages that actually behaved as we expected, and not only that, some of the packages come without source code, which is crazy.

Unity's Cons

These cons I'll list are from MY perspective, you don't need to agree, because your context may be different, but I'd like to have you at least pay attention to see if any of these issues applies to you.

Loss of authorship

This may sound a little bit weird to some people, but I find really important to feel related to the code I write. I need to feel I authored that code, and the way Unity imposes its opinions on how things need to be done (with its component system and all) feels wrong to me. I know you can use C++ and do bindings, I know I can ignore the MonoBehaviour and just use Unity as little as I can, but then you lose all the functionality that you picked Unity for in the first place.

Future Compatibility

This a crucial one for me. Nothing ensures that you'll be able to compile your game 10, 20, 30 years from now because you depend on a company, that might die at some point, and you won't be able to make your game work without an incredible amount of reverse engineering. It's obvious that people on the F2P-world don't care about this a lot, because their game will probably fail before Unity collapses, but for us trying to provide value to human culture it is important.

Garbage Collection

On the technical side, and this is arguable, I don't like garbage collection. I think GC is just a bad solution for lazy programmers. I enjoy managing the memory of my games, it's part of the authorship thing.

Virtual Machine

Do we really need a virtual machine when all we need is a graphics context, sound, input, and network? Remember we need to fit all our CPU processing in 16ms (and less in the future), so how on earth having a layer between us and the processor can help us on that? I think this an overhead that games do not need. Creating the OS layer in an engine is something that can be done in weeks if not days and you can profit from all the performance gains.

OOP / Performance / Multi-threading

A lot has been said about OOP not being great for games, let's say I adhere to that both on the performance and code design standpoints. I understand how you can not relate to this, I was one of the patterns guys in the past. But I grew up and understood that all that is just bullshit to patch a paradigm that was not meant to be used on games.

On the performance/multi-threading thing, Unity has a lot of issues with Multi-threading because of the fact that you can't access Unity's API from a thread, and that almost leaves you with nothing.

True Multi-platform

As I said, I want to be able to release my game in the most obscure watch created by hidden people in Iceland. Unity won't allow me to do that because I have to go with their choice of platform. This brings an important issue: Unity does not implement EVERYTHING on EVERY platform. And this is a huge problem if that happens to be YOUR platform. This gets me to:

Bugs

With an engine of the size of Unity, is normal to live around zillions of bugs. This is not a problem if you can fix a bug (When I was working with Moai, I actually started contributing with the codebase by patching some bugs I found while working on The Insulines), but Unity is closed source (at least for us poor developers). This is a deal-breaker. We were not sure if we could release Nubarron for A YEAR because of a crash Unity had with Tegra CPUs (which happened to be the processor used in Fuze, the console we were meant to release to). Also, when we released Piedra libre, Medialuna on Android, we had to launch with a bug that won't allow us to stop the audio when you closed the application if you used FMOD separately from Unity. The bug is still there. I don't feel comfortable with this, I can't have control over many things with my game, I can't control if the audience will like it, I can't control how people is going to play it, I can't control how much time it will realistically take, but I should be able to control the quality of it, and having an engine with bugs takes away this right.

The engine makes progress only on what makes sense economically

I can't blame Unity for this, I mean, makes total sense, but this implies several things that hurt my freedom as a developer. The consequences of the Bugs section is in part because of this, but also the multi-platform issue. There is another big issue that I see with Unity's model. They rely on the Asset Store to make money, and I feel like they deliberately leave important functionality away from the engine so that you have to buy Assets. The Input System is the clear example of this, if you want to use a controller, you'll have to rely on InControl or something like that, because it's a nightmare to set up controllers correctly.

What about another engine?

I think this makes sense if we create games that are basically in the same genre of another one and we want to avoid programming a lot. Or if we have specific requirements that are met by this engine and we can ignore the decisions such engine makes for us. As I grow up as a programmer, I have this feeling that generic solutions never work the way I expect them to. So I'm moving away from engines because of this.

So what do I want to do?

Games! (Not engines), and, for now, using C/C++.

Memory Management

C++ provides the tools to be able to control the memory and work efficiently with it.

Multi-Platform

Nowadays every single platform supports C++ since it's the main language used to build operating systems. This said I think it's the wisest choice for the moment.

Multi-paradigm

I can basically use as much as I want of OOP, or not use it at all, and that's a feature I love about C++. I know you can do this with several other languages, but most of them have drawbacks (like being garbage collected).

No political/economical limits

Since C++ is not tied to a single company, and it's a standard with so many implementations, with some great open source ones, I can stay free of the problems of depending on a company that I already mentioned.

Multi-threading

This is not specific from C++, there are many other options obviously that you can use if you care about Multi-threading, but for completeness, I add it here.

Conclusion

You may or may not agree with me, that's fine. Unity could have saved your game development life, but it did not do that for me, I feel the pain every single day with Nubarron, so I'm not falling in the same trap again. Maybe I'm too old of a programmer to accept a model where you integrate poorly made stuff from several unreliable sources to get some sort of thing working. I feel this is the way new programmers expect to work, and I don't feel comfortable with that. I also give a lot of importance to creativity, and being bound in how to implement stuff feels like a creativity blocker.

We'll see how it goes.