ECS framework

ECS stands for Entity-Component-System. There are several interpretations of this paradigm and this is what URSA thinks it is:

• Entities are mere identifiers for a collection of Components.
• Components only hold data, and simple properties (like converters, getters)
• Systems don't communicate with each other, communicating through components.

Layman explanation in context of Unity:

Unity looks like an ECS, because it has "Entities"(gameObjects) and "Components"(MonoBehaviors), however the way they did it, is far from pure ECS approach. First of all to have a pure Entity, all the components must belong to it, in Unity that is not the case. Unity tends to use a vast amount of GameObjects to represent an entity, if its a player rig, there are a lot of bones that each is a separate entity. This leaves the burden to identify the "root" entity on the developer, forcing him to create special root accessor scripts/controllers that gather references and make sense out of underlying hierarchy.

Thus in Unity there is no native clean way to abstract an arbitrary bunch of GameObjects into an "Entity". Next problem is the mixing of logic(system) and data(component). Unity explicitly teaches developers to encapsulate their code into scripts, however due to locality of those scripts they often end up being very tightly coupled, creating complex dependencies that are hard to maintain. While in some scenarios that is a desirable effect (selling encapsulated asset), in most it is not, and can be avoided by using ECS approach.

In URSA we solve those problems with 3 concepts.

1. Component
2. Entity
3. System Component in URSA, is what you would think of as an ECS component. It is implemented on top of MonoBehavior, and self registers in ComponentPool, allowing systems to easily iterate over them.

In URSA, class Entity act's as an identifier for all of its children GO's, abstracting un