データに紐づくタスク管理ツールで骨組みから作るオープンワールド「ゼルダの伝説BotW」のプロジェクト運営

8月31日、パシフィコ横浜で開催されたCEDEC 2017にて「『ゼルダの伝説　ブレス オブ ザ ワイルド』のプロジェクト運営　～試作から製品までシームレスに！～」と題された講演が行われた。タイトルの通り、今年3月に発売された「ゼルダの伝説 ブレスオブワイルド」（以下「BotW」）の開発を任天堂のスタッフが振り返り、エンジニアとアーティストの立場からプロジェクトマネジメントの秘訣を説明したセッションであった。任天堂がこのような公開での発表を行うことが非常に稀であり、特に今回の発表では任天堂が社内で利用している内製タスク管理ツールが紹介されたのが貴重だ。すべてのスタッフが作品のクオリティにコミットするという任天堂らしい開発スタイルを大規模プロジェクトでいかに実現したか、そのあらましを説明しよう。

まずは登壇者の紹介が行われた。プログラマーの岡村祐一郎氏は「BotW」でシステムアーキテクトを担当。ゲーム開発を円滑に行うための全体の設計やツールや環境を整えるのが仕事だ。今回はエンジニアの立場からプロジェクト運営の方法を紹介する。他方、アーティストの尾山佳之氏はゼルダの伝説シリーズの多くのキャラクターデザインに関わってきた。「BotW」でもキャラクターモデルのとりまとめを行ったそうだ。立場として岡村氏が描くシステムや作業フローのなかで尾山氏が現場のアーティストの仕事を仕切るといった感じであろう。

具体的な内容に先立ち紹介されたのは「ゼルダエディタ」と呼ばれる「BotW」専用のツール（群）である。ゼルダエディタではゲームで扱うすべてのデータを管理することが可能で、レベルエディタ、様々なツールとそのランチャー、データを変換するコンバータなどを一括して操作できるそうだ。様々なツールの一括管理という役割であるため統合開発環境である「ゲームエンジン」とは謳われてはいないが、「BotW」のプロジェクトの中核を担うツールであることは間違いない。今回はこのゼルダエディタというツールを前提にプロジェクト運営の実際が説明された。

ゲーム開発における積み上げ方式と骨組み方式

まず実例を紹介する前に、その目的について理念的なレベルで説明された。岡村氏によれば、ゲーム制作のフローには大まかにわけて「積み上げ方式」と「骨組み方式」の2種類がある。岡村氏は五重塔の建築を例えに、その2つの方式を説明した。「積み上げ方式」とは最初の階層を作成して、その階層に合わせて一つずつ階層を増やし行くやり方だ。対して「骨組み方式」とは最初に全体の階層の骨組み部分を作り、その後にブラッシュアップしていくやり方だ。ここでの階層をゲームにおけるレベル（ステージ）と考えれば、この2つのイメージは伝わるだろう。

この2つの方式はどっちが良いというものではなく、作りたいゲームに合わせて一長一短があるという。では今回の「BotW」にはどちらが適しているのだろうか。過去のゼルダ作品を手がけてきた尾山氏によると、「風のタクト」などでは基本的には「積み上げ方式」を使用してきたそうだ。巧みなレベルデザインで定評がある任天堂では、ひとつの見本となるステージを作り込み、その後にそれをアレンジする形で残りのステージを作ることが多いという。しかしながら、オープンワールドであり、様々なモンスター、素材、ダンジョン、といった要素が世界の中で関連づけられている「BotW」では、限定された領域のようなステージやレベルといったものが存在しない。そのため、最初から世界のすべてを用意しなければいけず、必然的に「骨組み方式」が採用されることになった。

このように積み上げ方式と骨組み方式の大きな違いは試作段階にあたるプロトタイピングにある。積み上げ方式ではひとつのステージやレベルがそのゲームの面白さを検証するためのプロトタイプとなるが、骨組み方式は全体の骨組みがプロトタイプになるのだ。ここで問題となるのは、プロジェクトのロードマップをどう構成するかだ。積み上げ方式の場合は全体を5ステージといった風に決めてしまえば、それぞれのステージごとにマイルストーンが接地されることになる。

