［CEDEC 2020］ 「リングフィット アドベンチャー」のハード・ソフト一体型開発が語られたセッションをレポート。3班が互いの領域に踏み込む

　ゲーム開発者向けカンファレンス「CEDEC 2020」の最終日，2020年9月4日に「『リングフィット アドベンチャー』のハード・ソフト一体型開発〜開発サイクルの違いを乗り越える〜」と題されたセッションが行われた。


　リングコンという前代未聞のコントローラを採用し，今までにないゲームとして大ヒットした「リングフィット アドベンチャー」。このセッションでは任天堂の田邨嘉隆氏，和田真樹氏，成瀬文覚氏の3人が，開発の模様を語った。開発サイクルの異なる「ハード班」「システム班」「ゲーム班」が互いの領域に踏み込む意識改革があったことが明かされた，その模様をレポートしよう。


　「リングフィット アドベンチャー」について，もはや詳しい説明は必要ないだろう。押し引きの力を認識する輪っか型のコントローラ「リングコン」を使う運動と，ファンタジー世界で冒険するRPGが両立しているソフトである。リングコンには，繊維強化プラスチックによるバネが使われており，しっかりとした負荷がある運動を楽しめるのだ。


　これまでになかったコントローラを使うゲームを作るので，田邨氏の「ハード班」，成瀬氏の「システム班」，和田氏の「ゲーム班」という3班の協力が不可欠となる。ハード班は材料や組み立て方法を検討して物理的なモノとしてのリングコンを開発。システム班はSDKやリングコンのファームウェアなど，リングコンを動かす仕組みを作る。そして，ゲーム班はリングコンを使ったユーザー体験（遊び）を開発するわけだ。

　とはいえ，3班の仕事はそれぞれサイクルが異なっている。そのまま進めていけば待ち時間が多く発生し，時間をロスしてしまう。これでは，「限られた時間で，できるだけ多くのフィットネス（ミニゲーム）を高速で開発する」という目標の達成は難しい。こうした中で，3班が行った意識改革について語るというのが，本セッションの主旨だ。

障害となった，開発サイクルの違い

　ハード班はリングコンの機構や回路を設計し，プロダクトデザインを行う。必要な機能や実現手段などを見極める「原理試作」，設計通りに実現できるかを確認し改善を行う「開発試作」，そして品物を量産する準備を行い，仕様が適切であるかを確認する「量産試作」の3サイクルで仕事は進んでいく。後になるほど関わる人数も多くなり，責任も大きくなっていく。ユーザーの安全が関係するだけに，1つのサイクルは比較的長い。


　そしてシステム班は，リングコンをゲームで扱えるよう，Nintendo SDKを開発する。Nintendo SDKには，「リングコンのファームウェア」，Joy-ConのファームウェアやNintendo SwitchのSwitch OSといった「本体システム」，「リングコン用ライブラリ」が含まれるのだ。
　まずはリングコンにかかった力をファームウェアが取得し，セットされたJoy-Conへ生データとして渡す。生データは複雑な数値の羅列なので，Switch OSがゲームで扱えるゲーム用データ（ここでは速度やリングコンの位置を示す座標）へ変換。このゲーム用データをライブラリが取りだし，ゲームへ渡す……というプロセスが必要になる。
　とはいえ，Nintendo SDKはリングコン開発のためだけのものではない。さまざまなゲームやサービスから要求されて修正や改良，新機能追加を行い，ある程度の数をまとめたうえでリリースされる。3班の中では中程度のサイクルで動いているといえるだろう。


　ゲーム班は，約1か月で仕様検討→実装→モニタープレイ→改善点検討という1サイクルを回し，ゲームを開発していく。1サイクルは3班の中で最も短く，沢山のフィットネスを高速で開発するのがミッションとなる。


　つまり，3班の仕事サイクルは長さと終了タイミングがバラバラであり，普通に仕事を進めたのではゲーム班に待ち時間ができてしまうのが問題であるわけだ。

ハード班とゲーム班の協力でリングコンの耐久力を可視化

　田邨氏は，ハード班とゲーム班が共同で行った耐久性評価の効率化について語った。
　リングコンはこれまでにないコントローラであり，安全のためにも高い耐久性が求められる。ゲーム班が提唱したフィットネスも，耐久性評価を経てからの実装となるため，リングコンに特化した新しい評価サイクルによる効率化が求められたのだ。


　そこで，ハード班とゲーム班が考案したのが，リングコンの耐久性を，RPGなどで使われる「HP（ヒットポイント）」と捉えた数値化である。リングコンを自動で押し引きする試験機を作成。全力の押し引きにリングコンが耐えられる回数，即ちリングコンのHPを割り出した。HPの数値化により，リングコンを改良した際の効果も分かりやすくなったのだ。


　こうした考え方を応用したのが，20秒間にリングコンを押した回数を競うミニゲーム「大胸筋チャレンジ」の実装時に行われた，ダメージの数値化である。ここでいうダメージは，ユーザーがリングコンを押し引きすることで，リングコンに与えるダメージのこと。ダメージはリングコンのHPを減らしていき，ゼロになると壊れたことになる。
　まずはゲーム班が新しいミニゲームの実装を希望し，これを受けたハード班がリングコンに与えるダメージを測定。HPへの影響が少なければ無事に実装されることになる。


