Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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!

share|improve this question
5  
Have you considered component-based design? I think it should solve most of your problems. –  da4c30ff 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. –  da4c30ff 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
add comment

2 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
Josh thank you!!! –  Edward83 Jan 16 '12 at 16:59
add comment

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

share|improve this answer
2  
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
    
Thanks for the link –  Jimmy Jan 16 '12 at 21:13
    
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. –  Daniel Jan 17 '12 at 4:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.