This is a followup to this question, which I answered, but this one tackles with a much more specific subject.
This answer helped me understand Entity Systems even better than the article.
I've read the (yes, the) article about Entity Systems, and it told me the following:
Entities are just an id and an array of components (the articles says that storing entities in components isn't a good way of doing things, but doesn't provide an alternative).
Components are pieces of data, that indicate what can be done with a certain entity.
Systems are the "methods", they perform manipulation of data on entities.
This seems really practical in many situations, but the part about components being just data classes is bothering me. For example, how could I implement my Vector2D class (Position) in an Entity System?
The Vector2D class holds data: x and y coordinates, but it also has methods, which are crucial to its usefulness and distinguish the class from just a two element array. Example methods are:
rotate(point, r, angle),
normalize(), and all other standard, useful, and absolutely needed methods that positions (which are instances of the Vector2D class) should have.
If the component was just a data holder, it wouldn't be able to have these methods!
One solution that could probably pop up would be to implement them inside systems, but that seems very counter-intuitive. These methods are things that I want to perform now, have them be complete and ready to use. I don't want to wait for the
MovementSystem to read some expensive set of messages that instruct it to perform a calculation on the position of an entity!
And, the article very clearly states that only systems should have any functionality, and the only explanation for that, which I could find, was "to avoid OOP". First of all, I don't understand why should I refrain from using methods in entities and components. The memory overhead is practically the same, and when coupled with systems these should be very easy to implement and combine in interesting ways. The systems, for example, could only provide basic logic to entities/components, which know the implementation themselves. If you ask me - this is basically taking the goodies from both ES and OOP, something that can't be done according to the author of the article, but to me seems like a good practice.
Think about it this way; there are many different types of drawable objects in a game. Plain old images, animations (
getCurrentFrame(), etc), combinations of these primitive types, and all of them could simply provide a
draw() method to the render system, which then doesn't need to care about how the sprite of an entity is implemented, only about the interface (draw) and the position. And then, I would only need an animation system which would call animation-specific methods that have nothing to do with the rendering.
And just one other thing... Is there really an alternative to arrays when it comes to storing components? I see no other place for components to be stored other than arrays inside an Entity class...
Maybe, this is a better approach: store components as simple properties of entities. For example, a position component would be glued to
The only other way would be to have some kind of a strange lookup table inside systems, that references different entities. But that seems very inefficient and more complicated to develop than simply storing components in the entity.