タグ付けされた質問 「entity-system」

私はエンティティのコンポーネントとシステムについて多くのことを読んでおり、エンティティが単なるIDであるという考えは非常に興味深いと考えてきました。 しかし、これがコンポーネントの側面やシステムの側面でどのように完全に機能するのかわかりません。コンポーネントは、関連するシステムによって管理される単なるデータオブジェクトです。衝突システムは、空間データ構造とともにいくつかのBoundsComponentを使用して、衝突が発生したかどうかを判断します。 これまでのところすべて良いですが、複数のシステムが同じコンポーネントにアクセスする必要がある場合はどうでしょうか？データはどこに保存する必要がありますか？入力システムはエンティティBoundsComponentを変更できますが、物理システムはいくつかのレンダリングシステムと同じコンポーネントにアクセスする必要があります。 また、エンティティはどのように構築されますか？私がこれまで読んだことのある利点の1つは、エンティティ構築の柔軟性です。システムは本質的にコンポーネントに結び付けられていますか？新しいコンポーネントを導入したい場合、新しいシステムを導入したり、既存のシステムを変更したりする必要がありますか？ 私がよく読んだもう1つのことは、エンティティの「タイプ」は、そのコンポーネントが持っているものによって推測されるということです。エンティティが単なるIDである場合、ロボットエンティティを移動またはレンダリングし、何らかのシステムで変更する必要があることをどのようにして知ることができますか？ 長い投稿で申し訳ありません（少なくとも、私の携帯電話の画面からはそう思われます）！

177 architecture  component-based  entity-system 

2つのユーザーケースがあります。 どのようにメッセージをentity_A送信しtake-damageますentity_Bか？ のHPをどのようにentity_A照会しますentity_Bか？ これまでに遭遇したことがあります： メッセージキュー entity_Atake-damageメッセージを作成し、それをentity_Bのメッセージキューに投稿します。 entity_Aquery-hpメッセージを作成してに投稿しentity_Bます。 entity_B代わりに、response-hpメッセージを作成してに投稿しentity_Aます。 パブリッシュ/サブスクライブ entity_Btake-damageメッセージをサブスクライブします（おそらく、何らかのプリエンプティブフィルタリングを使用して、関連するメッセージのみが配信されます）。 を参照entity_Aするtake-damageメッセージを生成しますentity_B。 entity_Aupdate-hpメッセージをサブスクライブします（フィルタリングされる可能性があります）。すべてのフレームがメッセージをentity_Bブロードキャストしupdate-hpます。 信号/スロット ??? entity_Aupdate-hpスロットをentity_Bのupdate-hp信号に接続します。 もっと良いものはありますか？これらの通信方式がゲームエンジンのエンティティシステムにどのように結び付くのかを正しく理解していますか？

115 architecture  entity-system 

