ゲームサブシステムにゲームオブジェクトコンポーネントを登録しますか？（コンポーネントベースのゲームオブジェクトデザイン）

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

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

登録の仕組みでは必要ありComponentsでGameSubsystems（ときGameObjectに作成および構成されているが）。4つのアプローチがあります。

• 1：一連の責任パターン。すべてComponentがすべてに提供されますGameSubsystem。GameSubsystemどちらComponentsを登録するか（およびそれらを整理する方法）を決定します。たとえば、GameSubsystemRenderはレンダリング可能コンポーネントを登録できます。

プロ。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 *）のようなものを呼び出します。

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

詐欺。Componentsとうまく結合されていませんGameSubsystems。

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

プロ。ComponentsそしてGameSubystemsお互いについて何も知りません。

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

質問： どのアプローチがより優れており、コンポーネントベースの設計で主に使用されていますか 練習は何を言いますか？の実装に関する提案はありApproach 4ますか？

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

ドア番号3 ...コンポーネントは自身をGameSubsystemに登録します

コンポーネントは、カップリングをGameObject自体から抽象化しておくために配置されています。どういうわけか、どこかで実際に何かがサブシステムと相互作用する必要があり、これがコンポーネントとその目的です。

この場合、結合は実際には悪いことではありません。

この場合、基本的にパフォーマンスが必要ですが、システムに複雑さが予想される場合、他のオプションの検索スタイルのアプローチを利用する余裕はありません。

最後に、あるサブシステムが別のサブシステムに反応する必要がある場合（レンダラー、物理、オーディオはすべて、何かが発生したときに何かを行う必要があります）、コンポーネントはゲームオブジェクトを通じて相互にこれを促進し、この特定のタイプのシステム間カップリングをコンポーネント。