What's wrong with Unity?

Introduction

And I mean besides the whole licensing change thing that happened this year, and that they went back on, because obviously it was stupid, and management didn't listen to the people who told them it was stupid, and pushed for it anyway, and got a ton of well deserved shit for it.

These are some of my thoughts after working with unity for a few years almost every day, both at my actual day job and on some other projects. I don't think many of these things can be fixed without much effort by them, that they won't do, because it does not bring them more money. This leads us nicely to the first point I want to make:

The focus on the features that don't matter

Have you ever read the official unity blog? It feels like every time I open that page, the latest article is something I as a developer do not care about in the slightest. You're adding support for mobile browsers? I don't care, I don't make mobile games. You added some "next-gen" AI bullshit to the engine as a package? I really don't care, I'd rather hand craft everything, and have a real artist make the art, and learn blender to make 3D models, and write an actual connected story myself, or have an actual writer do that. But I'm sure the investors care about it, it's the current big thing.

The other thing they have been pushing for a while is AR, which I never understood the actual purpose of for a game engine. I don't think I've ever seen an AR "game" that worked well and didn't look out of place. It feels to me like the techology has not progressed since the time of the New 3DS (which had AR cards that would show you funny 3D models of characters. And going through all of those took like half an hour tops).

And whatever else next thing they push, despite the actual engine and editor having so many things that could be improved. Instead, they prefer to create another half-baked new feature to chase after a trend. I don't think I was ever excited for something they added in a new version. Since 2019 the most exciting thing for me was when they updated their C# runtime to actually support modern C# versions, that was nice. As to the things that could be improved…

The editor itself

It is so, so painfully slow. Why is it so slow? Everything takes time even on a modern PC with a fast SSD. Maybe that's a me issue, but I have heard similar complaints from other people. Sometimes a new version makes things not as slow, but at my job I really hate having to wait for 5-10 seconds after I change a line of code for it to recompile, reload, update the assets, and whatever else it's doing. Why can other engines have a responsive interface and compile times that don't completely stop your work flow for 10 seconds and unity can't? I'm not sure. Maybe it's the C# runtime, maybe it's because it checks the entire project every time. Even for smaller projects it still takes a fair bit longer than I'd like.

Actually, why are they using C# at all for a game engine? I don't think this is a very popular opinion, but I feel like C# does not fit very well into something that requires, preferably, no pauses for garbage collection and little to no constant garbage allocation. You have to work around the language a lot of the time, like making sure to pool your objects, and not create too many strings, and not use C# events and static fields because they live outside the engine and unity can't control them, so if your object gets destroyed that stuff now has dangling references to dead objects and will break things. And the compile times, again. It just takes so long on big projects, is there really no solution to this issue? And the whole IL2CPP thing, too, that blows up the already long project build time tenfold in terms of both RAM and time, that just transpiles the whole project to C++. It's an interesting solution and arguably helps with performance in the compiled game, but it takes so long. And by now I don't have enough RAM in my PC to build the project locally (currently I have 34GB installed and that's still not enough for it most of the time, unless I close every single other program on my computer).

The custom editors and serialization

