1
ゲームサブシステムにゲームオブジェクトコンポーネントを登録しますか?(コンポーネントベースのゲームオブジェクトデザイン)
コンポーネントベースのゲームオブジェクトシステムを作成しています。いくつかのヒント: GameObjectは単にのリストですComponents。 あります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ますか? ありがとうございました。