問題タブ [entity-system]

Go と Entity-Component-Systems の両方を調査しています。私は ECS がどのように機能するかを理解しており、ECS の頼りになるドキュメントと思われるものを複製しようとしています。

パフォーマンスのために、このドキュメントでは、すべてのコンポーネント タイプの静的配列を使用することを推奨しています。つまり、コンポーネント インターフェイスの配列 (ポインターの配列) ではありません。Go でのこれに関する問題は、循環インポートです。

私は 1 つのパッケージecsを持っています。これには、 Entity、Component、およびSystemのタイプ/インターフェイスとEntityManagerの定義が含まれています。別のパッケージecs/componentsには、さまざまなコンポーネントが含まれています。明らかに、ecs/componentsパッケージはecsに依存しています。ただし、 EntityManagerで特定のコンポーネントの配列を宣言するには、ecsはecs/componentsに依存するため、循環インポートが作成されます。

これを回避する方法はありますか？通常、上位システムは下位システムに依存すべきではないことを認識しています。また、ポインターの配列を使用することはおそらく私の目的には十分高速であることを指摘したいと思いますが、可能な回避策に興味があります（将来の参考のために）

ご協力ありがとうございました！

JRubyのArtemis エンティティ システム フレームワークを使用しようとしています。JRuby に変換しようとしている Java コードは次のとおりです。

これを実行すると、出力は次のようになります。

ConsoleOutputSystem.process() メソッドは 10 回呼び出されます。ここに私のJRubyコードがあります:

出力は次のとおりです。

したがって、ConsoleOutputSystem コンストラクターは呼び出されますが、ConsoleOutputSystem.process() は呼び出されません。@world.initialize と @world.java_send :initialize の両方を使用しようとしましたが、出力は同じです。私が試したもう 1 つのことは、java_signature 'protected void process(Entity)' を ConsoleOutputSystem.process() メソッドに追加することです。

Artemis パッケージの他のいくつかのクラスには、initialize() という名前の保護メソッドがありますが、それが私の問題に関連しているかどうかはわかりません。

[編集]

質問を投稿してから、私はいくつかの進歩を遂げました。@world.java_send :initialize が機能し、正しいメソッドが呼び出されます。うまくいかないのは Aspect.get_aspect_for_all() です。Java Aspect.getAspectForAll() では、

引数として。JRuby では、これらのどちらも Aspect.getAspectForAll() の引数として機能しません。

機能する唯一の方法は、最初に Position インスタンスを作成し、そのクラスを Aspect.getAspectForAll() に渡すことでした。

動作するコードは次のとおりですが、おかしな感じがします。

の出力

は：

では、私の問題は、Position クラスのインスタンスを作成せずに org.jruby.proxy.com.artemis.Component$Proxy0 にアクセスする方法ですか?

[編集2]

Namek's answer のおかげで、動作するコードがここにあります。それは使用しています

そのため、JRuby クラスのインスタンスを作成してその Java クラスにアクセスする必要はありません。

コンポーネント作成用のファクトリ パターンを実装しており、ファクトリによって作成された各タイプのすべてのインスタンスに対してシングルトン コンテナーを実装したいと考えています。理想的には、これはファクトリで作成されたタイプごとに 1 つのベクトルになります。

基本クラスのポインターをベクターに保持できれば、これは非常に簡単ですが、残念ながら、私のユースケースでは、 new が配置する場所ではなく、すべてのインスタンスを連続して保存して、できるだけ多くのキャッシュヒットを取得することを非常に好みます。

私は工場マップのためにこのようなことをすることを考えていました:

これには、基本クラスにキャストされるため、派生クラスからのデータが失われるという問題があります。

また、ペアの 2 番目のメンバーとしてベクトルへのポインターを使用するのも良い方法だと考えていましたが、各ベクトルに異なるデータ型を格納したまま実装する方法がわかりません。テンプレート化されたベクトルはすべて技術的に異なるクラスであるため、これは可能ではないと思います。

私がやろうとしていることをする方法はありますか？過去数日間、運が悪いので何かを理解しようとしてきました。

あるいは、ベクトルを格納する別の良い方法がある場合 (つまり、コンポーネント クラスの静的メンバーとして)、そのような提案も受け付けています!

ここ数日、Erlang について多くのことを学び、コンポーネント エンティティ システムにも精通しています。

Erlang のプロセス中心のアプローチでは、各エンティティが Erlang プロセス インスタンスになることをお勧めします。CES (Component Entity System) アプローチに関しては、MovementComponent (たとえば) を所有するエンティティの「MovementSystem」のようなプロセスがあります。次に、末尾再帰を使用して、登録されているすべてのエンティティを「反復」し、メッセージを送信して、MovementSystem 自体によるバッチ処理として行うのではなく、独自のプロセス状態を更新できるようにします...私の理解では、CES は処理しているすべてのエンティティとコンポーネントのすべての情報を持っているため、これは「共有メモリ」を意味し、概念上、Erlang の一部ではありません)

これらの 2 つのアプローチ/パラダイム - Erlang と "Component Entity System" - は互いに除外していますか、それとも何か不足していますか?

(GitHub ( https://gist.github.com/sntran/2986790 ) でこのプロトタイプを実際の Component Entity System と呼ぶことさえしません。このアプローチは、Entity-System よりもむしろ、私にはgen_event ベースの MQ アプローチ、おそらく代わりに RabbitMQ を使用します...しかし、それはここでは関係ありません...)

今のところ、これらの 2 つの概念をどのように組み合わせることができるかさえわかりません...

私は自分の小さな 2D RPG 用にカスタム マップ フォーマットを作成しようとしています。そのため、私の質問は、カスタム マップ フォーマットの読み取りと作成を適切かつ柔軟に管理するにはどうすればよいかということです。まず、Java でコードを書いています。アイデアは、「TileMap」と呼ばれるクラスを持つことでした。このクラスは、すべてのエンティティが格納される 2 次元の整数配列を定義します (エンティティ システムを使用してゲームを実現しています)。また、実際の読み取りプロセスが発生する前に、マップのサイズに関する情報を保存して解析したいと考えています。マップ ファイルは次のようになります。

ここで、layercount は z 次元が提供するレイヤーの数です。tilesize は各タイルのピクセル単位のサイズです。エンティティは括弧の間で定義されます。パターンは [entity_id;x_pos;y_pos;z_pos] です。このようなファイルを解析するためのコードは既に書きましたが、角かっこの前に小さな空白を 1 つ置くだけでマップを読み込めないため、あまり柔軟ではありません。これを柔軟な方法で行うには、いくつかの役立つヒントが必要です。誰でも私を助けることができますか？

現在「Entity Component System」について学んでいます。多くのチュートリアルやフォーラム スレッドを読んだ後でも、レンダリング ロジックはどこに行くべきなのか疑問に思っています。たとえば、スプライトを取得してレンダリングする実際の OpenGL/DirectX レンダリング コードについて話しているわけではありません。つまり、どのスプライトをレンダリングするかを決定するロジックです。

目に見えるエンティティには、次の 3 つの側面が必要です。

1. AI の評価 (位置、状態の変更など)
2. レンダリング状態の評価。たとえば、エンティティが歩いたり、よじ登ったり、殴られたりするときにどのスプライト サイクルを使用するか...
3. 実際にスプライトをレンダリングする

ほとんどのチュートリアルでは、ロジックに 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」クラスのインスタンスにアタッチされます。したがって、技術的には、コンポーネントにはロジック自体は含まれていません。ただし、これは過剰に設計されているのではないかと心配しています。