昨日、私はGDCカナダから、属性/行動エンティティシステムに関するプレゼンテーションを読みました。ただし、理論上だけでなく、実際に使用する方法もわかりません。まず、このシステムの仕組みを簡単に説明します。 各ゲームエンティティ（ゲームオブジェクト）は、属性（=データ、動作によってアクセスできるだけでなく、「外部コード」によってもアクセス可能）および動作（= OnUpdate()およびを含むロジック）で構成されますOnMessage()。したがって、たとえば、ブレイクアウトクローンでは、各ブリックは（例！）で構成されます：PositionAttribute、ColorAttribute、HealthAttribute、RenderableBehaviour、HitBehaviour。最後の例は次のようになります（C＃で書かれた単なる機能しない例です）。 void OnMessage(Message m) { if (m is CollisionMessage) // CollisionMessage is inherited from Message { Entity otherEntity = m.CollidedWith; // Entity CollisionMessage.CollidedWith if (otherEntity.Type = EntityType.Ball) // Collided with ball { int brickHealth = GetAttribute<int>(Attribute.Health); // owner's attribute brickHealth -= otherEntity.GetAttribute<int>(Attribute.DamageImpact); SetAttribute<int>(Attribute.Health, brickHealth); // owner's attribute // …

59 c#  component-based  entity-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つのディメンション（祖父母、親、子）のソリューションが表示されます。これで十分なはずです。

47 entity-system  component-based  entity-component-system 

私はC ++でエンティティコンポーネントシステムに取り組んでいます。Artemisのスタイル（http://piemaster.net/2011/07/entity-component-artemis/）に従ってくださいロジックを含むシステム。このアプローチのデータ中心性を活用し、優れたコンテンツツールを構築したいと考えています。 ただし、データファイルから識別子文字列またはGUIDを取得し、それを使用してエンティティのコンポーネントを構築する方法があります。明らかに、1つの大きな解析関数があります。 Component* ParseComponentType(const std::string &typeName) { if (typeName == "RenderComponent") { return new RenderComponent(); } else if (typeName == "TransformComponent") { return new TransformComponent(); } else { return NULL: } } しかし、それは本当にいです。コンポーネントを頻繁に追加および変更し、できればプロトタイプ作成のためにコンポーネントとシステムをLuaに実装できるように、何らかのScriptedComponentComponentを構築する予定です。あるクラスから継承するクラスを作成しBaseComponent、おそらくすべてを機能させるために2、3のマクロを投げて、実行時にインスタンスを生成できるようにしたいと思います。 C＃とJavaでは、クラスとコンストラクターを検索するための素晴らしいリフレクションAPIを取得するため、これは非常に簡単です。しかし、私はC ++でこれを行っています。なぜなら、その言語の習熟度を高めたいからです。 それで、これはC ++でどのように達成されますか？RTTIの有効化について読んだことがありますが、ほとんどの人は、特にオブジェクトタイプのサブセットにのみ必要な状況では、それについて警戒しているようです。そこでカスタムRTTIシステムが必要な場合、どこでそれを書くことを学び始めることができますか？

37 c++  component-based  entity-system 

最近、私はC ++ / OpenGLゲームエンジンに実装するために、エンティティシステムで多くの読書を行ってきました。エンティティシステムについて絶賛されている2つの主な利点は次のとおりです。 複雑な継承階層に絡む必要がないため、新しい種類のエンティティを簡単に構築できます。 キャッシュの効率性、私は理解するのに苦労しています。 理論はもちろん単純です。各コンポーネントはメモリブロックに連続して格納されるため、そのコンポーネントを処理するシステムは、メモリ内をジャンプしてキャッシュを削除することなく、リスト全体を繰り返し処理できます。問題は、これが実際に実用的である状況を本当に考えることができないということです。 最初に、コンポーネントがどのように保存され、どのように相互に参照するかを見てみましょう。システムは複数のコンポーネントで動作する必要があります。つまり、レンダリングシステムと物理システムの両方が変換コンポーネントにアクセスする必要があります。私はこれに対処する多くの可能な実装を見てきましたが、どれもうまくいきません。 コンポーネントに、他のコンポーネントへのポインター、またはコンポーネントへのポインターを格納するエンティティへのポインターを格納させることができます。ただし、ポインタをミックスに投入するとすぐに、キャッシュの効率がすでに低下しています。すべてのコンポーネント配列が「n」の大きさであることを確認できます。「n」はシステム内に存在するエンティティの数ですが、このアプローチはひどくメモリを浪費します。これにより、新しいコンポーネントタイプをエンジンに追加することは非常に困難になりますが、1つのアレイから次のアレイにジャンプするため、キャッシュ効率が失われます。個別の配列を保持する代わりに、エンティティ配列をインターリーブすることもできますが、それでもメモリを浪費しています。新しいコンポーネントやシステムを追加するのに法外な費用がかかりますが、古いレベルをすべて無効にしてファイルを保存するという利点が追加されました。 これはすべて、エンティティがリスト、すべてのフレームまたはティックで線形に処理されることを前提としています。実際には、これは多くの場合そうではありません。オクルージョンカリングを実行するためにセクター/ポータルレンダラー、またはオクトツリーを使用するとします。エンティティをセクター/ノード内に連続して保存できる場合もありますが、好きかどうかに関係なく、飛び回ることになります。次に、他のシステムがあります。これは、他の何らかの順序で格納されたエンティティを好む場合があります。AIは、AI LODでの作業を開始するまで、エンティティを大きなリストに格納しても問題ありません。次に、プレーヤーまでの距離、またはその他のLODメトリックに従って、そのリストを分割します。物理学はそのオクトツリーを使用したいと思うでしょう。スクリプトは何でも構いません。実行する必要があります。 コンポーネントを「ロジック」（ai、スクリプトなど）と「ワールド」（レンダリング、物理、オーディオなど）に分割し、各リストを個別に管理できますが、これらのリストは相互にやり取りする必要があります。AIは、エンティティのレンダリングに使用される変換またはアニメーションの状態に影響を与えない場合、意味がありません。 エンティティシステムは、実際のゲームエンジンでどのように「キャッシュ効率」が高いのですか？おそらく、アレイにエンティティをグローバルに保存し、octree内でそれを参照するなど、誰もが使用しているが、話しているわけではないハイブリッドアプローチがあるのでしょうか。

32 c++  entity-system  optimization 

エンティティ・システム（約2つの質問尋ねる後1、2）、およびいくつかの読書記事をそれらの上に、私ははるかに良い以前よりもそれらを理解していると思います。主にパーティクルエミッタ、入力システム、カメラの構築については、まだいくつかの不確実性があります。エンティティシステムの理解にはまだいくつかの問題が残っており、他のあらゆる範囲のオブジェクトに適用される可能性がありますが、これらは非常に異なる概念であり、かなり広い範囲をカバーし、エンティティシステムとその方法を理解するのに役立つため、これら3つを選択しましたこれらの問題を自分で処理します。 JavaScriptでエンジンを構築しており、入力処理、柔軟なアニメーションシステム、パーティクルエミッター、数学クラスと関数、シーン処理、カメラとレンダー、および多数のコア機能のほとんどを実装しています。エンジンが通常サポートするその他のもの。Byte56の答えを読んで、エンジンをエンティティシステムにすることに興味を持ちました。基本的なシーンの哲学を持つHTML5ゲームエンジンのままですが、コンポーネントからのエンティティの動的な作成をサポートする必要があります。 私が今抱えている問題は、古いエンジンの概念をこの新しいプログラミングパラダイムに適合させることです。これらは、更新された以前の質問の定義の一部です。 アンエンティティの識別子です。データはなく、オブジェクトではなく、すべてのエンティティのシーンリスト内のインデックスを表す単純なIDです（実際にコンポーネントマトリックスとして実装する予定です）。 A コンポーネントが、そのデータを操作することができる方法と、データ保持部です。最良の例はVector2D、または「位置」コンポーネントです。これにはdata：xとyがありますが、データの操作を少し簡単にするいくつかのメソッドもあります：add()、normalize()など。 A システムは、一定の要件を満たしているエンティティのセットを操作することができるものです。通常、エンティティは、操作対象のコンポーネントの指定されたセットを持っている必要があります。システムは「論理」部分、「アルゴリズム」部分であり、コンポーネントによって提供されるすべての機能は、純粋にデータ管理を容易にするためのものです。 カメラ カメラには、Vector2D位置プロパティ、回転プロパティ、およびポイントを中心とするいくつかのメソッドがあります。各フレームは、シーンとともにレンダラーに送られ、すべてのオブジェクトはその位置に従って変換されます。その後、シーンがレンダリングされます。 エンティティシステムでこの種のオブジェクトをどのように表現できますか？カメラはエンティティ、コンポーネント、または組み合わせになりますか（私の回答によると）？ パーティクルエミッタ パーティクルエミッタの問題点は、何がどうあるべきかということです。10,000個以上のパーティクルをサポートしたいので、パーティクル自体がエンティティであってはならないことは間違いありません。そのようなエンティティを作成すると、パフォーマンスに大きな打撃を与えると考えています。 エンティティシステムでこの種のオブジェクトをどのように表現できますか？ 入力マネージャー 最後に話したいのは、入力の処理方法です。現在のバージョンのエンジンには、というクラスがありInputます。これは、キーの押下やマウスの位置の変更などのブラウザーイベントにサブスクライブし、内部状態も維持するハンドラーです。次に、プレーヤークラスにはreact()、入力オブジェクトを引数として受け入れるメソッドがあります。これの利点は、入力オブジェクトを.JSONにシリアル化し、ネットワーク上で共有できるため、スムーズなマルチプレイヤーシミュレーションが可能になることです。 これはどのようにエンティティシステムに変換されますか？

31 javascript  entity-system  component-based 

エンティティシステムのバリアントを実装しています。 Entityクラス IDより少しであることが結合コンポーネント一緒に 「コンポーネントロジック」がなく、データのみを持つコンポーネントクラスの束 多数のシステムクラス（別名「サブシステム」、「マネージャー」）。これらはすべてのエンティティロジック処理を行います。ほとんどの基本的な場合、システムは、関心のあるエンティティのリストを反復処理し、各エンティティに対してアクションを実行するだけです。 MessageChannelクラスオブジェクトのすべてのゲームシステムで共有されています。各システムは、特定のタイプのメッセージをサブスクライブしてリッスンし、チャネルを使用して他のシステムにメッセージをブロードキャストすることもできます システムメッセージ処理の最初のバリアントは、次のようなものでした。 各ゲームシステムで順次更新を実行する システムがコンポーネントに対して何かを実行し、そのアクションが他のシステムにとって重要である場合、システムは適切なメッセージを送信します（たとえば、システム呼び出し messageChannel.Broadcast(new EntityMovedMessage(entity, oldPosition, newPosition)) エンティティが移動されるたびに） 特定のメッセージをサブスクライブした各システムは、そのメッセージ処理メソッドを取得します システムがイベントを処理しており、イベント処理ロジックで別のメッセージをブロードキャストする必要がある場合、メッセージはすぐにブロードキャストされ、メッセージ処理メソッドの別のチェーンが呼び出されます このバリアントは、衝突検出システムの最適化を開始するまでは問題ありませんでした（エンティティの数が増えると、本当に遅くなりました）。最初は、単純なブルートフォースアルゴリズムを使用して各エンティティペアを繰り返します。次に、特定のセルの領域内にあるエンティティを格納するセルのグリッドを持つ「空間インデックス」を追加しました。これにより、隣接セルのエンティティのみをチェックできます。 エンティティが移動するたびに、衝突システムはエンティティが新しい位置にあるものと衝突しているかどうかを確認します。そうである場合、衝突が検出されます。衝突するエンティティが両方とも「物理オブジェクト」である場合（両方にRigidBodyコンポーネントがあり、同じスペースを占有しないように互いを押しのけようとしている場合）、専用の剛体分離システムがエンティティを移動するように移動システムに要求しますそれらを分離する特定の位置。これにより、移動システムは変更されたエンティティの位置を通知するメッセージを送信します。衝突検出システムは、空間インデックスを更新する必要があるため、反応するように設計されています。 場合によっては、セルの内容（C＃のEntityオブジェクトの汎用リスト）が繰り返し処理されている間に変更され、イテレーターによって例外がスローされるため、問題が発生します。 だから... 衝突をチェックしている間に衝突システムが中断されるのを防ぐにはどうすればよいですか？ もちろん、セルの内容が正しく繰り返されることを保証する「巧妙な」/「トリッキーな」ロジックを追加することもできますが、問題は衝突システム自体にあるのではないと思います（他のシステムにも同様の問題がありました）メッセージはシステムからシステムへ移動するときに処理されます。私が必要とするのは、特定のイベント処理メソッドが中断することなく仕事を確実に行うための何らかの方法です。 私が試したもの： 着信メッセージキュー。あるシステムがメッセージをブロードキャストするたびに、そのメッセージは関心のあるシステムのメッセージキューに追加されます。これらのメッセージは、システム更新が各フレームで呼び出されると処理されます。問題：システムAがシステムBのキューにメッセージを追加する場合、システムBがシステムAよりも後（同じゲームフレーム内）に更新される場合、それはうまく機能します。それ以外の場合、メッセージが次のゲームフレームを処理します（一部のシステムでは望ましくありません） 発信メッセージキュー。システムがイベントを処理している間、システムがブロードキャストするメッセージは送信メッセージキューに追加されます。メッセージは、システムの更新が処理されるのを待つ必要はありません。最初のメッセージハンドラが処理を完了した後、「すぐに」処理されます。メッセージの処理によって他のメッセージがブロードキャストされる場合、それらも発信キューに追加されるため、すべてのメッセージが同じフレームで処理されます。問題：エンティティライフタイムシステム（システムでエンティティライフタイム管理を実装）がエンティティを作成した場合、いくつかのシステムAとBに通知します。システムAがメッセージを処理している間、メッセージチェーンが発生し、最終的に作成されたエンティティが破棄されます（たとえば、弾丸エンティティが障害物と衝突する場所で作成され、弾丸が自己破壊します）。メッセージチェーンが解決されている間、システムBはエンティティ作成メッセージを取得しません。したがって、システムBがエンティティ破壊メッセージにも関心がある場合、システムBはそれを取得し、「チェーン」の解決が完了した後にのみ、最初のエンティティ作成メッセージを取得します。これにより、破棄メッセージは無視され、作成メッセージは「受け入れられます」、 編集-質問への回答、コメント： 衝突システムがセルの内容を繰り返し処理している間、誰がセルの内容を変更しますか？ 衝突システムが一部のエンティティとその近隣で衝突チェックを行っている間、衝突が検出される可能性があり、エンティティシステムは他のシステムがすぐに反応するメッセージを送信します。メッセージに対する反応により、他のメッセージが作成され、すぐに処理される場合があります。そのため、他のシステムは、以前の衝突チェックがまだ終了していない場合でも、衝突システムがすぐに処理する必要があるメッセージを作成する場合があります（たとえば、衝突システムが空間インデックスを更新する必要があるため、エンティティを移動します）。 グローバルな送信メッセージキューを使用できませんか？ 最近、単一のグローバルキューを試しました。新しい問題を引き起こします。問題：タンクエンティティを壁エンティティに移動します（タンクはキーボードで制御されます）。それからタンクの方向を変えることにしました。タンクと壁を各フレームに分離するために、CollidingRigidBodySeparationSystemはタンクを壁から可能な限り最小の距離だけ移動します。分離方向は、戦車の移動方向の反対方向でなければなりません（ゲームの描画が開始されると、戦車は壁に移動したことがないように見えるはずです）。しかし、方向はNEW方向とは逆になり、タンクを壁の最初とは異なる側に移動します。問題が発生する理由：これがメッセージの処理方法です（簡略化されたコード）： public void Update(int deltaTime) { m_messageQueue.Enqueue(new TimePassedMessage(deltaTime)); while (m_messageQueue.Count > 0) { Message message = m_messageQueue.Dequeue(); this.Broadcast(message); } } private …

30 c#  component-based  entity-system 

コンポーネントベースの設計に頭を悩ませ始めたところです。これを行う「正しい」方法が何であるかはわかりません。 これがシナリオです。プレイヤーはシールドを装備できます。シールドはプレイヤーの周りにバブルとして描かれ、個別の衝突形状を持ち、プレイヤーがエリア効果から受けるダメージを減らします。 コンポーネントベースのゲームでは、このようなシールドはどのように設計されていますか？ 混乱するのは、シールドに明らかに3つのコンポーネントが関連付けられていることです。 ダメージ低減/フィルタリング スプライト コライダー。 さらに悪いことに、さまざまなシールドのバリエーションがさらに多くの動作をする可能性があり、そのすべてがコンポーネントになります。 プレイヤーの最大ヘルスを向上させます 健康回復 発射体のたわみ 等 私はこれを考え直していますか？シールドは単にスーパーコンポーネントである必要がありますか？ これは間違った答えだと思います。それがあなたがこれが行く方法であると思うならば、説明してください。 シールドは、プレイヤーの位置を追跡する独自のエンティティである必要がありますか？ そのため、損傷フィルタリングの実装が難しくなる場合があります。また、アタッチされたコンポーネントとエンティティの間の線がぼやけます。 シールドは他のコンポーネントを収容するコンポーネントですか？ 私はこのようなものを見たことも聞いたこともないが、たぶんそれは一般的であり、私はまだ十分に深くない。 シールドは、プレーヤーに追加されるコンポーネントのセットである必要がありますか？ おそらく他のコンポーネントを管理するための追加のコンポーネントがあります。たとえば、それらをすべてグループとして削除できます。（誤ってダメージ軽減コンポーネントを残します。今ではそれが楽しいでしょう）。 コンポーネントの経験が豊富な人にとって明らかな何か他のものはありますか？

29 architecture  component-based  entity-system 

コンポーネントベースのアーキテクチャを使用したゲームに取り組んでいます。Entity一連の所有Componentの組それぞれ有する、インスタンスをSlot格納するとインスタンスを送信し、値を受け取ります。Player必要なコンポーネントとスロット接続を備えたエンティティの生成などの工場機能。 コンポーネントの最適な粒度を決定しようとしています。今、例えばPosition、Velocity、とAcceleration直列に接続された全ての別個の構成要素です。VelocityそしてAcceleration容易に均一に書き換えることができるDelta成分、またはPosition、Velocity、およびAccelerationのような成分と一緒に組み合わせることができるFrictionとGravityモノリシックにPhysicsコンポーネント。 コンポーネントの責任は可能な限り小さくする必要がありますか（相互接続性が犠牲になります）、または関連するコンポーネントを組み合わせてモノリシックコンポーネントにする必要があります（柔軟性が犠牲になります）。前者に傾いていますが、セカンドオピニオンを使用できます。

26 architecture  entity-system  component-based 

私はしばらくの間、コンポーネントベースのエンティティシステムに興味があり、その上で数え切れないほどの記事を読んでいます（Insomiacゲーム、かなり標準的なEvolve Your Hierarchy、T-Machine、Chronoclast ...など）。 それらはすべて、次のようなものの外側に構造を持っているようです。 Entity e = Entity.Create(); e.AddComponent(RenderComponent, ...); //do lots of stuff e.GetComponent<PositionComponent>(...).SetPos(4, 5, 6); そして、共有データのアイデアを取り入れると（これは、どこでもデータを複製しないという点で、これまで見た中で最高の設計です） e.GetProperty<string>("Name").Value = "blah"; はい、これは非常に効率的です。ただし、読み取りまたは書き込みが最も簡単なわけではありません。それはとても不格好で、あなたに対して働いているように感じます。 私は個人的に次のようなことをしたいと思います： e.SetPosition(4, 5, 6); e.Name = "Blah"; もちろん、この種の設計に到達する唯一の方法は、Entity-> NPC-> Enemy-> FlyingEnemy-> FlyingEnemyWithAHatOnのような階層に戻ることですが、この設計は回避しようとします。 この種のコンポーネントシステムの設計を見たことがありますが、これはまだ柔軟性がありますが、ユーザーフレンドリーなレベルを維持していますか？それに、データストレージ（おそらく最も難しい問題）を良い方法で回避できますか？ ユーザーフレンドリーでありながら柔軟なコンポーネントベースのエンティティシステムにはどのような設計がありますか？

23 c#  architecture  component-based  entity-system 

少し背景を説明しますが、エンティティシステムにENTTを使用して、C ++の友人と進化ゲームをコーディングしています。クリーチャーは2Dマップ内を歩き回り、緑や他のクリーチャーを食べ、繁殖し、その形質が変化します。 さらに、ゲームをリアルタイムで実行した場合のパフォーマンスは良好です（60fpsは問題ありません）が、大幅な変更を確認するために4時間待つ必要がないように大幅にスピードアップできるようにしたいと思います。だから、私はできるだけ早くそれを取得したい。 クリーチャーが食物を見つけるための効率的な方法を見つけるのに苦労しています。各クリーチャーは、彼らに十分近い最高の食べ物を探すことになっています。 食べたい場合、中央に描かれた生き物は、149.64の半径（視界距離）で自分の周りを見回し、栄養、距離、およびタイプ（肉または植物）に基づいて、追求すべき食物を判断することになっています。 。 すべてのクリーチャーの食料を見つける機能は、実行時間の約70％を消費します。現在どのように書かれているかを単純化すると、次のようになります。 for (creature : all_creatures) { for (food : all_entities_with_food_value) { // if the food is within the creatures view and it's // the best food found yet, it becomes the best food } // set the best food as the target for creature …

21 c++  performance  entity-system 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店しました。 私は自分のゲームでよりコンポーネントベースのアプローチに移行することを検討しています。この移行を少し簡単にするのに役立つまともな参考資料やサンプル実装は他にありますか？

20 architecture  entity-system  component-based 

（私が説明しているのは、この設計に基づいています：エンティティシステムフレームワークとは何ですか？、下にスクロールすると見つかります） C ++でエンティティコンポーネントシステムを作成するときに問題が発生します。コンポーネントクラスがあります。 class Component { /* ... */ }; これは実際には、他のコンポーネントを作成するためのインターフェースです。したがって、カスタムコンポーネントを作成するには、インターフェイスを実装し、ゲーム内で使用されるデータを追加するだけです。 class SampleComponent : public Component { int foo, float bar ... }; これらのコンポーネントはEntityクラス内に格納され、Entityの各インスタンスに一意のIDが付与されます。 class Entity { int ID; std::unordered_map<string, Component*> components; string getName(); /* ... */ }; コンポーネントは、コンポーネントの名前をハッシュすることでエンティティに追加されます（これはおそらくそれほど素晴らしい考えではありません）。カスタムコンポーネントを追加すると、コンポーネントタイプ（ベースクラス）として保存されます。 一方、今では、内部にNodeインターフェースを使用するSystemインターフェースがあります。Nodeクラスは、単一のエンティティのコンポーネントの一部を格納するために使用されます（システムはエンティティのすべてのコンポーネントの使用に関心がないため）。システムがupdate()必要な場合、システムは異なるエンティティから作成されたノードを反復処理するだけです。そう： /* System and Node implementations: (not the interfaces!) */ class …

18 c++  entity-system  entity-component 

Adam Martin（t-machine）に触発されたEntity Systemのアイデアはすでに得ていると思います。次のプロジェクトでこれを使い始めたいです。 エンティティ、コンポーネント、システムの基本をすでに知っています。私の問題は、UI / HUDの処理方法です。たとえば、クエストウィンドウ、スキルウィンドウ、キャラクター情報ウィンドウなど。UIイベントをどのように処理しますか（ボタンを押すなど）。これらは、すべてのフレームを処理する必要がないものです。現在、UIをコーディングするためにMVCを使用していますが、Entity Systemとの互換性はないと思います。 Entity Systemはより大きなOOPに埋め込まれていることを読みました。UIがESの外にあるかどうかはわかりません。これにどのようにアプローチしますか？

18 architecture  entity-system