Mike Acton の「Data-Oriented Design and C++」を見ましたが、非常に興味深いものでした。ただし、データの依存関係がどのように解決されるのかわかりません。
以下を備えた単純な 2D エンジンがあると想像してください。
グラフィックデータとサウンドデータは、物理データに格納されている位置に依存します。位置は物理データから参照できますが、私の意見では、それは国防総省の要点全体を殺してしまいます - 同じメモリ位置に必要なデータを持つことです。
このような状況は、データ指向設計ではどのように処理されますか?
DOD は、最初にデータを効率的に表現する方法に焦点を当てた、アーキテクチャを設計するためのより一般的な方法です。それを行う唯一の方法はありません。Linus Torvalds は、Linux カーネルや Git などに対してその考え方を示しましたが、それはゲームとはまったく異なる領域です。重要なことは、彼が何よりもまずデータを効率的に表現する方法に焦点を合わせたことです。
基本的な例として、画像処理アプリケーションを設計している場合、データ指向の方法で考えるのではなく、最も幅広いピクセル形式を最も簡単にサポートし、最も簡単なインターフェイスを考え出す方法に焦点を当てていたとします。使用すると、アブストラクトPixelや、ピクセルごとのヒープ割り当てさえ思いつくかもしれません。その時点で、仮想ポインター (多くの場合、ピクセル自体よりも大きい)、ピクセルごとの動的ディスパッチ、おそらく別の間接レイヤー、および潜在的に空間的局所性の完全な損失のコストを支払っています。代わりに、最初にデータを効率的に表現する方法を考えた場合、おそらくより粗い抽象化を行うでしょう。Imageピクセルごとのレベルでそのようなオーバーヘッドを支払わない場所で抽象化する場合は、レベル (ピクセルの抽象的なコレクション、おそらく特定の画像に対して数百万ピクセル)。
とはいえ、ゲームの場合、話している内容にアプローチする一般的な方法は、データを中央からアクセスできるようにすることです。これは SE の原則に違反しているように見えるかもしれませんが、通常、エンティティ コンポーネント システムのようなものを使用する場合、特定のタイプのコンポーネントは少数のシステムからのみアクセスされることがよくあります。その結果、そのデータの範囲は、不変条件を効果的に維持するのに十分なほど小さくなる傾向があります。
物理システムで 2 つのエンティティが衝突し、サウンド システムがサウンドを再生するなど、ゲーム内で発生する可能性のあるイベントについては、物理システムとサウンド システムをそれぞれから分離しておくための多くのアプローチがあります。他の。1 つは、イベント キューを使用することです。
あるシステムで必要なデータが別のシステムでも共有されている場合、これは一般的に非常に実用的です。これらのシステムを互いに並行して実行したい場合でも、共有データをコピーし、場合によっては更新し、何らかの方法で結果を調整する必要があります。とはいえ、私の意見では、それをいじることを避け、システムが行っていることを並列化する (例: 並列 for ループを使用する) 方がはるかに生産的です。通常、ECS にはホットスポットであるシステムはほんの一握りしかないからです。多くのシステムを同時に実行しようとしたり、ワームの可能性を開いたりすることなく、これらの特定のシステムの作業をスレッド間で簡単に分散できます。