しかしながら、オープンワールドの開発のような骨組み方式でははじめからそのようなマイルストーンは存在しない。そこで「BotW」では骨格段階の試作からアセットの量産、さらにそれらの磨き上げといった形でマイルストーンを設置していったという。具体的には試作段階のオブジェクトは仮のもので、余計なディテールは描き込まれていない。その後、それらのオブジェクトやアセットは製品版に徐々に近づいていくということだ。重要な点は遊びを構成する要素は初期段階から入っており、それらのディテールが徐々に立ち上がってくるという点。これを今回の発表では「シームレスな制作フロー」と呼んでいる。

過去作のアセット流用で骨組みを作る

ここからは具体的なマイルストーンにそってプロジェクトの概要が説明された。最初から全体の要素が存在して、それを磨き上げるプロセスであるため、マイルストーンは陸上のトラック競技のように1周目、2周目、3周目という形で設けたという。ゲームの全部の要素を3回にかけてブラッシュアップしていくようなイメージだ。またそれぞれの周回で余計な作業が発生しないように、禁止事項を定めた。具体的には1周目では、ゲームの本質以外の実装は禁止、2周目はキャラクターや環境アセットを揃えるに留まり、それらを磨き込みを禁止といった具合だ。以下ではそれぞれの周回の作業を説明する。

1周目はゲームの本質、つまり世界にある要素のインタラクションで生まれる遊びに注目する。そのため、キャラクターなどはすべて過去作品のデータを流用したり、その場で作った仮データを当てはめることになった。NPCには過去作品の「風のタクト」のお嬢様キャラをゲルドの王女として利用、その他、モンスターなどもゴブリンの色変えで対応していった。ちなみにこの段階からスタッフクレジットさえ入っているが、すべてがエグゼクティプロデューサーという面白い状況になっている。いずれにせよ、クレジットも含めたゲームの全体を最初から準備することで、ゲーム全体のユーザー体験を確認できるというメリットがある。この段階で検証することで、早い段階での軌道修正が行えるというわけだ。

他方、アセットの流用や仮データを当てはめている間に、実際のモデルなどを作るアーティストは何をしていたのだろうか？ 正直なところ直接ゲーム制作においては「何もしていなかった」そうだ。実際にはコンセプトになるアートや雰囲気をアーティスト全員で考えたり、取り入れる技術のための研修などを行っていたそうだ。また本作独特のトゥーンレンダリングや金属感を出す表現の研究やアセットを量産するためのワークフローの検討、さらに種族の考察といった世界設定の共有も行った。

タスク管理ツールで骨組みから肉付け

2周目では1周目でいれた仮のデータを正式なデータに置き換えるのがメインとなる。実際に置き換えられたアセットによるゲーム画像は製品版にかなり近くなっているが、テクスチャやNPCのアニメーションに雑なところが残っている。これらをいかに磨き上げるかが重要となるが、キーとなったのはタスク管理だ。

タスク管理はゲーム開発に限らずプロジェクトマネージメントにおいて重要だ。タスクとは端的に言えば、作業のお願いであり、通常はチケットシステムなど専用ツールで管理する。具体的にはタスクの内容、発注者、作業者、作業見積もりなどを書いた一連のチケットを発行する。ただ従来のツールでは、タスクを行う対象が曖昧であったり、作業するデータにすぐにアクセスできなかったり、タスクの粒度が大きすぎたりといった形の「迷子タスク」が発生する。通常はこういった曖昧なタスクをしないように個々の発注者がタスクの書き方に注意するか、プロジェクトマネージャーがタスクの精査や棚卸しをすることが普通だ。

しかしながら、任天堂が取った解決方法はより大胆なものだ。というのも、ゼルダエディタに専用のタスク管理機能を付け加えたのだ。このタスク管理ツールは通常とは異なり、すべてのタスクが何らかのデータに貼り付けられている。例えば、ゴブリンのモデルに問題があれば、そのモデルのデータに「モデルをしかじかにしてください」といった具合にタスクを貼り付けるのだ。イメージとしてはゲーム内のあらゆるものに直接付箋を貼って作業を指示するとった感じだ。

