管理における手続き上の混乱：救済の経験からの教訓

今年の夏のGDCで、上級VFXアーティストのRemedy Johannes Richterが、スタジオの最新ゲームである神秘的なアクションゲームControlで手続きの中断がどのように実装されているかについて話しました。



彼の講演では、多くのゲーム内エフェクトを構築する基本原則、または粒度の原則に注意を払いました。スタジオが現実的な破壊可能性の大規模システムをどのように実装したか、自身のリソースとプラットフォームのパフォーマンスのどのような制限に直面したか、どのような最適化を行ったか、そしてこれらすべてからどのような教訓を学んだか-さらに資料で。







それで、最初にスタジオが直面した課題について。



ゲームは、壁の移動などの超自然的な機能を備えた、残忍なスタイルの政府機関の建物内で行われます。



本社の構造は信頼できるように見えるはずでした。なぜなら、これは政府機関であり、日常業務を行う何千人ものサービス要員を雇用しているからです。テーブル、電話、マグカップ、MFP-これらはすべて、職場で見られると予想されるサラリーマンの通常の属性であり、それらの存在によって、この場所のストーリーを定性的に伝えるのに役立ちます。残虐行為とは、大量のコンクリートを意味しますが、それだけではありません。ここには、木とガラスの両方があり、特別なサービスビルに最適な外観を作り出しています。







破壊に関して最初に考えるべきことは触覚です。開発チームは、その中のほとんどすべてのものと対話できるという感覚を即座に生み出す、豊かなインタラクティブ環境を組織化するという任務を負っていました。







明らかに、スタジオはその作業中に特定の制限に直面しました。オブジェクトとの相互作用は、リアルに見える必要がありました。ゲームの可能性はプラットフォームの究極のパフォーマンス、メモリ、人工知能の要件にかかっているため、プレイヤーは破壊に関してある程度の行動の自由を持っている必要がありますが、無制限ではありません。同時に、破壊可能な環境の実装を任されたチームは非常に小さいことが判明しました。これも作業で考慮する必要がありました。







したがって、ゲーム内の破壊可能性は、粒度の原則に基づいています。また、映画撮影における多くの特殊効果の基礎でもあります。その意味は、自然が定量化されていないということです。これは、大規模なものから小さなもの、大規模な固体からほこりや煙まで、さまざまなオブジェクトから作成された連続したキャンバスです。画面に何かが映っていないと、全体像がうまくいきません。



ゲームエンジンでは、この原則を3つの異なる詳細レベルで実装できます。それらのオブジェクトは、リジッドボディ（リジッドボディ）、それらのパーツ、小道具のパーツ、小道具自体、および環境の形で表示されます。この場合の後者は、インタラクティブオブジェクトが衝突する可能性のある一種の静的グリッドです。メッシュパーティクル、ソリッド階層、およびマテリアルデカールにより、特定のレイヤーのオブジェクトがより詳細になります。したがって、ソリッドオブジェクトから、それらのフラグメントに移動し、次にフラグメントに移動します。最後の層は粒子そのものです。粒子スプライト、残り火粒子、砂などはすべて、これらの勾配を埋めるのに大きな役割を果たします。







上のスクリーンショットは静的環境を示しています。ここには詳細がありますが、かなり空っぽに見えます。たとえば、背景には階段の手すりが見えます。







直接対話できるオブジェクトでスペースを埋め始めると、知覚がどのように変化するかは驚くべきことです。







Remedyのワークフローに関しては、実際にはかなり些細なことです。環境アーティストは、組み立て用のレベルジオメトリモジュールと小道具を提供し、その後、VFX部門がリグと映​​画の破壊アニメーションを構成します。最後に、結果はRemedy独自のエンジンであるNorthlightに送信されます。



すべてがどのように機能するかについてのアプローチを決定する必要があり、チームは手続き型のものに落ち着きました。



どういう意味ですか？



手続き型アプローチは、ルールベースの処理とデータの解釈です。







ゲームの世界に関する情報は、マテリアルに関するメタデータを含むモデルによって表されます。たとえば、ベンチのシートはファブリックで、ベースはコンクリートで、植物は実際には植物であると設定できます。マテリアルを定義したら、それらごとに有限のルールセットを作成して、ゲームで実行できるすべてのアクションに対する反応を決定できます。たとえば、植物から発射すると、葉の破片が飛び散り、コンクリートが破片に砕け、金属パイプが変形し、水が飛び出します。次に、すべてのデータがエンジンにリダイレクトされ、必要に応じて各インタラクションにすでに反応します。







