Sign in to follow this  

Component manager design

This topic is 2386 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

I'm working on writing a component based entity system and I came to a point where I can't decide what to do. Should the component be passed a pointer to it's owner in the constructor like this?

[code]

class IComponent

{

public:

IComponent(GameObject* owner);

//etc...

}

[/code]

Or should it have the game object passed in each function like this?

[code]

class IComponent

{

public:

void update(float dt, GameObject owner);

void init(GameObject owner);

void destroy(GameObject owner);

}

[/code]

The advantage of the first way is that it's easier to just create a whole bunch of components and forget about it. But the second way prevents you from having to duplicate components because the game objects would all have pointers to the same component. I think the second way will be more efficient, is there a better way that anyone can think of?




Share this post


Link to post
Share on other sites
A few things to think about - why do you need a base [font="Courier New"]IComponent[/font] class? Why do components need to know which [font="Courier New"]GameObject[/font] they belong to?
A whole lot of problems seem to go away if the answers to those questions are "[i]you don't[/i]".


If components [i]do [/i]need to know about [font="Courier New"]GameObject[/font]s for any reason, I'd go with the second option assuming it's feasible for the caller to have knowledge of the links instead of storing the links in the components (e.g. if the caller is the [font="'Courier New"]GameObject[/font]).

Share this post


Link to post
Share on other sites
As much as I'd love to have components NOT know about their "owner", it is incredibly difficult to do it that way. I've managed to get mine so components don't need to know about other components but knowing about the parent always seems to be stuck there. My access to the parent is usually just getting its ID or somehting very basic.

I'd either pass the parent in in the constructor or - I have OnJoin/OnLeave methods for when a component is added to or removed from a "container". I pass in a pointer to the container (parent) in each.

Share this post


Link to post
Share on other sites
I'm having good success using Components as 'dumb' data objects with only default and copy constructors defined where necessary.


I only add parent or child references when needed as a member of the specific Component struct.

I don't derive from a Component base class but instead pair each component with 1) an enum and 2) a bitmask identifier to handle general collections and storage of Components.
That and a few templated functions.

I've also found function typedefs to be really useful for Do/DrawAll/Active type functions and even templated function typedefs are not too ugly to implement as a templated class.

Share this post


Link to post
Share on other sites
I do not have the answer to your question but this is the best article I ever found on component based game design:
[url="http://gameprogrammingpatterns.com/component.html"]http://gameprogrammingpatterns.com/component.html[/url]

When deciding how to use use pointers wouldn't the most important questions to answer be:
[b]How will communication between components work?[/b]
(Because in reality the componets will need to communicate with other components as well as the entity they belong to even if this shouldn't be necessary in the best of worlds.)

and
[b]Will you maintain some sort of index / structure of arrays?[/b]
The article mentions a structure of arrays pattern and there will be even more pointers involved there.

I suggest the following (possibly insane) "Gang of Four strategy pattern" approach because I use it in javascript programming:
* The entity contains pointers to it's components.
* The components only contains state and no logic.
* The components does NOT have a pointer to the entity they belong to.
* The logic is executed by subsystems.
* A subsystems handles all entities which has a certain component type and you use an index aka strucuture of arrays to be able to find those entities fast.
Read more on that approach in my article here: [url="http://jsteam.org/component-based-entities/"]http://jsteam.org/component-based-entities/[/url]
Would such an approach work in C++?

If you decide to not use a "Gang of Four strategy pattern" approach and keep the logic as well as the state in the component you could do it like this:
* The entity contains pointers to it's components.
* The component contains a pointer to the entity it belongs to.
* The components contains both state and logic.
* Use one of the many suggestions for communication between components mentioned in this article: [url="http://gameprogrammingpatterns.com/component.html"]http://gameprogrammingpatterns.com/component.html[/url]
* You have index aka strucuture of arrays to be able to find all components of a certain type fast.

Share this post


Link to post
Share on other sites
Actually, I've already implemented it. I let components access other components through the parent entity. The parent entity contains the unique data and settings that the components use. So the parent entity can contain hit points, or strength, or speed. Any data/settings the components need; all managed through a property class.

Share this post


Link to post
Share on other sites

This topic is 2386 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this