Doing powerups in a component-based system

Question

I'm just starting really getting my head around component based design. I don't know what the "right" way to do this is.

Here's the scenario. The player can equip a shield. The the shield is drawn as bubble around the player, it has a separate collision shape, and reduces the damage the player receives from area effects.

How is such a shield architected in a component based game?

Where I get confused is that the shield obviously has three components associated with it.

• Damage reduction / filtering
• A sprite
• A collider.

To make it worse different shield variations could have even more behaviors, all of which could be components:

• boost player maximum health
• health regen
• projectile deflection
• etc

---

1. Am I overthinking this? Should the shield just be a super component?
   I really think this is wrong answer. So if you think this is the way to go please explain.

2. Should the shield be its own entity that tracks the location of the player?
   That might make it hard to implement the damage filtering. It also kinda blurs the lines between attached components and entities.

3. Should the shield be a component that houses other components?
   I've never seen or heard of anything like this, but maybe it's common and I'm just not deep enough yet.

4. Should the shield just be a set of components that get added to the player?
   Possibly with an extra component to manage the others, e.g. so they can all be removed as a group. (accidentally leave behind the damage reduction component, now that would be fun).

5. Something else that's obvious to someone with more component experience?

Answer 1

Should the shield be its own entity that tracks the location of the player? That might make it hard to implement the damage filtering. It also kinda blurs the lines between attached components and entities.

Edit: I think there's not enough "autonomous behaviour" for a separated entity. In this specific case, a shield follows the target, works for the target and does not outlive the target. While I tend to agree that there's nothing wrong with the concept of a "shield object", in this case we're dealing with behaviour, which fits just fine in a component. But I'm also an advocate of purely logical entities (as opposed to full-blown entity systems in which you can find Transform and Rendering components).

Should the shield be a component that houses other components? I've never seen or heard of anything like this, but maybe it's common and I'm just not deep enough yet.

See it in a different perspective; adding a component adds other components as well, and upon removal, the additional components are gone too.

Should the shield just be a set of components that get added to the player? Possibly with an extra component to manage the others, e.g. so they can all be removed as a group. (accidentally leave behind the damage reduction component, now that would be fun).

This could be a solution, it would promote reuse, however it is also more error prone (for the issue you mentioned, for instance). It's not necessarily bad. You might find out new spell combinations with trial and error :)

Something else that's obvious to someone with more component experience?

I'm going to elaborate a bit.

I believe you noticed how some components should take priority no matter when they've been added to an entity (this would answer your other question as well).

I'm also going to assume we're using message-based communication (for the sake of discussion, it's just an abstraction over a method call for the moment).

Whenever a shield component is "installed", shield component message handlers are chained with a specific (higher) order.

Handler Stage    Handler Level     Handler Priority
In               Pre               System High
Out              Invariant         High
                 Post              AboveNormal
                                   Normal
                                   BelowNormal
                                   Low
                                   System Low

In - incoming messages
Out - outgoing messages
Index = ((int)Level | (int)Priority)

The "stats" component installs a "damage" message handler at the In/Invariant/Normal index. Every time a "damage" message is received, decrease the HP by its "value" amount.

Fairly standard behaviour (put in some natural damage resistance and / or racial traits, whatever).

The shield component installs a "damage" message handler at the In/Pre/High index.

Every time a "damage" message is received, deplete the shield energy and substract
the shield energy from the damage value, so that the damage down the message
handler pipeline is reduced.

damage -> stats
    stats
        stats.hp -= damage.value

damage -> shield -> stats
    shield
        if(shield.energy) {
            remove_me();
            return;
        }
        damage.value -= shield.energyquantum
        shield.energy -= shield.energyquantum;

     stats
        stats.hp -= damage.value

You can see this is pretty flexible, albeit it would require careful planning when designing component interaction, as you're going to have to determine in which part of the message handling pipeline component message event handlers are installed.

Makes sense? Let me know if I can add more detail.

Edit: regarding multiple component instances (two armour components). You can either keep track of the total instance count in just one entity instance (this kills per-component state, however) and just keep adding message event handlers, or make sure your component containers allow for duplicate component types in advance.

Answer 2

1) Am I overthinking this? Should the shield just be a super component?

Maybe, depends on how reusable you want your code to be and if it makes sense.

2) Should the shield be its own entity that tracks the location of the player?

Not unless this shield is some sort of creature that can walk around independently at some stage.

3) Should the shield be a component that houses other components?

This sounds a lot like entity, so the answer is no.

4) Should the shield just be a set of components that get added to the player?

It is likely.

"Damage reduction / filtering"

• core shield component functionality.

"A sprite"

• is there a reason you cannot add another SpriteComponent to your character entity (in other words more than one component of certain type per entity)?

"A collider"

• are you sure you need another one? This depends on your physics engine. Can you send a message to character entity's ColliderComponent and ask it to change shape?

"Boost player maximum health, health regen, projectile deflection etc."

• other artifacts might be able to do this (swords, boots, rings, spells/potions/visiting shrines etc.) so these should be components.

Answer 3

A shield, as a physical entity, is no different from any other physical entity, e.g. a drone which circles around you (and which in fact, could itself be a type of shield!). So make the shield a separate logical entity (thus allowing it to hold its own components).

Give your shield a couple of components: a Physical/Spatial component to represent it's collision form, and a DamageAffector component which holds a reference to some entity to whom it will apply increased or reduced damage (eg. your player character) every time the entity holding the DamageAffector takes damage. Thus your player is taking damage "by proxy".

Set the shield entity's position to the player's position every tick. (Write a reusable component class that does this: write once, use many times.)

You will need to create the shield entity, eg. on collecting a powerup. I use a generic concept called an Emitter, which is a type of entity component that spawns new entities (usually through the use of an EntityFactory which it references). Where you decide to locate the emitter is up to you -- eg. put it on a powerup and have it trigger as the powerup is collected.

---

Should the shield be its own entity that tracks the location of the player? That might make it hard to implement the damage filtering. It also kinda blurs the lines between attached components and entities.

There is a fine line between logical subcomponents (Spatial, AI, Weapon slots, Input-processing etc. etc.) and physical subcomponents. You need to decide which side of it you stand on, as this strongly defines what sort of entity system you have. For me, the Physics subcomponent of my Entity handles the physics-hierarchical relationships (such as limbs in a body -- think scenegraph nodes), while the logic controllers noted above are typically what are represented by your entity components -- rather than these representing individual physical "fixtures".

Answer 4

Should the shield be a component that houses other components?

Maybe not houses other components, but controls the lifetime of sub components. So in some rough pseudo code, your client code would add this "shield" component.

class Shield : Component
{
    void Start() // happens when the component is added
    {
        sprite = entity.add_component<Sprite>( "shield" );
        collider = entity.add_component<Collider>( whatever );
        //etc
    }

    void OnDestroy() // when the component is removed
    {
        entity.remove_component( sprite );
        entity.remove_component( collider );
    }

    void Update() // every tick
    {
        if( ShouldRemoveSelf() ) // probably time based or something
            entity.remove_component( this );
    }
}

Answer 5

If your component system allows scripting, the shield component could be almost a super component that just calls a script for its "effect" parameter. That way you maintain simplicity of a single component for shields, and offload all the logic of what it actually does to custom script files that get fed to shields by your entity definitions.

I do something similar for my Moveable component, it countains a field that is of keyreaction script (a subclass of script in my engine) this script defines a method that follows my input message. as such i can simply do something like this in my tempalte definition file

camera template
    moveable
    {
        keyreaction = "scriptforcameramoves"

    }  

player template
    moveable
    {
        keyreaction = "scriptfroplayerkeypress"

    }  

then in my moveable component during message registering i register the scripts Do method (code in C#)

Owner.RegisterHandler<InputStateInformation>(MessageType.InputUpdate, kScript.Do);

of course this relies on my Do method following the pattern of functions that my RegisterHandler takes. In this case its (IComponent sender, ref type argument)

so my "script" (in my case also C# just runime compiled) defines

 public class CameraMoveScript : KeyReactionScript
{
 public override void Do(IComponent pSender, ref InputStateInformation inputState)
 {
    //code here
 }
}

and my base class KeyReactionScript

public class KeyReactionScript : Script
{
      public virtual void Do(IComponent pSender, ref InputStateInformation inputState);
}

then later when an input component sends a message of the type MessageTypes.InputUpdate with the type as such

 InputStateInformation myInputState = InputSystem.GetInputState();
 SendMessage<InputStateInformation>(MessageTypes.InputUpdate, ref myInputState);

The method in the script that was bound to that message and datatype will be fired and handle all the logic.

The code is fairly specific to my engine, but the logic should be functional in any case. I do this for many types in order to keep the component structure simple and flexible.