This is what I have been trying to say.
And this is why I said the GameFramework would have to be rebuilt 
Considering how Unity’s ECS is a completely alien entity (ha!) to GameObjects and MonoBehavior components, yeah, an “Unreal ECS” too would have little to do with the GameFramework to get 100% efficiency. You could reduce the overhead of dealing with individual StaticMesh representations of your entities by using ISMs, HISMs, or even feeding the data into Niagara.
“What about animated characters”? AFAIK Unity doesn’t quite have that yet. There’s a package that can bake animation into textures and materials that can play those back, for instanced skinned characters but it’s far more limited than Mecanim due to the nature of the technique.
BTW I have plans to code an “hybrid ECS-ish” framework for some upcoming projects, but the use case is to serve as a basis for rollback netcode, so it would still piggyback on the GameFramework to display the simulation results because the goal is being able to run the simulation 8x per frame (to support rollback) but only “display” it once.
That is really big deal if the game is 3D.
For a 2D engine it’s absurdly easier converting to ECS.
If you plan to make your own, this lady also has interesting points to share:
Yeah, Rust is temping, but I’ll pass for now. It’s too new, and I have no desire to deal with the funsies of compiling anything exotic on PS4, XB1 and Switch.
My main focus is finding the sweet spot between:
- Making it hard to break determinism
- Usability for designers
- Performance
Prioritized in that order. The rough plan is:
- Use blueprints with nativization. BP allows enforcing tight restrictions by using contexts and metadata, so I can limit the functions that can be called. This helps with #1 and #2.
- Simulation functions receive the previous frame entity state struct and must output the new state. No dealing with UObjects, no mutable state. This allows me to update entities in parallel (#2) without breaking determinism (#1). State is basically component data as in ECS, can be stored in arrays and will make it easier to do rollbacks, since I can just keep the states from previous frames around.
- Use message passing for interaction between entities. Simulation function posts messages, which are then read by the recipients at the appropriate time deterministically. Some work will need to be done here to keep delays from creeping in (messages being received 1 frame late).
- Every frame the current state of all entities is “rendered” using standard components/actors. This separation eases the burden during rollbacks, as it only ever happens once per frame even if the rollback caused multiple re-simulations, and enables running the simulation at a fixed time step while the “display” actors/components show interpolated data.
If I can get all of that working without any engine modifications, I might put it up on the marketplace.
We have actually implemented the data-driven framework which is basically ECS, the “Unrealian” way. It supports both C++ and Blueprint workflows. It’s available on the Marketplace, but since the link can be rightfully treated as a advertisement, I will just elaborate on our approach.
Like in ECS our approach separates the data and the code, relating to that data. We then implemented a sophisticated custom node type that could iterate over Entities of a matching type, while altering and processing, adding or removing the Components.
The Components managing and storing is a whole another story as we cache and look-up things to the maximum. We also have some basic memory management that is fully compatible with Unreal Engine’s GC which was quite important to us from the ground up.
Please post the link. If posting Unreal Marketplace link to Data Driven framework for Unreal Engine is not appropriate on Unreal Engine forum in a thread about data driven frameworks, then I don’t know what is This could not be more on-topic
I’ll be most glad to and hope it won’t get flagged: Apparatus in Code Plugins - UE Marketplace
Any more questions, and I’ll be glad to answer them and maybe even share some technical design details if you’d like.