タグ付けされた質問 「component-based」

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

177 architecture  component-based  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 

成功の歴史を見てみましょう。コンポーネントベースのゲームオブジェクトシステムを使用して構築された人気のあるゲーム（およびゲームエンジン）はどれですか？各回答には以下を含める必要があります。 ゲームタイトル（回答ごとに1つ） 著者/会社 年 開発時間（オプション） 事後分析へのリンク（オプション） docs / sourceコードへのリンク（オプション）

43 component-based  game-industry 

私は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 

FPSのエンティティシステムを設計しました。基本的には次のように機能します。 GameWorldと呼ばれる「世界」オブジェクトがあります。これは、GameManagerの配列とComponentManagerの配列を保持します。 GameObjectはComponentの配列を保持しています。また、非常にシンプルなイベントメカニズムも提供します。コンポーネント自体は、すべてのコンポーネントにブロードキャストされるイベントをエンティティに送信できます。 コンポーネントは基本的にGameObjectに特定のプロパティを与えるものであり、GameObjectは実際にはそれらの単なるコンテナであるため、ゲームオブジェクトに関係するすべてはコンポーネント内で発生します。例には、ViewComponent、PhysicsComponent、およびLogicComponentが含まれます。それらの間の通信が必要な場合は、イベントを使用して行うことができます。 ComponentManagerは、Componentと同様の単なるインターフェイスであり、各Componentクラスには、通常1つのComponentManagerクラスが必要です。これらのコンポーネントマネージャは、コンポーネントを作成し、XMLファイルなどから読み取ったプロパティでコンポーネントを初期化する役割を果たします。 ComponentManagerは、外部ライブラリを使用するPhysicsComponentのように、コンポーネントの大量更新も処理します（世界中のすべてを一度に実行します）。 構成可能性のために、XMLファイルまたはスクリプトのいずれかを読み取るエンティティのファクトリーを使用し、ファイルで指定されたコンポーネントを作成します（また、一括更新のために適切なコンポーネントマネージャーに参照を追加します）。次に、それらをGameObjectオブジェクトに注入します。 次に問題が発生します。これをマルチプレイヤーゲームに使用しようとしています。私はこれにどのようにアプローチするのか分かりません。 まず、最初からクライアントはどのエンティティを持っているべきですか？まず、シングルプレイヤーエンジンがどのエンティティを作成するかを決定する方法を説明する必要があります。 レベルエディタでは、「ブラシ」と「エンティティ」を作成できます。ブラシは、壁、床、天井など、基本的に単純な形状のものです。エンティティは、先ほどお伝えしたGameObjectです。レベルエディタでエンティティを作成するとき、各コンポーネントのプロパティを指定できます。これらのプロパティは、エンティティのスクリプト内のコンストラクターのようなものに直接渡されます。 ロードするエンジンのレベルを保存すると、エンティティとそれに関連付けられたプロパティのリストに分解されます。ブラシは「ワールドスポーン」エンティティに変換されます。 そのレベルをロードすると、すべてのエンティティがインスタンス化されます。簡単ですね。 さて、エンティティをネットワーク化するために、多くの問題に遭遇しました。最初に、最初からどのエンティティがクライアントに存在する必要がありますか？サーバーとクライアントの両方にレベルファイルがあると仮定すると、クライアントは、サーバー上のゲームルールのためだけに存在する場合でも、レベル内のすべてのエンティティをインスタンス化できます。 もう1つの可能性は、サーバーがその情報を送信するとすぐにクライアントがエンティティをインスタンス化することです。つまり、クライアントは必要なエンティティのみを持つことになります。 別の問題は、情報の送信方法です。サーバーはデルタ圧縮を使用できると思います。つまり、フレームごとにクライアントにスナップショットを送信するのではなく、何かが変更されたときにのみ新しい情報を送信します。ただし、サーバーは各クライアントが現時点で知っていることを追跡する必要があります。 最後に、ネットワークをエンジンにどのように注入する必要がありますか？ネットワーク化されることになっているすべてのエンティティに注入されるNetworkComponentというコンポーネントを考えています。しかし、どのようにネットワークコンポーネントの知っておくべきどのようなネットワークへの変数は、とどのようにそれらにアクセスするために、そして最終的にクライアントに対応するネットワークコンポーネントは、ネットワーク変数を変更する方法を知っている必要がありますか？ 私はこれに近づくのに大きな問題を抱えています。あなたが途中で私を助けてくれたら本当に感謝しています。コンポーネントシステムの設計を改善するためのヒントも受け付けていますので、提案することを恐れないでください。

