左：岡村憲明氏，右：山本俊介氏

　2017年5月9日，Unity主催の大型カンファレンス「Unite 2017 Tokyo」の2日めに，Nintendo Switch向けタイトルのUnity事例セッション「Unityを使ったNintendo Switch ローンチタイトル制作〜スーパーボンバーマンRの事例〜」と題する講演が行われた。

　Uniteの基調講演においては，UnityはNintendo Switchのローンチタイトルで実に5作品に採用されていることが発表された。その一つが「スーパーボンバーマンR」である。パブリッシャはコナミデジタルエンタテインメント，開発はヘキサドライブが担当している。本セッションはその開発とノウハウを振り返るものだ。
　まずコナミデジタルエンタテインメントの岡村憲明氏がタイトル概要を紹介し，技術面の解説はヘキサドライブの山本俊介氏が解説した。

　ヘキサドライブは大阪と東京に拠点を持つゲームデベロッパだ。受託で大型タイトルの開発を行うほか，任天堂の「ゼルダの伝説 風のタクト HD」やカプコンの「モンスターハンターポータブル 2nd G」iOS版など，過去作品のHD化にも優れた技術を持つ企業である。
　今回は注目のNintendo Switch講演だけあって，会場は超満員で立ち見も多く出る大盛況ぶりであった。

「スーパーボンバーマンR」で目指したこと

　「ボンバーマン」（爆弾男）はハドソンから生まれ，現在はコナミデジタルエンタテインメントがIPを継承している人気シリーズだ。Nintendo Switch版である「スーパーボンバーマンR」は，ファンからの支持が厚いSFC版を意識した新作となっている。ローンチタイトルかつワールドワイドでの発売で，11言語に対応したタイトルだ。
　また本作では，SFC版テイストの復活と共に，新要素として「高さ」の要素を加えた進化もテーマとなっている。この「高さ」のギミックの作り込みではPCでα版を作り，さまざまな試行錯誤があったそうだ。

　そうした中，Nintendo Switchのローンチ合わせで出すことは企画の当初から決まっていた。“スピード感のあるプロジェクトだ”ということを察知した山本氏は，スタッフの習熟度や開発期間から，Unityエンジンを採用することに決めたのだという。

PC上でのα版開発

　「スーパーボンバーマンR」のプロジェクトが始まった当初，Nintendo Switchのハードウェアスペックは不明で，どのくらいの絵が出せるかも分からない状態であったという。そこで，まずはPCでα版を開発しながら，全般的に負荷を抑える方向で対応を行った。

　今回のボンバーマンは破壊するブロックが3Dであり，大量のブロックが画面内に表示される仕様だ。Unityの担当者との会話で，そのすべてをGameObjectとして扱うと処理が重くなるだろう指摘され，このことは初めから問題点として意識していたという。そのためStandard.shaderをカスタマイズし，インスタンシングによる一括描画ができるような改善を行ったそうだ。

ボンバーマンのアートスタイル

　また，GC（ガベージコレクション）がなるべく走らないように，クラスのインスタンスを作る処理は対戦開始前に実行する仕様にした。ほかにも固定長の配列を使う，コレクション（IEnumeable）に対するforeachは使わない，などの対策が取られたという（筆者注：foreachが起因のメモリアロケートはUnity 5.5でコンパイラの更新により改善されている）。

　こうしたルールに対するコードレビューには，Phabricatorを利用したそうだ。

Nintendo Switch実機ビルドで起きたこと

　いよいよ開発機が届いたところでNintendo Switch用のビルドが実行された。当時のNintendo Switchビルドは，iOSビルドのようにUnityから一度ソリューションを書き出してビルドを行う方式だったそうだ。
　そこでいくつかの問題が露見する。まずはロード時間関連だ。初期のUnityバージョンでは，単純なUIを乗せただけのシーンを読み込むだけで10秒以上の読み込みが発生する不具合があったが，エンジン側が更新されることで自然解決された。

　そのほかのロード時間は，GameObjectのinstantiate処理が重いことが分かった。そこで，ゲームオブジェクトを必要になるより前に生成しておく手法を取り入れた。本作ではタイトル画面の時点から裏でinstantiate処理を実行しており，ボム，アイテム，キャラクターはCPUが空いている時間をうまく使って対戦が始まる前に生成しているのだそうだ。

　また開発中に，Asset Bundleに絡む問題が起きたという。Unityのシェーダ設定はEditorのプラットフォームに依存しており，Asset BundleはEditorに設定されたプラットフォームによってビルドする内容を決めている。Editorではプラットフォーム「Switch」の設定で開発をしているため，この状態ではNintendo Switch用のシェーダ設定でAsset Bundleを作成してしまう。つまり，Editor上でゲームを動作させるためのPC用Asset Bundleは別途作る必要があるということだ。これでは長いプラットフォーム切り替えの作業が入ってしまう。

　そこで，プラットフォーム切り替えすることなくPC用Asset Bundleが作成できるように，まずはコンバート専用のディレクトリを用意した。Unity Editorを二つ立ち上げ，片方はPCプラットフォームの設定で待機させておき，コンバート専用のツールとして利用するやり方だ。ビルド内容はシンボリックリンクを張ることで，二つのUnity Editor間で同期をとるようにしたそうだ。


　そのほかのプラットフォームに依存する処理については，ネイティブプラグインを作成することで実装された。プラグインの実装方法はiOSと同じように作ることができ，マーシャリングのノウハウや，C++とC#間のデータのやり取りはほぼ同じように作ることができたそうだ。ネイティブプラグインはSwitch本体に紐づけられたニックネームの取得やセーブ・ロード，入力周りなどのために用意された。


