# Should I use inheritance or composition for modelling game objects?

In terms of game engine modeling, please give your pros and cons for two types of interfacing:

class MySceneObject_Model1 : public IRenderable, public IScriptable, public IAnimatable { ... }

class MySceneObject_Model2
{
protected:
IRenderable* m_ptrRenderable;
IScriptable* m_ptrScriptable;
IAnimatable* m_ptrAnimatable;

public:

IRenderable* GetRenderable();
IScriptalbe* GetScriptalbe();
IAnimatable* GetAnimatable();
}


What if MyObjects have different variations of supported interfaces? For example one of them can be only Scriptable. Some of interfaces could appear in future. Some of them could be very similar to each other: IAnimatableByMorphing, IAnimatableByBones, etc. Some of them can be very close to each other: IRenderable depends on new object's state after IAnimatable's work. I know it is very basic and very wide question, but tell about your experience!

• Have you considered component-based design? I think it should solve most of your problems. – Gerstmann Jan 16 '12 at 13:14
• ExplodingRat, thank you! could you give some link about component-based design? – Edward83 Jan 16 '12 at 14:55
• It's very popular topic these days, even this site has tons of information about it. – Gerstmann Jan 16 '12 at 15:21
• Component-based design is the currently-trendy implementation of composition. Has lots of advantages, and some disadvantages compared against other types of composition. – Trevor Powell Jan 16 '12 at 21:52

It is generally preferable to prefer composition to inheritance. There are many available resources on the subject if you ask Google about it. According to that principle, your second example is better. If you take the first approach you will have to implement IAnimatable (or whatever) in every concrete game object class, and you may not be able to easily re-use that code unless you take an approach that is far more like the second option anyhow. This will, in turn, imply you have many different game-object level classes that exist only to mix-and-match different interface implementations. You could achieve this more easily, more cleanly, and with less code using the second approach and simply configuring an object with the appropriate interface implementation objects.

Your second example is actually a very primitive component-based architecture, one where the available component set is rigid. What Edward83 was suggesting in the comments is probably the (currently very trendy) evolution of that architecture where objects are composed of a dynamic list of components.

In the second example, if an object does not supporting animation or scripting, the respective components would be null or you would install a dummy component that implements the interface but does so with no-op methods.

As a note, you probably should not have "IAnimatableByMorphing" or "IAnimatableByBones" interfaces (as implies by the 'I' prefix), rather those should be concrete classes that implement IAnimatable.

as others have said, prefer composition over inheritance. you may find Refactoring Game Entities with Components to be of interest.

• If others have said it then it's not really worth repeating it, especially as an answer. – Jonathan Connell Jan 16 '12 at 21:05
• Suggest an edit, not answer again with the same thing. – Gustavo Maciel Jan 16 '12 at 23:41
• Could be a link on Joshes answer. – deceleratedcaviar Jan 17 '12 at 4:35