盾牌应该是自己的实体，可以追踪玩家的位置吗？这可能使实施损害过滤变得困难。这也模糊了附加组件和实体之间的界线。
编辑：我认为没有足够的“自主行为”为一个单独的实体。在这种特定情况下，防护罩会跟随目标，对目标起作用并且不会超过目标。尽管我倾向于同意“屏蔽对象”的概念没有错，但是在这种情况下，我们正在处理行为，它适合于组件。但是我还是纯粹逻辑实体的提倡者（与可以在其中找到“变换”和“渲染”组件的成熟的实体系统相反）。
屏蔽是否应该是容纳其他组件的组件？我从未见过或听到过这样的消息，但也许很常见，但我还不够深入。
从不同的角度看待它；添加组件也会添加其他组件，并且在删除后，其他组件也将消失。
盾牌应该只是添加到播放器中的一组组件吗？可能还有一个额外的组件来管理其他组件，例如，这样它们就可以作为一个组全部删除。（偶然地留下减少伤害的部分，这很有趣）。
这可能是一个解决方案，它将促进重用，但是它也更容易出错（例如，您提到的问题）。不一定坏。您可能会发现带有反复试验的新咒语组合：）
对于具有更多组件经验的人来说，还有其他明显的东西吗？
我将详细说明。
我相信您已经注意到，无论何时将某些组件添加到实体中，它们都应具有优先级（这也会回答您的其他问题）。
我还要假设我们正在使用基于消息的通信（为了便于讨论，目前这只是对方法调用的抽象）。
每当“安装”屏蔽组件时，屏蔽组件消息处理程序都以特定（较高）的顺序链接。
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)
“状态”组件在In / Invariant / Normal索引处安装“损坏”消息处理程序。每次收到“损坏”消息时，将HP减少其“值”数量。
相当标准的行为（具有某种自然抵抗力和/或种族特质，无论如何）。
防护组件在In / Pre / High索引处安装“损坏”消息处理程序。
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
您可以看到这是非常灵活的，尽管在设计组件交互时需要仔细计划，因为您将不得不确定在消息处理管道的哪一部分中安装了组件消息事件处理程序。
说得通？让我知道是否可以添加更多细节。
编辑：关于多个组件实例（两个装甲组件）。您可以只跟踪一个实体实例中的实例总数（但是这会杀死每个组件的状态），而只是继续添加消息事件处理程序，或者确保组件容器事先允许重复的组件类型。