Return to Answer

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 hold 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 -- I would put it on the powerup and have it trigger as the powerup vanishes.

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".

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".

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 hold 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 -- I would put it on the powerup and have it trigger as the powerup vanishes.

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). However the logical aspects (controllers) I've given examples of, are typically what are represented by your entity components, rather than these representing logic for controlling individual physical "fixtures".

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 hold 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 -- I would put it on the powerup and have it trigger as the powerup vanishes.

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".

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 hold 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 -- I would put it on the powerup and have it trigger as the powerup vanishes.

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 hold 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 -- I would put it on the powerup and have it trigger as the powerup vanishes.

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). However the logical aspects (controllers) I've given examples of, are typically what are represented by your entity components, rather than these representing logic for controlling individual physical "fixtures".