『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】 | GameBusiness.jp

『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】

『エルデンリング』のオープンワールドを開発するためには自動化・効率化が不可欠だった

ゲーム開発 ゲームエンジン
『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】
  • 『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】

2022年もオンライン開催となったゲーム中心の開発者向けカンファレンスCEDEC2022。フロム・ソフトウェアのアクションRPG『ELDEN RING』におけるオープンワールドのゲーム開発に対してどのように対応したかを語る、「ELDEN RINGのオープンなフィールドに対応するためのエンジニア取り組み事例紹介」のセッションレポをお届けします。

このセッションにはフロム・ソフトウェアの設計セクションサブリーダーである松本龍氏が登壇しました。同氏は、本作においてはシステムデザインディレクターを、2015年の『Bloodborne』ではシステムデザイナーを担当しています。


「CEDEC 2022」他の講演レポートを読む


『DARK SOULS III』よりも広大な『ELDEN RING』の世界を作る為には?

フロム・ソフトウェア初のオープンワールドゲームである『ELDEN RING』は、2016年発売の『DARK SOULS III』と比較してもマップがとてつもなく広大であることが挙げられます。『DARK SOULS III』の「ロスリックの高壁」では216m×220mの広さを持ち、同作には同等規模のマップが13ほど存在していますが、『ELDEN RING』でプレイヤーが移動できる距離は、海など移動不可能なエリアを含めても6100m×7400mとかなり広大です(他にも、開発上「オープンマップ」と呼んでいたそう)。

『ELDEN RING』では開発上、地下マップや小規模ダンジョンが点在するオープンなフィールドを「オープンマップ」、「ストームヴィル城」のような作り込まれたマップを「レガシーマップ」と呼んでいました(「ストームヴィル城」も「ロスリックの高壁」より大きく約3.6倍の大きさを持つ)。

ゲームプレイでの戦闘に関しては過去作と大きく変わる訳ではありませんが、ボリュームに応じて跳ね上がる量産コストやデータ管理、デバッグなど様々な問題に対応する必要があります。そのため、人の手で作っていた箇所を可能な限り自動化/効率化することや、データ管理においてもマップロードでの調整や、デバッグの効率化も避けられません。

過去作の『DARK SOULS III』では、緻密に作り込まれたマップで構成されているために、1マップごとにデータを管理しています。また、マップとマップの接続部付近に移動すると、続きのマップをバックグラウンドでロードすることなど、ユーザーから読み込みを気付かせにくくする施策がとられています。

一方で『ELDEN RING』においてレガシーマップは基本的に過去作と同じ作りですが、広大なオープンマップではオープングリッド制御を導入。これは四方を正方形のグリッドとして分割して管理する方法で、最小サイズは256m×256mからはじまり、512m×512の中規模サイズ、さらに1024m×1024の大規模サイズも生成しています。これは広範囲に読み込みが必要な配置物を制限することで、読み込み数の爆発的増加を抑え、遠景のクオリティを維持することも目的に含まれるからです。また、巨大な敵や移動する敵を小さなグリッドに設定してしまうとプレイヤーから離れて制御出来ないために、大規模なグリッドで制御する必要があります。

過去作の『DARK SOULS III』におけるマップ構成では、プレイヤーが行動できる範囲をマップパーツとして作成し、アニメーションや破壊可能なものをオブジェクトとして配置。一方『ELDEN RING』では、マップパーツを地形形状のみに絞り、何らかのインタラクト可能なものなどをアセットにすることで、データのユニーク性を低下させ1箇所でしか使わないものを減らし、メモリを有効的に扱います。

ナビメッシュ生成を自動化をして敵味方を制御

ナビメッシュは、敵や味方が移動経路を探索するために使うデータで、障害物を避けた最短ルートの割り出しやステップ移動した先が安全か否かを確認できるものです。『DARK SOULS III』では、マップパーツのヒット形状から作成し、飛び降りなどの特殊な挙動はグラフィッカーによってデータを設置して生成されていました。当然のことながら『ELDEN RING』はオープンマップであり、プレイヤーにジャンプなどが実装されているため、過去作のやり方をそのまま踏襲することは不可能です。そのためナビメッシュの構造が改修されました。

『ELDEN RING』では、広大なマップにおいて敵もジャンプや飛び降り動作を行ってきます。そのため、ジャンプや飛び降り可能なエッジデータを自動生成しています。エッジデータの自動生成条件は「幅と距離が一定の範囲内」で「両ナビメッシュの大きさが一定以上」、そして「間に邪魔する存在がない」などを満たしていることです。

一方で各地に存在する巨大な敵は、「多少の段差や障害物を無視する」などルールが違うために通常のデータを利用できません。ナビメッシュを無視して直線的に迫る形にしても、障害物による進路妨害や海へ落下する事などが起きてしまい、まともな敵として運用できません。そのため、巨大な敵専用のナビメッシュを多少の段差や障害物を無視して作成することで、プレイヤーに向けたルートを構築しました。

