『ドンキーコング バナンザ』は意図せぬ挙動も面白ければ仕様化。任天堂QAチーム＆デバッグ会社「マリオクラブ」の活躍を披露【CEDEC2026】

『ドンキーコング バナンザ』（以下、『バナンザ』）といえば、画面上のあらゆるものを破壊できるゲーム性が最大の特徴。単に地形を殴って破壊するだけでなく、敵を吹き飛ばしたり、吸い込んだり、あるいはドリルのように地形を掘って進んだりと、縦横無尽な破壊アクションが繰り広げられます。

このゲーム性を実現するため導入されたのが「ボクセル技術」です。3次元空間に配置したデータの箱「ボクセル」によって地形や敵、NPCなどを構築しており、ボクセル内部のデータをリアルタイムに変更することで見た目を変化させています。

このボクセル生成・変形技術の自由度を活かすことで、破壊アクションのみならず、「敵にボクセルを付着させる」「ショートカットルートを開拓する」といった多彩なギミックを実装できます。一方で、これほどまでに地形の変形が頻発するゲームとなれば、バグとの戦いは避けられません。

『バナンザ』の開発でも例に漏れず、コリジョン抜けや処理落ち、ポリゴンメッシュの崩れといった多数の不具合に直面したといいます。しかし、破壊を軸とした自由な体験こそが本作のコアな魅力であるため、これを損なわないために、QAにおいては以下の3要素からなる「体験ファースト」という方針が掲げられました。

本講演では、この「体験ファースト」に基づくQAおよびデバッグの具体的な進め方について、テクニカルリードプログラマーの栗原 竜矢氏と、オブジェクトプログラムに加えて自動テストの実装やデバッグチームとの連携などQA領域も担当した濱崎 福平氏によって解説されました。

QAに関する最初のトピックとして「コリジョン」の課題が挙げられました。

壁抜けや意図しない落下を防ぎ、安定したコリジョンの挙動を実現するには、通常、コリジョン形状に対して一定のルールを設ける必要があります。しかし『バナンザ』ではボクセルの破壊や変形によって地形が目まぐるしく変化するため、ルールに収まらないイレギュラーな形状が容易に発生し得ます。

『バナンザ』開発チームが過去に手がけた『スーパーマリオオデッセイ』では、抜けやすい「V字のコリジョン」を作らないルールが定められていた

すべての形状変化を予測してルール化することは困難です。かといって、不具合を防ぐために破壊できない地形を増やしてしまっては「制約を増やさない」という開発方針に反してしまいます。

そこで、コリジョン抜けの対策は進めつつも、どうしてもキャラクターが地形に埋まったり内部に入り込んでしまったりした場合には「周囲のボクセルを自動で破壊する」というアプローチが採られました。万が一コリジョン抜けが発生しても、ゲーム体験を損なうことなく自然にプレイへ復帰できる工夫が施されています。

地形が変化した際、ドンキーコングの周囲を囲う赤い円（画像中央）の範囲にあるボクセルを自動で破壊することで、地形に埋まる現象を防いでいる

自由な地形破壊・変形を許容するこのゲーム性は、ステージ進行のシーケンスにも大きな影響を及ぼしました。プレイヤーの工夫次第では多彩なショートカットが可能となるため、ときには開発側が想定していたフェーズをスキップしてボス戦などのイベントに到達してしまう「シーケンスブレイク」が多発。これらを放置すれば最悪ゲームが進行不可に陥るなど、深刻な問題に繋がりかねません。

しかしここでも、移動ルートに制約を課すのではなく、ショートカットの存在を「活かす」方向で調整。シーケンスブレイクによって収集アイテムが入手不可になるといった破綻をなくし、自由に攻略順を入れ替えても問題なく進行できるよう、あらゆるシーケンスがスキップされ得ることを想定した設計へと見直されました。

スキップされたイベントについてNPCに言及させないなど「ブレイクされる前提」でシーケンスを設定している

