「ゼルダの伝説 BotW」にバグが少ない理由

素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。　

では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが、実のところそれはほとんど答えになっていない。

ゼルダのアタリマエを徹底的に見直した１人

日本最大級のゲーム開発者向け技術交流会CEDEC 2017にて、任天堂の丸子良太氏と大礒琢磨氏は「『ゼルダの伝説 ブレス オブ ザ ワイルド』におけるQA～ゲームの面白さを最大化するツールやデバッグの紹介」という講演を行った。ゲームの品質管理とは何なのかというところからスタートした本セッションは、デバッグへの挑み方が特に印象的だったので紹介しよう。

大礒氏は2010年に任天堂に入社したQAエンジニアで、BotWが初めて携わった「ゼルダの伝説」シリーズのタイトルだ。同氏はそれまで「nintendogs + cats」や「New スーパーマリオブラザーズ U」といったタイトルのシステム部分や開発環境のプログラマーだったが、BotWでは終盤に炎上せず、本作を無事に完成させるために、QAエンジニアになることを志願して開発初期から本作に関わることになった。そして、大礒氏もまた――プレイヤーには見えないところで――ゼルダのアタリマエを徹底的に見直した１人である。

これまでの「ゼルダの伝説」シリーズにおけるデバッグは、ゲームの終盤に入ってから行われていた。それを変えるきっけは開発の初期に行った「面白さの検証作業」だった。当時チームメンバーの全員（約80名）は2日間かけてゲームを最初から最後までプレイし、目指したビジョンを実現できたかどうか、検証した。ビジョンは達成されていたが、検証作業は非常に困難だった。様々なバグが発生し、ゲームがたった2日で617回もフリーズしたからだ。大礒氏によると、チーム内で「小まめにセーブしよう」という合言葉もできたくらいだ。

「このままではヤバイ」

「このままではヤバイ」と大礒氏は思った。

いつものように終盤に入ってからデバッグにとりかかるのであれば、頑張ったところでバグをなくせる気がしなかったという。そこで、序盤からデバッグをはじめることを提案した。

「デバッグする暇があったらもっと実装を進めたい」と反対の声も多かったそうだ。開発途中のバグが最終製品に残るかどうかもわからないとあっては、開発を進めながらデバッグをしていくのは時間の無駄だという考えが任天堂社内にあった。だが、大礒氏は「序盤からのデバッグ」と「終盤のデバッグ」を分けて考えるべきだと主張した。

「面白さの検証作業」といったテストプレイは大量のバグによって効率が明らかに落ちていた。他にも開発の様々なところでバグが悪影響を及ぼしていたはずだ。序盤からデバッグすることの目的は最終製品でバグをなくすというよりも、制作サイクルの効率を上げるところにある。副産物として、良い状態で最終デバッグに入れるという一石二鳥の作業でもある。

序盤ですべてのバグを直すのではなく、あくまで開発に支障のあるバグを厳選してデバッグを行った。プログラマーが困っている自分のバグや、誰かが直してほしいと報告したバグは修正し、時間の都合や原因不明であるためにデバッグが困難なものは見送り、現時点で特に困っていないものも序盤では直さなかった。

発見したらバグを簡単に報告できる仕組みを考案

では、「ゼルダの伝説」シリーズはこれまで、大礒氏が提案した序盤からのデバッグを行ってきていないのにも関わらず、バグがほとんどなかったのはなぜだろうか。同氏によると、ゲームによっては確かに終盤までデバッグにとりかかる必要のないゲームもある。だが、BotWは過去作と比べられないほど膨大なスケールの大規模プロジェクトで、多様かつ巨大なデータのゲームだ。このような特徴のゲームでは自分のバグすら把握することが困難で、そのバグが自分の気づいていないところで他のスタッフを困らせているケースも珍しくない。このようなことから、大礒氏はチーム全体がバグに対して意識を高め、発見したらバグを簡単に報告できる仕組みを考えた。

これまでの「ゼルダの伝説」シリーズでバグは主にテスターが報告しており、ゲームに実装する「タスク」と「バグ」は別々のツールで管理されていた。ところが、開発拠点が一箇所ではないBotWのような制作体制のゲームでは、このような仕組みは理想的ではなかった。バグとタスクの管理ツールを統合し、「バグだから後回し」という考え方を避け、すべてのバグを序盤から報告して優先順位をつけた。意識を高めるためにはシステムを導入するだけでなく、チーム全員への説明会も実施した。

バグを生みにくくするためには、ゲーム内でバグを検知する仕組み「ZELDA_ERROR」を導入した。気づいた時点で簡単に報告できるこのシステムは積極的に使われ、BotWのソースコードには6000以上もの「ZELDA_ERROR」が仕込まれていた。これは「投稿」を押すだけでバグを簡単に報告できたからであり、忙しくても手間にならなかったことがひとつの要因だ。さらに、序盤でバグの報告者はバグが修正されたかどうかを確認しなくても良いことになっていたので、「面倒なので報告はしない」とならないシステムだったことも大きいだろう。

実行中のゲームを再起動することなく、PCで編集した最新のデータを実機に反映される仕組み、ホットリロードもデバッグの防止に繋がった。編集中のデータを小まめに確認しながら作業を進められるので、ミスやバグには早い段階で気づけたからだ。

早い段階からバグを排除することで制作サイクルの効率を上げ、良い状態で終盤のデバッグにとりかかることもできた。これを実現するためにはタスクとバグを同じツールで管理し、手間のかからない形で報告できる仕組みを用意した。結果、BotWはオープンワールドゲームというジャンルの短い歴史において、最もバグの少ない作品のひとつになり、それもまた本作のユーザーからの高い満足度につながった大事な要素のひとつと考えるべきだ。