　ミニゲームがリングコンに与えるダメージを測定するには，いきなり試験機を使うのではなく，ユーザーのプレイログが必要だ。押し込む力はユーザーの筋力によってまちまちだし，同じユーザーでも疲れてくると力が弱まってくるからだ。
　そしてハード班は，ログの分析を行った。リングコンを押し込んだ量を10〜100%の10段階で評価（押し込んで両手がくっついた状態を「押し込み量」100%と）。それぞれの押し込み量で何回押し込まれているかの集計を取った。
　そして，先の試験機を用い，“押し込み量100%なら何回の押し引きに耐えられるか”を基準に，90%なら何回，80%なら何回……というように測定を行い，押し込み量ごとにリングコンのHPに与えるダメージを数値にする定量化を行った。
　これをログに記録された段階毎の押し込み回数と組み合わせて，1回プレイした際のダメージを算出。ダメージが小さかったことからリングコンに与える影響も少ないと判断され，「大胸筋チャレンジ」は無事に実装されることとなった。


　また，ゲーム班が「負荷を上げてもっとキツい設定にしたい」と要望した際もこの考え方が用いられた。開発者全員のログを収集し，ハード班がこれを分析してゲームクリアまでの総ダメージを計算。リングコンが充分な余裕を持って耐えられると分かったことから，ゲーム班の望む調整が実装されている。

　相手の班が抱える課題を自分の班の課題と捉え，お互いの領域に踏み込み合うことで問題が解決できた，と田邨氏は今回の取り組みを総括した。

高速開発のため，これまでのポリシーを捨てる

　フィットネスを高速で開発するためのもう一つの課題は，SDKが即座にリリースされないこと。前述した通り，SDKは複数の修正や改良，新機能をまとめてリリースするのが通例である。せっかくの新機能も使えるのはSDKがリリースされた後のことであり，ここでもタイムラグが発生するからだ。
　ゲーム班がゲーム開発に集中できるよう，「機能を簡単に使えるよう，分かりやすく作ること（容易）」「色々なゲームで同じ処理を組み込む必要がないよう，共通化できる処理はシステム側へ集約すること（機能の集約）」「統合テストを行い，様々な使い方で問題なく動くようにすること（堅牢性）」を大切にしてきたものの，このサイクルに固執していたのでは，開発サイクルの違いを乗り越えることはできなかった……と成瀬氏は語る。
　そこで氏は，必要となるリングコンのファームウェア，本体システム，リングコン用ライブラリをSDKに含めることはせず，直接ゲーム班へと提供することとしたが，そこにはいくつかの課題が存在していた。


　まずはリングコンのファームウェア更新である。本体システムからのアップデートを考えたものの，SDKのリリースサイクルに依存するため没に。次はSwitch上で動くツールを用意したが，バージョン管理がややこしくなった上，ゲーム班からはアップデートに関する質問が寄せられることとなり，こちらも没となった。
　こうした試行錯誤の時期について成瀬氏は「いかにゲーム班の手を煩わせることないように進められるか……と気を遣っていたが，開発全体における最適解ではなかった」と語る。解決のきっかけとなったのは，ゲーム班にこの悩みを相談したことだった。ゲーム班からは，「デバッグメニューに更新ツールがあれば便利である」という意見が出され，即座に提供できる環境が整ったのだ。


　残るは本体システムとリングコン用ライブラリだ。前述の通り，本体システムは，リングコンのファームウェアから得られた入力データに「適切な処理」を行い，使いやすい値にするものだ。しかし，開発の過程ではこの「適切な処理」が移り変わっていくため，即座に提供するわけにもいかない。ここで成瀬氏は考え方を変え，本体システムを「土管化」した。入力データの処理はリングコン用ライブラリに任せて，本体システム側ではなにも触らないようにしたのだ。これで本体システムはJoy-Conとの接続や通信処理のみを行うこととなり，ゲームにはまったく影響を及ぼさなくなった。ゲーム班の意見に左右される部分を本体システムから分離し，リングコン用ライブラリに集約したと言ってもいいだろう。これで本体システムの即時提供が可能になったのである。



　そして，リングコン用ライブラリはソースコードの形でゲーム班に提供し，システム班以外でも修正できるようにした。つまり，3班がお互いの領域に踏み込みつつ，共同で開発できるようにしたわけだ。ゲーム班が開発に集中できるようにするのではなく，「リングフィット アドベンチャー」チームの一員として3班で完成を目指していくという意識へ変更していったのだ。


　こうして進められていった開発だが，スケジュールギリギリのところでリングコンだけでトレーニングする「ながらモード」を実装することとなった。3班が共同で開発を進める中，リングコンのファームウェアとJoy-Conのファームウェア，どちらに機能を追加するかを決めることに。前者は残り空き容量が数KBという少なさだったが「リングフィット アドベンチャー」でしか使わないハードであるため，影響は3班のみに留まり，自由度は高い。一方，後者は空き容量が大きいものの，Joy-Con自体は他のゲームでも使うため，機能を追加した際の影響も大きい。


　結局，3班が協力して高速で開発サイクルを回すためには「リングフィット アドベンチャー」だけで完結できる体制を整える必要があるということでリングコンへの追加が決定。1バイトを削る作業の末，無事に「ながらモード」が実装されたという。

　通常，ゲームに何か機能を追加したり変更を加えるのであれば，ソフトウェアをいじるだけで済む。しかし，「リングフィット アドベンチャー」の場合は，これまでになかったリングコンがあるため，耐久性評価とファームウェアやライブラリ開発も必須となる。特に耐久性評価については，新機能を追加する度に行わなければならないのだから，通常のゲームでは考えられないほどの労力がかかっているといえるだろう。新しいハードウェアやゲーム体験を送り出すためには，苦労するだけでなく，意識改革も必要だったと言うことで，興味深い講演であると感じられた。

「リングフィット アドベンチャー」公式サイト

「CEDEC 2020」記事一覧