|
So first of all, the way the scene is defined in the track description file is independent from how the engine is structured. The engine could be component-based or not at all component based and still use description file layout you proposed. I like the layout you proposed.
About the engine architecture... I think the general idea of the component-based stuff is good, but I don't like the implementation that they commonly use: "Giving each component a common interface means deriving from a base class with virtual functions." My understanding is that component-based architecture means making all components derive from a generic component class, putting all the components into one component manager, and having that update them all in one big generic update. I don't like that at all. In my opinion, making all of your component types derive from a generic component class blurs the lines between the components. Instead, break things out into different components that have their own, unrelated types. Drawables get their own type, and are unrelated to physics bodies which get their own type, etc.
The two arguments for component-based aggregation (as I understand them) are 1) data-driven aggregation and 2) easy updating of all objects.
For 1, I don't think doing the full-on component thing and allowing data-driven aggregation gets you much; I foresee difficulty later on with debugging and understanding code. Instead of defining aggregation in your data, just put it in your code. If it's a car, then make a car type and have it include drawable and body objects.
For 2, I understand that if all bodies need to be updated, you might not want to traverse all of your entity types to see if they have bodies that need to be updated. Instead of going component-based, though, just put all of your physics bodies into a body manager, and have the manager update all bodies. Just keep a reference around inside your entity. I think that's a lot clearer than making all bodies derive from the generic component type and putting all components in a component manager and having that update all components, especially since sometimes the manager needs to do a lot of work that is specific to the type of component it's updating.
Okay, that was a brain dump, I'll stop now.
|
