|Original post by Sneftel|
There have always been a few things I didn't like about the component-based model.
* Components have difficulty finding other components in the same Entity. Given an AnimationComponent which requires a PathfindingComponent to use, often it's necessary to manually iterate through the list of Components, dynamic_casting each one until you get a hit, or else to complicate the factory with details of what component needs to know about what, or the Entity with specific typed Component members for direct access.
* Components have difficulty finding the same components in other Entities, and their associated game-wide subsystems. The PathfindingComponent needs to know at least about other Entities' PathfindingComponents, or (more likely) a GameWidePathfindingSystem. The former can require a lot of iteration and dynamic_casting; the latter requires either some pretty serious arrow chains, or singletons/globals.
This isn't anything earth-shattering, but I thought I'd throw it in... We are using a component-based system where logic components publish named attributes, actions, and events, so you don't have to "find" other components, you just have to perform an operation using a name.
For example, if you want to adjust an entity's "speed", you don't have to find the component that publishes it because the entity itself knows how to deal with that:
float speed = entity->GetAttribute("ATT_SPEED");
In our system, attributes kept to a small set of fairly primitive types (strings, vectors, ints, floats, bools, that sort of thing), but you could allow it to pass pointers around so that like components on different entities could locate each other.
We can subscribed to attribute changes...
...or to any published event.
In the system we use, there is actually a database of all published attributes, events, actions, etc., which allows for development tools to bring up lists of published names so that you can see what's available at dev time.
Then there are renderable components which can't publish attributes, but which look for published attributes. So if you wanted a component to draw a HUD, for example, you would need a HUD logic component to keep the details straight, and a renderable component to draw everything, pulling data from the logic component.
It's sort of an MVC component-based architecture.
I am jumping in here late, but a quick comment in response to Sneftel's OP.