Overriding component behavior

Question

I was thinking of how to implement overriding of behaviors in a component based entity system. A concrete example, an entity has a heath component that can be damaged, healed, killed etc. The entity also has an armor component that limits the amount of damage a character receives.

Has anyone implemented behaviors like this in a component based system before?
How did you do it?

If no one has ever done this before why do you think that is. Is there anything particularly wrong headed about overriding component behaviors?

Below is rough sketch up of how I imagine it would work. Components in an entity are ordered. Those at the front get a chance to service an interface first. I don't detail how that is done, just assume it uses evil dynamic_casts (it doesn't but the end effect is the same without the need for RTTI).

class IHealth
{
public:
   float get_health( void ) const = 0;
   void do_damage( float amount ) = 0;
};

class Health : public Component, public IHealth
{
public:
   void do_damage( float amount )
   {
      m_damage -= amount;
   }
private:
   float m_health;
};

class Armor : public Component, public IHealth
{
public:
   float get_health( void ) const
   {
      return next<IHealth>().get_health();
   }

   void do_damage( float amount )
   {
      next<IHealth>().do_damage( amount / 2 );
  }
};

entity.add( new Health( 100 ) );
entity.add( new Armor() );
assert( entity.get<IHealth>().get_health() == 100 );
entity.get<IHealth>().do_damage( 10 );
assert( entity.get<IHealth>().get_health() == 95 );

Is there anything particularly naive about the way I'm proposing to do this?

Answer 1

I think you're making it a little too complicated, or not complicated enough.

One direction I would suggest would be to break apart getting health and doing damage interfaces.

So maybe as an idea, your Armor component would look like this:

class Armor : public Component, public IDamageReceiver
{
public:
   void do_damage( float amount )
   {
      // just assume that subtract_health isn't used in client code maybe
      this.get<IHealth>().subtract_health( amount / 2 ); 
   }
};

Alternatively (and probably what I would do), you could make your components a little bigger and just have a generic "Entity" base class that your specific types derive from. This would contain the functionality of both health and armor and you could implement specific entities from that.

Answer 2

Your thoughts are in the right place but I think you are trying to take the component system to a level of detail that it does not need. I would say make a component called Health when all you need is straight up health. But if you need a health component that also has armor in it, then make it a CHealthAndArmor component that still fits the API of Health in general so it can be used like any other, but then provide the manner of also changing the armor levels if needed.. If its completely a load time value then there is no need, that's just the internal workings of that particular health component.

Honestly the concerns you are having (from this and your other post) are how fine a level of detail you break components down into. If you ever find yourself inheriting or encapsulating a component within another component, you should reconsider what you are doing. You generally are trying to avoid inheritance like this in component based architectures.

Hope this helps

Answer 3

Your Component stuff is too much OOP. See what I'm doing here:

https://github.com/thelinuxlich/starwarrior_CSharp

And this is the Entity System framework I've ported to C#: https://github.com/thelinuxlich/artemis_CSharp

Answer 4

I use an event driven component system and had this same issue. Basically I subscribe component functions to other component events. For one event I can have x functions subscribed and events are fired in the order they were subscribed. Events also give one parameter which is a dynamic class and passed by reference. All of this means I can create a Stats component and a Health component. I subscribe both to a hurt message but because Stats is subscribed first it'll use the armor stat of the Stat component and modify the damage value that is inside the parameter object. The health component is next in the subscription list and by the time it is called the damage value has already been reduced.

I can't talk up enough the event waynof dealing with components. It really does allow piecing together functionality via components where they don't event know about each other. The user is just setting up the event subscriptions to build up the functionality. Would never look back from this system.