私はコンポーネントベースのゲームオブジェクトを設計しています建築。私の状況では、私はレンダラと物理オブジェクトを持っています。レンダリングシーンにはレンダリング可能なものが含まれています。物理シーンには物理オブジェクトが含まれています。レンダリング可能な物理オブジェクトを持つゲームオブジェクトがあります。これらのそれぞれは、絶対にゼロの結合をしています。それらは別々のライブラリにもある。
ゲームの最も明白なデータの1つオブジェクトのニーズは位置と回転です。レンダリング可能オブジェクトと物理オブジェクトの両方がこの情報を読み取り、場合によってはそれに書き込む必要があります。コンポーネントではなく、ゲームに固有の情報を処理するためのいくつかの効率的な方法は何ですか。
回答：
回答№1は2これは私にとってはちょっと変わったアーキテクチャのようです - 2つの別々のシーングラフを同期させるために多くの作業を強いられるので、それらを完全に切り離すことは不可能だと思うでしょう（問題で説明している状況は一例ですが、もっとたくさんあるでしょう）。 ……）
私はあなたが単一のゲームについて考えることを奨励しますオブジェクトグラフオブジェクトごとに物理戦略とレンダリング戦略を設定することはできますが、それらを別々のオブジェクトグラフではなく、ゲームオブジェクトへの「プラグイン」として表示することをお勧めします。物理とレンダリングコンポーネントの両方からアクセスされます。
あなたが "tファンシー"ではない場合は、代替手段単一のゲームオブジェクトグラフに再構築することは、位置／回転情報を別々の構造に分離することであろう。ベクトルの大きな配列物理オブジェクトとレンダリングオブジェクトはどちらもこの構造へのアクセスを共有できます。
これは次のことを意味します。
- PhysicsオブジェクトとRenderオブジェクトはどちらも（インデックスを直接保存するか、何らかの形のハッシュルックアップによって）配列内の自分の位置のインデックスを知る必要があります。
- PhysicsオブジェクトとRenderオブジェクトはどちらも、同じ位置/回転フォーマットに満足している必要があります。
- オブジェクトが作成されたり破壊されたりすると、余分な簿記が必要になる
- 並行処理については少し注意が必要です。たとえば、レンダリング中に新しいPhysicsオブジェクトが追加された場合はどうなりますか。
全体的に私はこれがあなたに多くの利益をもたらすことを確信していません......しかし、もしあなたがサードパーティの物理学ライブラリの設計のような何か他の制約があればそれは意味があるかもしれません。