Entity System - Storing components in a Manager vs. in Entity

Question

Like many aspiring designers and programmers out there, I've stumbled upon the Entity/Component System design, including various excellent articles on the subject and a few working implementations as well. And I, like many others, have taken it upon myself to implement such a system.

Conceptually an Entity is a bag of components, which are nothing more than bags of data to be handled by a series of Systems. So it would seem logical to me that an Entity object could be used to hold all components associated with it, but others' work says otherwise. Across all of my research it seems almost universally understood that an Entity is nothing more than an ID and that you must avoid at all costs falling into the trap of Object Oriented thinking. They suggest storing the components in a manager instead, but without directly addressing the advantages of such a design.

Don't both designs, components held in the entity vs. in the manager result in the same end result? Please let me know if I'm misunderstanding / missing something.

Answer 1

I am in no way an expert with Entity Component Systems, but here is my view on the subject from what I have read.

I think that you should never access components directly. If you do, then your components begin to rely one another, and later, when you decide that you want to change how one component behaves, all of the other components relying on the one you want to change now have to be fixed.

To avoid this problem, components should not know anything about each other. They each have one job and should only focus on that job. If some data is needed from another component (for example, you may need positional data), you should either ask another system for the data, or develop a messaging system.

Of course, once you actually start coding, it is hard to comply with this rule 100% of the time, but you get the idea.

Another reason to avoid storing components in an entity is for speed. When components are contained in systems (where all the like-components are stored together), you can process large amounts of components quickly. You have a chance to setup any data they may be reused, loop through and process each component, and then release any reused data. Not only this, but each system may (should) be able to run on a separate thread, which allows you to easily take advantage of multiple cores.

Again, in practice, this isn't always 100% true, but that is the theory of it.

In summary, keeping components in systems rather than in the entity reduces the temptation of directly accessing components, and allows for bulk updates in systems. I hope this helps, and if you have any questions, please let me know.