問題タブ [component-based]

私が作成している 2D ゲーム (Android 用) では、GameObject が複数の GameComponent オブジェクトを保持するコンポーネント ベースのシステムを使用しています。GameComponents には、入力コンポーネント、レンダリング コンポーネント、弾丸放出コンポーネントなどがあります。現在、GameComponents はそれらを所有し、それを変更できるオブジェクトへの参照を持っていますが、GameObject 自体はコンポーネントのリストを持っているだけで、オブジェクトが更新されたときに更新できる限り、コンポーネントが何であるかは気にしません。

コンポーネントには、GameObject が知る必要のある情報が含まれている場合があります。たとえば、衝突検出の場合、GameObject はそれ自体を衝突検出サブシステムに登録して、別のオブジェクトと衝突したときに通知を受けます。衝突検出サブシステムは、オブジェクトのバウンディング ボックスを認識する必要があります。x と y をオブジェクトに直接格納します (複数のコンポーネントで使用されるため) が、幅と高さは、オブジェクトのビットマップを保持するレンダリング コンポーネントにしかわかりません。その情報を取得するメソッド getBoundingBox または getWidth を GameObject に入れたいと思います。または、一般的に、コンポーネントからオブジェクトに情報を送信したいと考えています。しかし、私の現在の設計では、GameObject はリストにある特定のコンポーネントを認識していません。

この問題を解決するには、いくつかの方法が考えられます。

1. コンポーネントの完全に一般的なリストを用意する代わりに、GameObject にいくつかの重要なコンポーネント用の特定のフィールドを持たせることができます。たとえば、renderingComponent というメンバー変数を持つことができます。使用するオブジェクトの幅を取得する必要があるときはいつでもrenderingComponent.getWidth()。このソリューションでは、コンポーネントの一般的なリストを引き続き使用できますが、一部のコンポーネントの扱いが異なります。より多くのコンポーネントを照会する必要があるため、いくつかの例外的なフィールドが発生することになるのではないかと心配しています。一部のオブジェクトには、レンダリング コンポーネントさえありません。

2. 必要な情報を GameObject のメンバーとして保持しますが、コンポーネントがそれを更新できるようにします。したがって、オブジェクトの幅と高さはデフォルトで 0 または -1 ですが、レンダリング コンポーネントは更新ループでそれらを正しい値に設定できます。これはハックのように感じられ、すべてのオブジェクトがそれらを必要としない場合でも、利便性のために多くのものを GameObject クラスにプッシュすることになる可能性があります。

