ニュース

「ドンキーコング バナンザ」破壊支えたデバッグ! 人海戦術と自動化で初期からバグ探し&最適化

バグでも面白いものはしっかり実装

【CEDEC2026】
開催期間:7月22日〜7月24日
会場:パシフィコ横浜 ノース/オンライン

 コンピュータエンターテインメント開発者を対象とした、ゲームに関する技術や知識を共有する国内最大級のカンファレンス「CEDEC2026」にて、レギュラーセッション「『ドンキーコング バナンザ』の破壊を推進するQA ~楽しく安心な破壊体験のために~」が7月24日13時40分より14時40分まで実施された。

 本セッションは、主にQA(Quality Assurance)についてのもの。同作にてテクニカルリードプログラム / ボクセルプログラムを担当した栗原竜矢氏と、オブジェクトプログラムを担当した濱崎氏によって、開発段階の映像やスクリプト、チーム内のチャットなどと共に開発中に行なわれた取り組みが紹介された。

 本稿では、その内容を一部抜粋して紹介していく。なお、「CEDEC2026」での講演はオンライン配信も実施されている。リアルタイムで視聴できなかった人でも、レギュラーパス、オンラインパスで受講登録を済ませている人であればタイムシフト配信を利用可能だ。

 タイムシフト配信はセッション終了の後日に公開され、会期終了後でも8月3日10時まで視聴できるので、本稿で興味を持った方はぜひ利用していただきたい。

□「CEDEC2026」タイムテーブル / セッション一覧のページ
□CEDEC2026「『ドンキーコング バナンザ』の破壊を推進するQA ~楽しく安心な破壊体験のために~」

【登壇者プロフィール】

栗原竜矢氏 任天堂株式会社 企画制作部  『ドンキーコング バナンザ』 テクニカルリードプログラム / ボクセルプログラム
『ドンキーコング バナンザ』ではテクニカルリードプログラマーとしてボクセルプログラムやCPU最適化を担当。
入社以来、オブジェクト、グラフィックス、HD振動などのプログラムに携わってきました。

濱崎福平氏 任天堂株式会社 企画制作部  『ドンキーコング バナンザ』 オブジェクトプログラム
『ドンキーコング バナンザ』では主にオブジェクトプログラムとQAを担当。
QA業務では、自動テストおよびデバッグチームとの連携を行いました。

QAの方針は3つ! 「安心して破壊できる」「自由度を保つ」「面白いなら活かす」

 まず栗原氏から説明されたのは、本作がピクセルの3次元版である「ボクセル」を採用していること。ゲーム内の様々なものにボクセルを採用することで、本作らしく自由度の高い「破壊」だけでなく「地形にものを投げつけて道を作る」といった遊びができるようになっているという。

 ボクセルが使われているということを踏まえたうえで語られたのはQAの方針だ。前述したように本作は自由度の高い「破壊」を使った遊びが魅力のタイトルである。そのため、QAの方針として大切にしたのは「破壊」とのこと。さらにいえば「破壊を軸とした自由な体験」。すなわち「体験ファースト」だという。

 自由度の高い「破壊」が魅力であるとはいえ、開発時には破壊を繰り返すうちに地形から抜けたり、処理落ちしたり、オブジェクトがうまく表示されなかったりと様々なバグが発生していたようだ。

 そこで、実際のバグ映像などと共に語られたのが「体験ファースト」として紹介された「楽しく安心して破壊できる」(破壊によってプレイヤーが体験を損なわないようにする)、「制約を増やさない」(バグ対処のためにできることを減らさない)、「面白いなら活かす」(一見バグでも良い体験なら調整したうえで仕様に組み込む)という本作におけるQAの軸となる考え方だ。

順番を無視しても攻略できる! 遊びの自由度を確保

 QAの方針の次に濱崎氏から語られたのはシーケンス(ゲームの流れ)についての考え方。他のゲームにも多く見られるように、本作にも攻略の順番がある。例えば「A地点から進みボスを倒したらB地点に行けるようになる」といったような攻略の流れである。

 しかし、本作では自由度の高い破壊と地形の変更ができる。そのため、先の例で言えば「ボスを無視してA地点からB地点まで無理やり移動する」(順番を無視することをシーケンスブレイカーと呼んでいた)といったこともできる。

 濱崎氏によればこういった問題が起こった際に大切にしていたのが「順番を無視してもゲームが破綻しないようにすることだ」とのこと。この“破綻”には単にクリアできるといった意味合いだけでなく、順番を無視した後のセリフの変更や収集アイテムの取得など本筋とはまた異なる面でもプレイヤーが違和感を感じないようにすることも含まれているようだ。

最適化・デバッグは人海戦術と自動化で徹底的に!

 その後に語られたのは、最適化とデバッグについて。

 最適化について栗原氏は「本作は息を吸うように破壊できるのが魅力だが、破壊をすると大きな負荷がかかる。そのため、破壊の自由度を落とすのではなく、通常時の負荷を下げて破壊を繰り返しても処理堕ちしないように調整していた」としている。そのために、ステージ毎にチームを作り、プログラマー以外のアーティストやレベルデザイナーも全員で最適化を行なったという。

 最適化の際には進捗を確認しやすくするために毎日自動で更新される最適化を視覚的に確認できる機能や、ニュース担当者を用意し日々手動で他チームの状況も含め周知することだったそうだ。そのおかげでモチベーションに繋がったり互いの状況を確認できて良い方向に進んだそうだ。

 また、デバッグについては濱崎氏よりデバッグに向けて行なわれた「テスターも開発者になってともに作る体制」と「自動化などの仕組み」が紹介された。体制については、任天堂の子会社であるマリオクラブ(京都)からの出向扱いでテスターを初期段階から開発チームの一員として迎えていたそうだ。

 テスターを初期から開発チームに迎えることの利点として濱崎氏は、開発情報の共有、開発者ミーティングへの参加、レベルエディタを使用した仕様確認など「ゲームをより詳しく知ったうえで検証してもらえること」を挙げていた。

 テスターがゲームの仕様や設計思想を詳しく理解できているおかげもあり、日々のテストプレイでは「問題が起こりそうな操作」「破綻が起きそうな箇所」などを予測しながら確認してもらえたという。

 また、自動化などの仕組みについては、ゲーム内で直接ボクセル(地形など)を操作・復元する機能だけでなく、ボクセル表面のマテリアルを変更できるデバッグ機能に加え、スクリプトなどを用いてゲームを最初から最後まで要所要所の本筋以外の部分も検証しながら自動でプレイする自動テスト機能なども用意していたそうだ。

 なお、デバッグ機能の一部は「DKアーティスト」でも活かされているとのことだ。

開発初期からのデバッグで様々なバグを検知! タイムアタック的な遊びの検証もできた

 前述したデバッグの仕組みのおかげで、バグを多数検出することができたほか、本作ではテスターによる開発が想定していない高度な操作や組み合わせを使った検証もできたという。

 おかげで、面白いバグやタイムアタック的に一部ギミックを力技でスキップするなど、ゲームをより面白くする時間に充てられたそうだ。例としてはレースを丸々スキップして次のマップへ行く様子などが明かされた。なお、このスキップも発見時はバグだったが、実装する際にはしっかりとその後のセリフ差分も追加したという。

マイナスを減らすだけでなくプラスを活かし伸ばすQA

 最後にまとめとして、QAの軸である「体験ファースト」と早期からのデバッグによる利点という本セッションの総括が行なわれた。

 両氏は内容を振り返り、「マイナスを減らすだけでなくプラスを活かし伸ばすQA」と紹介していた。