7

コンポーネント ベースのゲーム オブジェクト システムを作成しています。いくつかのヒント：

  1. GameObjectの単なるリストですComponents。
  2. ありますGameSubsystems。たとえば、レンダリング、物理などです。それぞれGameSubsystemに、いくつかの へのポインタが含まれていますComponents。GameSubsystemは非常に強力で柔軟な抽象化です。ゲーム世界のあらゆるスライス (または側面) を表します。

Components登録する仕組みGameSubsystems（GameObject作成・合成時）が必要です。4 つのアプローチがあります。

  • 1:責任パターンの連鎖。EveryComponentは every に提供されますGameSubsystem。GameSubsystemどちらComponentsを登録するか (およびそれらをどのように編成するか) を決定します。たとえば、GameSubsystemRender は Renderable Components を登録できます。

プロ。Componentsそれらがどのように使用されているかについては何も知りません。低カップリング。A.新規追加できGameSubsystemます。たとえば、すべての ComponentTitle を登録し、すべてのタイトルが一意であることを保証し、タイトルでオブジェクトを照会するためのインターフェイスを提供する GameSubsystemTitles を追加しましょう。もちろん、この場合、ComponentTitle を書き換えたり、継承したりしてはなりません。B.既存の を再編成できGameSubsystemsます。たとえば、GameSubsystemAudio、GameSubsystemRender、GameSubsystemParticleEmmiter を GameSubsystemSpatial にマージできます (すべてのオーディオ、エミッター、レンダリングComponentsを同じ階層に配置し、親相対変換を使用するため)。

コン。毎回チェック。非常に非効率的です。

コン。Subsystemsについて知っていComponentsます。

  • 2: それぞれが特定のタイプSubsystemを検索します。Components

プロ。よりも優れたパフォーマンスApproach 1。

コン。Subsystemsまだ知っていComponentsます。

  • 3:Component自分自身を に登録しGameSubsystem(s)ます。コンパイル時に GameSubsystemRenderer があることがわかっているので、ComponentImageRender は GameSubsystemRenderer::register(ComponentRenderBase*) のようなものを呼び出します。
    オブザーバーのパターン。Component"update" イベント (によって送信されGameSubsystem(s)ます) をサブスクライブします。

プロ。パフォーマンス。Approach 1やのような不要なチェックはありませんApproach 2。

コン。Componentsとひどく結合していGameSubsystemsます。

  • 4:メディエーターパターン。GameState( を含むGameSubsystems) registerComponent(Component*) を実装できます。

プロ。ComponentsそしてGameSubystemsお互いに何も知らない。

コン。C++ では、醜く遅い typeid-switch のように見えます。

質問: コンポーネント ベースの設計で最もよく使用されているアプローチはどれですか? プラクティスは何と言っていますか？の（データ駆動型）実装に関する提案はありApproach 4ますか？

ありがとうございました。

4

2 に答える 2

2

3番目のアプローチに投票します。

私は現在、コンポーネントベースのゲームオブジェクトシステムに取り組んでおり、このアプローチのいくつかの追加の利点をはっきりと見ています。

  • コンポーネントは、利用可能なサブシステムのセットにのみ依存するため、ますます自給自足のサブエンティティになります（このセットはプロジェクトで修正されていると思います）。

  • データ駆動型設計がより適切です。理想的には、この方法で、コンポーネントがデータの観点から完全に定義されているが、C++では定義されていないシステムを設計できます。

編集：CBGOSに取り組んでいるときに私が考えた1つの機能。サブシステムのないパッシブコンポーネントを設計および構築する機能があると便利な場合があります。これが頭に浮かぶときは、4番目のアプローチが唯一の方法です。

于 2010-10-18T11:40:24.140 に答える
1

私のアプローチは、各サブシステム内にプロキシ パターンを実装することでした。各サブシステムは、各エンティティに含まれる可能性のあるコンポーネント全体のサブセットのみに関心があるため、プロキシは、システムが関心を持つコンポーネントのみへのポインタを格納します。たとえば、モーション システムは位置と速度のみを気にするため、それらのコンポーネントへの 2 つのポインター。エンティティにそれらの 1 つ以上が欠けている場合、サブシステムはそれを無視します。両方のコンポーネントが存在する場合、プロキシ ノードが作成され、内部コレクションに追加されます。また、プロキシがエンティティの一意の識別子の値を格納することも有用です。これにより、必要に応じて各サブシステムからプロキシを一定時間で追加/削除できます。

このようにして、エンティティをエンジンから削除する必要がある場合、エンティティの ID を含む単一のメッセージをすべてのサブシステムに送信できます。プロキシは、各サブシステム コレクションから個別に削除できます。

于 2014-06-26T06:54:58.493 に答える