This should ring a bell for two young programmers who recently revealed their new game engine in these forums.
Who are you calling young, punk?!
No, seriously though, this is a really really interesting topic, and something that most people don't value enough: For the reason that it's decided above their head and they are just presented with the finished API.
I think that there is no silver bullet here, as with so many other things. Both systems have their advantage and disadvantages, for example: A component based design is incredibly flexible with just a few, well defined objects, but it can become really complex really fast. On the other hand, an inheritance based system is less flexible and may end up resulting in awkward inheritance graphs.
This being said, if you just create a game and no general purpose API or engine, you should pick the one that is the easiest to work with in terms of your game. This is whole other level of things to keep in mind, because the requirements to build one specialized game and a general purpose game engine are vastly different. And don't think too much about code re-usage across games: Yes, there is a basic toolset that you will re-use over and over again, but the core game itself will be uniquely tailored and trying to make it as general purpose as possible is just making it more complicated in some extents.
Coming from the other direction, the general purpose game engine, I think a hybrid approach is the way to go. It's also implemented that way in a game engine currently developed by two young programmers. The thing is that components make a lot of sense for things like physics. Being able to attach a rigid body as a component to a scene node is so useful, because otherwise, you would've to provide an extra scene node for rigid bodies. But what happens if you want to inherit other behaviour as well? Diamond shaped inheritance graphs are not common and in most languages impossible. C++ offers virtual inheritance and it really isn't that much of a problem as most people tend to make it out to be, but it makes for even more ridiculous inheritance graphs and it's just a hassle.
Having well defined scene nodes is a good thing though. Take a scene node for water for example: That doesn't need to render an arbitrary mesh or model. It doesn't need to cast light, it's a scene node that renders water. Period. Same with particle emitters, really. It may make sense to attach particles to something else, but this can be done by simply adding the particles as childs to the other scene node, ie, representing their relationship via the scene graph.
To stick with the rigid body/physics example, this isn't that easy to express using a scene node based system. The water for example may want to provide physics behaviour, or the entity may want to have a rigid body. You can't just attach them as child scene nodes, because their relationship can't be expressed that way: Childs are moved through the scene relative to their parents, not the other way around. Here is where a component based system makes the most sense, because you can just attach these things as additional components/attributes to scene nodes.
Here is an example that is going to look a lot like Unity, but it helps to bring the point across:
RN::Entity *entity = ...;
RN::bullet::RigidBody *body = entity->GetAttachment<RN::bullet::RigidBody>();
body->ApplyImpulse(RN::Vector3(10.0f, 0.0, 0.0f));
Instead of applying the impulse directly to the entity, it's applied to the rigid body that's attached to the entity. The entity may be anywhere in the scene graph, it will still work the same way, and it doesn't require an extra subclass. How would that even look like? A rigid body class that inherits from entity? What about cases where you don't want to inherit from entity but still have a rigid body?
The hybrid approach tries to combine the best of both worlds, things where it is an obvious parent -> child relationship (a blood particle effect for example, that's the child of a damaged entity) can be expressed using the scene graph and inheritance, no problem. The other way around, where a child (which isn't really a child but more of a property) affects the parent, that can be expressed using components.
The difference is that scene nodes and childs appear in the scene graph, whereas components are merely additional properties to a given scene node.
Well, those are my 2 cents anyways. Take them as you will
PS: 3333 posts!
