2017年9月4日 07:00
- 8月30日～9月1日 開催
- 会場：パシフィコ横浜
CEDEC2017での目玉講演となっていた、任天堂の「ゼルダの伝説 ブレス オブ ザ ワイルド」関連セッション。この中にはクリエイターだけでなく、どのようなエンジニアのバックアップにより本作が完成できたのかというセッションもいくつか行なわれた。
そんなセッションの中から「『ゼルダの伝説 ブレス オブ ザ ワイルド』のプロジェクト運営 ～試作から製品までシームレスに！～」、「『ゼルダの伝説 ブレス オブ ザ ワイルド』の遊びと物量を両立するための制作パイプライン・TA事例」、「『ゼルダの伝説 ブレス オブ ザ ワイルド』におけるQA ～ゲームの面白さを最大化するツールやデバッグの紹介～」の3つについて概要を解説していこう。
ゲーム全体の進行を支えた「ゼルダエディタ」
まず特徴として挙げられるのは、本作を制作するに当たって「ゼルダエディタ」という新しいツールが導入されたこと。ここではゲームで扱う全データを管理すると共に、エディット機能、ツールランチャー機能、コンバート機能を持たせた。いわばプロジェクト運用の中核を担うツールだ。そして制作にあたっては、まずガイドラインを作成して、そこに肉付けをしていく「骨組み方式」が導入されたほか、陸上トラックに例えて、1周目は骨組みを作って面白さを確定する試作期、2周目は正式データをすべてそろえる量産期、3周目は製品までひたすら磨き上げる仕上期と、マイルストーンを決めていったという。
それぞれの周回では禁止事項が設けられた。これは1周目であればゲームの本質の実装以外は禁止すること、2周目は素材をそろえることに専念し、磨き込みを禁止すること、など。最後の仕上げ期になったら磨き込みをしていくわけだ。
このため試作期では過去作品の村のモデルを利用したり、NPCのモデルを利用して制作が進められた。これは敵やラスボスについても同様の対応がなされた。つまり過去作品の資産をフル活用して、ゲーム体験を作って面白さを確定したのが1周目だ。この時アーティストは絵作りを考え、ゲーム内に落とし込むための技術検証をしていた。量産に向けてワークフローの整備をしたり、ゲーム本編とは別に動きなどを開発していた。
2周目では正式データをひたすらそろえていった。この際には、かなりボリュームの大きな作業となるため、従来のタスクツールではうまく管理ができなかった。そこでタスクをデータに貼り付ける機能をゼルダエディタに持たせ、タスクをゲーム内のデータに貼り付けることで“迷子タスク”をなくす努力が行なわれた。これにより、仮データそれぞれの進行がしっかりと管理できたという。
また従来は手作業で行なっていた進捗管理を、タスクを集計して自動更新することで情報が正確になり、しっかりとした管理もできるようになったという。プロジェクトの終了時期もグラフによりある程度読めるようになった。
3周目に行なわれたのは全データを製品クオリティにすること。その際に必要になってくるのがデバッグだが、本作のプロジェクトではバグもタスクとして計算するようにした。また報告についてもゼルダエディタを使い、バグが起きているか所にラベルを貼り付けて報告しやすくしたという。そしてモデルサイズやテクスチャサイズが適正かどうかは自動的にチェック。アイテムの燃え方や武器が水に浮くかといったものは目視でチェックした。
今回はこのようにエンジン統合タスクを導入したが、その際のメリットとして挙げられるのは、データへのアクセスが楽だったこと。タスクからデータを探す必要がなく、調整確認コストが削減できたそうだ。また情報収集が楽になり、正確な情報を集めることができたほか、リストの作成やデータ管理に対して大きなメリットがあった。そして何よりも、タスク管理が楽になったこと。すべてのタスクやバグタスクがゼルダエディタに集約されたため、集中管理を可能とした。その結果、クリエイティブな作業に集中できたことが大きかった。新たな作品は、新たな開発プロセスを編み出すことで生まれてきたことがよくわかるセッションだった。
制作パイプライン・テクニカルアーティストはどのように関わったのか
次に制作パイプラインとテクニカルアーティスト（TA）の話に移る。同社のゲーム開発では、遊びの手応えを1番大事にしているという。このため、職種を問わず、作った物がゲームとしてうまくデザインされているかを意識している。そして最後の最後まで調整すること。「この粘りが製品クオリティにつながっていると信じている」と語る。
こうしたこだわりから生まれたゲームだが、本作では遊びに対して膨大な物量があり、全体像を共有しつつ生産性を上げる必要があり、安定したゲームを作るためのスタッフとのやりとりを十分にするほか、リテイクを重ねる中でも品質を上げなければいけない、という相反する課題を抱えていた。そこでパイプラインエンジニアとTAは制作スタイルを生かしたまま、広い世界を作ることにチャレンジした。
アセット制作面の課題としては、物量も多く、品質も保ち、リテイクによるブラッシュアップをするなど、膨大なアセット制作コストが見込まれた。しかし人数や時間は際限なく増やすことができない。そこでアーティストのアセット制作サイクルを円滑に回し、個々の力を最大限に発揮することを目的とした。
そのために必要なのが、DCC（Digital Content Creation）ツール環境の安定化。本作はMayaとPhotoshop CCにより作成されていたが、多数のプラグインが導入されているほか、利用しているアーティストの数も多かった。こうした場合は環境の不一致によるトラブルが起きやすく、1度起きてしまうと多数の手が止まるなど、損失も大きい。このためDCCツールの安定化が先決だった。
そこでDCCツール実行環境を統一するため、専用ランチャーで起動をするようにしたり、Mayaプリファレンスを統一したほか、ツールの自動テストも実施。またアーティストのところで起きたエラーを検知して自動的にレポートする機能を使い、ツールのリリース後に発覚したバグに迅速に対応した。
また本作では“物理”を使った遊びをゲームに取り入れるという試みがなされている。物理エンジンにはHavokが使われていたが、物理データの質が、遊びの質に直接つながることが見込まれた。また新たな世界を埋めるために大量の物理データが必要であるのに対して、物理専任アーティストは設けない方針だった。このため、多数のアーティストが安定して物理データを量産できる環境が必要だった。
そこで採られたのが、Havokの環境を表に出さずに、DCCツール用のプラグインに作業を集約することで、物理データ制作フローを簡易化した。また、物理データの安定性を向上するため、危険な物理データがROMに渡らないようにチェックした。こうした対策により、アーティストが安定して物理データを量産できるようになったそうだ。
そして多数発生するであろうリテイクについては、LODモデル制作を自動化することで、アーティストの負担を軽減。LODモデルは生成パラメータを通してのみ制御するほか、それについてはプログラマー・TAが管理することとした。これによりアーティストはベースモデルに注力することができた。こうすることで、モデル全体の品質向上が図れたという。
また自動化について、「試練の祠」について例を挙げて解説。ここではアーティスト、プランナー、プログラマーが担当した工程をマージする必要があったが、パーツモデルの制作と、パーツ配置工程をマージする作業を自動化。最適化により最後の最後まで、試練の祠の遊びについて追求することができた。
またアニメーションデータについても、モデル制作、リグ制作、アニメ制作といった各工程でバージョンアップが行なわれた際の更新データ作成を自動化。接地データも設定を自動化することで、後工程を気にせずにアセット調整サイクルを何度も回せるようになった。
こうして今回はクリエイティブでない作業となる後工程を重点的に自動化。クリエイティブな制作に注力することができ、アセット全般の品質向上を支えることができる結果となった。TAはアーティストの力をゲームに結びつけるのが仕事なのだ。
ここからは開発用ROMの作成に移る。基本的にはアーティストが作成したDCC中間ファイルをコンバートしたりソースファイル、プログラマが用意したソースコードに基づいてビルドされた実行ファイルが合わさり、ROMが作られる。データが更新されるたびにROMが作られ、成果としてほかのスタッフに渡っていくこととなる。つまりきちんとした開発を行なうためには、安定して高速な、高頻度で動くロムパイプラインが求められる。
そしてその際に重要なのがバージョン管理だ。ビルドに時間がかかっているとその間に更新されたデータとは不整合が起きてしまい、実行エラーが出てしまう。また、自社だけでなく協力会社も制作に取り組んでいるので、多拠点対応もする必要がある。そこで今回はダウンロード時に実行ファイルとリソースのバージョンをそろえることができるように設定。手元で作業しているデータについては例外として、戻すのかそのままにするか選べるようにした。また複数のROMを選択可能にして、トラブル時にも別のROMを選ぶだけで復旧できるようにしたそうだ。
そしてリソースパイプラインだ。ここでは不要な作業をしない、すぐに次の人に渡せる、正しい状態がずっと維持されるという必要がある。このため複合リソースのパッチ読み込み時には、一時的な開発用リソースがあれば使うようにしたほか、開発用リソースはJenkinsがコンバート時に自動的にきれいにするようにした。パッケージリソースについては、差分読み込み時にバージョン管理をしているが、個別リソースとずれる場合がある。そこで差分テーブルを用意し、差分があるものは個別リソースを使うように設定。これによりアーティストは個別リソースだけアップロードすればよいようにした。
なおすぐに渡すことと安定性を両立するため、自動化を導入。Jenkinsでも念のためコンバートするようにしたほか、どのリソースからも、必ず全コンバートするようにした。そして一時的におかしい状態になったとしても、最後に収束すればよいという方針を立てた。
ビルドパイプラインに求められるのは、高速に、高頻度に、安定してROMができること。高速に作るためにはリソースはPCから直接よい、実行ファイルはコピーするだけにして、ビルド時にバージョン番号を控えるだけに設定した。
高頻度を実現するために、メインで遣うROMは5分に1度のビルドに。またプラットフォームやビルドターゲットによって、ビルド頻度を変えた。中でも開発で1番使う「デバッグ機能あり版」などは高頻度でビルドすることにした。
安定性を確立するために、ビルドエラーを名指しして通知するようにし、「誰か」にしないで個人を特定することで、最優先で治してもらう態勢を取った。またROMの安定のために、実機による簡単なスモークテストを実施。失敗したらROMを削除すると共にチャットにより名指しで修正依頼をかけた。
またROMパイプラインがタスクと連動する際に求められるのは、作業が反映されたROMを特定できることと、確実にROM作成通知が届けられること。ROMを特定するためには、バージョン番号を順番に振るように設定。数字の大小で反映されたか明確になるようにした。そしてJenkinsが自動でタスクのステータスを更新するようにし、タスクでROM作成を通知するよう設定した。
これらの作業を作り上げていくことで、ROMはあって当たり前、動いて当たり前とすることに成功。全員でゲームの全体像を共有しながら開発ができたそうだ。開発のサイクルをたくさん回すことができたため、遊びの手応えのブラッシュアップにもつながった。クリエイティブなところは人間、定型・確実・安定には自動化を導入したところ、最終サブミット数を数えたら、スタッフが52％、Jenkinsが48％という結果となったという。
面白さも品質に含まれると考えてQAを実施
最後はQAのパートについてご紹介していこう。本作のQAをするにあたっては、バグがないことだけが品質ではなく、面白さも品質に含まれると考えたところからスタート。面白さを深めるために制作のサイクルをたくさん回せるよう、その環境の提供と維持をQAの役割と定義した。
また本作は広大なフィールドで展開されるゲームで、大規模なプロジェクトになることが予想され、多様かつ巨大なデータを扱う必要があった。そこで各ツールの機能をゲームに特化したり、効率を上げるだけでは不十分であるという課題を抱えていた。そこで人とデータ、ツールを繋げて利用しやすい状態にすることを目標に、編集データやツール、タスク、作業者それぞれのデータをデータベース化した。
そして何か作業をしたい時に、データと人、ツールがつながっていないと、それらの作業対象を探す部分で苦労し、クリエイティブな時間を奪ってしまう。このためにゼルダエディタが誕生したのは、すでに述べたとおりだ。これにより作業対象を探す手間を省き、制作サイクルの効率を改善できた。
ゲーム全体の把握と品質向上を図るためには、データベースからデータを抽出する際のクエリを誰でも扱えるように設計。フィールドに関連する情報をマップ上に可視化するワールドプロットを作成し、フィールドタスクビューを設けて、全体作業の進捗具合を把握できるようにした。ゲームオーバービューでは、よくゲームオーバーになる場所を記録。そこにオートセーブを入れるといった対策を立てられるようにした。
またデータを共有することも設定。データベースビューワーでクエリを共有して再利用できるようにした。ここでは誰かが作成したクエリを共有するほか、プログラマでなくても制作に活用できるようにし、問題のあるデータを自動でタスクかできるように設計したという。こうしたツール類の連携により、面白い物を作るサイクルがたくさん回るようになったわけだ。
デバッグについてだが、これまでは開発終盤に導入することが当たり前と考えられていた。しかし最初のマイルストーンでのデモプレイではバグが多く、2日間で617回もフリーズしたのだとか。このままでは、終盤にいくら頑張ってもバグをなくせない可能性も見えてきた。そこで導入したのが序盤からのデバッグだ。ただし開発者としては、デバッグをする暇があったら、もっと実装を進めたいと思うのが当然だ。
そして自分が困ったバグや、誰かが困っていて治して欲しいと言われたバグについては直しているという自覚があるだろう。ただし直っていないバグも多数ある。時間が足りなかったり、原因がわからなかったり、そもそもバグに気づいていない場合もある。また今は誰も困っていないと判断して、後回しにしたものもあるだろう。
このため、序盤からのデバッグは制作サイクルの効率化を図ることを目的とし、終盤のデバッグについては、最終製品のバグをなくすという、2つの役割を設定して進めていった。そこで、これまではバグ管理システムとタスク管理システムは別になっていたものを、ゼルダエディタ内にバグもタスクとして管理する設定を導入した。これらについては説明会も行なって運営していったそうだ。
またバグについては「ZELDA_ERROR」によってミスに気づきやすいようにした。フリーズをしないためにプログラマーがこの仕組みを作ったのだが、製品版までには6,000以上のZELDA_ERRORが仕込まれていたという。加えて「ホットリロード」が導入され、間違ったデータはその場で修正可能に。プログラムについても同様にホットリロードを使って、ビルドした新規プログラムも試せるようにした。
バグを減らすのに役立ったのが、ゲーム画面からすぐにバグ投稿できるようにしたこと。その際にはプレーヤーの座標、シーンの切り替え、イベント、ダンジョンといった情報も自動で挿入するようにした。このため担当者を知らなくても、データの情報から担当者宛に連絡が行くので、デバッグが簡略化された。このほか人が見つけられない場合を想定して、自動テストによりバグを見つけるという方法も採用された。
こうした活動により、バグの報告が確実になってデバッグに寄与。開発スタッフ自身のバグ報告も多くなり、新しい試みによりチームを変えることができた。デバッグは制作の一部であり、実装と並列に作った結果、最後まで磨き込みができた。こうした方策により、新しい「ゼルダ」は作られてきたのだ。
