現在「Entity Component System」について学んでいます。多くのチュートリアルやフォーラム スレッドを読んだ後でも、レンダリング ロジックはどこに行くべきなのか疑問に思っています。たとえば、スプライトを取得してレンダリングする実際の OpenGL/DirectX レンダリング コードについて話しているわけではありません。つまり、どのスプライトをレンダリングするかを決定するロジックです。
目に見えるエンティティには、次の 3 つの側面が必要です。
- AI の評価 (位置、状態の変更など)
- レンダリング状態の評価。たとえば、エンティティが歩いたり、よじ登ったり、殴られたりするときにどのスプライト サイクルを使用するか...
- 実際にスプライトをレンダリングする
ほとんどのチュートリアルでは、ロジックに AISystem (1.) を使用し、RenderComponent で定義されたスプライト (サイクル) を表示するために RenderSystem (3.) を使用することを提案しています。彼らが言わないのは、RenderComponent が更新される場所です。(2.) を (1.) に入れるだけで、キャラクター ロジックとレンダリング ロジックを混在させることは、悪い設計になると私は理解しています。
簡単な解決策は、敵ごとに特定のレンダリング ロジック システムを追加することです。たとえば、Gumba の場合、GumbaLogicSystem、GumbaRenderLogicSystem を追加し、実際のレンダリングでは、すべてのスプライト ベースのエンティティが使用する汎用 SpriteRenderSystem を追加できます。ただし、これはエンティティ タイプごとに 2 つのコンポーネント*と 2 つのシステムを作成することを意味し、良い解決策とは思えません。
システムの数を少なく保ちながら、キャラクターロジックとレンダリングロジックを分離する良い解決策はありますか?
ありがとうございました
(* = 簡単なアプローチでは、システムはそのコンポーネントに応じてエンティティを処理します。GumbaRenderLogicSystem をエンティティで機能させるには、このシステムによって認識されるために GumbaRenderingLogicComponent が必要です。文字ロジックについても同じことが言えます。 .)
Edit1: ECS が抽象的なパターンであることは承知しています。私の質問は、システムの数を少なく保つ方法に関するベスト プラクティスを目的としています。私の例はゲーム プログラミングから動機付けられていますが、この分野に限定されません。より抽象的な例で説明しましょう。
目に見えるエンティティがあると想像してください。階層ベースのアーキテクチャでは、次のようなものがあります。
- SomeModel (AbstractModel から継承)
- SomeController (AbstractController から継承)
- SomeRenderer (PixelRenderer から継承し、PixelRenderer は AbstractRenderer から継承します)。
ECS では、たくさんの新しいクラスが必要になります。
- SomeModelSpecificDataComponent (つまり、このセマンティック エンティティに固有のデータ)
- SomeModelSystem (ロジックを実行する)
- SomeModelSpecificRenderComponent (つまり、このセマンティック エンティティに固有のレンダリング データ)
- SomeModelSpecificRendererLogicSystem (レンダリング方法を決定するシステム)
- PixelRendererSystem
導入が必要な新しいシステムの数を減らす方法はありますか? 1 つの解決策は、「エージェント」または「動作オブジェクト」を追加することです。一般的な RenderingComponent は、RenderSystem で呼び出される単一のメソッド「Update」を持つ「RenderingAgent」クラスのインスタンスにアタッチされます。したがって、技術的には、コンポーネントにはロジック自体は含まれていません。ただし、これは過剰に設計されているのではないかと心配しています。