Well i'm doing a whole bunch of research for designing my engine(in c++), making sure i gto a good design and plan before i start putting the pieces together. I came across this:http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy

Component based entity system seems like a good idea, with the down side of not so clear component interaction with each other. I haven't really used anything with a similar design, from what i gather is that the entity doesn't control the life of its components since it uses aggregation. So what does control the life of the component; also they talk about a component manager how does that work?

Try searching the forums. There are lots of threads discussing component systems.

You should be able to find some threads in the forums about this.

Here's a link to get you started though: http://entity-systems.wikidot.com/

In our system, the entities do own the lifetime of the components they aggregate. A factory creates different types of components based on a type id, and the ownership of the components is given to the entities. When the entity dies, it cleans up after its components.

Thanks you very much

I'm already coming up with way to implement the components, so it will be a thing to add down the line; going to keep hierarchies for now.

Thanks you very much
I'm already coming up with way to implement the components, so it will be a thing to add down the line; going to keep hierarchies for now.

Clockwork, there is a good amount of merit to stick to aggregation of a hierarchical approach. It does seem complicated at first and particularly when you're trying to think non-object oriented, it's not an easy approach to grasp, but the beauty of it is that once the foundation is set and is solid, the ease of dropping in new features cannot compare to the level of time and effort you'd have to deal with by implementing it in a typical class hierarchy approach usually.

There are several ways a component-based entity system can be implemented and there isn't a real right way to go about it. A chunk of it boils down to how decoupled you wish to design your code.

Some developers are satisfied with the modular design that aggregation provides that they're ok coupling their components together explicitly. This is done a lot of times by having an entity class that holds a map of components that make up that entity. Then components get another component's interface by calling some templated GetComponent method on the entity and then use the component to obtain properties needed. For example, my renderable component needs to know position, so it gets the transform component from the entity by calling GetComponent<TransformComponent>().

Others would rather not couple their component systems together at all and obfuscate any relationship that would otherwise be visible between them by using a mediator, observer, or combination of both patterns in conjunction with events/callbacks. Often this approach is realized where there is no real "entity" class but rather an identifier for an entity. The components themselves are managed in separate subsystems of the entity system and reference the entity by id. The benefit is that so long as a component or component system handles and/or emits the same events, i can change the internal implementation, to the point of replacing Bullet with PhysX for physics and the remainder of the code remains as-is, no changes and the level of effort is considerably lower than when things begin to be coupled in more traditional programming patterns.

Regardless of either approach, the lifetime of the components is that of the lifetime of the entity unless a component is temporary and added/removed based on game logic events that are triggered in game-play. Typically, once an entity is removed from the world and destroyed, either an event fires that the component systems (in the case of second approach) receive and then deallocate the components to that entity id or the entity's destructor deallocates the components if they're not managed by a subsystem when the entity object is deleted.

Either way, use what works best for you & good luck.