では、なぜ手続き上の破壊なのか？



迅速で一貫した行動の転換が必要だったため、明確に定義された条件下での予測可能な行動。ゲームには何百もの資産が関係しています。上の画像では、部屋、壁、柱、階段、手すりなどを構成するあらゆる種類のブロックを見ることができます。その下には、テーブル、椅子、花瓶、植物、コンピューター、電話など、さまざまな小道具があります。このようなさまざまなオブジェクトの破壊を実装するために、1〜3人のチームだけが選択されました。したがって、世界が機能するパターンを事前に決定する必要がありました。オブジェクトが特定の方法で影響を受ける場合、特定のマテリアルの選択された破壊方法に規定されているとおりに正確に破損する必要があります。







そのため、素材によっては一定の動作を設定する必要がありました。あなたが木を撃つとき、それが粉々に飛ぶように。または、ガラスを撃つと、破片に砕けてしまいます。同時に、粒子とデカールも、オブジェクトの構成に応じて特定の方法で動作する必要があります。







各材料には、さまざまなレベルで定義された独自の破壊ジオメトリがあります。この例では、ベースがコンクリートで、次に金属製のサポート、最後に木材である手すりがあります。左から右に、ステージが壊れたときに表示されます。

• レベルAはコンクリートの破損を示しています。まだ亀裂が少ないので、ここにはデカールはありません。サポートがわずかに曲がっていることがわかります。
• レベルB。金属はなくなりましたが、壊れたコンクリートと木が残っています。
• C : , .

ここで、オブジェクトの特定の角度に当たったと想像してみましょう。完全に壊れてはならず、その一部だけが壊れているはずです。







したがって、Controlには、単一のオブジェクトであるソリッドボディがあります。しかし、リンクで接続された詳細もあります。これらは、いわゆる複合衝突で分離できるのと同じ剛体です。







パーツは初期化中に作成され、共通のコライダーを共有し、破損するまで1つのピースとして移動します。それらは、互いに接触する表面によって互いに接続されています。







接続について話しましょう。それらは、メタデータに基づいて幾何学的な階層で作成されます。ソリッドは、ドアや引き出しの場合など、一種のヒンジによって相互に接続されています。それらは、再び衝動の強さによって動的に破壊される可能性があります。







化合物には特別な破壊の物理学があります。それらはオブジェクトと一緒に壊れません-つまり、ドアに穴を開けても、ドアはオブジェクト全体のままで、内部接続によって一緒に保持されます。したがって、親ブロックRB1を壊しても、ドアはヒンジから外れません。衝撃の影響を受けずに、ドアの一部が開口部に取り付けられたままになります。また、中央に穴の開いたドアは、期待どおりに開閉できます。したがって、開発者は、一部のゲームの場合のように、打撃がどこでどのような力で落ちたかに関係なく、オブジェクトが完全に壊れる状況を避けたいと考えました。







Northlight独自のシミュレーションは、破壊ロジックを実行し、それに反応するイベントとパーティクルを決定します。次に、NVIDIA物理エンジンは剛体をモデル化し、それらをゲームの制約に適合させようとします。







破壊自体は次のように実現されます。いくつかの入力ジオメトリがあります。モデルを事前に準備し、ボンディングジオメトリを設定し、どの場合にどのパーツが破損する可能性があるかを判断する必要がある場合があります。その後、モデルはHoudiniに送信され、そこで処理されます。 Houdiniの破壊は、マテリアルベースの反応を実行してデータをメモリに書き込む、かなり大規模なHDAセットアップです。特に接続に関しては、設定が正しいことを確認するために、いくつかの物理メタデータを手動で修正して設定する必要がある場合がありました。次に、すべてのデータがエンジンに転送され、そこでゲームワールドの作成に使用されます。







Houdiniの破壊ツールは次のようになります。入力として具体的なブロックがあるとしましょう。どの領域が破損する可能性があるかを判断し、材料を設定する必要があります。この場合、ブロックはコンクリートに設定されたルールに従って破棄を実行し、それを管理し、レンダリングジオメトリと衝突に関して異なる階層を作成します。次に、設定した予算とスタイルの範囲内でモデリングが行われていることを確認する必要があります。その後、モデルをエンジンにエクスポートできます。







