I am learning ECS and the data oriented way of doing stuff and, I came across this blog about ECS.
So I am curious, how you would solve it?
Is Unity ECS suitable for everything?
Is not. At least not yet I terms of Unity.
Regarding blog, please ask specific question (s), you would like to know about. You can reference blog. But blog can be tomorrow offline, rendering your question irrelevant. So please take that into consideration, for future readers.
1 Like
Direct questions about ECS in this forum please: Unity Engine - Unity Discussions if serious about it / actually doing some ECS / DOTS 
(moved it for you)
I actually spent 15 minutes thinking about this - I’ve never personally written any ecs - so take this with a grain of salt, but is there actually a problem in ops design?
Personally, I think I would probably try to cut the “pose transfer system” the “cross entity pose transfer system”, but the article presents this as a problematic design, with the assertion that a monobehaviour driven one would be better.
But looking over this - isn’t this basically identical to what the monobehaviour driven design would look like?
One animation component (pose transfer system is rolled into mecanim’s humanoid rig).
Cloth pose transfer system would be a monobehaviour.
Cloth system, obviously.
Attachment system.
Deformation bone solver.
Like - wouldn’t the mono approach be basically the same?
I think so but only on a conceptual level. What a system does and doesn’t is the same form of encapsulation like OOP but fundamentally it works on a global level unlike OOP which focus is on the individual. This also means that the same encapsulation might not be the best.
Regarding the image, I also think some systems can be merged and I don’t think they are complex. I mean, what is presented as a complicated solution for a simple “updating” an item, is actually a pretty complicated sequence when you have animations and everything. At one point all those calculations have to be done anyway. Making it data oriented can make you think about it on a higher level and easier to make bigger changes. Systems that are linked anyway, can be merged then. Personally I’ve done this several times, often merging 3 systems into one because the steps I’ve introduced in-between were unnecassary.
Thinking about it long term, many of those systems can be reused in other systems and when it works, it works without the problematic sequence order problems that arise with OOP and monobehaviours.
At the end of the day, system programming feels a lot more stable.
OP also raised his concern that this is complicated for designers and it is, when you don’t have an authoring stage. I always build those now and I think it’s pretty cool.
I might not go as far, to say ECS suitable for everything. It’s too broad of a statement, but I think data oriented certainly is.
Is this a good characterization of the data model in ECS?
Having never used it before I could be mistaken, but isn’t it essentially column oriented not row oriented (like OOP tends to be)?
This is pretty typical for a complex animation system. You would also find this level of complexity (actually more) in OOP but in many cases that gets abstracted. In Unity’s case with GameObjects, that is abstracted deep in the C++ backend. ComponentSystemGroups and good project structure can help wrangle the chaos, and there’s probably a few variations that can be made in the data structure and systems, but the general concepts are pretty much spot on.