The component based game programming paradigm is becoming much more popular. I was wondering, are there any projects out there that offer a reusable component framework? In any language, I guess I don't care about that. It's not for my own project, I'm just curious.
Specifically I mean are there projects that include a base Entity class, a base Component class, and maybe some standard components? It would then be much easier starting a game if you didn't want to reinvent the wheel, or maybe you want a GraphicsComponent that does sprites with Direct3D, but you figure it's already been done a dozen times.
A quick Googling turns up Rusher. Has anyone heard of this / does anyone use it? If there are no popular ones, then why not? Is it too difficult to make something like this reusable, and they need heavy customization? In my own implementation I found a lot of boilerplate that could be shoved into a framework.
Answer
If there are no popular ones, then why not?
Because there is nothing resembling a consensus on how such a framework would operate.
On a thread on Gamedev.net I determined that when people talk about component-based game systems there are actually at least 8 possible permutations of how they expect them to work, based on 3 different factors:
Inboard vs. outboard - should components be aggregated into an entity, or should they be part of a subsystem and only associated by an entity ID?
Static vs. dynamic composition - should entities consist of a known set of components (eg. 1 Physics, 1 Animation, 1 AI, etc) that can communicate in code via well-known interfaces, or can entities have arbitrary quantities of components added to them (with associated strategies for locating other components of interest)
Data on component vs data on entity - Should data be held by the component that primarily operates upon it? Or should data be stored on the entity in a shared space, accessible by all components?
Beyond that there are further questions over how the components should communicate (via the shared data? Via function pointers? Via signals/slots? Or not at all?), how they should update (in a fixed order based on component type? a per-entity order defined at creation time? based on a topological sort of component interdependencies?), etc.
Each of these choices are completely arbitrary, and anything you can do with one system can be done with the other. But the way in which you have to code it is quite different in each case. And people seem to have strong opinions over which way works best for them.
Right now people are still too caught up in the idea that components are somehow a replacement for object orientation (which they're not) and also imagining that they're a massive change from how games were traditionally made (which again, they were not - people have factored out the various subsystems in their entities for ages), so there's a lot of hyperbole and not much agreement. Maybe in a few years things will have settled down and people will settle on one or two fairly standard approaches.
No comments:
Post a Comment