3. 照会できる情報の種類を示すインターフェースをコンポーネントに実装させます。たとえば、レンダリング コンポーネントは、getWidth や getHeight などのメソッドを含む HasSize インターフェイスを実装します。GameObject が幅を必要とする場合、そのコンポーネントをループして HasSize インターフェイスを実装しているかどうかを確認します ( Java またはC# でinstanceofキーワードを使用)。isこれはより一般的な解決策のように思えますが、欠点の 1 つは、コンポーネントの検索に時間がかかる場合があることです (ただし、ほとんどのオブジェクトには 3 つまたは 4 つのコンポーネントしかありません)。

この質問は特定の問題に関するものではありません。それは私のデザインで頻繁に出てきて、それを処理する最善の方法は何だろうと考えていました。これはゲームであるため、パフォーマンスは多少重要ですが、オブジェクトあたりのコンポーネントの数は一般的に少なくなります (最大 8)。

ショートバージョン

ゲームのコンポーネント ベースのシステムで、一般的なデザインを維持しながら、コンポーネントからオブジェクトに情報を渡す最良の方法は何ですか?

私は最近、エンティティ システム アーキテクチャを発見しました。C++ でそれを実行するのは困難であり、実装を理解することもできません。

エンティティ システムの見方:

コンポーネント: 属性、set および get を持つクラス。

1. スプライト
2. 物理体
3. 宇宙船
4. ...

System : コンポーネントのリストを持つクラス。

1. リスト項目
2. エンティティマネージャー
3. レンダラー
4. 入力
5. カメラ
6. ...

Entity : コンポーネントのリストを持つ単なる空のクラス。

私がやったこと：

現在、私はそれを可能にするプログラムを持っています:

EntitySystem を正しく理解していれば、各システムには、それが動作するコンポーネントの独自のリストがあります。（コンポーネントのリストまたはエンティティのリスト、それが問題です）

(高速デバッグのためだけにコードを .h に入れました ^^)

問題

X コンポーネントのリストを持つシステムに「T」コンポーネントを追加したい

私が試したこと：

しかし、私はそのようなものが欲しい:

私の System クラスは抽象的です。私のシステムの子クラスには、このリストが独自のタイプである必要があります。

解決 ：

System クラスにテンプレート クラスを持たせようとしたので、次のようにしました: class Renderer: System

しかし、私の SystemManager はこのコードが好きではありません: std::vector<System> systems.

T タイプのシステム クラス:

SystemManager コード:

これにより、SystemManager に次のエラーが表示され ます 。

この問題の解決策はありましたか? 私のEntitySystemアプローチは良かったですか？

ありがとう！

私はゲームを開発する学校のプロジェクトに取り組んでいます。私たちは、私たちが持っているチームの1つによって作られたエンジンを使用しています. エンジンのビルドアップは私には不明確であり、アンチパターンのようです. しかし、誰も私にデザインの選択を明確にすることはできないようです. エンジンは「コンポーネントベース」の設計を使用することになっていますが、私にはわかりません。以下は、Component、Composite、および Entity クラスの両方のコードです。簡単に言えば、私の質問は次のとおりです。このコードは有効な設計パターンを使用していますか、それとも「設計パターンを実装する」ためだけに複雑すぎて、アンチパターンを引き起こしていますか?

コンポーネント.cpp:

エンティティ.cpp

コンポジット.cpp

次のコードは Player.cpp で、複合型とエンティティの両方をハイブリッド型のオブジェクトとして使用しています (ロジックがよくわかりません)。

Player.cpp

これがコンポーネントベースの設計であるとはまったく思いません。エンティティを削除せず、コンポジットとコンポーネントのみを使用してください。コンポーネントの基本クラスを空にして直接使用してはいけませんか? Rigidbody データのデータ構造を保持する「Rigidbody」と呼ばれるコンポーネントと、完全に仮想的なコンポーネントの基本クラスをオーバーライドするいくつかの関数のように?

関数型プログラミング (LISP、Haskell など) や OOP プログラミング (Java、C#、Ruby、Python など) 用の言語があることは知っていますが、エンティティ コンポーネント プログラミングの概念に基づいて作成された言語はありますか?

エンティティ コンポーネント システムは、ゲーム開発におけるオブジェクト指向プログラミングで発生するスケールの問題を解決することができます。ECS に関していくつか質問があります。

概要を説明すると、いくつかのコンポーネント (データを持つ) を含むエンティティと、歩行ロジック、戦闘ロジックなどのロジックを持つシステムがあります。したがって、どのゲームでも、敵はエンティティであり、ヒーローは独自のシステムを持つエンティティなどです。各プレイヤー/敵はエンティティになります。

1. 最初は、ステージ、グループ、およびアクターを使用していました。ステージは、階層を使用してアクターにイベントを渡し、イベントに基づいてそれを処理していました。私はエンティティを持っているので、何が私の新しいアクターになりますか? すべてのエンティティがアクターになりますか? はいの場合、各行為で、すべてのコンポーネントの更新関数を呼び出し、描画関数で描画しますよね?
2. エンティティ コンポーネント システムはアクターのみに使用されますか、それともステージ、グループ、カメラにも使用する必要がありますか? すべての人に使用する必要がある場合、誰かがその方法を理解するのを助けることができますか?

オブジェクト指向では、グループにアクターを追加し、適切なタスクを実行するイベントに基づいてアクターにイベントをステージ送信するので簡単です。ECS で考えるのは初めてなので、何かが足りない場合は申し訳ありません。コードを書き始めましたが、システム全体を考えているうちに混乱してしまいました。役者の仕事の仕方はわかったけど、それをグループや舞台、カメラなどでどうやって働かせるか。

少し前にゲームを作り始めて、とても好きなスタイルに出くわしました。コンポーネントベースのアーキテクチャと呼ばれます。チュートリアルは C++ ではなく Objective-C 用ですが、とにかくリンクを含めました: http://www.raywenderlich.com/24878/introduction-to-component-based-architecture-in-games

プロジェクトからプロジェクトへと大量のコードをコピー アンド ペーストしていることに気付いたので、一般的なフレームワーク用のライブラリを作成することにしました。通常、コンポーネントは次のようにエンティティ オブジェクトに含まれます。

ライブラリには個々のコンポーネントではなく、一般的なフレームワークが含まれるため、この方法は機能しなくなります。代わりにComponentManager、コンポーネントを管理するクラスを作成しました。現在、エンティティは次のようになっています。

これらの関数はまだ定義していないため、実装ファイルは含めませんでした。

ComponentReference構造体は単に、特定のコンポーネントを見つけるために使用される int と文字列のコレクションです。エンティティは、特定のオブジェクトの内部リストを検索ComponentReferenceする のテンプレート化された関数に を渡します。managerそして、レンガの壁があります。さまざまな未知のタイプの未知の数のオブジェクトを含むリストを作成する方法がわかりません。これらは親Componentクラスから派生していますが、すべて異なる関数とメンバー変数が含まれています。ポインターの配列と型キャストを使用しようとしましたが、3 時間後に、型キャストへの過度の依存は不適切に記述されたコードの指標であると読んだときに断念しました。

STL コンテナーを使用してみましたが、1 つの型しか必要としないため、明らかに機能しません (テンプレート クラスへのポインターを含む C++ std::vector ) 。

私はラッパーについて何かを見ましたが、私が読んだものから、それらは関数でのみ機能するようです: ( c++ store a pointer to a member function of unknown class ) それらが私の問題を解決するために使用できる場合は、それらがどのように機能するかを説明してください (私は今日まで聞いたことがない）

これは私の最初の質問なので、お気軽にフィードバックを残してください。調べたのですが、重複していたらすみません。私は C++ を初めて使用するわけではありませんが、専門家でもありません。また、C++ は大きな言語であるため、説明を求める場合があります。前もって感謝します！

現在、XNA を使用してゲームを構築しており、現在、ゲーム オブジェクト コンポーネントを次のように設定しています。

メニュー システムを作成して以来、データ コンテナー タイプのオブジェクトをいじってみました。たとえば、DataContainer の基本クラスと、IntContainer、FloatContainer などのサブクラスがあるとします。サブクラスに応じて、含まれているデータ型を返します。このメニュー システムをコンポーネントに接続して、簡単に編集できるようにしたいのですが、コンポーネントを変更して、明示的に型指定されたデータの代わりに汎用データ コンテナーを保持するこのモデルを採用する必要があるかどうか疑問に思っています。 :

上記のように適切な名前のメソッドを保持できるため、コードで名前を指定して値を取得することは依然として簡単です。私のエンジンをこのデータ ストレージの方法に切り替えるには少し作業が必要です。値を直接取得するよりも、値を取得するために 2 つのメソッドを呼び出す方が悪いですか?

GameObject私のコンポーネント ベースのゲーム エンジンの抽象的な実装は次のとおりです。

ゲームオブジェクト

• 一意のID
• isActive フラグ
• コンポーネントの配列

コンポーネントベースの設計について読んでいて、気になった点の 1 つは、配列の線形トラバーサルがキャッシュによって高速であることです。そのため、基本的な配列を使用してエンティティ/ゲーム オブジェクトを保持することにしました。

もう 1 つ気になったのは、一部のリソースがコンポーネントをゲーム オブジェクトから切り離していたことです。彼らが代わりに行ったのは、エンティティ マネージャー内にマップを用意することでした。マップには、キーとしてゲーム オブジェクトがあり、値としてコンポーネントの配列がありました。この場合、AGameObjectは ID しか持っていませんでした。

GameObjectクラス内にコンポーネントを配置する代わりに、ゲーム オブジェクトをコンポーネントにアタッチするマップを使用する利点 (パフォーマンスおよび/または設計上の観点から) はありますか?

さらに、頻繁なメモリ割り当てを避けるために、 GameObjects はオブジェクトからプール (リサイクル) されます。Pool

私は、2D 用と 3D 用の 2 つの異なる変換クラスを持つカスタム エンジンに取り組んでいます。#define を使用して、使用する変換クラスを選択し、ロジックが同じであるべき場所でクラス名の代わりにその定義を使用しています。私は今、彼らに異なるロジックを持たせたいと思っており、そのために分岐するために比較をしたいと思っていました。これを機能させるにはどうすればよいですか?

そのためにタイプIDが機能しました。どのように扱いますか？

2 つのモデル: AnOwnerと a Dog:

owner.rb

dog.rb

そして、ここにスキーマがあります：

schema.rb

かなりシンプルなセットアップ。

彼を散歩ownerに連れて行きたい。dog散歩が終わると、飼い主の気力が5減り、犬の気力が20減る。

明らかに、このwalk_the_dogアクション/メソッドは、ownerオブジェクトとオブジェクトの 2 つのオブジェクトに影響を与えdogます (もちろん、この犬のオブジェクトはたまたまこの所有者に関連付けられています)。

このコードをどこに置くべきかわかりません。内で単純にアクションを作成できることはわかっていますがowners_controller.rb、それは悪い考えのように思えます。次のようになります。

owners_controller.rb

私が理解しているように、オブジェクトは自分自身の状態のみを変更する必要があり、他のオブジェクトの状態を変更するべきではありません。ownerオーナー コントローラ内でオブジェクトだけでなく、関連付けられたオブジェクトの状態も変更しているため、これは悪い考えのように見えdogます。

サービスについて読みました。walk_the_dog私が理解しているように、サービスはオブジェクト間の相互作用と複数のオブジェクトの状態変更を可能にするため、サービスの優れたケースのようです。私はそれを行う/実装する方法がわかりません。

と呼ばれるサービスオブジェクトが必要walk_the_dogですか? 一連のサービスメソッドを含むサービスディレクトリ内のファイルである必要があります-そのうちの1つが呼び出されwalk_the_dog、owners_controller.rbコントローラーでこのメソッドを使用するだけですか? 次のステップが何かわかりません。

注: 「これが OO 設計を壊すかどうかなんて誰が気にするんだろう。ただそれを実行して、うまくいくならうまくいく」と言っている人を見ることができます。残念ながら、これはオプションではありません。私が今取り組んでいるアプリケーションは、その考え方に従いました。アプリケーションが非常に大きくなり、現在は維持が非常に困難になっています。アプリの大幅なリニューアルでこの状況を打破したい。