How far do I take Composition?

Question

(Although I'm sure this is a common problem I really don't know what to search for. Composition is the only thing I could come up with.)

I've read over and over that multiple inheritance and subclassing is really, really bad, especially for game entities. If I have three types of motions, five types of guns, and three types of armoring, I don't want to have to make 45 different classes to get all the possible combinations; I'm going to add a motion behavior, gun behavior, and armor behavior to a single generic object. That makes sense.

But how far do I take this?

I can have as many different types of behaviors as I can imagine: DamageBehavior, MotionBehavior, TargetableBehavior, etc. If I add a new class of behaviors then I need to update all the other classes that use them. But what happens when I have functionality that doesn't really fit into one class of behaviors? For example, my armor needs to be damageable but also updateable. And should I be able to have use more than one type of behavior on an entity at a time, such as two motion behaviors?

Can anyone offer any wisdom or point me in the direction of some useful articles?

Thanks!

Answer 1

Inheritance isn't a bad thing per-se, you just shouldn't start using it too far up the hierarchy. I usually mix them.

class Weapon{
    void Attack() = 0;
}
class Sword : public Weapon{
    void Attack(){...}
}
class Gun : public Weapon{
    void Attack(){...}
}

class Player{
Weapon* m_weapon;
Mover* m_mover;
Armor* m_armor;
...

void Update(){
    if(UserHasPressedAttackKey)
        m_weapon->Attack();
    ...
}
}

From there on I think about what else I need. For example, if I need my "behaviors" to be very generic (e.g. an armor that doesn't only mitigate damage but also sends lighning bolts to all nearby enemies every 2 seconds) I think about implementing a messaging system instead.

class LightningArmor : public Armor{
    void OnMessageReceive( Message message ){
         if(message.type == EVERY_2_SECONDS)
              useMassiveLightningAttack();
         else if(message.type == ATTACKED)
              mitigateDamage();
    }
    LightningArmor(){
         ListenToMessage(EVERY_2_SECONDS);
         ListenToMessage(ATTACKED);
    }
}

An event-messaging system allows you to be very generic. As long as you have the events your stuff can basically do everything. But of course it's much more work implementing that than keeping a rather static system like above.

If you need even more power (e.g. having 2 Movers/Weapons) at the same time you can use a container instead

class Player{
    std::vector<Behavior*> m_behaviors;

   ....
}

Instead of specifically calling m_weapon->Attack() you can now let it run solely through event messages. Regarding your question whether it's useful to have 2 Motion behaviors - it might be. For example, a second one could be used to simulate gravity (or any other directional force) by constantly trying to move you down the Y axis.

But the question is whether you really need that. If you're not sure you can always come back later and implement what other things you need.

If you own StarCraft 2 (or a friend does) you might want to look into their Map Editor. Their data portion basically handles everything with behaviors. It nicely shows the advantages and disadvantages - you can do everything with it, it just becomes a lot more complicated than other approaches.