I saw the Java Artemis Entity Component System and thought of the entity system in Unity3D.
In Artemis for example you can only add one component type to each entity and the logic is not in the component.
In Unity3D it's completely different. Can someone explain me how the entity system in unity 3d works?
I mean, is Unity3D a real entity system, or is it something else?
Yes, it's still an entity system. There's no strict definition for how an entity system should work, so it's OK that it's different from Artemis. Both still have entities that are composed of components.
The goal of an entity system is to move away from inheritance based designs. Unity's system accomplishes this goal.
Similar to Artemis, you can add components to an entity to make a new object. Changing the data in the components can, on a surface level, drastically change the object produced. Some key differences are where the logic is stored, and how components are grouped for processing. While these differences might seem dramatic, they're not too different. Both approaches can be modified to be even more similar. For example, you could create components with just data in Unity, and create "system" that finds all the game objects with specific components and processes them.
Either way, you're going to have components and entities. Where the entities are not derived from a long list of inherited classes. This reduces code duplication, trims out unnecessary code and data and gives you an easy way to think about how objects are created.
Unity3D works on top of GameObject-Component model. It's so much different than Entity Component Systems. To my experience it's worse because when you want to code some logic it's put into Script Component, instead of Systems. How different is it to OOP model? Unity3D GameObject contains data and logic - same as in OOP, those components aren't reusable (which is one of reasons for not doing OOP). Of course, you can make some bulletproof conventions which will hold you from mixing data and logic but it might be a pretty hard work to do so continously.
Dependencies. When you work in ECS, every System has an Aspect (it's described which components it manages). Thanks to the Aspect your Components are depended by System and not by other Components. I've seen code where few Components were referencing to each other. When order of execution wasn't set properly, then... total mess. When you refactor Component (logic) dependencies it's better to do it in ONE place, like System, instead of few places (Components).
The another great disadvantage of model used in Unity3D is a problem to manage objects of same Aspect (set of components). In my opinion it is best to go ECS way if possible or something more closer to it. To take that approach in Unity3D, look at @Byte56 answer.
Although definitions can vary, I wouldn't define Unity3D as an Entity System engine. When we talk about Entity System, we should follow the Adam Martin definition.
According his idea, the Systems should be created by the programmer, while in Unity3D the "systems" are predefined in the engine and cannot be extended.
This is an old way to manage Entities and Components, it's more an evolution of the ancient technique where game objects were holding pointers to components compatible with the engine functionalities (like rendering, culling and so on).
Of course when is not possible to extend the "Systems" functionalities, the only way to extend the logic of our entities is to add logic inside Components. This is anyway a step forward from the classic OOP techniques. Component Oriented (I call them Entity Component, without System) frameworks like the one in Unity, push the coder to favor Composition over Inheritance, which is surely a better practice.
All the logic in Unity should be written inside focused MonoBehaviour. Every MonoBehaviour should have just one functionality, or responsibility, and they shouldn't operate outside the GameObject itself. They should be written with modularity in mind, in such a way they can be reused independently on several GameObjects. Monobehaviours also hold Data and their design obviously follows the basic concepts of OOP.
Modern design tends instead to separate data from logic. See for example the MVC or MVP patterns. Data, Views and Logic should be separated to achieve a better code modularity.
The real problem with the Unity Entity Component design is about the complexity needed to put two entities in communication in a reasonable way that doesn't lead to the use of various anti-patterns.
Unity inverts the control of the creation of entities, thus the coder doesn't have any control on the creation of them. Inverting the creation control is a good thing, but Unity doesn't do it in a proper way. Not being able to inject dependencies in Entities is a limitation that forces coders to use anti-patterns in order to overcome all the intrinsics consequences.
Eventually the cleanest option available is to use Singletons in order to share information between entities.
That's why is quite hard to manage and maintain big projects with Unity. I wrote a lot about these problematics in my blog. So if you want you can continue reading my thoughts there:
http://www.sebaslab.com/ioc-container-for-unity3d-part-1/
http://www.sebaslab.com/ioc-container-for-unity3d-part-2/
http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/
http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/
http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/
In these posts I extensively discuss about the Unity3D design flaws that hinder the development of big projects and both IoC container and Entity Component System framework as possible solutions.
