Lesson Learned: Unity
I was pleasantly surprised by how much Unity will do for you and some things that are normally difficult, such as render to texture, are easy with Unity. Unity ran fast and well, I didn’t initially see the bugs I keep reading about, and it only took me a few months to come up with a prototype. However, as the game got more complex I found many of the complaints about Unity to be well-founded.
1. As your code base gets larger, the Editor progressively gets slower. I’ve avoided things that will obviously cause that, such as running during editor mode, or OnValidate(). Regardless, Opening a prefab, renaming a file, starting in play mode, or ending playmode can take anywhere from 10 seconds to a minute. It’s very disruptive, losing perhaps 50% of my workday, and I have a pretty fast computer.
2. Common features are well-documented and work as expected. But once you get into more advanced features expect odd internal error messages, freezes, crashes
3. Unity tends to be architected towards ease-of-use over scalability. It makes large projects hard to manage though. The animation controller system is a good example of this. A graphical editor for animators is great. But it doesn’t scale – either you can duplicate it a bunch of times (a nightmare if you later have to change how it works), or you use a single overridden template and lose much of the flexibility.
This isn’t Unity’s fault but be careful about which asset store assets you buy. It’s really awesome and exciting to see all these features you can just drop into your game. But a lot of / most of these authors are not professionals. The second biggest loss of time on this project was picking poorly made or buggy assets, then having to remove them later.