エンジンではこんな感じ。レイヤーA、B、Cなどに関する情報を運ぶ一種の階層があります。これには、マテリアルの名前、オブジェクトが静的であるかどうか、接続に関するデータ、それらのタイプなどが含まれます。階層はレベルで表され、材料の名前によって物理的特性が異なります。名前が正しく指定されている場合、物理はエンジンによって処理されます。名前の問題については後で説明します。







上記はリジッドボディシミュレーションシナリオです。ジェシーは彼女の周りの物体を撃ち、それらは爆発し、それによって破壊の物理学を実現します。







破壊可能な環境はリソースを大量に消費するものであり、コンソールとPCには独自のパフォーマンス制限があるため、チームは、デバイスが過負荷にならないようにシステムを最適化するという課題に直面しました。



特定のパフォーマンスバジェットに合わせる必要があるため、画面上のアクティブなソリッドを200に制限しました。そのため、画面外のオブジェクトは完全に消えました。



多くの高速で移動するオブジェクトが関係するイベントの場合、衝突が遅れるため、システムはすべての計算を実行する時間があります。



未使用のアイテムにはスリープモードも実装されました。たとえば、コンクリートブロックが床に落ちた場合、ボールのようにジャンプし始めるとは誰も予想していません。そのため、ブロックはすぐに「眠りに落ちる」可能性があります。これは、ゲーム内の多くのアイテムに当てはまります。同じ理由で、それらは互いに積み重ねることができ、同じように動かずに横たわります。



また、アイテム間の隙間は粒子で埋められていました。したがって、オブジェクトが破壊されると、その周囲にほこりやチップが形成されます。







ゲーム内のすべてが体系的でイベント主導型です。次のパーティクルイベントが存在します。

• 弾丸の影響。素材によって結果が異なります。
• 2つの部分の間の接続を切断します。この場合、スクレーピングが発生し、粒子が放出されます。
• オブジェクトが完全に破壊され、粒子に崩壊します。

上記は、パーティクルを編集するプロセスを示しています。ゲーム内で、特定の粒子システムを配置してから変更することができます。この場合、火花形成の頻度は単に変化します。興味深いことに、文字通りリアルタイムで変更してすぐにフィードバックを受け取り、もう一度再生して効果がどのように機能するかを確認できます。このように実装された高速反復ループを使用すると、正しく表示されるまでこのようなものを磨くことができます。







粒子のもう1つの機能は、標準モデリングです。時々、チームは署名された距離フィールド（SDF）を使用しなければなりませんでした。これにより、非常に奇妙に見える物体が床から落ちないようにすることができました。







上記の例では、破壊可能なオブジェクトは粒子と固体の共生です。これが私たちが見ているものです。爆発は、粒度勾配の欠落したギャップを埋める粒子の追加の層のために、空気中にほこりを生成します。







そして最後に、ゲーム内に多数あり、動的に生成されるマテリアルのデカール。基本的に、それらは破壊の外観を作成するためにオブジェクトに適用される単なるテクスチャです。



何かが壊れた場合、ひびの入ったデカールがアイテムに表示されます。それらは通常Houdiniまたは同様のもので作成されます。コントロールでは、目的のデカールの選択は、マテリアルに基づいて動的に行われます。また、静的ジオメトリのかなり大きな部分を利用するのにも役立ちました。最初に示したように、私たちの周りには常に多くの静的オブジェクトがあり、それらも考慮しなければならない何らかの影響を受ける可能性があります。







これはそれがどのように見えるかです。床を分割すると、ポリゴン自体は同じままですが、デカールの導入により、外観が大きく変わる可能性があります。それらは非常に経済的で効果的に使用できることは注目に値します。







つまり、粒子、固体、デカールがあります。この例では、単純な爆発ツールではそれほど多くのデカールが生成されないため、いくつかのトリックを実行する必要がありました。今、ジェシーは床にへこみを残すことができるオブジェクトを「投げる」。同時に、床は静的なポリゴンのままですが、デカールのおかげで、衝撃マークが床に残ります。







カスタム小道具のトピックにも触れましょう。消火器、コンピューター、ランプなど、ゲーム内に散らばるアイテムがたくさんありますが、完全に手続き的に生成することはできません。環境アーティストは、それぞれのエフェクトを手動で設定する必要がありました。ただし、それらの存在から、ゲーム内の世界はより豊かで多様に見えるだけです。



