Entity-Component-Systemエンジンでは、依存エンティティのグループをどのように処理しますか？

いくつかのゲームデザインパターンを検討した後、ゲームエンジンのEntity-Component-System（ESシステム）で解決しました。私は記事（主にT = Machine）を読み、いくつかのソースコードを確認しましたが、始めるには十分だと思います。

私が苦労している基本的な考えは1つだけです。互いに依存しているエンティティのグループをどのように処理しますか？

例を使用してみましょう。

標準のオーバーヘッドシューティングゲームを作成し（ジェームズタウンを考えてください）、複数の別個の、しかし接続されたパーツで「ボスエンティティ」を構築したいとします。内訳は次のようになります。

• 船体：移動、レンダリング
• キャノン：位置（船体に対してロック）、ヒーローでTracking \ Fire、無効になるまでダメージを受ける
• コア：位置（船体に対してロック）、ヒーローでTracking \ Fire、無効になるまでダメージを受ける、船グループ内の他のすべてのエンティティを無効にする（破壊する）

私の目標は、新しい集約要素を構築するたびにサブシステムを一から書き直すことなく、別個のゲーム要素として識別（および操​​作）されるものです。

この種の設計をESシステムに実装するにはどうすればよいですか？

1. 何らかの親子エンティティ関係を実装しますか（エンティティは子を持つことができます）？これは、エンティティが単なる空のコンテナであり、OOPをより多く感じるという方法論と矛盾しているようです。
2. ある種の接続コンポーネント（BossComponent）と関連システム（BossSubSystem）を備えた別個のエンティティとして実装しますか？コンポーネントの通信方法は大きな弱点であると思われるため、これを実装するのは難しいと考えざるを得ません。
3. コンポーネント（ShipComponent、CannonComponents、CoreComponent）のコレクションを持つ1つのエンティティとして実装しますか？これはESシステムの意図の方向を変えているように見えます（ここのコンポーネントは重量のあるエンティティのように見えます）が、私はこれを知っているので、それをそこに置くと思いました。
4. 私が言及した他の何かとしてそれらを実装しますか？

私はこれがOOPで非常に簡単に実装できることを知っていますが、OOPよりもESを選ぶことは私が固執するものです。この設計を実装するために純粋なES理論を破る必要がある場合（以前に純粋な設計を妥協する必要がなかったのではなく）、しかし、悪い設計から始めるよりもパフォーマンス上の理由でそれを好むでしょう。

追加のクレジットについては、同じ設計を考えてください。ただし、各「ボスエンティティ」は、実際には、メインボディ、メインコア、3つの「ボスエンティティ」で構成されるより大きな「ビッグボスエンティティ」に接続されました。これにより、少なくとも3つのディメンション（祖父母、親、子）のソリューションが表示されます。これで十分なはずです。

この状況にあった場合、ボスの各部分を個別のエンティティとして作成します。これらの「サブエンティティ」には、何らかの種類AttachmentPointまたはParentEntityコンポーネントが含まれます。このコンポーネントには、親エンティティへの参照と、親の位置からのオフセットが含まれます。位置を更新するとき、親の位置を確認し、オフセットを適用して独自の位置を生成します。さらに、親エンティティがまだ存在することを確認するためのチェックを行うことができます。さらに、SubEntity親エンティティのサブエンティティの存在を追跡するコンポーネントを持つことができます。これにより、シールド付きの腕が破壊された場合にのみボスのコアを脆弱にすることができます。

現在TargetEntity、ゲームでコンポーネントを使用しています。これは、タレットの追跡や、ゴブリンがリソースを取得するときに使用されます。ターゲットエンティティの位置を確認し、それに応じて動作を変更できます。位置を持たないエンティティはターゲットとして追加されないため、心配はありません。ただし、親または子エンティティのヘルス、シールド、パワーリザーブなどを確認するなど、さらに深くなるには、親または子エンティティに実際に関連コンポーネントがあることを確認する必要があります。

各パーツを独自のエンティティにすることで、追加の異なるコンポーネントをボスの各パーツに追加できるため、エンティティ/コンポーネントフレームワークの柔軟性が維持されます。たとえば、ボスの一部には銃コンポーネントとヘルスコンポーネントがあり、別の一部にはシールドコンポーネントとヘルスコンポーネントがあります。

ここでこのトピックに関する別の議論を見つけました。ユーザーが同じタイプの複数のコンポーネントを1つのエンティティに追加することについて議論しています（これは私にとっては悪い考えのようです）。ディスカッション全体を読んでいませんが、それは有益な会話のようです。

既存のシステムについてあまり多くの詳細を知らずに、これをモデル化する方法（そして、ある程度自分のエンティティシステムで行う必要がある方法）は、AttachedTo（parentEntity）のようなコンポーネントを持つことです。その後、任意の子にAttachedTo（boss）コンポーネントを与えることができます。

レンダリングシステム（または何でも）は、Position、AttachedToなどのコンポーネントを持つエンティティを取得し、適切な階層を形成します。

エンティティをIDだけで表す場合は、エンティティの包含を特別なコンポーネントを介して実行できます。CompositeComponentを呼び出すことができます。これには、子エンティティIDのリストと、そのリストから子を追加/削除するためのインターフェースが含まれます。

明らかに、位置などに依存するコンポーネントは、エンティティを適切に配置するためにこれと連携する必要があります。これを実装する方法は、現在のポジショニングの実装方法に多少依存します。

ところで、「純粋なES理論」はありません。コンポーネントからエンティティを作成することは一般的なアプローチですが、正確な方法はまだ標準化されていません。