技術者インタビュー: メトロ 2033

関係はありません。私が STALKER でリード プログラマーおよびテクノロジー アーキテクトとして働いていたとき、多くのアーキテクチャ上の決定が、設計当時には素晴らしかったものの、現在に適応できないことが明らかになりました。

STALKER エンジンの将来に対する主な障害は、本質的にマルチスレッドに対応できないこと、脆弱でエラーが発生しやすいネットワーキング モデル、そしてあらゆる種類のストリーミングを禁止するか、単にワーキング セットを小さく保つだけのひどいリソースとメモリ管理でした。 「次世代」コンソールには十分です。

もう 1 つ気になったのは、テキストベースのスクリプトです。 STALKER に取り組んでいるうちに、デザイナーや脚本家がより多くの制御を望んでいることが明らかになり、それを手に入れたとき、彼らは道に迷ってプログラマーのように考える必要がありましたが、彼らはプログラマーではありませんでした。それが STALKER の当初の遅延に大きく貢献しました

そこで私は、未来の建築を確立し、デザインの可能性を探るための個人プロジェクトを立ち上げました。プロジェクトは非常にうまく進化し、ゲームとしては機能しませんでしたが、デモとしても、当時はレンダリング エンジンがありませんでした。次に何をすべきかについて明確なビジョンを与えてくれました。

4A が独立したスタジオとしてスタートしたとき、この作品は将来のエンジンの基礎となりました。タイムスケールが厳しいため、作業を迅速に進めるために多くのミドルウェアを使用することにしました。物理学には PhysX、AI ナビゲーションには PathEngine、簡単な SVN マージのためにスクリプト エンジンではなく主要な開発ファイル形式として LUA、物理ネットワーク層には RakNet、顔アニメーションには FaceFX、サウンド形式には OGG Vorbis などを選択しました。圧縮ライブラリなどのその他の小さなもの。

レンダリングは約 3 週間で完了しました。ディファード シェーディングを使用する場合は簡単に実行できますが、最適化や機能豊富とは程遠いものでした。

エンジンの哲学が根本的に異なる場合、コードを共有することはほぼ不可能です。たとえば、C++ 標準テンプレート ライブラリなどの基本的なものは使用せず、STALKER にはコードの 2 行ごとに何らかの STL メソッドを呼び出します。 STALKER のゲームプレイ コードでも、主に更新/ポーリング モデルを使用していましたが、私たちはよりシグナルベースのモデルを使用しています。

したがって、最終的な答えは「いいえ」です。X-Ray と共有コードはありませんし、共有することも不可能です。

それは非常に難しいでしょう。すべてのテクスチャ、すべてのサウンド、すべてのジオメトリがなければ、ストレート ポートはメモリに収まりません。そして、1 秒あたり約 1 ～ 3 フレームで動作します。しかし、テクスチャとジオメトリがなければそれらのフレームは表示されないため、それは問題ではありません。これは私の個人的な意見ですが、おそらく GSC にとっては別の世代のコンソールを待つのが賢明でしょう。

主な焦点は、マルチスレッド モデル、メモリとリソースの管理、そして最後にネットワーキングです。

マルチスレッドの実装で最も興味深い/非伝統的な点は、PhysX スレッドを除いて、ゲーム内の特定のタスクを処理する専用のスレッドが存在しないことです。

すべてのスレッドは基本的なワーカーです。タスクモデルを使用しますが、事前調整や前後の同期は行いません。基本的にすべてのタスクは、生成された時点からロックなしで並列実行できます。タスクには相互依存関係はありません。これはタスクのツリーのように見え、システムの自己バランスを保つために、フレームの先頭にあるより重いタスクから開始されます。

サブシステム間にはいくつかの同期点があります。たとえば、PhysX とゲームの間、またはゲームとレンダラーの間などです。ただし、他のタスクによってクロスオーバーされる可能性があるため、アイドル状態のスレッドはありません。前回統計を測定したとき、Xbox 360 では、すべての HW スレッドが 100% の負荷で CPU を大量に使用するシーンで、30 ミリ秒のフレームあたり約 3,000 のタスクを実行していました。

ちなみにPS3もそこまで変わりません。 「ファイバー」を使用して 6 スレッド CPU を「エミュレート」すると、各タスクが SPURS (SPU) ジョブを生成して別のファイバーに切り替えることができます。これは一種の PPU オフロードであり、システムに対して透過的です。この美しいモデルの最終結果は、多少制限はありますが、ハードウェアの不足制限まで完全に線形にスケールアップできることです。

メモリとリソースの管理に関しては、ほとんどのコードで単純な古い C++ ポインタを使用せず、参照カウントされた強いポインタと弱いポインタを使用します。ところどころにアトミック操作とメモリバリアを少し加えることにより、マルチスレッドプログラミングのための非常に堅牢な基本ツールになります。

それは少し非効率的に聞こえますが、そうではありません。 PS3-PPU/360 CPU での手作りシナリオでは最大 2.5 倍の差が測定されました。もしその「非効率性」がゲーム全体の少なくとも 0.1% のパフォーマンス低下につながっているのであれば、ビールを一杯飲む義務があります。

次にメモリ管理が登場します。ご存知のとおり、それは常にカスタムメイドです。(サブシステムを制限するため、またはロック競合を減らすための) 多数の異なるプール、さまざまな種類のデータに対する多数の異なる割り当て戦略、それは退屈です。ただし、主要なメモリ消費者が最も注目されています。たとえば、幾何学的データは再配置によってガベージ コレクションされますが、より重要なのは生の統計です。

出荷中の 360 バージョンには、約 1 GB の OGG 圧縮サウンドと約 2 GB のロスレス圧縮 DXT テクスチャが含まれています。それは明らかにコンソールのメモリに収まりません。私たちは、足音や武器の音などの基本的な音さえも含め、何もプリロードしないという極限まで、これらのリソースを DVD からストリーミングする方法を採用しました。 DVD のシーク レイテンシを補うために多くの作業を行ってきたため、プレーヤーはレイテンシに気付かないはずです。それが難しい部分でした。

ネットワークについては長い話になりますが、Metro 2033 はストーリー主導のシングル プレイヤー エクスペリエンスに重点を置いているため、ここでは省略します。