# Component Aggregation

This topic is 2556 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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?

##### Share on other sites
Try searching the forums. There are lots of threads discussing component systems.

##### Share on other sites

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

##### Share on other sites
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.

##### Share on other sites
Hi Clockwork Frog,

There are some really deep discussions on Entity Components like this one. I agree that components are cool for Game Entities. I found myself evolving naturally towards Component-based Entities in writing my umpteenth iteration of a 3D GUI which is now the core for my Game Platform. In fact, I thought I came up with some revolutionary approach to designing GUIs at the time, only to discover after reading ~20 Threads on GameDev.net and some popular Articles on the net the approach has been adopted by Pros for years .

In my opinion, one of the most complicated (foggy) aspect of the concept is working out the inter-communication between components (especially between components that have dependencies on one another). There are very few guidelines on how to implement such communications so I borrowed ideas from my previous GUI development. Looking into Observer Pattern, Signal/Slots, and Delegates could be useful in devising inter-communications for your components.

Although, I'm no expert on components implementation, I would warn anyone using the approach to avoid going overboard on the number of components used, otherwise you end up with a bloat similar to the hierarchy bloat you're trying to avoid in the first place. I've seen other developers create Position Components to simply hold a set of values like a Position Vector3.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
Try searching the forums. There are lots of threads discussing component systems.
Seconded. There are a few interesting threads. I strongly suggest using google's [font="'Courier New"]site:[/font] feature, forum search on gamedev is quite broken.

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633702
• Total Posts
3013450
×