ビデオゲームとフィットネスを複合し、『リングフィット アドベンチャー』。本作の大きな特徴のひとつは、ニンテンドースイッチのコントローラーを組み合わせて使う「リングコン」でしょう。
リングコンは「ハード班」、「ゲーム班」、「システム班」の3つの班による協業開発でした。ですが各班で専門分野が違うため、開発サイクルが異なっており、スムーズな開発をするうえで当初はいくつか問題があったそうです。
では、そんな問題をどのように解決したのか？ CEDEC 2020にて、「『リングフィット アドベンチャー』のハード・ソフト一体型開発～開発サイクルの違いを乗り越える～」のセッションでは、任天堂のプログラマーである和田真樹氏と成瀬文覚氏、そしてハードウェアエンジニアの田邨嘉隆氏が登壇。開発の背景についてが語られました。
新しいコンセプトのコントローラーは3班に分かれて行われた
さてリングコンは、力で操作するコントローラ―という大きな特徴を持っています。コントローラーには新規開発した繊維強化プラスチックが使用されています。この素材は加えた力に応じて反発する性質を持ち、しっかりとした運動の付加によって筋肉をつけられるようにしていました。
さらに押し込んだり、引っ張ったりする力を感知する「チカラセンサー」を実装しています。センサーはかつての『Wii Fit』と同種のものを使用しており、リングコンにも過去の技術が生かされた形となっています。
リングコンの開発には3つの要素が絡み合っていました。ひとつは、コントローラーそのものを構築する「ハードウェア」。物理的な要素です。続いてリングコンを動かす「システム」の開発と、最後にリングコンを使った「ゲーム」の開発です。
この3つのどれひとつが欠けても、お客さんに届かないと説明。そこで3つの要素を競業したのが「ハードソフト一体開発」というスタイルでした。
まずはそれぞれの要素ごとに班を分けていきます。リングコンそのものを開発する「ハード班」、そしてハードウェアをゲームから作る「システム班」、最後にゲームを設計する「ゲーム班」が、各々の役割を追求していく形となりました。
まずハード班の目的はリングコンそのものを作ることです。機構設計に加え、回路設計とプロダクトデザインを行い、コントローラーを開発していきます。
コントローラーを開発するタイムラインは、大きく分けて3つのフェーズによって行われました。
まずは「原理試作」のフェーズです。ここで必要な機能や性能などを見極めていきます。本格的に『リングフィット アドベンチャー』の作成が決まると、続いて「開発試作」のフェーズへと移行します。ここからはスタッフも増え、製品の機能やデザインが、設計どおりに実現可能か確認していきます。
最後に、商品として大量生産が妥当かどうか確認する「量産試作」のフェーズです。ここからはコントローラーの量産準備に入るため、協力会社も関わっていきます。各フェーズで早期の検証を行い、手戻りがないように進めていきました。
システム班の目的は、ハードウェアをゲームから動かす仕組みを作ることです。ここでは、リングコンに実装されているファームウェア、そしてJoy-Con、ニンテンドースイッチの本体システムそれぞれで機能する独自OSであるNintendo SDK（以下、SDK）を中心にしています。
SDKは数百人規模で作られている独自OSであり、要求元によってリクエストを受け、SDKの開発者に両テストを行い、その後利用者に渡されます。
システム班主にSDKをリリースするタイミングで開発サイクルが周るかたちを取っています。システム班は開発を通して、「いかに簡単にゲーム開発に専念してもらうか」を目的としているといいます。
ここまでの「リングコンを作る」役割はハード班、システム班が担当していました。リングコンを使ったゲームを本格的に開発していくのがゲーム班となります。
ゲーム班はユーザー体験としてリングコンを評価していきます。評価の基準は、実際にユーザーの体験としてコントローラーが十分か、そして実際のゲームプレイを通して機能しているかです。その評価を後でハード班、システム班へと返していくのです。
ゲーム班の開発タイムラインは、他の班と比べると非常に細かいです。1サイクルで仕様検討と実装、そしてモニタープレイと改善点検討を繰り返していき、これはゲームの仕様が固まるまで続けられます。
このように、各班で開発サイクルの期間がまったく異なっており、1サイクルが終わるタイミングがそれぞれの班でズレてしまっています。そのため、各班で連携が取りにくい問題が生まれており、スムーズな開発が難しくなっていました。
リングコン開発では、まず「どう魅力的になるか」をゲーム班が考えていきます。フィットネスがテーマのゲームですが、お客様のニーズに幅があるため、ゲームに実装するフィットネスををたくさん提供する必要があったそうです。
なのでゲーム班が、リングコンを使ったフィットネスを高速に増やすことが必要になるのです。ここで他の班と連携しづらい問題に足を取られてしまします。先述した各班のタイムライン比較を見ても分かるように、ゲーム班がハード班にリングコンへの評価をしても、ハード班からのレスポンスにラグがあるのです。
このように3班の開発サイクルでラグがあるせいで、実装まで煩雑な流れとなってしまっており、この問題を解決するためにそれぞれの違いを乗り越える必要がありました。
各班の連携が困難な問題をいかに乗り越えていったか
続いて、具体的な開発事例を通して3班の連携をどのように取っていったかの事例が紹介されます。
まずハード班から「コントローラーの耐久性と課題」について説明。安全かつ安心な製品を考えるうえで、はじめのころはコントローラーの使い方も未知数だったといいます。
しかしゲーム班は、どんどん使い方を増やしていきたいと思っており、ハード班と足並みがそぐわないと開発の進捗が悪くなってしまうため、ハード班は「新しい評価方法が必要になる」と判断していました。
そこでハード班はリングコンの評価方法として、「リングコンの耐久値が、プレイヤーの使い方による要求値を越えた状態」の数値化を考案。言い換えれば「リングコンのHPが、プレイヤーの使用によるダメージに耐えられるようにすること」を目指したのです。
ではどのように耐久値の数値化が行われたのでしょうか。まずハード班はリングコンのHPを、「全力での押し引きに耐えられる回数」と定義します。しかし実際のゲームでは、いろんな使い方によって差が出てきます。これを回数と、押し込み量によって評価し、モニタープレイによって集めたプレイログから分析したといいます。
評価方法を決めたハード班は、ゲーム班にモニタープレイのデータ提供をお願いしたところ、「モニタープレイだけではなく、常に全開発者から自動収集します」と大きく協力することを宣言します。
本格的にゲーム班とハード班は連携し、続いてコントローラーの使い方によるダメージの数値化に取り組みます。
実例として「大胸筋チャレンジ」の例をあげ、ダメージをいかに数値化するかを説明。まずチカラセンサーの値をプレイログとして取得し、押し込み量ごとのダメージの割り出しを行います。次に、回数×ダメージを押し込み量ごとに計算し、ダメージ量を割り出します。
このようにコントローラーの耐久値＝HPが、要求値＝ダメージに耐えられるかどうかこれをフェイズごとに確認していきます。こうしてゲーム班はハード班の課題に共に取り組んでいきました。
しかしまだ課題があります。システム機能の追加でした。システム班が最も優先していることは、ゲーム班がゲーム作りに集中してもらうことです。
そこで目標としたことは、容易であること、機能の集約、堅牢性を持ったシステムの構築です。先述したように、システム班がリングコンのファームウェアやと本体システムなどを実装し、SDKのリリースを待ってから、ゲーム班へと提供するプロセスとなっています。
通常のタイトルであれば、そのプロセスでよかったのですが、今回はリングコンを使ったタイトルです。ゲーム班が開発する高速サイクルに対応するために、すぐにシステムをゲーム班へ渡すことを考え、今回はSDKに依存せずに、すぐに提供することを考えました。
たとえばファームウェアの更新の際、新しいファームウェアをどうゲーム班へ届けるかが課題でした。
最初に思いついたのは、スイッチ上で動くツールからアップデートさせることでした。この方法では、確かにSDKをスキップして直接ゲーム班に渡す事はできました。
しかしツールを渡しただけでは運用ができず、フォームウェアの更新について質問が来たり、昔のROMのほうを使いたい意見が来たり、むしろ開発チームの負担が増える結果になってしまいました。
システム班だけでこの問題の対処に限界を感じ、ゲーム班に相談します。そこでゲーム班はあっさりと「デバッグメニュー」にあったら便利と回答してくれました。先に書いたようにシステム班の目的は「ゲーム班が開発に集中してもらうこと」。なのでゲーム班に気を使ってしまい、相談にいけなかったことで、逆に遠回りしてしまっていたようです。
解決策は、ゲームののデバッグメニューに更新用ライブラリと、リングコンファームウェアを入れることで、導入コストやバージョン管理が楽にしました。
続いて本体システムのソフトウェアをどう提供するかでした。本体システムの役割は、様々な機能を集約し、使いやすい形にすることです。
しかし今回のリングコン開発では、さまざまな班から「調整機能が欲しい」とか「この機能を使わなくなりました」といった意見を受け、適切な処理が変わり続ける問題がありました。
本体システムもSDKの提供サイクルでリリースされるため、即座の提供ができません。そんな本体システムをどうするかというと「システムを土管にする」ことでした。
土管にするというのは、つまり入力されたデータを一切触らずにそのまま届けるということです。今回はリングコンファームウェアによる、チカラセンサーの値を使いやすい値に変換し、リングコンライブラリへと伝達する仕組みです。
ゲームへの伝達も、リングコンに取り付けるJoy-Conとの通信に特化することで、本体システムを通さずにライブラリに送ることに成功しました。
システムの即提供を目指した結果、機能の集約や汎用性を捨ててでも、本体システムとリングフィットの依存の切り離しを行い、すぐにゲーム班へ伝達することを選択したとのことです。
最後にリングコンライブラリをいかに即提供したか解説されます。SDKにおけるライブラリとは、switchOSの機能を、ゲームから使うための口となるソフトウェアです。使い方と呼び出し方をまとめたヘッダーファイルと、ゲームに組み込むバイナリファイルのふたつからなっています。
このライブラリを即提供するために取った施策は、ソースコードをそのまま提供し、ゲーム側でビルドしてもらうことでした。この方式により、ライブラリを修正したいときゲーム側が行えるようにしたのです。
もともとのライブラリの方針は、さまざまな理由によりゲーム班は内部を理解しなくてもよいものでした。ですが今回は、ゲーム班も内部を理解する必要に切り替えました。
ゲームに合ったライブラリ自体を即提供するために、ここでハード班とも協働。3班が協力する体制となります。
ゲーム班がリングコンを使ったゲームを他の班に提案したとき、システム面やハード面から可能かどうかを確認していく流れとなりました。
こうした連携によって、ゲームが発想されるプロセスにも変化があります。たとえばシステム班側が「ゲーム班の仕様を変えるとこんなこともできるようになる」とレスポンスしたり、ハード班側が「この使い方であればまだ余裕があるので、もっとこう使ってみませんか？」と提案したりします。こうした3班の協働によって、新機能を即提供でき、ゲームの実装を待たせない体制を作ったのです。
まとめとして、「未知数のリングコン開発に取り組むために、これまでの意識を変えた」ことで他の班と連携できるようになったとのこと。当初、連携しやすいように方法を変えていく過程で、3班がお互いの領域に踏み込みあい、協力しての制作へと変化していったのです。
3班で協力してリングコンの完成へ！
3班の協働体制がまとまったことにより、ゲーム班は高速にフィットネスを追加していくことが可能になりました。結果的に60種類以上フィットネスを実装することができ、お客さんの広いニーズに答えられるようになったのです。
とても困難な課題を乗り越え、チームは「やるべきことはやった……」と感慨深くなります。ですがここでもうひとつ考えたことがありました。「追い込みが足りない」。
ゲームを魅力的にするために、さらにできることはなにか？ 最後に3班が協働し、さらなる追い込みで生まれたゲームモードについて紹介します。
そこで生まれたのは「ながらモード」です。これはゲーム本体を起動せずとも、Joy-Conとリングコンのみで動くシステムです。名前のとおり、リングコンで運動をしながらテレビをみたり、他のことをしたりするためのモードで、この時に行った運動によってゲーム本編にボーナスがつくという仕組みです。
『リングフィット アドベンチャー』ならではの、ゲームを起動していなくても運動をしたくなるモードでしたが、「最後の追い込み」と言うとおりとてもタイトなスケジュールでの開発となったそうです。
まず本モードはJoy-Con、リングコンのみで動くモードです。なのでシステム班がファームウェアを更新する必要がありました。
ですがこのモードはシステム班だけで開発できるものは限界がありました。最後の追い込みの時期で、どの班も大変でしたが、ハード班・ゲーム班ともに協力を受け入れます。
ながらモードの課題は3班で高速にサイクルを回せるかにあり、各班がお互いの領域に踏み込んで開発されていったといいます。
まず本モードの機能をJoy-Conのファームウェアか、リングコンのファームウェアどちらに置くかを考えました。両者の比較によって、どちらにもメリットにもメリットがあることが分かりましたが、検討の結果リングコンに置くことに決めます。
リングコンに決めた大きな理由は、3班で協力するために「本体からの依存をきり、独立を上げる」ためだといいます。リングコンにはハード、システム、ゲームそれぞれが密接に関わっているため、とりわけ連携を取るのに重要だったのでしょう。
こうして3班の連携サイクルが完成。ゲーム班が触り心地を検討し、システム版が最適化し、ハード版が耐久性の評価を行っていきます。このサイクルで役になったのは、ながらモードの上限回数を500回に決めることでした。
ながらモードの課題は、上限回数が少なすぎるとモードの意味がなくなるため駄目なので、あまりに多すぎるとボーナスに届かないことです。
そこでゲーム班が手応えと楽しさ検討し、ハード班が行動を推測して評価。そしてシステムが調整する形で上限回数が決まっていったそうです。まとめとして、実装の難しさより本体との依存を切ることを優先したことで、こうした開発スタイルが可能になったとのことでした。
このようにリングコンの開発では、通常のタイトルと開発サイクルが異なっているために、普段の開発とはまったく違うかたちになりました。でもそこで違う班同士であっても、お互いの領域に踏み込むことを恐れないことで、チームを強くできたのではないか、と語ります。本セッションは「チームをより強くするきっかけ、ヒントになるのではないか」と締めくくられました。
※UPDATE（2020/10/02 15:43）：本文中の誤字を修正しました。
