シールドは、プレイヤーの位置を追跡する独自のエンティティである必要がありますか？そのため、損傷フィルタリングの実装が難しくなる場合があります。また、アタッチされたコンポーネントとエンティティの間の線がぼやけます。
編集：私は、独立したエンティティには十分な「自律的な行動」がないと思います。この特定のケースでは、シールドはターゲットに追従し、ターゲットに対して機能し、ターゲットよりも長持ちしません。「シールドオブジェクト」の概念には何の問題もないことに同意する傾向がありますが、この場合はコンポーネントにうまく適合する動作を扱っています。しかし、私は純粋に論理的なエンティティの擁護者でもあります（変換コンポーネントやレンダリングコンポーネントを見つけることができる本格的なエンティティシステムとは対照的です）。
シールドは他のコンポーネントを収容するコンポーネントですか？私はこのようなものを見たことも聞いたこともないが、たぶんそれは一般的であり、私はまだ十分に深くない。
別の視点で見てください。コンポーネントを追加すると他のコンポーネントも追加され、削除すると追加のコンポーネントも削除されます。
シールドは、プレーヤーに追加されるコンポーネントのセットである必要がありますか？おそらく他のコンポーネントを管理するための追加コンポーネントがあります。たとえば、すべてをグループとして削除できます。（誤ってダメージ軽減コンポーネントを残します。今ではそれが楽しいでしょう）。
これは解決策になる可能性があり、再利用を促進しますが、エラーが発生しやすくなります（たとえば、あなたが言及した問題の場合）。必ずしも悪いわけではありません。あなたは試行錯誤のある新しい呪文の組み合わせを見つけるかもしれません:)
コンポーネントの経験が豊富な人にとって明らかな何か他のものはありますか？
少し詳しく説明します。
エンティティに追加された場合でも、一部のコンポーネントがどのように優先されるべきかに気付いたと思います（これは他の質問にも答えます）。
また、メッセージベースの通信を使用していると仮定します（説明のため、現時点ではメソッド呼び出しの単なる抽象化です）。
シールドコンポーネントが「インストール」されるたびに、シールドコンポーネントメッセージハンドラーは特定の（より高い）順序でチェーンされます。
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)
「stats」コンポーネントは、In / Invariant / Normalインデックスに「damage」メッセージハンドラーをインストールします。「損傷」メッセージを受信するたびに、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
メッセージ処理パイプラインコンポーネントメッセージイベントハンドラーのどの部分がインストールされているかを判断する必要があるため、コンポーネントの相互作用を設計する際には慎重な計画が必要ですが、これは非常に柔軟です。
理にかなっていますか？詳細を追加できるかどうかを教えてください。
編集：複数のコンポーネントインスタンス（2つの装甲コンポーネント）について。1つのエンティティインスタンスのみで合計インスタンス数を追跡し（ただし、これによりコンポーネントごとの状態が強制終了されます）、メッセージイベントハンドラーを追加し続けるか、コンポーネントコンテナーが事前にコンポーネントタイプの重複を許可していることを確認できます。