1
\$\begingroup\$

I want to create a component-based game engine with subsystems which do the work, entities which are simply a list of components (plus position and rotation, because every object will have that), and data.

In addition I want the subsystem to create the components for the entity (the entity has a list of component types and the subsystem creates them). The subsystem has to be notified if an entity is added to the world. I think the best way is the observer pattern: my scene manager notify every subsystem.

This is where I got stuck. When the scene manager notifies, should this be a function pointer or a abstract system class with handle message? In the first case, how can I get this work with a variable count of parameters?

This approach with an abstract class is not my favorite, I think function pointers may be better. Consider this case: my position component will be edited from the position system, so my system or my component have to notify the render system.

Given my above requirements, what should I do to deal with these notifications?

\$\endgroup\$
2
  • 3
    \$\begingroup\$ Please consider looking at the faq for information about how to ask questions here. What you've asked is begging for an extended discussion. \$\endgroup\$
    – user1430
    Commented Jul 25, 2013 at 15:46
  • \$\begingroup\$ I made some attempt to pare down the question into something more reasonably scoped (rather than just close it as too broad). \$\endgroup\$
    – user1430
    Commented Jul 25, 2013 at 16:40

1 Answer 1

1
\$\begingroup\$

Move your initialization logic. The "subsystem" can create a component or register a component, but leaves it uninitialized. Then the code that requested the creation can initialize the component, using the per-component-type initialization methods that understand all the different types. If the subsystem needs an initialized version of the component, have a separate "activate" message you can send after activating the component (or even better, let game objects be active/inactive, and activate all components as necessary after activating the game object - this lets you remove/deactivate an entire object without destroying or deinitializing it, which does come in handy here and there).

So, create the component, register it, initialize it, active, and profit, in that order.

Another approach would be to do one of your suggestions and have messages with "rich" data. A super easy way to accomplish this is to just use Lua tables or the like for your messaging (embedding Lua is C++ is super easy). Another similar way is to pack all your message data into a string of some kind (using XML, JSON, or a custom format) that can then be parsed/unpacked by the subsystem when it creates the component. I'd highly recommend the first approach, though.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .