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?