The custom editors. It's a great idea but it is a very bad implementation. The whole immediate mode GUI thing that is not connected at all to how you build the UI in game (which is a topic I will mention again later) and that you have to constantly work around if you want to do something slightly out of the ordinary, because it's oriented on using their terrible "SerializedProperty" system which only allow access to a hard coded substet of types that unity has arbitrarily decided upon. And it also breaks every single major release. I don't remember updating unity without a custom editor breaking in some stupid way, like text suddenly being the wrong size, or the "open folded property" button being inside of the text instead of on the left of it, or one of the properties just deciding that it's of a different size now and being moved into the middle of the big textbox above it, or letters in that big textbox just collapsing into echh other. Really, "hard coded substet of X unity has arbitrarily decided upon" seems to be a reoccuring thing. You want a serialized function? Only zero or one arguments, or it won't work. You want a nested list? No, wrap each of the nested lists in a class, or it won't work. You want a dictionary? Just straight up does not exist. Use two lists as keys and values. You want polymorphism? Well, there's SerializeReference, but it doesn't have a proper UI to create instances of the polymorphic classes, so you better write a custom editor for that one. Also, if the name/namespace of your class changes, it will break. This is really the only thing that breaks if you rename a class properly (which means also renaming the meta file, since everything else actually uses its meta ID, it's just THIS thing that uses the actual full class name), and sure there's an annotation to fix the renames but was it really that difficult to just make it work? Sure, alternative solutions exist, and they have solved all of these issues a long time ago, but why the hell is the built in solution so bad?

As a comparison, godot's editors are just normal UI nodes. In fact, the whole godot editor is just normal UI nodes. And their serialization system actually has dictionaries and polymorphism built-in, and functions with any number of arguments. Hell, you can even bind or unbind certain arguments in editor and then add more when calling the function. It's actually insane how much better both of these things are compared to unity's broken system. I'm sure if Unity wanted, the could make all of these things work, it's just that their priorities are ad techologies and AI "innovation".

The animation system

The whole animation system. Why the hell are animation events so limited? Once again it has been arbitrarily decided that you can only call functions, and that these functions have the the restrictions as mentioned above of "zero or one parameter". And the editor for that whole thing is just atrocious. Why can't I reorder events that are on the same frame without doing an acrobatic fucking pirouette of moving it to another frame to the left if I want to move the event before the others or to the right if I want it to the right of the others; and if I want it in the middle? Well, do the same thing with all other events that are after or before it, depending on which is faster to rearrange. Godot was able to do it just fine, they have events of arbitrary types and arbitrary properties and even different interpolation types. I'm not actually sure if unity can do anything beside linear interpolation and curves. Also, why not just let me type out the property I want to animate, or at least allow me to search for the game object, or the property on the object? You really have to manually open the whole hierarchy each time in the tiny selection window and browse to the property you want to animate, and then remove the parts you don't want to touch like RGB in the Color type when I just want to change the alpha.

The asynchronous programming

It actually baffles me how bad it is with the whole "asynchronous queue" which is actually very much synchronous, just in another thread. If you try to load two things, they won't actually load in parallel or anything like that, and if you, Dog forbid, try to load a scene without instantly activating it, that will stop the whole queue until you activate the scene. Also, no canceling the loading of the scene. And they built the whole "addressables" system on top of that, so it still doesn't solve the issues of "loading a part of the world where the player may go next without activating it and causing a spike of Awake calls". In fact, I don't think there's any way in Unity to do that short of having your own life cycle for objects so they don't immediately activate all in one frame after scene loading. You can theoretically work around this by having your scenes as prefabs instead, these can in fact be loaded and activated later, but it's a different editor than scenes and half of the things that work with scenes don't work with prefabs when they're loaded like that (static batching at runtime, for example, unless you manually call that on the prefab yourself, which by the way uses FindObjects to get every single object currently in the running game, then runs a for loop on all of them to see if they're a child of a parent you passed into the function, and then uses LINQ to copy that entire array but now make it sorted. If you ever have the time, you may have some fun by decompiling StaticBatchingUtility.Combine and reading through the shit they do in there). And also, no rearranging children and having a preview of the actual game world in prefabs, et cetera. Why did they even have Scenes and Prefabs as separate things? Other engines just have them be the same thing and it works just fine. They're the same fucking thing, Unity.

The UI system

I have no idea how people build UIs with that garbage. The components it has are very basic and the layouting capabilities are just not reliable at all, I am still to figure out how to make the UI in unity look any good without just using sprites for everything and disregarding their components. Sure, there's some new "UI elements" thing, which still has almost zero built in components and the "recommended" UI system is stil the atrocious barely working old one. And even with the whole UI elements thing, I'm not sure I want to write HTML and CSS for a game's UI after my experience with WPF (which I hear some people like, but I am not one of those people). Also, the default styling for them is just straight up bad and half of the built-in components are actually other components stacked in a weird way that kind-of-barely-works but the styling clashes and you have to replace all of it anyway, like the scroll box (which by the way has no way to scroll to an element in it built-in, you have to also code that one youself. Was it really that difficult to just make a normal scroll component with basic features and not "let's pretend that masking child content outside of boundaries of this component and moving the child up and down is actually scrolling").

Unity is not a 2D engine

They love to pretend that it is sometimes, but the lack of actual 2D components is just stupid. For the longest time there was just no way at all to have lighting in 2D, though I hear that's been solved a little bit ago finally. There are no 2D particles, there is no 2D pathfinding, all the coordinates of all the objects are still a Vector3, at least the damn physics system is an actual 2D physics system (Box2D, what else could it be?), that would have been even more embarassing if they got that wrong, and they have 2D collisions "kind of" but they're not as advanced as 3D and have separate callbacks (Why? It doesn't make sense to have an object collide in both 2D and 3D anyway. Probably because they couldn't figure out a good type for it or something). The audio attenuation still works in 3D so if your camera is too far from the 2D world you won't hear anything. Then again, the audio system in unity is also just not very good, better use FMOD if you can. At least they have various audio effects if you want them and can't affort FMOD. Can't vouch for the quality of those, did not have to use them much. Also, while not a 2D issue per se, why the hell is there no built-in tweening solution? I don't want to use the idiotic animation system to show a menu slide in, and what if the position is dynamic? There's a great package called "DOTween", and it solves this problem, but why the hell is it not built in? I feel like animation is one of the very important parts that a game engine should provide, especially for 2D games which (sometimes, not always) tend to be more UI heavy and would benefit greatly from an easy way to animate all of that.

(Update: 14 Feb 2024) No file selection dialogue

Unity does not and never had a built in way to show a file selection dialogue in a running game. There are, as usual, plugins that kind of work. You can also manually copy a mono Windows Forms DLL file and use the ugly Windows Forms file selection dialogue, but I'm not sure if this works anywhere but on windows, so you probably will need to create some kind of workaround for every system yourself or use the aforementioned plugin.

Thing is, unity has a file selection dialogue for the editor, it's in EditorUtility. It works on every system, too. So why not add the same thing to the built standalone player? Is it really that difficult? I don't think it is. Hell, they could make their own system-independant file selection dialogue. Godot did that, and it works fine. That one even works in browsers (with the virtual filesystem, which is a bit different, but still).

(Update: 28 Feb 2024) Advanced search

Did you know unity has advanced search that can filter things in the scene or in the project by various things, and even by the values of properties, I have always thought this would be nice and turns out it does exist (with caveats, the property filter is very basic, like everything unity does. Honestly, is it really that difficult to add things like arrays into this filter?). This is a really cool feature that's never ever advertised or used by anyone I know, and the only way to access it is to press Ctrl+K, I don't even remember where I learned this.

However, there is a very big issue with it that makes it not really usable for me: if there are a lot of results it will crash the progam because it takes too much memory. It's not even a normal unity crash where it asks to submit a crash report, it will just hang up after searching for some time and then hard-close the program with no message. I tried searching for meshes in the whole project and it happened 2 times after a little bit of waiting. Come on, couldn't there be some kinda limit on it or something? I have 34G of RAM, and I still run out of memory a lot. And every time it happens, it's always Unity.

Conclusion

I probably forgot something else, in which case I might update this article later. These are the things that come to mind when I use any other engine and think "I wish unity had this, this is so much better". But Unity is not a game development company, they don't actually use their own engine. If they did, it wouldn't be so bad, I'm sure. They're an ad company, they're a making huge cash money and pleasing the investors company. So what goes in the engine is whatever gives them more money, it seems like. And not the things people have been begging them to add for the last 10 or whatever years. Just use a different engine. Especially if you're making a 2D game. DO NOT USE UNITY FOR 2D GAMES. Use ANYTHING else:

GameMaker recently became free and they're actually adding new useful features to the engine, it looks like (and you need to just pay them 100$ once if you want to sell your game now instead of some stupid subscription that they had before). But also look at this stupid stunt they pulled in 2012 and think what you will about that.

RPGMaker MV/MZ is arguably not a great engine, but since it's javascript you can literally go inside the engine and change the parts you don't like; It's very easy to get started with these two.

Defold, this one uses Lua (which is for sure better than C# for games), and I've heard some nice things about it before, plus it's open source. Want to try that one myself at some point. Apparently it can do 3D too, might be interesting to look at.

Godot is probably my favourite from these, and you can do 3D games in it too, in fact it seems pretty alright for 3D games. I've been using it for about a year now and sure it has issues, especially with the editor stability, but it starts up in like a second and reloading code changes is instant. And they have a programming language specifically designed by them for making games. Seriously, try it.

I've been meaning to gather everything I dislike about unity in a single post for a while, and this is the result. It's getting a bit late now, so I'll probably go to bed after publishing this. Goodnight, and thank you for reading my blog post.

Comments