Jump to content
  • Advertisement
Sign in to follow this  
clockfrog

Component Aggregation

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 :angry:.

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!