Difference between ECS and ECSY?

Hey guys,

I am writing an academic paper about A Frame. For the explaination of the A Frame’s architecture I want to dive deeper into the difference between the ECS and ECSY framework. In your article, Ferando, you wrote the difference between both frameworks is:

The difference between a pure ECS like Unity DOTS, entt, or Entitas, and a more object oriented approach, such as Unity’s MonoBehaviour or A-Frame’s Components, is that in the latter the components and systems both have logic and data, while with a pure ECS approach components just have data (without logic) and the logic resides in the systems.

But if I compare illustrations of an ECS framework like the one from Kevin Ngo:

Bildschirmfoto 2020-08-06 um 08.15.14

Or that one of the ECSY framework:

They look pretty similar to me. In both frameworks entity can hold components which assign certain properties to the entity. From my understanding, in a ECS framework, components could have a certain logic. For example, I could attach a component to an entity which would move the entity. ECSY tries to avoid this, right? How could I highlight the difference in a illustration?

Thank you very much!

Best regards,

Hi Matthias!

So if you look for the definition of a ECS, usually is (Wikipedia): “Every entity consists of one or more components which contains data or state. Therefore, the behavior of an entity can be changed at runtime by systems that add, remove or mutate components.”

Component will hold just data, and then you will have systems that will iterate queries of entities based on the components or values they have and will implement behaviour in there (logic). So there is a clear separation between data and behaviour, that’s why it’s also called a “data oriented” programming. So to your question difference between the ECS and ECSY framework ECSY, as Unity DOTS for example, both are ECS frameworks as they follow that paradigm.

A-Frame is more aligned with how Unity’s Monobehaviour works: Components have data (defined by its schema) but also logic (init, update, tick, remove, pause, play) and they could, and usually have internal state, like doing something like init() { this.whatever = new Vector3() } to hold a vector3 reference inside to help with calculations or so. So components themselves are not truly stateless and having logic break the rule of the ECS paradigm itself.
Then instead of having systems iterating over list of entities based on queries, you iterate over entities calling their components.tick() method, so you can still have system in A-Frame but they are not really mandatory, you could implement all your logic just on components.
And even so, your systems usually are tied to a specific components. For example if you define a Enemy component, you could have an Enemy system that will hold a reference to all the Enemy entities, but you can’t easily have a list of all the enemies that don’t have a target, or all the enemies that are dead, or so, are you are restricted to one component by default.

If you look at the graph, in both cases you compose the entities with a set of components but in A-Frame the logic is also hold in the components (you don’t really need systems) while in ECS you need systems to add logic and iterate over these entities and components, in the ECSY case by defining queries and calling execute() to loop through them.

So in my opinion defining A-Frame as an ECS is not exactly right, the same as you won’t call that for Unity’s MonoBehaviour (Which also have components and allow composition over inheritance), but more correct definition could be something like Component Based Architecture which doesn’t need to follow the ECS / data oriented paradigm.