Why We Didn't Use Unity
Unity is one of the major engines out there, but its definitely not the only choice.
When we started development of Vignette, there was this ongoing question on the project's technology stack. One of this questions is very striking and quite often ending up in every discussion space I was in when I showcased my project in?
Why isn't it on Unity?
Vignette's main tenet was to always do things differently; that means almost everything we do is quite unorthodox. We designed Vignette to be unique in a lot of aspects as our response to the shortcomings of our contemporaries (which sometimes bit back to us).
Our choice to make it open source was unorthodox by itself as most software like ours are either paywalled or freemium. We chose not only to make every core features of it free, but open source, in the interest of the VTuber community.
When it comes of choice of technology, it also struck us how limited the options were, of course Unity is on those options, but in a market where there are diverse options, Unity is definitely not the only option for our choice of stack, therefore, we always seeked alternatives that were better, but sometimes bleeding edge. We were not afraid to take risks, that's why we were willing to look for alternatives that are sometimes unstable or novel in the industry.
Despite the fanfare, Unity is actually one of the tools most people frown upon, even by Garry Newman who made quite a detailed blog how Unity falls short on development experience.
Despite our risk-taking, bleeding edge approach to software development, we still can't deny there should be stability where it needs to be, and Unity has proven countless times how it became a pain to use, even to novice game developers who just want things done. Quoting Garry Newman's blog and my own experience, the shortcomings were as follows:
Unity provides almost no choice for you in rendering pipelines. The choices are limited or sometimes even forced to you since they will deprecate the rendering pipeline you're using almost immediately. It's understandable for a few who wants the new features almost immediately, but if you look into it at scale, it becomes cumbersome and just adds more work to the developer.
Code samples for Unity has little to no maintenance, which makes it harder for new developers who want to get the gripes of the engine to catch up with new engine features, and sometimes will force them to learn deprecated behavior when they shouldn't - a bad example to promote.
Unity will force you their DOTS architecture, which is, for most part, frowned by many. DOTS does makes sense for a data perspective, but that's not really what the developers want, what they want is getting up to date with .NET and being able to do multithreading properly with TPL.
They will deprecate a specific API with no mature API to replace it properly. I get that people might be okay with it, but even me, thinks that's a horrible way to do development. If you're going to replace an API, you must have a compelling reason, or a better alternative in hand.
This is in no way a comprehensive list, but these are some sentiments shared with some of the developers who uses Unity that I conversed with.
In our first build, we used osu!framework which got the job done, but we were not satisfied how it was very limiting, so we are moving to Evergine, which fulfills all what we love from osu!framework without it's drawbacks, and with a saner architecture that fits our intended use case.
A lot of the lessons we learned from each iteration allowed us to iterate better in the software, and if it were made it in Unity, we wouldn't be able to innovate as much as we can right now due to its major shortcomings, and its incompatibilities with the greater .NET ecosystem.