3
Entity-Component-Systemエンジンでは、依存エンティティのグループをどのように処理しますか？
いくつかのゲームデザインパターンを検討した後、ゲームエンジンのEntity-Component-System（ESシステム）で解決しました。私は記事（主にT = Machine）を読み、いくつかのソースコードを確認しましたが、始めるには十分だと思います。 私が苦労している基本的な考えは1つだけです。互いに依存しているエンティティのグループをどのように処理しますか？ 例を使用してみましょう。 標準のオーバーヘッドシューティングゲームを作成し（ジェームズタウンを考えてください）、複数の別個の、しかし接続されたパーツで「ボスエンティティ」を構築したいとします。内訳は次のようになります。 船体：移動、レンダリング キャノン：位置（船体に対してロック）、ヒーローでTracking \ Fire、無効になるまでダメージを受ける コア：位置（船体に対してロック）、ヒーローでTracking \ Fire、無効になるまでダメージを受ける、船グループ内の他のすべてのエンティティを無効にする（破壊する） 私の目標は、新しい集約要素を構築するたびにサブシステムを一から書き直すことなく、別個のゲーム要素として識別（および操作）されるものです。 この種の設計をESシステムに実装するにはどうすればよいですか？ 何らかの親子エンティティ関係を実装しますか（エンティティは子を持つことができます）？これは、エンティティが単なる空のコンテナであり、OOPをより多く感じるという方法論と矛盾しているようです。 ある種の接続コンポーネント（BossComponent）と関連システム（BossSubSystem）を備えた別個のエンティティとして実装しますか？コンポーネントの通信方法は大きな弱点であると思われるため、これを実装するのは難しいと考えざるを得ません。 コンポーネント（ShipComponent、CannonComponents、CoreComponent）のコレクションを持つ1つのエンティティとして実装しますか？これはESシステムの意図の方向を変えているように見えます（ここのコンポーネントは重量のあるエンティティのように見えます）が、私はこれを知っているので、それをそこに置くと思いました。 私が言及した他の何かとしてそれらを実装しますか？ 私はこれがOOPで非常に簡単に実装できることを知っていますが、OOPよりもESを選ぶことは私が固執するものです。この設計を実装するために純粋なES理論を破る必要がある場合（以前に純粋な設計を妥協する必要がなかったのではなく）、しかし、悪い設計から始めるよりもパフォーマンス上の理由でそれを好むでしょう。 追加のクレジットについては、同じ設計を考えてください。ただし、各「ボスエンティティ」は、実際には、メインボディ、メインコア、3つの「ボスエンティティ」で構成されるより大きな「ビッグボスエンティティ」に接続されました。これにより、少なくとも3つのディメンション（祖父母、親、子）のソリューションが表示されます。これで十分なはずです。