The reason for this thread is to express my general feelings about the direction Unity is taking and maybe get some clarifications from the more informed part of the community.
Have to admin I’m yet to try digging into ECS and Jobs and trying to make some prototypes using them. Still, I’ve been watching the latest features in Unity 2019.x and their roadmap on GDC and I’ve got a strong impression that Unity considers the old GameObject system as “legacy” and really pushes DOTS hard as the one and only way of coding in “Unity 2.0” (newest features require DOTS etc.). I understand all the performance and scalability benefits of ECS/Jobs, so no need to explain it here… It’s beside the point.
They marketed Unity from the start as the tool to “democratize game development”, meaning the barrier of entry must be very low. For me personally probably the main selling point of Unity was it’s easy-to-use and easy-to-understand MonoBehavior system. It’s a bit messy, yes (as I’ve now discovered), yet it was still way ahead of how most people made games before - strongly (over)using OOP with huge ugly inheritance trees etc. Here I could clearly break my game into self-contained components, so in effect I got a nice ECS structure with small SOLID classes.
Yes it arguably wasn’t a true ECS (code and data is not explicitly separated into different classes), but I’ve arranged groups of related MonoBehaviours and learnt to think about them as “systems”. For example you could have a Pickup behavior and an Inventory that you add to your player. Together they form a “Pickup/Inventory” system that’s pretty well defined and separated. The only problem was that the system had to be “smudged” between all related components somehow and unless you have a strong convention for this, you can make a mess.
Nevertheless the old way allowed me to use the full power of C# with it’s wide assortment of existing tools and libraries, strong features, etc. It really allows you to think less about implementation details, more about WHAT you want in your game. That’s to me the whole point of “democratized development”. It should be easy to hack together a simple game. All you had to do to make it performant enough is to make sure your garbage collection is under control, that you don’t produce anything in every frame, that kind of stuff.
Now here’s where I see a problem with current trend. If we go full DOTS with HPC# instead of the old C#, completely moving into the territory of “performance by default”, Unity will lose it’s main selling point and the main reason people started using it in the first place. Easy prototyping, high productivity for making smaller games.
I want to remind that maybe 99% of Unity games are simplistic Mobile games that will NEVER have 10000 objects flying around the screen and interacting in a complex way etc. They maybe have 10 characters at most, 50 dynamic objects, some static background - that’s it! More just doesn’t fit to the mobile screen and doesn’t make sense for most types of games with 3 to 5 minute play sessions. I’m all for huge battles and complex visual effects in high-end PC games, but it should not be forced!
IMO, the best way for Unity moving forward (I mean the future, after DOTS is 100% integrated) is to keep focus on normal C# way of coding, with DOTS support being optional for those who actually need it. Also in most games I think both systems should seamlessly coexist. The “hybrid” mode shouldn’t be considered as a temporary solution, a “transition” phase. But a legitimate way of balancing between productivity and scalability of your games in those critical places that actually NEED this “highest possible performance”, NOT in the whole game!
I’d be personally happy if I could use ECS with old Vector3, Quaternions etc. but without all the crap that MonoBehaviors have in their bloated base classes. And occasionally inject some hard-core HPC# Jobs for specific systems like special effects, bullets, etc.
