ゲーム エンジンの階層化アーキテクチャ (トップダウン)
ツール層
現代のゲームエンジンにおいて、最初に目に入るのは複雑なコードではなく、さまざまなエディターであり、これらのエディターを使用して、レベル、キャラクター、アニメーションなどを作成およびデザインできます。エンジンのレイヤー - ツールレイヤー。
機能層
- 3 次元の仮想世界をフレームごとの 2 次元画像に変換するプロセスには、レンダリング システム (レンダリング) の使用が必要です。
- 静止したモデルを動かし、本物のような動きをさせて連続的な画像を形成するには、アニメーション システム (Animation) を使用する必要があります。
- 物理的な衝突やさまざまな力の作用により、物体の動きは現実世界に近づくため、物理システム (物理学) を使用する必要があります。
- 各ゲーム世界には独自のルールがあり、スクリプト (Script)、ステート マシン (FSM)、AI の使用を必要とするゲームのプレイアビリティを強化する NPC もあります。
どのようなゲームの操作も、一連の機能を伴う人間とコンピューターの相互作用から切り離すことはできません。上記の機能を組み合わせて、ゲーム エンジンの機能層を形成します。
Resource Layer
ゲームには、ソース コード行だけでなく、PhotoShop の PSD ファイルや 3DSMAX の MAX ファイルなど、さまざまな形式のマルチメディア ファイルも含まれており、これらの一連のグラフィックス、画像、オーディオ、ビデオ ファイル、その他のデータが読み込まれて管理されます。リソース層のタスク。リソース層は機能層の下に位置し、機能層に継続的にデータを提供し、上に絵を描く画家のようなもので、下にリソース層が継続的に絵の具を提供します。
コア レイヤ
ゲーム エンジンの最もコアで最も重要なレイヤはコア レイヤです。コア層は、上位層からの頻繁な呼び出しに応答し、メモリ管理、コンテナ割り当て、データ計算、マルチスレッド作成などのさまざまな基本機能を提供する役割を果たします。
プラットフォーム層
プラットフォーム層は最も見落とされやすい層です。ゲームやエンジンは異なるプラットフォームでリリースされ、異なるグラフィカル インターフェイスを持つ場合があり、異なるユーザーはキーボード、マウス、コントローラなどの異なるハードウェア デバイスを使用する場合があります。さまざまなプラットフォームに適応するのは、プラットフォーム層のタスクです。
サードパーティ ライブラリ
ミドルウェアおよびサードパーティ ライブラリは、SDK (ソフトウェア開発キット) 形式またはファイル形式に変換されます。
なぜ階層構造を採用するのでしょうか?
ゲーム エンジンを分離して複雑さを軽減するために、各層は独自のタスクを独立して実行します。下位層は基本的なサービスを上位層に提供し、上位層は基礎となるツールを呼び出します。このような階層化されたアーキテクチャにより、上位層は柔軟になり、下位層は安定するため、機能の更新と開発がより容易になります。
リソース層
Photohop の PSD ファイルや 3DSMAX の MAX ファイルなどは、一般にツール独自の情報やエンジンとは関係のない大量のデータが含まれており、データ形式も比較的複雑であるため、そのまま使用すると効率が大幅に低下します。リソースのスケジュール設定の効率を向上させるために、エンジンはインポート時にさまざまなリソースをアセット ファイルに変換する必要があります。たとえば、エンジンでテクスチャ ファイルを使用する場合、JPG および PNG 形式でファイルをインポートすることがあります。ただし、これら 2 つのファイルの圧縮アルゴリズムは GPU にとって効率的ではありません。これらを GPU で直接使用するとパフォーマンスが無駄になるため、通常は dds に変換され、その形式はビデオ メモリに保存されます。
上の図の小さなロボットなどのゲーム キャラクターの場合、対応するマテリアル、テクスチャ、グリッド、アニメーション、その他のリソースをバインドし、XML ファイルなどのこれらのリソースを関連付ける複合アセット ファイルを定義し、GUID を使用する必要がある場合があります。 (Globally Unique Identifier) シンボル) を識別管理に使用します。
実際にゲームを実行する際には、アセット ライフ サイクル (Asset Life Cycle) に従ってアセットを管理するアセット マネージャー (Runtime Asset Manager)、アセットのリアルタイムのロードとアンロード、リソースの割り当て、ガベージ コレクションも使用する必要があります。 (GC).、読み込み遅延などが含まれます。
機能層
機能レイヤーを使用すると、ティックが通過するたびにゲーム内の仮想世界が前進します。ティック内では、tickLogic() 関数と NickRender() 関数がそれぞれ実行されます。論理的 NickLogic() は通常最初に実行され、主に入出力処理、カメラの視点位置の変換、衝突検出、 etc. 操作; 世界を描画するために使用されるtickRender()は、tickLogic()によって計算された各アセットの位置に基づいてレンダリングされます。
機能層は、特にネットワーク プログラミングに関しては非常に複雑かつ大規模であるため、通常はマルチスレッド コンピューティングが必要です。現在主流のマルチスレッドは、並列計算できるタスクを分割し、複数のスレッドに分けて計算するというものですが、並列計算に適さないタスクがあるとその欠陥が露呈してしまいます。将来的には、エンジンは各タスクを非常に小さな実行可能ユニットに分割し、各アトミック タスクを複数のスレッドに割り当てて実行することで、リソースをより効率的に使用できるようになります。
コア層
コア層は、上位層のすべてのロジックの基盤を提供し、数学ライブラリ (行列演算など)、データ構造とコンテナ (バイナリ ツリーなど)、メモリ管理、その他のツールを提供します。エンジン内のすべては効率を重視しているため、数学演算を実行するときは、近似演算または SIMD (単一命令を複数のデータ ストリームで同期的に同時に実行する) を使用して計算効率を向上させることができます。構造とコンテナ。プログラミング言語に付属するデータ構造は、いくつかの問題を引き起こす可能性があります。たとえば、C++ の Vector によって開かれるストレージ スペースは、オブジェクトを追加すると指数関数的に増加します。大量のオブジェクトを追加した後は、ストレージ スペースを使用するためです。メモリ ホールが発生する可能性があることが知られていますが、エンジン内のデータ構造はメモリ管理に便利で、アクセス効率が向上します。エンジンのメモリ管理はオペレーティング システムのメモリ管理と非常に似ています。基本原則は次のように要約できます: データをできるだけまとめて保存し、簡単にアクセスできるようにする 順番にアクセスし、バッチで処理する
プラットフォーム層
プラットフォーム レイヤーにより、ゲームは Xbox、Mac、Windows などのさまざまなプラットフォームや、コントローラー、キーボード、マウスなどのさまざまなデバイスと互換性が得られます。プラットフォーム層は、レンダー ハードウェア インターフェイス (RHI) を使用して、異なるグラフィックス API (DirectX11、DirectX12、OpenGL など) 間の差異を除去するため、上位層は、異なる API の使用によって発生する可能性のある問題を気にする必要がありません。
ツールレイヤー
ツール層は通常、エディター (ブループリント エディター、マテリアル エディターなど) の形式で表示され、さまざまなプログラミング言語 (C++、C#、Html5 など) を使用して開発でき、開発効率が優先されます。さまざまなユーザーがゲーム コンテンツを作成できるようにします。多くのゲーム デジタル アセットはさまざまな DCC (Blender、MAYA など) で作成されるため、ツール レイヤーには通常、ゲーム リソースをインポートおよびエクスポートするためのインポート ツールとエクスポート ツールが含まれています。