Entitas to Unity ECS

Hi,

I use/used Entitas (https://github.com/sschmid/Entitas-CSharp) in my recent projects and wondered if anyone has experience "porting" existing Entitas Projects to Unity ECS?

 

I know there are some people here already, with entitas previous experience. However, since I don't known entitias itself not sure how much difference is there. But don't expect any automatic porting tools at this point. At least not yet.

However, shouldn't be that hard, if you already familiar with DOD.

 

I don't expect any tools. Just basic knowledge. I have "nearly" zero experience with UECS, so I was wondering if somebody has an example port of a simple project.

Like if you use an Entitas System X with Components Y and Z it looks like this in UECS or how to port Entitas Reactive Systems.

Concept wise I suppose everything is very similar, in the end, it all is Components, Entities, and Systems.

 

I think for particular porting examples, you need wait for replay, from these people using both systems.

Otherwise, You would need investigate your own way.
Just be patient. Somebody surely will come by, to assist.

 

I am also wondering how to make ReactiveSystems in Unity ECS. I was expecting that it would be some class like ComponentSystem... From what I see - there is totally no such thing, because all of the systems examples are working OnUpdate. IDK how to make normal game without system that would launch directly on some component change.

Here is a good topic https://forum.unity.com/threads/statecomponent-reactive-system.534122/

All I can say from now - it all looks like unity team has a task to make some "high performant" API for ECS and they are not going to sacrifice any minor amount of performance to make API normal for unskilled people. That will attract big companies, but won't be easy to understand for some "middle" developers. Also all that will lead to a messy, hard writable/readable (but again - PERFORMANT) code. So from what I see now - individual developers will just stay on classic unity/Entitas or Entitas team will make some adeqate wrapper for all that trash that unity team does now.

IMO all that archetypes, sharedcomponents, statecomponents - all of that makes production last twice longer, it is not a solution for small teams.

 

Wrong. While for ECS current priority is performance, stability and consistency, debugging and standard editor UI is also planned, on top what we have already.
Look for example Tiny Project.

I am just hobbyist self thought and I am using ECS right now. Is NOT beyond reach whatsoever. For more, I contacted myself for the first time with C#, just few years back, with no any particular skill in C or C++.

Actually is opposite round. ECS makes nice and easy to read, understand and scale any size of project. Plus great re-usability of systems.

If you have nothing constructive to add, just please stay out of the topic. Go for a walk, or something.

 

I'll have to defend Unity here. Their ECS is so beautiful. You're just bitter you don't know how to use it. It's hard, yes, but it only takes some practice. Any good programmer will try to adapt to it, not bash it.

 

I would love if we all could go back to the topic at hand
I will try to come up with a simple conversion myself in the next couple of days. If anyone else has something to say on topic feel free to add your knowledge

 

Comparing Introduction to Entitas with Unity ECS concepts should help get you started. I'm by no means an expert on either but here is a very brief comparison of the overall concepts:

Entitas vs Unity ECS

• Context = World.
• Class IComponent = Struct IComponentData (Jobs & Burst) or MonoBehaviour (data only).
  
• Group = ComponentGroup.
• Collector = nothing, use reactive systems instead.
• IExecuteSystem = Job/ComponentSystem with Execute/OnUpdate.
  
• IInitializeSystem = Job/ComponentSystem manually executed at start.
  
• ICleanupSystem = Job/ComponentSystem using [UpdateAfter()].
  
• ReactiveSystem = Job/ComponentSystem using [ChangedFilter] and/or ISystemStateComponentData.

Please note that some of this might not be accurate as this list was made mostly from memory. Entitas has also probably changed a lot since I last used it. The rest of the features are probably too different to make a simple comparison anyway. Systems in particular are hard to compare because Unity uses a totally different approach, especially for reactive ones.

I've actually wanted to make a Unity example project that uses both classic, Unity ECS, Entitas and Svelto.ECS for comparison. So people can see each one's advantages and disadvantages, but I'm only one man! So there is only so much I can do in a day.

 

I may be wrong, but does not meant to be JobComponentSystem rather ComponentSystem?

 

@Antypodish Could be either, was just keeping the comparison simple but I'll add that too. Thanks.

 

Wow! That gives great insught.
I try to get a simple example working thanks!

 

Huge cons is that Gameobject is not an Entity...

 

@sebas77

 

Hello,

Thanks for the mention. @IsaiahKelly you are not the only one who wants to do some comparison.if you join the svelto discord channel, there is another person that is planning it. For hybrid approach the comparison is fair. For pure ecs approach svelto ecs 2.9 didn't support burst. It's something I am wrapping up with svelto ecs 3.0. Also the documentation is not great so the real support comes from the discord channel.

 

The Unity ECS authoring system can now automatically convert GameObjects to pure Entities at run-time, but not all components can be converted at the moment, so you still need to use GameObjects in some cases. But this is still a huge improvement and pure entities can already be used for most critical areas already.

 

I was just wondering if there's an update on this as I'm considering both Entitas and Unity ECS.

 

That's actually the biggest problem; Entitas is based heavily on structural changes, and reactions to these.

And no, ReactiveSystem cannot be mimicked by [ChangedFilter], because the latter will run the Job on the entire chunk, not on individual entities.

That means most Entitas code requires a full rewrite; and many of its idiosyncrasies don't translate at all. For example, in Entitas, structural changes are free and instantaneous, in DOTS, they are expensive and deferred (if Entitas had EntityCommandBufferSystems, that would be the best of both worlds).

Furthermore, in Entitas, all memory for IComponents and Entities appears to be pre-allocated - that's also one of its drawbacks, but in reality it almost never matters; and it is a good way to get around GC; though I still don't quite understand how the integrity of groups can be guaranteed in real time as it is - because sometimes, it isn't?

I really liked Entitas (while it was still being developed), even shipped games with it, but its turning into a complete dead end. Its heavy reliance on structural changes as triggers for systems actually hinders it in comparison to others ECS like Legion, Actors, or DOTS.

Its Event semantic to communicate Entity state to GameObjects was ill-conceived and provided very little real world applications other than in the most primitive data binding scenarios (so. much. BOILERPLATE!!!) Conversely, this is also something that doesn't work that way at all in Unity DOTS, where you generally seem to be encouraged to poll entity state from Monobehaviours, something which with Entitas we usually ended up doing, too; or writing elaborate presenter systems, which moves view code into your model to cut down on the number of Monobehaviours.

That said, despite the convenience and clean syntax, the code generation in Entitas has always been clunky and brittle, even with or especially with Jenny, and System boilerplate was much too verbose. (almost as bad as with DOTS, but Entities 0.8 might actually alleviate this, praise Roslyn)

The only thing that Entitas got absolutely 100% right was the way Features and Systems were easily grouped, easily toggled, and absolutely deterministic in their order of execution. I can totally see how that's not possible if you want parallel processing to happen like in DOTS, but dependency and execution order management between systems has been the most aggravating experience about DOTS for me, by far. I can't even toggle a system off and on without getting errors because of how dependencies are set up.

 

This is interesting. I simultaneously relate to your frustration and disagree with your point.

• Unity.Entities system ordering is
  • deterministic - he same exact collection of systems by default always execute in the same order on all platforms
  • groupable - ComponentSystemGroup exists
• Unity.Entities system ordering is not
  • stable - the relative ordering of systems when a new system is added changes
  • intuitively predictable - you have no idea what the final system ordering will be just from looking at the code
  • regroupable - systems choose what groups they are in, rather than groups choosing what systems they contain, which makes regrouping paradigms or alternate loop orders difficult to achieve.

I'm not familiar enough with Entitas, but is this closer to what you are looking for? https://github.com/Dreaming381/Latios-Framework/blob/master/Documentation~/Core/Super Systems.md

Regarding errors with dependencies, that almost certainly suggests a mishandling of JobHandles on your part. I have copied an entire game's worth of systems into another game, disabled some of the copied systems, and used the copied simulation as an environment background for a game with completely different core gameplay. I didn't touch anything related to dependencies. It just worked.

 

I have many problems with having not only to specify UpdateAfter or Before, but must also painstakingly enumerate all Input and Output dependencies for every Scheduled job.

I'd really expect at least s tiny bit of automation here, but it just doesn't work.

Otherwise for whatever reason, Unity seems to assume the systems want to execute indefinitely across frame boundaries, even at zero loads. Intuitively, I would expect every system in a Group to finish before the Group updates again unless is very explicitly state otherwise.

In Entitas, when a Feature ('group') is done updating, the next Feature updates.

In DOTS, any given system in a group with a .Schedule()d Job appears to run indefinitely by default (that's a theoretical indefinite - all this causes is subsequent systems throwing errors trying to access Native arrays used by the previous one)

Maybe I'm doing it wrong but it's a nightmare to write Physics systems and I spend half my time splicing dependencies.

 

It runs, if matches the query, has key attribute set to allwaysUpdate, or you execute system manually.
Then it runs, as long system jobs are require to run, until is done.
I don't know if you make them static, share across systems, or otherwise, but if you start having problem with NativeArrays across multiple systems, seems you doing something wrong.

 

Execution Order and Inputs (dependencies) are two completely independent things. You cannot derive one from the other. Inputs are for the job system, and when used correctly, the execution is logically equivalent to all the jobs running sequentially on the main thread. If specifying the inputs is tedious, don't use the job system. Use .Run() for everything. If Unity.Physics and Netcode are biting you, that's a different story, and has nothing to do with the implementation of Unity.Entities.

Jobs scheduled by SystemA are completed right before the next time the same instance of SystemA has its OnUpdate called on the main thread. That's assuming nothing else completes the job first.

That's an issue with how NativeContainer's dependencies are being handled with respect to JobHandles on your end. In other words, that's a bug in your code.

Is this Unity.Physics? If so, I have also found it extremely frustrating to work with. While my opinions of it seem to be against the general consensus on these forums, if you are willing to entertain the thought of an alternate physics solution, feel free to PM me.