エンジニアの岡村氏とアーティストの尾山氏が語る、約4年間のプロジェクト運営
2017年8月30日～9月1日の3日間、パシフィコ横浜にて開催された、日本最大級のゲーム開発者向けカンファレンスCEDEC 2017。開催2日目には“『ゼルダの伝説 ブレス オブ ザ ワイルド』のプロジェクト運営 ～試作から製品までシームレスに！～”と題したセッションが行われ、任天堂株式会社企画制作部の岡村祐一郎氏と尾山佳之氏が登壇した。
岡村氏は2005年度入社のシステムアーキテクトで、これまでにWii用『Wii Sports』やWii U用『Nintendo Land』などといったタイトルに関わってきた。また、尾山氏は1999年度のシニアリードアーティストで、『ゼルダの伝説』シリーズにはNINTENDO64用『ゼルダの伝説 ムジュラの仮面』から携わっている。
このセッションでは、任天堂にとってかつてないほどの大規模開発となった『ゼルダの伝説 ブレス オブ ザ ワイルド（以下、『ゼルダの伝説 BotW』）』において、ゲームで扱うすべてのデータを管理するツール“ゼルダエディタ”が、いかにプロジェクト運営の中核を担ったかを紹介。スムーズな運営を支援する機能をゲームエンジンに実装した岡村氏と、それを使用した尾山氏が、開発期間約4年、約300人が参加した一大プロジェクトを振り返った。
制作フローを従来の“積み上げ方式”から“骨組み方式”へ
岡村氏によると、『ゼルダの伝説 BotW』は、従来の『ゼルダの伝説』シリーズとは異なる制作フローで開発されたという。たとえば、尾山氏が参加した『ゼルダの伝説 風のタクト』の場合、“積み上げ方式”と呼ぶ制作フローが採用された。
【積み上げ方式】
五重塔を建設するとして……
1）大枠をイメージ
2）1階をしっかり作る → 試作期
3）1階の仕上げを上に展開 → 量産期
4）全体のバランスを取る → 仕上げ期
『ゼルダの伝説 風のタクト』は、ダンジョンを1ステージとし、各ステージにあるアイテムを使ってそのステージを攻略するという、「遊びがステージの中で完結する」設計。それゆえ、まずは五重塔の1階部分＝ステージ1を、遊びから絵の部分までしっかりと完成させ、それを“お手本ステージ”として、以降のステージを量産していくという方式が適切だった。
対する『ゼルダの伝説 BotW』はオープンワールド型であり、ステージの概念がない。そこで、“骨組み方式”と呼ぶ制作フローが採用された。
【骨組み方式】
五重塔を建設するとして……
1）大枠をイメージ
2）骨組みをしっかり作る → 試作期
3）壁や屋根を作る → 量産期
4）装飾をして仕上げる → 仕上げ期
まず、粗くてもいいから、ゲームサイクルを世界全体で体験できる骨組みを制作する。その骨組み＝プロトタイプに、あとから肉付けをし、磨き上げていくという方式だ。最初に作った世界のなかで、制作が進むにつれ、仮データが製品クオリティのものに置き換わっていく、シームレスな制作フローである。
「あえてやめておこう」と言える空気で、骨組み作りをスムーズに
骨組み方式での開発スタッフたちは、「世界を1周まわって骨組みを作り、もう1周まわって肉付けをし……」と、周回を重ねていくイメージとなる。
1周目：骨組みを作っておもしろさを確定する → 試作期
2周目：正式データをすべて揃える → 量産期
3周目：マスターアップまでひたすら磨き上げる → 仕上げ期
しかし、オープンワールド型ということで、たとえ粗い作りであっても、骨組みを作るのは大掛かりな作業となる。そこで、「1周目はゲームの本質以外の実装は禁止」、「2周目は磨きこみは禁止」という禁止事項を設けた、と岡村氏。たとえば、イノシシのゲーム的な機能とは“倒すと肉になる”“近づくと逃げる”というもの。そこで、倒すと肉になる、近づくと直線移動して消えるという部分のみを、1周目で実装した。アニメーションやエフェクトなどは、1周目ではあえて用意しなかったというのだ。
1周目でやることを増やしてしまうと、いつまで経っても骨組みができあがらない。そこで、チーム全体で「いまはあえてやめておこう」と言える空気を作ったのである。さらに、プロジェクトチームとして禁止事項をあらかじめ宣言しておくことで、プロジェクト外部が1周目の状態を見たときに進行を心配することもなくなり、ひいては担当者を守ることにもなったという。
1周目：過去作品の資産を活用してゲーム体験を作り、おもしろさを確定
具体的に1周目では、村の様子からNPC、ラスボスに至るまで、ほぼすべてが過去作品のデータで構成された。岡村氏は1周目の取り組みを「過去作品の資産をフル活用してゲーム体験を作り、おもしろさを確定した」と言い表した。
この、過去データの活用により、新作用のデータを揃える仕事を最小限にとどめることができたのがアーティストたちだ。尾山氏は、この期間に「グッとくる絵作りや、自分たちの作りたいものをゲーム内に落とし込むための技術検証、2周目からはじまる量産の準備に集中することができた」と、アーティスト側の動きを説明した。
ところで、1周目制作中の段階から、チーム内で何度かモニタープレイが行われていたそうだが、初期の段階で大幅な見直しが発生。当初、開発チームがオープンワールド型のゲーム制作に慣れていなかったため、「世界をいくつかのエリアに分割して、エリアごとに知っている文法で」制作を進めていたのだが、これがモニタープレイでNGとなったそうだ。岡村氏は、「もちろん、見直しはないに越したことがないが、大事になる前に軌道修正ができたのは、1周目の取り組みの大きな成果」と振り返った。なるほど、最初から多くの人を巻き込んだ作りかたをしていたら、もっとたいへんな事態になっていたかもしれない。
2周目：ゼルダエディタに実装したオリジナルのタスク管理機能で効率アップ
2周目は、過去作品のデータを正式なデータに置き換えていく周回となり、膨大な量のタスク管理が必要に。タスクとは作業指示のことで、一般的には市販のタスク管理ツールを使い、書面で発注されることが多い。しかし、たとえば「ボコブリンのシェーダーの実装ができましたので、調整をしてみてください」という発注があったとして、作業者は該当のシェーダーまでたどり着くのがたいへんだし、ボコブリンといってもボコブリンなのか黒ボコブリンなのかもあやふやで、スムーズにタスクに取り掛かれなかったという。
岡村氏たちは、このようなタスクを“迷子タスク”と呼び、これを失くして作業効率をあげようと考えた。そこで、ゲーム中のすべてのデータを管理する“ゼルダエディタ”のなかに、自作のタスク管理ツールを実装。“タスクを必ずデータに貼りつける”という、付箋のような仕組みを作り上げた。これで該当データになかなかたどり着けなかったり、どのデータを指すのかあやふやだったりという問題は解決。また、データは粒度が小さく、ひとつのファイルをひとりの作業者が編集する程度であったことから、タスクをデータに貼りつけることで自動的に作業者を限定することもできた。
さらに、この仕組みをアーティストたちがうまく活用した。尾山氏によると、従来は剣を作る場合、ひとりのアーティストがまるごと担当していたため、タスクもひとりの作業者へ「剣のモデルを作ってください」と発注して終わりだった。今回は、これを“スケッチ”、“モデル”、“アニメ”など、細かな作業ごとに作業者を分ける体制に変更。これによってタスクの粒度が小さくなり、納期の見積もりがしやすいなどのメリットが生まれた。
ただし、この方式だとすべての作業者に対してタスクをひとつひとつ発注しなければならず、発注者にたいへんな労力がかかる。そこで、エンジニアに頼んだのが“タスクの一括発注機能”。たとえば、武器のデータを全選択して右クリックすると、“まとめてタスクを投稿”というメニューが選択可能で、すべてのデータに自動的にタスクを貼りつけることができ、大幅に時間を節約することができたそうだ。
ほかにも、タスクをデータに貼りつけることで生まれた恩恵があった。従来は進捗管理リストを手動で作成していたが、追加や更新のたびに作業が発生し、手動ゆえに情報の正確性も“？”だった。ところが、今回はタスクがデータに紐づいているため、タスクの自動集計ができるようになり、更新も毎日自動的に行われるように。もちろん、情報も正確である。
このように、オリジナルのタスク管理機能を実装し、手動ではなく機械的にできることを増やした結果、開発チームは膨大な作業量の2周目をうまくのりきることができたのだった。
3周目：大量のバグを消化するため、エンジン全体でタスクをサポート
3周目は、すべてのデータを製品クオリティーにする周回で、バグに向き合う機会が増えていった。ゼルダエディタでは、通常のタスクもバグも、どちらもタスクとして扱うため、作業の優先順位が正確につけられるというメリットがあったとのことだ。
岡村氏は「大量のバグを消化するため、エンジン全体でタスクをサポートした」と振り返る。バグの報告機能はゲームに実装され、モニタープレイ中にバグを発見した場合は画面をクリックすれば、ゼルダエディタへタスクとして報告できる仕様とした。また、ゼルダエディタのあらゆるところにはスクリプトを実行する道がつけられ、タスクからデータ、データからゲーム、タスクからゲームにダイレクトにアクセスできるようにした。この仕様により、バグを報告するとき「いつどこでどんなときにデモが見にくい」という状況を、スクリプト言語で伝えることで状況を正確に再現することができた。
一方、アーティストサイドでは、膨大なデータを製品クオリティーにするためのバグチェックと磨きこみとがあり、どちらもタスクとしてリーダーが一括発注。ゼルダエディタではすべてのデータを機械的にチェックし、モデルやテクスチャサイズが適性かどうかなどの判別が可能で、問題のあるデータはその場でデバッグ生成して確認できるよう、エンジニアのサポートを受けたそうだ。加えて目視でのチェックも重視し、ゲーム上でアイテムをすべて並べて火をつけ、正しく燃えているかどうかなどを確認したとのこと。
尾山氏は、3周目にもエンジンに組み込まれたタスク管理機能の便利さを実感したといい、「タスクからデータを探す時間がかからないので、確認、調整する時間を削減できた」、「正確な情報を集めることができるので、リストの作成やデータ管理がラク」、「すべてのタスクがゼルダエディタに集まっているので集中管理できてラク」と、そのメリットを挙げた。それによって、「アーティスト全体がクリエイティブな作業に集中することができた」ことが、最大のメリットだとした。
ゲームエンジンに機能を実装し、円滑なプロジェクト運営を
こうして、1周目に約1年半、2、3周目にそれぞれ1年強を費やし、『ゼルダの伝説 BotW』は完成した。最後に岡村氏は、「プロジェクト運営は、対象となるゲームの制作や、置かれている環境によってまったく異なるもの。今回の事例がそのまま当てはまらないことは多いと思う。しかし、プロジェクト運営のためになにができるかということを考えて、ゲームエンジンに機能を実装していくという構図は、どこにでも当てはまる考えだと思う」と、聴講する開発者たちにメッセージを贈った。
［関連記事］
・『ゼルダの伝説 BotW』自然と寄り道してしまうレベルデザインのカギは、“引力”と“地形”！ 魅力的なハイラルができるまでを解説【CEDEC 2017】