　また，ムービー再生やドックの抜き差し検出，システムフォントの利用などは，Unity側で対応が行われていたため，ネイティブでの開発は必要なかったとのことだ。

重い処理をどう削るか

　PCで開発していたα版をNintendo Switch実機にそのまま持っていってみたところ，デバッグビルドは6fps，リリースビルドでも12fpsという重さになってしまったのだそうだ。

　ここからさまざまな負荷軽減策が始まった。まずはCPU側の処理軽減として，NPCの制御処理を見直したほか，爆風エフェクトをあらかじめインスタンシングしておくことで負荷を低く抑えた。一番効いたのはデータの転送単位を調整することだったそうだが，こちらはUnityエンジンの更新によって改善が行われたそうだ。

　GPU関連では，まずUnityの設定でレンダリングパスをDeferredからForwardに変更したほか，Depth of Fieldを限定的な設定に変更するなどの措置を行ったとのこと。調整の結果，まずは30fpsでの動作にこぎつけたという。本作は本体同時ローンチを死守という使命があったため，バージョン1としてはまずはここで一区切りということで30fpsの仕様で固められた。

　オンライン対戦には，任天堂が開発したUnityプラグインを採用した。同期方法については，タイトル特性を鑑みて，ボタンの入力情報を同期する「入力同期」のシステムを採用。Unityを使って入力同期をするゲームを作るうえで注意すべき点は，RandomとDeltaTimeの扱いだ。UnityのRandomやシステムのRandomでは，タイミングを指定できないため，シード値を合わせても異なる結果になってしまう。そこで呼び出し回数と呼び出し順序を制御できるラッパーを用意してRandomの結果を同期できるようにしたそうだ。


　そのほか，オンライン対戦についてはヘキサドライブから任天堂にかなり要望を出し，現在の最新プラグインでは，ランダムマッチメイクやフリーマッチメイクが利用できるようになっているそうだ。

　プラットフォーム固有対応で意外と大変だったのは，1台で2コントローラが可能であることによる制御だった。今作ではキャラクター選択画面でコントローラをペアリングして追加することもできるため，内部的には椅子取りゲームのような実装になっている。この実装を用意するのには少々苦労したそうだ。

ヘキサドライブ製のゲーム開発用ツールたち

　ヘキサドライブは，本作を開発するための専用エディタをUnity Editor拡張を使用して用意している。マップを作るステージエディタ，NPCの動作を設定するAIエディタ，エネミー（ストーリーモードのザコキャラ）のAIエディタ，ボスの制御などがあったそうだ。

[マップエディタ	NPCのAIエディタ
エネミーのAIエディタ	ボスデータ制御エディタ

息つく間もなくバージョンアップ作業

　そうして迎えたカートリッジのバージョン1.0と，Day 1パッチである1.1が配信となってめでたく完成……とはいかず，息もつかずにバージョン1.2の開発に着手することとなった。

　まずはオフラインモードのコントロールレスポンス改善だ。これは発売後にプレイヤーからの声が多かった，キャラクターの動きだしタイミングの修正である。Unityはシステム上トリプルバッファで描画されているが，当初のNintendo Switch版では，クアッドバッファ描画になってしまっていた。30fpsで動作するゲームに3〜4フレームの入力遅延（※0.1〜0.13s）が起きていたのだが，バッファの問題はUnity側ですでに修正されたそうだ。オンラインの操作性向上についても，入力同期方式による遅延やラグを考慮に入れたかたちでボムを置けるように修正がなされた。


　そして1.3では，オフラインモードではさらなるレスポンスの向上のために60fps化を達成した。新しい要素として，NPCの強さを選んだり，難度を選択できたりするオプションを用意した。オンラインでは通信環境によってラグ調整の数値を変えるなどの細かな調整がさらに加えられたそうだ。

60fps化を目指したチャレンジ

　60fps化にはさらなる調査と調整を要した。CPU処理とメモリのGCタイミングに関しては，UnityのDeep Profileを活用し，全体を見てどこが一番処理を食っているのかを見つけていった。こちらはPCでの調査に活用し，Nintendo Switch実機では任天堂から提供されているCPUプロファイラを使った調査を行ったそうだ。

　調査を経てさらなる対応が行われた。まずCPU負荷を軽減するために，ActiveになっているGameObjectをなるべく減らしにいった。具体的には，キャラクターについているエフェクトはSetActiveの負荷を気にして常時Activeになっていたが，それをDeactivate状態で持っておくように変更した。また，メモリアロケートの原因になりそうな箇所を徹底的につぶしにいった。例えばコードには構造体を多く使っていたが，それをHashtableに入れているとオブジェクト変換によるボクシングが走っていたためDictionaryに置き換えるなどの措置をとり，最適化を極限まで行っていった。


　GPU側の対応では，不透明オブジェクトの描画順を調整し，手前から順に描画する形に収まるようにした。また，3Dレンダリングの内部解像度を調整することで描画の高速化を図った。


　こうした細やかな努力の積み重ねにより，1.3では晴れて60fpsを達成することができたそうだ。

カリカリにチューニングされていたボンバーマン

　ローンチタイトルとして発売された「スーパーボンバーマンR」は，Joy-Conのコンセプトとあいまって，多くの人が同時購入したタイトルだ。オンライン対戦と大量の描画オブジェクトという制約の中，実直な積み重ねによってプレイの快適化が進められていった過程を本セッションでは知ることができた。またUnityも，ローンチに5タイトルという経験を経たことでエンジンの洗練速度はすさまじいものであったと想像される。家庭用ゲーム機向けUnityゲーム開発のノウハウであったとともに，Unityと任天堂によるデベロッパとの強い協力体制を感じることができるセッションであった。