ゲーム体験を向上させる最適化の数々
セッションの後半では本作で用いられた最適化の手法について説明が行われた。どれだけリアルな爆発が起きても、それで処理落ちが頻繁に発生するようでは、ゲームの体験が低下してしまう。そのため、グラフィックとゲーム体験のバランスを取ることが重要で、本作においても様々なテクニックが用いられている。
最も基本的なテクニックとして挙げられたのが、画面上で飛びかうオブジェクトのうち、衝突判定を行うものを限定することだ。リヒター氏は「画面上でアクティブなリジットボディをもつオブジェクトは、常時200個以下になるように制限されている」と述べた。そのため画面外に飛び出たオブジェクトは、そのまま消滅させるなどしている。他に大規模な爆発が起きたときに、オブジェクト間で衝突遅延を発生させたり、リジットボディを一時無効にしたり、といったテクニックも多用したという。
また、『CONTROL』の世界では現実よりも、格段にアイテムや破片が跳ね回る回数が抑えられている。プレイヤーの立場からいえば、それらはゲームプレイの障害でしかないからだ。
炎や粉じんなどのパーティクルを多用することも、処理負荷を抑えつつ、画面の密度感を高める上で重要だった。前述のように本作では1つのアイテムが複数のオブジェクトや破片の集合体で記述されている。その上で、個々の繋がりが破壊されたときに、そこからパーティクルが飛び散るように設定された。その後、元となったオブジェクトを画面から文字通り「消す」ようにした。これにより、まるでアイテムがバラバラになったかのように感じさせることができたという。
他に本作ではテクスチャ（デカール）による破壊表現も多用されている。主に床や壁などの、実際には破壊できない部分に対して用いられるもので、攻撃の結果で日々が入ったり、凹んだりしたような表現ができる。デカールはHoudiniやSubstance Painterで作成され、プレイヤーの行動に基づいて動的に表示される。このように本作の破壊表現はリジットボディとパーティクルとデカールの合わせ技で構成されているとリヒター氏は説明した。
リジットボディのみ
リジットボディ＋パーティクル
リジッドボディ＋パーティクル＋デカール
もっとも、全てがこの原則でつくられているわけではない。特別に手が加えられたアイテムも存在する。ノズルから消化剤をまき散らしながら空中を飛び回る消化器、モニタから火花を発生させながら壊れるコンピュータ、攻撃するとクルクルと回転するホワイトボード......これらはプロシージャルな階層構造とは別に、特別につくられたアイテム類だ。これらが渾然一体となって、おもちゃ箱をひっくり返したような本作ならではのゲーム体験が演出されている。
プロシージャルな破壊表現を行う上で重要な4要素
最後にリヒター氏は、これまで述べてきたようなプロシージャルな破壊表現を実現する上で求められる、開発環境のあり方について解説した。キーワードは「ジオメトリの品質向上」、「命名規則の遵守」、「一枚岩な破壊ツール」、「パフォーマンス測定」の4点で、各々が互いに関連性をもって影響を与えているという。
「ジオメトリの品質向上」とはデータの一貫性を保つという意味だ。いくらプロシージャルな破壊表現を行うといっても、元となるデータの記述方法に誤りがあれば、結果が間違ってしまうのは自明だ。ただし、実際には尺度が間違っていたり、マテリアルの割り当てが間違っていたり、タグ付けが間違っていたりと、細かい問題がつきまとう。これらを防ぐためには、パイプライン全体の標準化と事前チェックの徹底が重要になる。ツールのUIを改善するなどの施策も重要だ。
「命名規則の遵守」では、ファイルやデータに開発者が自分で名前を付けさせてはいけないと指摘された。「ジオメトリの品質向上」と同じく、人間は必ずミスをおかす生き物だからだ。これを防ぐために、できる限りツール上で自動化するようにパイプラインを整備するというわけだ。あるツールが吐き出したファイル名を、そのままツール間で使用するようにするのが、最も効率が良く、ミスの発生も防げる。そのためには、何らかの統一されたメタデータ生成のAPIが求められるという。
「一枚岩な破壊ツール」では、ツールの機能を拡張していくことで便利になっていくことと、それによってツールの見通しが悪くなり、保守運用の費用が増していくことのバランスの重要性について指摘された。本作の破壊ツールはHoudini Digital Assetとして制作され、ゲームエンジンと連携するようにデザインされている。これにより、2年間の間に20回ものアップデートがあっても、一貫したメンテナンス性と柔軟性を保持することができたとした。
最後に「パフォーマンス測定」で、『CONTROL』の開発でも、これが大きな課題として残った。
一般的に画面上の動的なオブジェクト数はパフォーマンスと反比例し、ゲーム体験と正比例する。そのため経験の乏しいレベルデザイナーは、ゲームを少しでも面白くするため、ステージに机や椅子やコンピュータなどのアイテムを、どんどん載せていきがちだ。その上で手榴弾を投げる敵が配置されたら......あっという間にパフォーマンスが低下する。「プロジェクトの終盤でなければ全体像がわからず、事態に対応できないため、これは非常に難しい問題です」とリヒター氏もコメントする。
対策とされたのが、「パフォーマンス指標の改善」と「テストの自動化」だ。また、ゲームの特定エリアのみをゾーニングして、特別な指標を設定したり、対応策を行うことも効果的だという。もっとも、本作では自動テスト機能が導入されることはなかった。そのためレベルデザインのイテレーションにあわせて、何度もテストプレイを繰り返し、パフォーマンスやゲーム体験をチェックする必要があった。これについては今後の課題だとした。
最後にリヒター氏は「『CONTROL』の開発では難産な部分もあったが、総じて高い評価を得ることができた」と振り返った。特にゲームの全体的な雰囲気や、部屋中を破壊できるユニークな体験について高い評価が得られたことは、自分たちが注力した部分でもあるため、大いに満足しているという。
また、本作はRemedyがNasdaq First Northに上場した直後のタイトルであり、完成までに7年かけた『ALAN WAKE』や、5年かかった『Quantam Break』に対して、3年以内に3,000万ポンド（約41億円）で完成させることが求められていた（Wikipediaより）。そのため、より少人数のチーム編成になったという。これをカバーしたのが内製エンジンを主体としたワークフローだ。こうした経緯もあり、ゲームエンジンチームとVFXチームに対する感謝の言葉とともに、講演が締めくくられた。
