I was thinking that there could be intermediate steps between the default Game Object API and DOTS and that these GAPS could be filled with game domain solutions like Pooling and Managers. ( link )
Then the idea that one way to facilitation this transition could be converting the data in default Game Objects into entities.
So a Game Object would be a container for entities and systems but provides a backward compatible API that maintains the Monobehaviour API.
With a WYSIWYG entities Editor interface developers could start out with GameObjects then add filters and systems, managers, pooling and multithreading where needed to convert to full DOTS systems where they need performance.
PROS
Easier learning curve between DOTS and Monobehaviour.
Converting from Mono to DOTS could be a lot simpler.
Performance improvements as the Unity game engine can take advantage of the DOTS Entities data within GameObjects.
Interim solutions like managed, pooling and multi-threading only need to fit the underlying data structures.
Potential Garbage collection benefits from DOTS data systems.
WYSIWYG interface that makes development easier and simpler (no need for Conversion).
CONS
Some API changes might need to be added to accommodate faster/cleaner processing of data e.g. entity parameters and system accessible data collections.
Do you think a more cohesive and coherent Unity would make it easier and better to work with than a divided Unity API?
It’s the disparity GAP between using DOTS and GO (GameObjects).
You can take GO code then add to it Pooling, Management, Structures and Multi-threading and gain in performance with each step.
But you would then have to completely strip down your code and data structures and convert them into System and Entities to make the full move over to DOTS.
Is all that work worth the performance boost you get from full DOTS?
And as I have raised here could GameObjects be made up from systems and entities that would mean every step of the performance conversion process takes you closer to raw DOTS code. Removing the need for converters and potentially allowing for faster and cleaner hybrid implementations.
In addition filling the API gaps would ensure that any Asset store systems would be more likely to be compatible and improvable as they would be built within a more Unified API with less ad hoc GAP filler code needed.
Transforms already have two-way coupling (although work could be done to match the hierarchies, but this is doable yourself if you really need it).
The other GameObject components that get converted into ECS representations come in additional packages you don’t have to use (you just use the MonoBehaviour implementations instead). So I would say you can already do this today.
My point is that very few built-in components have ECS representations written by Unity. For everything else, you just use hybrid components. If you already need the API surface of Renderer, then there’s no point using Hybrid Renderer instead of just using hybrid MeshRenderer components (the API surface loses all the performance gains that Hybrid Renderer offers). Similar things could probably be said for physics, animation, and all the other high-level functions that have WIP ECS equivalents.
So if you decide you want to migrate to ECS incrementally, you start by using just Entities and use hybrid components for everything other than custom ECS code. This requires two custom pieces of code that Unity hasn’t provided. The first is the hierarchy synchronization. The second is the mechanism that makes hybrid components out of everything that isn’t ECS native using a component blacklist.
For the hierarchy piece, the implementation would have heavy performance impacts you don’t want to pay for if you don’t need the hierarchy sync. The hybrid conversion piece probably hasn’t come yet because the team that would do that is prioritizing root scene conversion. And for both they probably aren’t comfortable supporting such another API surface so early.
However, if enough people request it, I could add these two pieces to a later version of my framework. I’m not bound by the same rules and processes as Unity.
The idea here is for Unity to adopt this so that it becomes compatible with all assets and frameworks people make.
One of the problems I am trying to resolve is the gaps in the Unity API and between DOTS and GameObjects that create issues where every asset/tutorial or framework needs it’s own bespoke code to fill those gaps and creates compatibility issues for developers and maintenance support issues for creators.
