Hey everyone,

I've been reading up on the Entity Component System paradigm ( http://www.gamedev.net/topic/643095-good-articles-on-entity-components-systems/ has been very helpful) and I think I understand everything I need to implement it except for one thing:

Where do the components "live"? Getting into implementation specifics, I'll be writing this in C++. So, for the sake of example, let's say I have a position component, a velocity/movement component, and a motion system which acts on both components.

Would it make sense for each entity to have a data member container consisting of pointers to components? If so, how would the motion system keep track of which entities have position and velocity/movement components? Or maybe a better way of phrasing the question is: How does the motion system keep track of which components it needs to iterate over when it runs?

When I look at diagrams and read articles about ECS, everything seems to make sense to me. But when I sit down with a pen and paper and try to map out the class relationships, my level of understanding starts to break down.

Thanks!

Edit: I've thought about this a little bit more, and maybe the a good approach would be to have each system contain a container of pointers to entities that contain a matching set of components. This would mean that every time an entity adds or removes a component, it would have to be examined by each system to determine if it contains the right components to be used by that system. However, this also means that each system doesn't have to go through and check EVERY entity to see if it has the right components in every iteration of the game loop. Thoughts? Am I heading down the wrong path?

The short answer is - different people do it different ways, and they all work

^this.
"ECS" is not as specific as other design patterns. It's a very vague description for hundreds of different designs, with the only common pattern being "components are some kind of structure, entities are groupings of components". That detail alone can be implemented in dozens of ways, and there's dozens of other details that may or may not even exist depending on the overall design, and whether the designer has come from a relational, OO, procedural or functional background, etc...

Different "ECS" systems are also designed around different requirements.
Sometimes the whole point is so that different components can automatically find each other, and send messages to each other without the programmer having to manually bind them (the "entity" is basically a message router and service provider).
Other times the whole point is just to allow entity "templates" to be defined in data (the component connections might be specified in the data files or magic like above), with the ECS basically being a fancy serialization and inversion-of-control library.
Other times the whole point is to decouple different parts of entities so that data can be rearranged into cache-friendly structures and processing can easily be multi-threaded (i.e. a design stemming from performance considerations, to avoid the pitfalls of OOP).

Given this huge range of designs falling under the "ECS" banner, you really have to be able to define what it is that you want your ECS library to achieve and what it's requirements are, before you can evaluate the merits of different design choices.

With that out of the way...

Where do the components "live"? Getting into implementation specifics, I'll be writing this in C++. So, for the sake of example, let's say I have a position component, a velocity/movement component, and a motion system which acts on both components.

Would it make sense for each entity to have a data member container consisting of pointers to components? If so, how would the motion system keep track of which entities have position and velocity/movement components? Or maybe a better way of phrasing the question is: How does the motion system keep track of which components it needs to iterate over when it runs?

I'm not a fan of the automatic binding (entity as message router and service provider) style of ECS, and I personally prefer a style where entity is a component, rather than some first class concept of the pattern. So, I'd KISS and just implement this in 7 lines of code, with the supporting library only being a compacting-pool class (a pool that moves items to always be contiguous, whenever a 'hole' is created through erasing an item) that supports handles (because pointers won't work due to the compaction):

struct Position { Vec3 pos; };
struct Movement { Handle<Position> who; Vec3 velocity; };
void MovementSystemUpdate( const Pool<Movement>& movements, Pool<Position>& positions, float dt )
{
  for( const Movement* m=movements.begin(), *end=movements.end(); m != end; ++m )
    positions[m->who].pos += m->velocity * dt;
}

Bam! "ECS" without the bloat

FWIW, here what i think are the 2 most used options for where the components live, and how they are coupled with entities:

#1, Components simply have an "int EntityOwner" that stores which entity owns them, and entities are simply an unique number.

#2, Entities contain a list of pointers to Component it owns. (something like a std::vector<TComponents> Components member).

How they are accessed is a much larger answer that has been covered.

In my ECS, which is somewhat based off the artemis framework, the components are stored in arrays in the "entity manager". The entity manager also maintains a mapping from entity to indices into these arrays (so that's how we determine which components are associated with a particular entity).

Each system declaratively states which types of components its interested in (e.g. "I require the Aspect and Position components"). Whenever an entity aquires Aspect and Position, the entity's index is automatically added to a list in that system. So each system is always guaranteed to have an up-to-date list of the entities (or rather, indices to the entities) in which it is interested.

In my ECS, which is somewhat based off the artemis framework, the components are stored in arrays in the "entity manager". The entity manager also maintains a mapping from entity to indices into these arrays (so that's how we determine which components are associated with a particular entity).

yes, relational database type thing. this seems the way to go.

i was thinking an array for each component type, and its associated methods, and a list (array) of entities, of course with indices pointing to the other databases.

your method is exactly the way i'd do it myself.

Thanks for all the help/feedback. You guys have given me a lot to think about and consider when designing this.

As far as Hodgman's point that there are different reasons to pursue ECS, I'd have to admit that my reason seems more basic than any of the ones he listed. It simply seems like a nice, clean alternative to rigid inheritiance heirarchies or potentially problematic multiple inheritance situations. Does this seem like a strong enough justification for the system in and of itself?

Also, in light of this fairly general goal, what are the pros and cons of storing the components within entities as opposed to in containers or structures that exist outside of the entities?

I'll keep hackin away and update this thread if more questions surface.