『ELDEN RING』開発における自動化はテストやデータベースにも

『ELDEN RING』では、マップだけでなくコメントや配置物の詳細データを表示するための情報地図を利用しています。また自動テストでは、開発中のタイトルにおける全マップ・全プラットフォームを対象に毎朝自動で走らせて、フレームレートだけでなくCPU/GPUの負荷やメモリ状況、そしてエラー情報などを収集しています(他にも、マルチプレイ想定の負荷や天候の変化なども収集している)。これらは非常に便利なものですが、結果が折れ線グラフで表示されるために、マップのどの位置で発生しているのかが把握しにくいデータでした。

これらの詳細が求められていたのは、フレームレートなどを確認するメモリ/パフォーマンスチェックでした。メモリチェックは使用量が極端に増えると強制終了を含めた問題を引き起こす為に避けては通れない問題です。そのため、先の情報地図とフレームレートの負担を連携させ、フレームレートの落ち具合をヒートマップとして表示すると共に極端に下がった所にピンを打ち、負担を可視化させます。

パフォーマンスチェックは関係者とのミーティングを定例化することで自動テストの結果から状況確認し、問題点の洗い出しを行った後に対策を進めたそうです。メモリチェックは、1人担当を決めて定期的に怪しい部分に対してアラートを発し、各自配置調整やデータ削減対応などを進めています。これらは様々な要素が絡みあう根が深い問題でもあるために、自動で可視化出来たことが開発の助けになったと分析します。

『ELDEN RING』では開発中に様々な用途においてデータの依存関係を知りたいケースがありました。カットシーンで使われているデータや未使用データ、指定のアセットを使ったマップの関係だけでなく、ネットワークテスト版で余計なデータを含まずに軽量化することなどが該当します。特に『ELDEN RING』は大規模な作品であるために、ドキュメントでの管理は随時置き換えが発生するために人力での精度の高い状態に保つのが難しいのです。ファイルの検索もコストが大きく現実的でないことから、これらを解決するために依存関係のデータベースを構築しました。

依存関係のデータベースは、その名の通り依存関係のデータベースを管理しているツールです。ビューワーを使って様々な情報にアクセスし、指定のカットシーンで使用されているキャラやアセットのリストアップだけでなく、使われているテクスチャなどを閲覧/検索/出力が可能です。またデータベースの更新は毎日実施し、更新の内容を都度解析して依存関係を登録。これらを活用することでローコストでのリストアップに繋がります。

他にも『ELDEN RING』に限らないことですが、描画負荷を軽減する取り組みも行われています。従来ではグラフィッカーが手作業で設定して描画物を制御していましたが、コスト問題から2019年発売の『SEKIRO』では描画設定の自動生成機能が開発されていました。先の通り『ELDEN RING』は、ジャンプの導入だけでなくアセットの導入で描画要素が爆発的に増えたため、『SEKIRO』で開発した描画自動化の仕組みを移植しています(『ELDEN RING』は『SEKIRO』と同じエンジンをベースにしているため移植が容易だったという)。

『ELDEN RING』は如何にして自動化と効率化を追求したのか

最後はまとめです。広大なオープンワールドの世界を構築するために、今回の発表を振り返るとマップの管理構造の変化やアセットの導入、ナビメッシュの自動化、パフォーマンス問題の可視化、データ依存関係のリスト化、描画設定の最適化など、ありとあらゆる要素について効率化と自動化を追求していました。

これらの取り込みを実現するためには、やりたいことを明文化すること、導入後における問題の検証、関係各所との合意、対応の優先度の整理、量産作業における並行した対応など様々なことに配慮する必要があります。フロムでは、ここに設計職が入り取り回しを行います。今回の発表では、アセット導入による各種対応とナビメッシュの問題点に設計職が関わっていました。

他にも、設計職はゲームシステムの設計にも関わっており「遺灰システム」や「サイン溜まりシステム」にも関わっています。最後に『ELDEN RING』は手探りの開発であったことを述べセッションを終了しました。


以上が今回の発表でした。セッションを聞いていると、『ダークソウル』シリーズを筆頭に2010年代を駆け抜けてきたフロムソフトウェアは、これまで職人芸的で緻密かつ繊細にクオリティを引き上げる開発スタイルだったことが推察できます。それが、オープンワールドという巨人に対応するために、自動化や効率化を深く追求せざるを得なくなっているものの、なるべくこれまでの開発スタイルを崩さないように如何にして対処してきたかが語られたようにも思えます。


「CEDEC 2022」他の講演レポートを読む
《G.Suzuki》

この記事の感想は?

  • いいね
  • 大好き
  • 驚いた
  • つまらない
  • かなしい
【注目の記事】[PR]

関連ニュース

特集

人気ニュースランキングや特集をお届け…メルマガ会員はこちら