33 networking  component-based 

エンティティ・システム（約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 

コンポーネントベースのゲームを実装する方法を検討しています。それはホットなものであるように思われ、このような柔軟なデザインのアイデアが気に入っています。このような設計の機能の1つは、データを介してゲームに新しいものを追加できることです。多くの場合、XMLなどのテキストファイルを介してコンテンツをロードすることで表示されます。これには、人間が読むことができ、テキストエディタで簡単に編集できるという利点があります。欠点として、テキストの処理が遅くなる可能性があり、データファイルの大規模なコレクションを管理する必要があります。JSONや設定ファイルのような類似のテキストベースの形式には、同様の利点があります。 反対側には、SQLiteやTokyo Cabinetなどの小さくてポータブルなデータベースがあります。人間が直接読むことはできませんが、これらのファイルは簡単にインターフェイスでき、ゲームコンテンツのデザインには何らかの編集ツールが適していると思います。DBを使用すると、構成情報を一貫して保存し、簡単に取得できます。ゲームを保存するために、データをDBにシリアル化することもできます。 パフォーマンスに関しては、一般的にXMLは小さいファイルの方が速いと思いますが、データベースは大量のデータに適しています。実際のゲームには、ゲームオブジェクトがたくさんあると思います。 質問：望ましいアプローチはどれですか？私はDBに傾いていますが、テキストファイルに隠れた落とし穴や本当に強い利点があるかどうかを知りたいです。または、これら以外の選択肢がある場合（バイナリ形式にシリアル化すると思いますか？）

29 component-based  databases  xml  data  configuration 

コンポーネントベースの設計に頭を悩ませ始めたところです。これを行う「正しい」方法が何であるかはわかりません。 これがシナリオです。プレイヤーはシールドを装備できます。シールドはプレイヤーの周りにバブルとして描かれ、個別の衝突形状を持ち、プレイヤーがエリア効果から受けるダメージを減らします。 コンポーネントベースのゲームでは、このようなシールドはどのように設計されていますか？ 混乱するのは、シールドに明らかに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 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 コンポーネントベースのゲームプログラミングパラダイムは、はるかに人気が高まっています。再利用可能なコンポーネントフレームワークを提供するプロジェクトはありますか？どの言語でも、私はそれを気にしないと思います。私自身のプロジェクトのためではなく、ただ興味があります。 具体的には、基本Entityクラス、基本Componentクラス、およびおそらくいくつかの標準コンポーネントを含むプロジェクトがありますか？ホイールを再発明したくない場合、またはGraphicsComponentDirect3Dでスプライトを実行したい場合は、ゲームを開始するのがはるかに簡単になりますが、既に何十回も実行されていることがわかります。 すばやくグーグルでRusherが表示されます。誰もがこれを聞いたことがありますか？人気のあるものがない場合は、なぜですか？このようなものを再利用可能にするのは難しすぎますか？私自身の実装では、フレームワークに押し込められるボイラープレートがたくさん見つかりました。

25 component-based 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 ステートマシンは、コンポーネントベースのアーキテクチャで有害な依存関係を引き起こすようです。 具体的には、状態マシンと状態関連の動作を実行するコンポーネントとの間の通信はどのように処理されますか？ 私がいる場所： コンポーネントベースのアーキテクチャは初めてです。 私は格闘ゲームを作っていますが、それは重要ではないと思います。ステートマシンを使用して、「クラウチング」、「ダッシュ」、「ブロッキング」などの状態を切り替えることを想定しています。 この状態管理手法は、コンポーネントベースのアーキテクチャにとって最も自然なシステムであることがわかりましたが、これまでに読んだ手法とは矛盾しています： 可変動作文字の動的ゲームオブジェクトコンポーネントシステムすべてのコンポーネントをアクティブ化/非アクティブ化することをお勧めしますアクティベーションの条件を継続的にチェックすることにより、自分自身。 「実行中」または「ウォーキング」などのアクションは状態として理にかなっていると思います。これは、https：//gamedev.stackexchange.com/a/7934で受け入れられている応答とは一致しません。 これは便利ですが、あいまいです。コンポーネントベースのゲームアーキテクチャに動作を実装する方法は？ステートマシンのみを含む別のコンポーネントを使用することをお勧めします。ただし、これには、ステートマシンコンポーネントと他のほぼすべてのコンポーネントとの間に何らかの結合が必要です。このカップリングがどのように処理されるべきか理解できません。これらはいくつかの推測です： A. コンポーネントはステートマシンに依存します。コンポーネントは、列挙定数を返す ステートマシンコンポーネントへの参照を受け取りますgetState()。コンポーネントは定期的に自身を更新し、必要に応じてこれを確認します。 B. ステートマシンはコンポーネントに依存します。 ステートマシンコンポーネントは、監視しているすべてのコンポーネントへの参照を受け取ります。getState()メソッドを照会して、どこにいるかを確認します。 C. それらの間のいくつかの抽象化 イベントハブを使用しますか？コマンドパターン？ D. コンポーネントを参照する個別の状態オブジェクト状態 パターンが使用されます。コンポーネントのセットをアクティブ化/非アクティブ化する個別の状態オブジェクトが作成されます。状態マシンは状態オブジェクトを切り替えます。 アスペクトの実装としてコンポーネントを見ています。彼らはその側面を実現するために内部的に必要なすべてを行います。コンポーネントは、他のコンポーネントに依存せずに、単独で機能する必要があるようです。いくつかの依存関係が必要であることは知っていますが、ステートマシンはすべてのコンポーネントを制御したいようです。