結果、作業するデータには一発でアクセスでき、曖昧さもなくなり、タスクの粒度も細かくなる。またあらゆるデータには制作者の履歴が入っているため、作業者も自動的に決定される。このような付箋型とも言うべきタスクは、モデル、シェーダー、AI、ゲーム内フィールドの座標といったあらゆるところにつけることができる。

タスク管理ツールを利用したアセット量産とバグフィックス

さて次にこのタスク管理ツールによってアーティストがいかにデータを量産したかが説明された。先程説明したとおり、「BotW」の開発の序盤においては、ゲーム内のデータは過去作品の流用や仮のものを使用している。この作業においても、まずアーティストは10種類の武器のために、仮の剣のデータをコピーで作り、区別のため色だけを変える。そこに「Sword_1は剣、Sword_2はこんぼう、Sword_3は斧」といった形で「兵士の剣のモデルを作ってください」といったタスクを付けていく。

このようにタスク管理ツールを使えば機械的に一括でタスクが発注できる。またタスクをデータに紐付けたことによって、タスクを集計することで正確で簡単な進捗管理も可能になった。実際にこのタスク管理ツールで集計した結果を見るときれいな右肩下がりでタスクが減っていき、ここからプロジェクト全体の進捗見積もりも可能となった。これもタスクがデータに紐付いているため、重複タスクや曖昧なタスクが生まれないことの恩恵と言える。

最終工程である3周目ではすべてのデータを製品版のクオリティにすることになる。具体的にはデータのバグを探したり、そのバグを取ったりする作業、つまり磨き込みのためのバグフィックスがメインとなる。このバグフィックスに関しても上述のタスク管理ツールを使用した。ただしツールからバグ報告を入れるだけではなく、テストプレイ中のゲーム内からもバグ報告を入れることが可能になっている。例えば、スケール感がおかしなキノコのオブジェクトがあった場合、そこを選択してバグ報告を付箋のようにつけることができるのだ。さらにタスク管理ツールはゲームを動かすスクリプトエンジンに対応しているため、バグ報告欄に直接スクリプトを書き込むことで、すぐに書き換えたスクリプトで実行も可能。タスクとテストプレイをシームレスに行ったり来たりできるわけだ。

一方、アーティスト側の３周目の動きとしてはとにかくデータの確認を行い、クオリティアップのために磨き上げる作業を行った。確認作業も２周目と同じくリーダーが一括発注を行い、モデルやテクスチャサイズといったものは表でチェック、その他のオブジェクトの燃焼、浮力、水流といった物理挙動は実機でチェックを行う。このタスク管理ツールでの確認と磨き上げの作業はデータへのアクセスが楽で情報が一元化しているため、アーティストとしてはかなり効率良かったと振り返っている。結果としてクリエイティブな作業に注力できたそうだ。

大規模開発でも常にゲーム自体に全体がコミット

以上の3周目までの過程で「BotW」の多様なキャラクターとフィールドが実現した。開発4年で人数のピーク時300人という大規模なプロジェクトであったが、それを支えたのがタスク管理ツールを搭載したゼルダエディタであったというわけだ。それぞれの周回の期間としては1周目が1年半と長く、2、3周目は1年強というところ。当初、任天堂にはオープンワールドのノウハウがなかったため、最初の段階で一番時間がかかったが、量産期のプロジェクトは安定していたそうだ。

プロジェクト運営はあくまでもゲームタイトルに合わせるべきとしながらも、今回のように骨組み方式のゲーム開発を大規模な人数で実現するために独自のタスク管理ツールを作ったところは非常に興味深い試みである。別のセッションではゲームのテストプレイのための開発版ロム（Wii U版）を自動で5分間に一回作成しているという発表もなされ、任天堂がいかにゲームプレイとゲーム開発の細かいサイクルを重視しているのか伺える。オープンワールドゲーム自体の開発は珍しくもないものの、この組織化されたやり方はまだまだ学ぶところが大きいだろう。