# C++ component model

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

## Recommended Posts

Hey!

I'm thinking about implementing a component based system for my game engine. What I have in mind is a model where different parts of the engine such as graphics and physics is encapsuled in manager classes, and each manager consists of components that handle different parts of these areas. For example the graphics manager would have a render component and so on. The way i see it, a flexible system since it allows you to easily swap out a component and helps break down mastodon classes into parts that are easier to maintain.

Now, i suppose this is quite a common model, but I haven't been able to find that much info on it.

What I'm looking for is how people usually implement this kind of model. More specifically I'm wondering how inter-component dependencies would be handled, as in one component needs to access another component in the same or another manager.

If taken to the extreme, I guess this could result in a pretty deep and wide tree-type structure, and if components need to access a higher / parallell level of the tree that could become tricky. Passing pointers around to components that another component might need seems like a very crude solution that would result in very long lists of pointers.

Any thoughts on the subject will be welcome.

##### Share on other sites
What you probably are looking for is using DLLs to create plug ins. I have used it for some really really basic testing purpose but never really went deep into it. I do however have this, which would most likely help you out a lot: http://3dgep.com/?p=1759

Have fun

##### Share on other sites
I guess this could result in a pretty deep and wide tree-type structure[/quote]

The whole point of component-based systems is to not have tree structures:
vector<PhysicsComponent> physics(1024); // the "manager" vector<LifeComponent> lives(1024); ... void updatePhysics() { // all dependencies are in here, just use whichever system you want for (int i = 0; i < physics.size(); i++) update(physics); // need life components? Just use them here. }

As for container itself:struct Component; typedef std::set<Component *> Container; struct Component { Container * parent; } Parent allows you to update references as needed when individual component lists are removed. There's other ways to do it.

The "manager" functions:template < class T > Component * add(vector<T> & manager, T & component) { if (manager.size() == manager.capacity()) return NULL; // container full, we don't resize manager.push_back(component); return &vector[size()-1]; }Similar for removal.

##### Share on other sites
AgentC on these forums has developed a 3D library, Urho3D, that uses a component model behind the scenes. I've been tinkering with it, and it seems pretty nifty. You might download it and check it out, at least.

Edit: In my own system, I disallow inter-component dependencies, and handle all communication via message passing. An entity does not need to know whether or not it has a FloatingCombatText component; it just sends itself a TookDamage message, and if there is a FloatingCombatText component then it will display a damage number.

In other systems, some form of linkage between components (between Physics and Rendering comes to mind specifically, due to the need to share transforms) might be desirable, but you should absolutely, definitely limit it severely. Nothing good can come of heavily linking your components, as you have surmised.

• 10
• 16
• 14
• 18
• 15