ニュース
「リングフィット アドベンチャー」に多数のフィットネスが実装された舞台裏
バラバラの3チームはいかにして高速化を果たしたか？
2020年9月5日 19:27
- 【CEDEC 2020】
- 9月2日～9月4日 開催
2019年11月に発売されたNintendo Switch用「リングフィットアドベンチャー」は、全く新しい専用コントローラー「リングコン」と、これまでのフィットネス系タイトルよりかなり強度の高い”ガチ”な仕様を引っさげて登場したフィットネスゲームだ。運動不足に悩まされがちなこのご時世、「ゲームで楽しく運動ができるなら」とゲーマー内外で話題を呼び、発売から時間が経った今でも品薄が続く人気商品となっている。
「リングフィット アドベンチャー」には多彩なトレーニングと遊びが盛り込まれており、その全てを「リングコン」で操作する。これは製品を手に取るユーザーとして見ればある意味当たり前だが、一方で”山盛りのコンテンツ全てを新しいコントローラーで上手く動かせるようにする”というのは、容易なことではなかったはずだ。
CEDEC2020のセッション「『リングフィット アドベンチャー』のハード・ソフト一体型開発～開発サイクルの違いを乗り越える」では、任天堂の企画制作部プログラマー 和田真樹氏、 ハードウェア開発部ハードウェアエンジニア 田邨嘉隆氏、そしてシステムソフト開発部プログラマー 成瀬文覚氏の3名により、いかにして製品としての「リングフィット アドベンチャー」、つまりゲーム本編と「リングコン」を作り上げていったかが語られた。
高速で開発サイクルを回したい！でも3班のサイクルはバラバラ
そもそもリングコンは繊維強化プラスチック（FRP）でできたリング状のバネと、押し込んだり引っ張ったりするチカラを検知する「チカラセンサー」からなるコントローラーだ。反発力のあるバネが筋肉に負荷を与え、チカラセンサーがその動きを検知してゲーム側に入力する。そしてゲーム側ではこの入力（＝トレーニング）を受けて、ゲーム的な面白さや体験を提供する。こうしたハードとゲームを同時開発することを任天堂では「ハード・ソフト一体型開発」と読んでおり、「リングフィット アドベンチャー」は物理的なモノを開発する「ハード班」、リングコンを動かす仕組みを開発する「システム班」、リングコンを使った「ゲーム班」の協力によって作り上げられていった。
「リングフィット アドベンチャー」の制作にあたり、問題になったのはハード、システム、ゲーム各班の開発タイムラインの違いだ。
ハード班はまず試作を繰り返しながら必要な機能やその実現手段、性能などを洗い出し（原理試作）、製品の機能がデザインが設計通りに実現できるかどうかを確認し（開発施策）、量産を行なう上で設計仕様が妥当かを確認（量産試作）する。さらに開発施策及び量産試作のフェーズではそれぞれ「設計」、「試作」、「評価」、「改善」という段階を踏んで、性能や耐久性に問題がないかどうかを慎重に確認しながら製品化に向けて進んでいく。
一方でシステム班はNintendo Switch向けに「Nintendo SDK（Soft Development Kit）」を開発するチーム。Nintendo SDKはゲーム開発に必要なツールやデータがパッケージングされたもので、中でもリングコンに内蔵されたマイコンに書き込まれた「リングコンファームウェア」、「本体システム」、「リングコンライブラリ」が「リングフィット アドベンチャー」における開発のキモとなった。
ゲームを作るための土台となる仕組みを作るシステム班は「いかにかんたんにゲーム開発に専念してもらえるか」を念頭に仕事にあたっており、そのサイクルは「リングフィットアドベンチャー」を含む様々な要求元からの「こういう機能が欲しい！」といったリクエストに応えて開発を行ない、それぞれの開発内容や修正、アップデートなどが1つのパッケージとして干渉や不具合なく動作するかの「統合テスト」を実施の上、利用者の元へと届けるというもの。つまり、ここでポイントとなるのは「各要素が統合されたSDKという単位で開発が進行していく」ということだ。
最後にゲーム班は、ハード班とシステム班が作ったリングコン本体と仕組みを使ってゲーム本体を制作していくチーム。さらにユーザーとしてリングコンを試すことで、システム、ハード班に実際に使用した上でフィードバックを戻す役割も担っている。ゲーム班は約1カ月単位でマイルストーンを設定しており、高速で検証を繰り返しつつ、仕上げ、最後にデバッグを行なってリリースを迎えるタイムラインだ。
さて、ユーザーが「リングフィットアドベンチャー」に求めるニーズは「お腹周りが気になる」、「運動不足を解消したい」など幅があり、そのニーズに応えるためには沢山のフィットネスを提供する必要がある。つまり開発側はフィットネスを高速に増やしていく方法が必要になるわけだが、各班のタイムラインを並べてみると、開発の1サイクルの長さも回るタイミングも全く異なることがわかる。図をひと目見ただけでなんだか嫌な予感がするほどに、各班の動きにはズレがある。
実際にゲーム班の高速サイクルをベースに試算してみると、まずゲーム班が新たなフィットネスを開発し、それににリングコンが耐えられるかどうかの検証をハード班に依頼する。しかしハード班の評価タイミングはサイクルの後半なので、暫し待ってやっと結果が返ってくる。この結果を待っていざ実装……と思いきやここで問題が発生！リングコンの機能不足でやりたいことができないことがわかったとしよう。すると今度はシステム版に新機能の開発を依頼。SDKのリリースまで機能追加を待ち、ようやく実装を迎えることになる。
1つのフィットネスの実装にこれだけ時間をかけていては、フィットネスを増やし続けることなどとても不可能だ。だからこそ、なんとしてでも開発サイクルの違いを乗り越え、必要な時間を圧縮する必要がある！
耐久値と要求値をHPとダメージに変換！新たな検証法で開発の高速化に成功
最も開発1サイクルが長いのはハード班だ。ただしもちろん無駄に長い時間を取っているわけではなく、ユーザーに安全・安心な製品を届けるために念入りな検証時間が必要で、しかも新しいコントローラーであるだけに、どう使われるかも未知数。使い方も考慮して判断していく必要がある。
では開発高速化のためにどうするか。これは耐久性に関わる2つの要素を数値化することで解決の糸口がつかめた。リングコンの耐久値を「HP」、使い方による要求値を「ダメージ」として、HPがダメージを上回ればOKとすることにしたのだ。
まずHPは「全力押し引きに耐えられる回数」と定義。手動で検証するのは大変なので、自動で押し引きを繰り返す検証機を複数台制作し、リングコンのHP測定を行なった。ちなみにこの数値化はハード班にとっても「試作製品のHPを比較検証するのにも役立った」とのこと。
続いて回数と押し込み量からダメージを数値化することにした。このためにはプレイログが必要で、ハード班はゲーム班にモニタープレイ時のデータを要求。ところがゲーム班からはモニタープレイに限らず、全開発者のデータを自動収集してくれるという素敵な返事があったのだ。課題解決のため、各班が協調し始めた瞬間だ。
さて、胸の前でリングコンを押しつぶして開く動作を繰り返す「大胸筋チャレンジ」を例に、全力で押した状態を100％と定義した上で、一回のプレイで何％の押し込みが何回あったかをカウントするとダメージ量が見えてくる。これをより定量化するため、リングコンのHP（＝全力押し引きを繰り返して壊れるまでの回数）をベースに100%、90%、80%……と、各押し込み量時のダメージに数値を設定。回数×ダメージを計算してみると、「大胸筋チャレンジ」1回のプレイがリングコンにダメージは23.63であることが判明した。100回プレイしても2,363のダメージということで、リングコンのHP総量からすると全く問題ない。ハード班は「HPに与える影響は小さいので大丈夫」という判断を下すことができた
続いての課題は「ゲームパラメータの調整」。例えばゲーム班が「運動負荷をもっと上げたい」という要望を出した場合、運動負荷の増加はそのままリングコンへの負加増を意味する。そのため、実装可否を判断するためにはゲーム内に存在する全ての要素で検証を行ない、耐久性のチェックを行なう必要がある。手動ではとても不可能な検証だが、ハード班は運動能力や好みの運動が異なる全開発者のプレイログを統計分析し、ゲームをクリアするまでの総ダメージを算出。リングコンの改良によりHPが大幅に増えていたこともあり、全編クリア分のダメージを差し引いてもまだまだ余裕があることが判明した。つまり、運動負荷の増加に対応できるこということがすぐにわかったのだ。
このように、ハード班の持つハード評価技術と、ゲーム班の持つロギング技術を融合して新たな検証方法を生み出し、検証の高速化に成功。サイクルの違いを乗り越えられたことで、次々とフィットネスが実装できるようになった……わけではなく、もうひとつ課題が残っている。そう、システム班によるSDKの開発サイクルである。
SDKリリース待ちを”土管化”で回避！システム版の高速化手法
システム班のSDKは、開発者が容易に使えて、共通処理はシステムに機能を集約、さらに統合テストを行なうことで、様々な環境で動作することを保証している。これらはシステム班が大事にしていることでもあり、特に統合テストはパッケージとしてのSDKがこれらの要素を満たしているかを確認する大事なプロセスだ。しかし逆に言えば、各ソフトウェアの開発が終わっていてもSDKとして統合テストを行なわない限り、開発者の手元に渡ることはないということだ。これに固執していてはサイクルの違いを乗り越えることはできない。開発の高速化のためには、3つのソフトウェアを即開発者に提供する必要がある。
まずは「リングコンファームウェア」。こちらは試行錯誤を経て、デバッグメニューに直接組み込んでしまうことにした。これにより、SDKパッケージから独立させることができたほか、導入コストは低く、ソフトウェアのバージョンにあったファームウェアを手軽に管理できるようになった。これは新しい手段を模索していたシステム班が「どうしたら手軽に使えるか」とゲーム班に聞いたことで生まれたアイデアだったが、実はシステム班、「ゲーム開発者の手をなるべく煩わせたくない」という思いから声をかけるのをためらってしまっていた。しかし、このひとつの成功により、ゲーム班に多少の負荷をかけてでも、開発チーム全体でベストな方法を模索すべきだということに気づけたのだという。
さて、続いては「本体システム」。本体システムは様々な機能を集約して使いやすい形にする、という役割を持ったソフトウェアだが、「リングフィットアドベンチャー」ではハードとソフトを同時開発していたこともあり、適切な処理は変わり続けていた。しかしSDKパッケージで提供するためには、仮に一部が出来ていたとしてもやはり即提供はできなかったのだ。
この解決方法は、システムを土管にすること。ユニークな表現だが、これは本体システムが本来担っていた「入力データをわかりやすい形で出力データに変換する」という役割を「リングコンライブラリ」に移してしまい、本体システムはJoy-Conとの接続・通信のみを担当する形にしてしまった。思い切った仕様変更ではあるが、これでシステム班が独立して作る部分と協力して作る部分を分離することができた。
最後に残った課題は「リングコンライブラリ」。本来ライブラリのソースコードはシステム班が完全に管理し、動作を保証するために隠蔽されるものだったが、これはゲーム班に直接ソースコードを提供し、ゲーム班側でビルドができるようにして問題を解決した。これが何を意味するかと言うと、ゲーム班もその内部を理解する必要が出てきた、ということだ。ここにハード班も加わることで、3班共同でライブラリを作るという流れができた。もはやこの段階では余計な遠慮もなく、互いに巻き込むことを躊躇しない体制ができあがっている。結果としてライブラリは3班で意見を出し合い、限界まで追い込んだものが完成した。
「まだ、追い込みが足りない」から作った「ながらモード」
こうして3班はサイクルの違いを乗り越えて、当初の目的だった高速化を成し遂げ、結果として60種類以上のフィットネスを用意してユーザーのニーズに応えることができた。しかしフィットネス開発者らしく彼らは思ってしまったのだ。「まだ、追い込みが足りない」と。
そうして生まれたのが「ながらモード」だ。これはソフト不要でJoy-Conとリングコンのみでトレーニングできるモードで、リングコンに押し引きの回数が記録され、回数に応じて次にゲームを起動したときにボーナスがもらえるというものだ。もちろん、最後のひと押しということでスケジュールはとてもタイトだった。
この開発に必要だったのはシステム班の管轄である「リングコンファームウェア」と「Joy-Conファームウェア」だが、システム班だけではユーザーの手応えを追求するのも、耐久性の検証も、そして納期的にも厳しかった。だからこそシステム班は即座にゲーム班、ハード班に助力を仰いだほか、システムを「リングコンファームウェア」と「Joy-Conファームウェア」のどちらに組み込むかという問題を、依存を切って独立性を上げられるほう、としてリングコンファームウェアに決定した。そうすることでスピーディな開発ができることをもう知っていたからだ。
「リングフィット アドベンチャー」は3班が互いの開発サイクルの違いを乗り越え、密に連携することで多数のフィットネスを実装し、ユーザーの獲得に成功した。和田氏は最後に「違う職種の人が自分の領域に踏み込んできた時、『担当外のことに口を出してきた！』と思ってしまうのはもったいない。それは皆さんのチームがより強くなるためのきっかけのサインではないかと思う」と語り、セッションを締めくくった。