23 architecture  ai  component-based  fsm 

私はしばらくの間、コンポーネントベースのエンティティシステムに興味があり、その上で数え切れないほどの記事を読んでいます（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 

プレイヤーと敵のAIをゲームに実装し始めていますが、これをコンポーネントベースのゲームアーキテクチャに最適に実装する方法について混乱しています。 次のプレイヤーキャラクターがいて、静止したり、走ったり、剣を振ったりできるとします。プレイヤーは、静止状態とランニング状態の両方からスイングソード状態に移行できますが、プレイヤーが立ち上がったり走り回ったりする前にスイングを完了する必要があります。スイング中、プレーヤーは歩き回ることができません。 ご覧のとおり、2つの実装アプローチがあります。 すべてのプレーヤーロジックを含む単一のAIコンポーネントを作成します（実際のコンポーネントから切り離されるか、PlayerAIComponentとして埋め込まれます）。プレーヤーエンティティを構成する個々のコンポーネント間の結合を作成せずに、状態制限を強制する方法を簡単に実行できます。ただし、AIコンポーネントは分割できません。たとえば、立ち上がって歩き回るだけの敵や、歩き回って剣を振り回すだけの敵がいる場合、新しいAIコンポーネントを作成する必要があります。 動作をコンポーネントに分割し、それぞれが特定の状態を識別します。次に、SandComponent、WalkComponent、SwingComponentを取得します。移行ルールを実施するには、各コンポーネントを結合する必要があります。SwingComponentは、スイングの間、StandComponentとWalkComponentを無効にする必要があります。たまに剣を振り回すだけの敵がいる場合、SwingComponentが存在する場合にのみWalkComponentを無効にする必要があります。これにより、より良いコンポーネントの組み合わせが可能になりますが、依存関係が追加されるたびに保守性の悪夢につながる可能性があります。既存のコンポーネントは、依存関係がキャラクターに課す新しい要件でうまく動作するように更新する必要があります。 理想的な状況は、エンジンやスクリプトコードの1行に触れることなく、コンポーネントをコンテナにドラッグすることで、デザイナーが新しい敵/プレイヤーを構築できることです。スクリプトのコーディングを回避できるかどうかはわかりませんが、できるだけシンプルに保ちたいと思います。 すべてをまとめる：すべてのAIロジックを1つのコンポーネントに分割するか、各ロジック状態を個別のコンポーネントに分割して、エンティティバリアントをより簡単に作成する必要がありますか？ 編集：私は私が最初と2番目の状況で何を意味したかについていくつかの混乱があると思う。以下の図で説明しようとしました。 個々の状態とエンティティ間の関係に注意してください。最初の状況では、AIコンポーネントはエンティティに配置される前に事前に構築されます。デザイナーが選択できるのは、プログラマーが利用できるAIComponentsの異なるセットからのみです。2番目の状況には、他のコンポーネントと同じレベルの異なる状態があります。設計者は、プログラマーの干渉なしに、独自のAIでエンティティを作成できるようになりました。 問題は、これらがコンポーネントベースのエンティティでAIを構築するための2つのオプションであり、もしそうなら、最大の柔軟性を与えるものは何ですか？

21 architecture  ai  component-based