では、スタジオはコントロールからどのような教訓を学びましたか？



ここで触れる価値があるのは次のとおりです。

• ;
• ;
• ;
• .

1つ目は、ジオメトリの品質です。一貫性のない入力ジオメトリは、不適切なスケーリングと方向だけでなく、不適切な材料割り当てからも発生する可能性があります。メッシュの品質が低すぎる場合があり、これも結果に悪影響を及ぼします。また、オブジェクトを壊すと、その中に何もないことに気づき、これが間違っていることもあります。このような問題を回避するには、入力データを改善し、ジオメトリパイプライン全体を標準化して、エクスポート中に何かが基準を満たしていないために修正が必要な場合にシステムが警告するようにする必要があります。これは、問題が発生した正確なタイミングを探している異なる部門間の絶え間ないフィードバックループを回避するのに役立ちます。



さらに、オブジェクトをモデル化して、破壊されたときにどのように見えるかをすぐに確認できるように、組み込みのツールがあると便利です。明らかに、これはより良いインターフェースでより多くのツールを作成するという課題を提起しますが、それは問題の価値があります。







私たちはさまざまなものに名前を付けることに慣れています。しかし問題は、これらの名前が正しくない可能性があることです。たとえば、コントロールでは、マテリアル「コンクリート」に17の異なる指定がありますが、常に人的要因があるため、これを誰のせいにすることもできません。リヒターのアドバイスは、命名基準を完全に廃止することです。メタデータAPIを1つだけ持つ方がよいでしょう。このように、アーティストが小道具を作成するためにどのツールを使用しても、中間の手順なしでそこから直接エンジンにデータをエクスポートすることが可能です。







次のチュートリアルは主にHoudini固有のものです。肝心なのは、何かの作業を開始するとき、その過程で何度もやり直し、いくつかのアドオンを作成し、2年間の作業の後でも、ソースファイルを開くことができることを確認する必要があるということです。作業ツールはすでに20回変更されている可能性があります。これは、HDAを使用するには、何らかの標準化が必要であることを意味します。これは、Remedyが現在取り組んでいることです。すべてが正しく配布されるようにすることで、ツールのバージョンを失うことがなく、過去に行ったことを常に繰り返す機会があります。



ここで重要なのは、自動ツールを作成するときは、実際にはすべてを手動で行っているのと同じソフトウェアを使用しているということです。そして、それらが同じバックエンドを持っている限り、すべてが完全に一貫している必要があります。







パフォーマンスとテストは、開発の最も重要な側面の一部です。



Remedyでは当初テストは自動化されていませんでした。レベルに新しいオブジェクトを追加した後、すべてが正しく機能していることを確認するために手動でそれを通過する必要がありました。しかし、その後、エンジンで何かが変更され、バックエンドが変更され、何かが最適化され、その後、再テストが必要になりました。あなたは確かに何かをチェックするのを忘れるので、これは非常に危険です。要するに、最善の方法ではなく、バグが蓄積する可能性があります。



2番目の側面はパフォーマンステストです。長い間、Remedyはフレームレートや計算時間などの重要なメトリックを測定しませんでした。したがって、パフォーマンスの問題が発見されるのが遅すぎることがよくありました。







ここでできることは、まず、パフォーマンス指標を改善することです。超過できない予算を最適化および決定する際にこれに依存するためには、どのパラメーターの増加がゲームに良い影響を与えるか、または悪い影響を与えるかを決定する必要があります。



さらに、自動テストが役立ちます。この場合、出力を変更して、エンジンの変更の影響をより適切に示すこともできます。







また、パフォーマンスの低下を特定して対処することもできます。たとえば、大規模なイベント中に、一部のオブジェクトが中間レベルの破壊をバイパスすることを確認します。たとえば、固体から粒子に直接移動します。



もう1つの方法は、予想される負荷に応じたエリアのゾーニングです。この考え方は、必要のないレベルですべての資産に適用しないように、特定の対策をどの領域に適用するかを自分で決定できるという事実に基づいています。たとえば、手榴弾を持った敵がすぐにジェシーに到着した場合、明らかにその場所の破壊が多すぎて、攻撃中に破壊を生成するプロセスが加速する可能性があります。



その結果、Remedyチームは記念碑的な仕事をしました。そこから、環境の手続き的破壊のシステムを実装および最適化することに関して多くのアイデアを得ることができます。