8月23日から25日にかけて、ゲーム開発者向けカンファレンス「CEDEC2022」が今年も開催された。本記事ではイベント2日目に行われたセッション「ELDEN RINGのオープンなフィールドに対応するためのエンジニア取り組み事例紹介」のレポートをお届けする。
フロム・ソフトウェア初のオープンなフィールドを実装した『エルデンリング』は、同社が得意とする美麗なグラフィックで壮大かつシームレスな空間を見事に表現した。しかし、広大なスケールのフィールドはいかにして開発されたのか。
本セッションでは、そんな『エルデンリング』の広大で美麗なフィールドの開発過程を明らかにする。登壇者は本作にシステムデザインディレクターとして参加した松本龍氏。エンジニアの視点から語られる『エルデンリング』の舞台裏をご照覧あれ。
『ダークソウル3』と比較して見える『エルデンリング』の広大なスケール
まず『エルデンリング』のシステムの概要をさらっておくと、フロム・ソフトウェアの過去作と比べて広大な世界が用意され、ローディング不要で全世界を移動可能だ。さらに最大4人でのマルチプレイと、霊場に試乗しての高速な移動、二段ジャンプが用意されている。
つまり、下記スクリーンショットに映る遠景のオブジェクトにシームレスにアクセス可能なマップとなっている。
『エルデンリング』のスケールの大きさを伝えるべく、セッションでは過去作である『ダークソウル3』とのサイズ比較が行われた。
『ダークソウル3』において最初に訪れることを想定された「ロスリックの高壁」は216m×220mとなっている。
いっぽうで、『エルデンリング』において最初に訪れることを想定されたレガシーマップ(オープンなフィールドでない、従来のソウルシリーズに準じたマップ)の『ストームヴィル城』は「ロスリックの高壁」の約3.6倍である500m×350mのフィールドになっている。エルデンリングのマップは全域で6100m×7400mとなっており、スケール感の違いは『エルデンリング』の全体マップと「ロスリックの高壁」のサイズを比較した画像を見れば一目瞭然だ。
フィールドのスケール感は違えど、『エルデンリング』と『ダークソウル3』の根本的なゲームシステムは大きく変わらない。同様の仕組みを流用したいところだが、フィールドのスケールが広大に増加することで自動化せざるを得ない作業や、四方が見渡せるステージの設計によりロードの仕組みの変更を行う必要性が生じた。
そこで導入された複数の解決策が本セッションの肝となる。
データのロード問題を解決する「オープングリッドシステム」
『エルデンリング』での取り組み紹介として、はじめに本作のマップ構成や地形形状について説明された。
『ダークソウル3』に立ち返ると、同作は緻密に作られたレガシーマップの連続で構成されているため、マップの接点で次のマップがロードされるというシステムになっている。
ロードはバックグラウンドで実行されるため、ユーザーに気付かれることなくロードと前マップのメモリの解放が行える。
いっぽうの『エルデンリング』でも7つの大きなレガシーマップと地下墓地、坑道、洞窟といった多数のダンジョンが存在し、基本的には『ダークソウル3』と同様のシステムでロードとメモリの解放が行える。
問題はレガシーマップではなく、オープンマップにある。閉鎖された大きなレガシーマップとは異なり、オープンマップでは四方を見渡し、移動可能であることからデータロードの観点で前述の仕組みをそのまま使用することはできないのだ。
この問題を解決するシステムが、東西南北の軸で区切られた正方形でデータを管理する「オープングリッド」だ。グリッドの大きさの最小サイズは256m四方で、プレイヤーの移動速度とロード頻度によりこのサイズを採用している。
また、最小のグリッドにくわえて512m四方と1024m四方のグリッドが用意されている。遠景から視界に入る大きな配置物をこちらのグリッドにあわせて切り出すことで、ロードの問題を解消しながら遠景のクオリティを維持できるという。
オープングリッドの読み込みシステムは上記の図のようになっている。青色の範囲が読み込んでいる範囲だ。図を参照すると、小さいグリッドはプレイヤーの付近のみ読み込んでいるが、大きいグリッドは比較的離れた範囲でも読み込んでいることがわかるだろう。
アセットの仕組みの導入
『ダークソウル3』ではプレイヤーが移動できる範囲をマップパーツとして作成し、その上にアクションや破壊可能なオブジェクト、エレベーター等のアニメーションする要素をオブジェクトとして配置している。
ロスリックの高壁を上空から見た画像と、同様のアングルから各パーツを色分けした画像を参照すると、区画ごとにパーツが作成されていることが読み取れる。
いっぽう、『エルデンリング』ではマップパーツをベースとなる「建物や岩などの自然地形」にしぼっている。それ以外のゲームの複数個所で使用され得る破壊可能なオブジェクトやアニメーションするオブジェクトはアセットによる管理に落とし込んでいる。これにより、マップの個別のデータのユニーク性が薄まり、アセットの組み合わせを活用してマップを生成可能となった。
この形式を採用することで一か所でしか使用しないデータが減り、容量を有用に使用可能となるのだ。ストームヴィル城とリムグレイブの画像を参照すると、区域ごとではなくオブジェクトのジャンルごとに色分けされ、アセットがところどころに活用されていることが視覚的に理解できるだろう。
自動生成するナビメッシュ、巨大な敵キャラ用の工夫
『ダークソウル3』では敵や味方などのキャラクターの移動経路を設定するナビメッシュや「ジャンプや飛び越えることが可能である」ことを示す「エッジデータ」の配置に関して、ジャンプが可能な高低差のある箇所を手作業で設定していた。
しかし、『エルデンリング』の広大なフィールドでは高低差が多く、すべてにエッジデータを手作業で配置する作業は骨が折れる。
そこで、本作ではエッジデータを自動で生成するシステムを用意し、効率的に制作されたのだという。
いっぽう、本作ではいままで以上に高い頻度で巨大な敵キャラクターが登場する。ここで生じる問題は、自動生成されるナビメッシュを巨大敵キャラクターに使用すれば、巨大な敵であるにも関わらず、細々としたマップの凹凸に引っかかってしまい、まともに敵キャラクターとして運用できない。
この問題は、「巨大な敵キャラクター」専用のナビメッシュを別途で用意することで解決された。
通常のナビメッシュ以上に段差も緩やかに設定したり、ジャンプや障害物の判定を変更することで、しばしば褪せ人の行く手を阻む「トロル」が実現しているのだ。
広すぎるマップをデバッグする自動テスト
続いて、開発中の様々な情報を視覚化し、効率化を促したツールが紹介された。ツールは「情報地図」と「自動テストツール」のふたつの事例が挙げられている。
情報地図は開発中のデータを使用し、ゲーム内のマップを俯瞰して確認できるWebアプリだ。下記画像はリムグレイブにおける各種配置物を表示した状態であり、各マークをクリックすることで詳細なデータを表示したり、ゲーム内の位置へワープできるという。
また、開発用のコメント機能や絞り込み検索機能、自動テストやプレイログ、バグトラッキングといった他ツールとの連携もできる。
自動テストツールは開発中のタイトルを毎朝自動で走らせ、ログを収集するツールだ。
マップの隅から隅までキャラクターを走らせて、収集したフレームレートやCPUおよびGPUの負荷、メモリ状況、各種エラー情報を多岐に集めた。
ゲーム設定は開発状況に変更して情報を収集し、グラフ化することで情報を比較したり、状況を把握する際に有効であったものの、問題の具体的な詳細を確認できないという問題も発生したという。
この問題は、情報地図と自動テストツールを連携することで解消されたそうだ。特にゲームの欠陥を産むメモリチェックやパワースペックの対策を連携することで具体的な情報を効率的に炙り出すことが可能となったのだ。
依存関係データベース
ゲームの開発では、「各データやコンテンツがどの場面でどのように機能しているかを確認したい」というケースにしばしば遭遇する。膨大なデータ量の『エルデンリング』において、本来人力で行っていた調査やドキュメント化する管理は作業のコストがかかり過ぎてしまう。
この問題を解決すべく、「依存関係データベース」というツールが用意された。本ツールは参照元のファイルに関する各種情報を保持し、ビューアーを通じて閲覧や検索出力が行える。
たとえば、参照したファイルから任意のテクスチャ画像が使用されたキャラクター、マップモデル、アセットを検索して導き出すことができる。
本ツールを利用することで、ローコストでデータの依存関係リストが生成可能となったそうだ。
描画設定
フロム・ソフトウェアが手がける高難易度の3Dアクションゲームにおいては、立体的なマップを多用することが多いため構造が複雑化し、描画負荷が大きくなる。そのため、画面に映らない描写は省略するパーツ描画設定を行わなければならない。
従来のフロム・ソフトウェアではパーツ描画設定を手作業で行っていたが、『SEKIRO』にて飛躍力のあるジャンプやワイヤーアクションが実装されたことで、グラフィッカーが都度手作業で設定するのは現実的な手段ではなくなってしまったという。
そこで、ナビマップを活用して移動経路を大量に撮影し、「一度映ったオブジェクト」を描画する設定によりパーツ描画設定は自動化された。
本技術は前述のとおり『エルデンリング』に向けて開発されたものではない。しかし、アセットの導入によってパーツ数が爆発的に増加したことから、『エルデンリング』のゲームエンジンに移植され、見事に工数の削減を果たしたそうだ。
開発プロセスを最適化するフロム独自の役職「設計職」の活躍
ここまでで紹介されてきた『エルデンリング』の取り組みは技術やコスト的に必ずしも難しいものではないという。しかし、要望を持っている人が直接解決へ向けて作業することは難しいそうだ。
何故なら、新たなツールや仕組みを導入した際に、他の部署に影響が出ないかを検討したり、関係する場合は各所と方針の合意を取ったりする必要があるからだ。同時に、プロジェクトとして開発する場合は要求の優先度を考えたり、量産作業を乱すことなく進行する必要性もあり、負担や想定しなければならない要素が多い。
そこでフロム・ソフトウェアは、他社ではあまり耳にしない「設計職」という役割を設けている。「設計職」はプログラム実装やデータ量産作業は行わず、ゲームを制作する仕組み(仕様)を作ることが仕事だ。
ゲーム開発にはさまざまな専門職のスタッフが参加しているが、各々の部署が担当している作業に集中すべく環境を整え、各専門職の「やりたい」アイデアの実現に向けてゲーム開発に携わる。
作業プロセスとしては、まず提案者がやりたいアイデアや要求を提示する。それを設計が掘り下げて仕様を検討する。そしてプログラマが実装方法を検討し、プログラムを実装する。最後に提案者が実際にデータを作成したり、バランス調整を行うことでゲーム開発用ツールが制作されている。
『エルデンリング』ではアセットの導入に伴う対応内容の整理と検討やナビメッシュの対応の洗い出しのほか、遺灰システムやサイン溜まりシステムといったゲームシステムの設計も担当したそうだ。
これらが、『エルデンリング』の果てしないマップと膨大なゲーム内コンテンツを成立させ、完成まで導いた取り組みだ。特にエンジニアの業務に関わる実際の問題と解決策を知ることで、『エルデンリング』の圧倒的な体験の凄みをより具体的に捉えることができるはずだ。
最後に松本龍氏は、その時々で最適な対応を随時考え、相談することが良いゲームを作る一助になると語り、セッションを締めくくった。