その代表的な例が、ドンキーコングの強化形態である「バナンザ変身」です。ゲーム内には合計5種類の形態が登場しますが、クリアに必須となる2種類以外は、取得せずともエンディングを迎えられる仕様となっています。そしてエンディング後には、未取得の形態を一括で習得できるイベントを追加することで、プレイ状況による進行度の差を均一化するフォローがなされています。

壊れた地形は必要な箇所だけをこっそり復元

本作の地形は基本的に、一度破壊すると別のステージへ移動するまでその状態が維持されます。しかし、足場が崩れたままになることで移動難易度が極端に上がってしまったり、ボス戦開始時の演出で敵が空中に浮いてしまったりと、地形が損なわれた状態によって予期せぬ不具合を招くケースも存在しました。

そうした場面にプレイヤーが遭遇すると「ここは壊さないほうがいいかもしれない」と破壊を躊躇してしまい、結果的に「楽しく安心して破壊できる」という体験方針を達成できなくなってしまいます。

そこで導入されたのが、ゲーム中の必要な箇所だけを「密かに復元」する仕組みです。落下によるミスや敵に倒された際など、「ステージへ入り直す」タイミングに合わせて該当箇所の地形が自動で復元されるよう、レベルエディタ上で設定が行われました。

職種の垣根を越えたチームプレイでの最適化

本作では破壊時に複雑な処理が走るため、激しい処理落ちも開発段階における大きな課題でした。ゲームの自由度や破壊表現を妥協せずにこの問題を解決するため、破壊を行っていない通常時の処理負荷に余裕を持たせるという対策が取られました。

とはいえ、各ステージには多彩な意匠が凝らされており、いかなる破壊状況でも処理負荷を一定以下に抑え込むのは容易ではありません。さらに、並行して進むバグ修正やブラッシュアップ作業によって再び負荷が増大する懸念もありました。そこで、最適化に携わる人員を拡大し「チームプレイでの最適化」を推進することになりました。

具体的には、プログラマーだけでなくアーティストとレベルデザイナーを加えた混成グループをステージごとに結成し、共同で処理負荷の軽減に取り組むという試みが行われました。

プログラマー以外のスタッフでも処理負荷の状況を正確に把握できるよう、マップ上で負荷の高低を視覚的に確認できる機能や、ゲーム内でリアルタイムの負荷を可視化するツールも導入されました。

マップ上に配置された円は「その位置から見た景色の負荷の高さ」を表しており、赤く示された方向が最も高負荷となる

リアルタイム負荷表示機能の画面。プログラマー以外の職種にも直感的に伝わるようシンプルな表示が心がけられている

さらには、開発チーム内に「処理負荷ニュース担当」を配置し、自動集計されたデータや更新情報をもとに手動での「ニュース発信」も実施。負荷の高いステージをランキング形式で発表するなど、現在の状況をチーム全体へ周知させる取り組みが行われました。

この体制により、「負荷の高いオブジェクトのアセットについて、アーティストが改善案を出し、プログラマーに確認をとる」といった、職種を横断した効率的かつスピーディーなアプローチが実現。開発チームが一丸となり、各ステージの負荷を「余裕を持たせる」基準値内に収めることに成功しました。

後半では、デバッグに対する取り組み方について語られました。

濱崎氏は「自由な遊びが魅力となる『バナンザ』ではデバッグにも労力がかかる」というQA目線での予測に基づき、本格的なデバッグ期間に入る前のかなり早い段階から「体制と仕組み」の構築を進めていたそう。

ここで重要な役割を担ったのが、任天堂の子会社としてゲーム開発をサポートしている「マリオクラブ株式会社」。過去の開発タイトルでもテスターとして参加してくれたマリオクラブのメンバーが、今回の開発においては初期段階から開発チームに出向する形でジョインしていました。

開発チームの一員として常駐したテスター陣は、開発者と同じ情報に触れられるようになり、各種ミーティングにも参加。仕様決定の経緯まで深く把握することでゲームへの理解度を飛躍的に高め、その知識をデバッグ作業へと還元していきました。

日々のテストにおいては、各テスターの自由な裁量でプレイを行う「フリーチェック」方式を採用。仕様の穴や破綻が起きそうな箇所を重点的に洗い出すなど、開発者と同じ視座を持ったテスター陣と「共に作る」体制が築き上げられました。

効率的かつ面白さをプラスするデバッグの「体制と仕組み」

テストおよびデバッグの効率を最大化するため、専用のデバッグ機能も導入されました。

ゲーム内のボクセルを任意に増減させたり、壊したボクセルを復元したりと自由な操作が可能となり、フィールド全体のボクセルを全て破壊してもゲームが正常に動作するかを確認するなど、幅広い検証作業で大きな効果を発揮しました。

ゲーム内の「DKアーティスト」モードは、ボクセルを操作するデバッグ機能をそのまま応用して実装されている

また、スクリプト制御によりデバッグ機能を駆動させ、ゲームを通しでプレイさせる「自動テスト機能」も導入。地形を破壊して繋がるルートが正しく機能しているか、カットシーンの再生や収集アイテムのコンプリートに破綻がないかといったチェックが自動化されました。

この自動テスト用のスクリプトは、ゲームの操作と仕様を熟知したテスター自身が実装を担当しており、あらゆるルートにおける自動テストパターンの量産に成功しています。さらに、これらのスクリプトはシビアな操作が要求されるバグの再現にも役立ち、修正対応後の確認作業においても大いに重宝されました。

開発中に発覚した「無限ジャンプバグ」の検証にはフレーム単位の精密な操作が要求されたため、再現用スクリプトが活躍した

これらの仕組みを活用し、本作の開発環境では自動テストによる状態確認を常時継続。自動プレイで失敗した箇所については、その日のうちに原因を特定して修正対応することを徹底。常にゲームが「最初から最後まで遊べる」「全収集アイテムがコンプリート可能」な状態に保たれていることを担保し続けました。

講演では、開発中に発生したさまざまなバグの事例も紹介された

マリオクラブのテスター陣と早い段階から協力して構築したこの「体制と仕組み」により、バグの検出や共有、修正対応のサイクルが高速化。濱崎氏も「結果として非常に多くのバグが報告されたが、それはつまり、通常のテストプレイでは発見が困難なバグを多数検出できたことを意味している」と確かな手応えを語りました。

ゲームの仕様を深く理解したテスター陣の高度な技量と、デバッグ機能によって構築された「常にゲームが安定して動作する環境」。この2つが機能して十分な検証時間を確保できたことで、熟練のテスター陣の腕前をフル活用した「スーパープレイによる検証」にまで進むことができたといいます。

テスターに対して「とにかく最速を目指す」といったイレギュラーな遊び方に挑戦してもらい、新たな操作テクニックやシーケンスブレイクの手法を開拓してもらった結果、開発陣の想定とは異なるアプローチでボスを撃破するプレイングや、必須と思われていたレースゲームのスキップなど、いくつもの想定外が発見されることとなりました。

そうした想定外の要素も「面白いなら活かす」のが、『バナンザ』の開発方針。予想だにしなかったショートカットの数々も、ゲーム体験として面白いと判断されたものは仕様として残すことを決断。スキップされてしまったイベントに関しても、その状況に応じた特別な専用セリフを追加するなど、面白さを最優先したQAプロセスが『バナンザ』ならではの魅力を支えています。

レースイベントをスキップした場合には、ポリーンが「レースに勝たなくて良かったのかな？」と専用のセリフを話すように

デバッグやQAはゲームのマイナスを減らす作業と捉えられがちですが、『バナンザ』の開発においては、予想せぬ要素すらもプラスとして活かして伸ばすことで、作品のテーマである「破壊」をQAの側面からも推進し、高品質のゲームを完成させることに繋がったと、栗原氏は講演を総括しました。

ハル飯田

大阪生まれ大阪育ちのフリーライター。イベントやeスポーツシーンを取材したり懐ゲー回顧記事をコソコソ作ったり、時には大会にキャスターとして出演したりと、ゲーム周りで幅広く活動中。
ゲームとスポーツ観戦を趣味に、日々ゲームをクリアしては「このゲームの何が自分に刺さったんだろう」と考察してはニヤニヤしている。