ゲームパッドとマルチプレイの対応
コストを最小限にするという考えがあったため、グラフィック・画面出力・サウンドはほぼ手を付けず、解像度のみPC版での使い勝手を考えて変更を可能にしたといいます。
そのほかおもな対応は操作関連となります。まずはPCゲームにおけるマウス&キーボード操作と、簡易的なゲームパッド操作。こちらは特に大きな問題ではありませんでした。ゲームパッド操作もSteamがAPIを提供していることもあり、さほど苦労しなかったとのこと。
問題は家庭用ゲーム機でのゲームパッド操作です。モバイルゲーム版がタッチ操作を前提としているということで、ポインティングデバイスがない家庭用ゲーム機は「どうすればいいの!?」と悩んだそう。他のゲームだと操作できる部分をフォーカスする処理をしていましたが、今から対応するのは厳しく、運用面でもつまづきが予想されたため、それ以外の方法を模索することとなりました。
結果的には、「仮想マウスカーソル」と便宜上呼んでいる機能を実装し、アナログスティックと十字キーに割り当てることにしました。さらに決定・キャンセルボタンや、各スキルをそれぞれのボタンに割り振ることでショートカットすることに。その開発過程では随時、社内で試遊会をして意見のフィードバックを募りました。
続いてマルチプレイでの要件です。
プラットフォームによってはアカウント名を表記しなければいけないルールがあったため、プロフィール画面だけでなく戦闘中でも表示されるよう画面構成を変更。またプレイヤー同士のコメントをやり取りする場面でもユーザー名が表示されるようにしました。
特徴であるクロスプレイでも、プレイ中の端末のみでマルチプレイするのか、それともマルチプラットフォームでプレイするのか、オンオフ機能で管理をすることにしました。
有害なコンテンツから子供を守るためのペアレンタルコントロール要件も重要です。ボイスチャットやチャット欄を制限したり、卑猥な文言や別サイトなどへの誘導を防いだり、課金額も制限しました。加えてネットワーク機能そのものも、必要最低限の機能を除いて制限できるようにしました。
運用ワークフローとビルドフローについて
まずバイナリビルドフローについて。こちらはもともと並列で作る仕組みだったため、新規のプラットフォーム用ビルドマシンを増やして並列化を行い、速度面の問題を解消しました。
そして前述した外部ストレージのダウンロードについてですが、こちらはビルドフローを一部変更することで対応。ビルド生成の直前に処理をひとつ加えています。
というのも、起動時にアセットをダウンロードするモバイル版と異なり、マルチプラットフォーム版は大部分のAssetBundleをバイナリに含めることで外部ダウンロードのストレージ容量を調節しています。バイナリ生成の前にビルド済みアセット類とカタログをストリーミングアセットフォルダに置き、そこから読み込むという、家庭用ゲーム機だけの処理を追加したわけです。
次にAssetBundleビルドフロー。こちらは追加プラットフォーム分のバイナリとAssetBundleがあるため、総ビルド時間がモバイル版より長くなってしまいます。そこでAssetBundleの一部を並列化し、ビルド速度をアップさせました。
続いて運用ワークフローのスケジュールです。変わった点としては、全プラットフォームでリリースの必要があるバイナリのスケジュールが、モバイルとPCなら2週間から4週間、家庭用ゲーム機は審査に時間がかかるプラットフォームを基準にして4週間から6週間ほどとなっています。これにより期間あたりの実装数はそれほど増えていませんが、1バージョンに含む機能の内容については増加しました。
またスケジュールで変わらなかった部分もありました。マスターデータやアセット配信のみで実施するイベントなどのリリース頻度、そして家庭用ゲーム機が関わらない部分のアップデートです。
課題としては、増えた分のプラットフォームの商品登録に時間が取られること。ひとまずツールである程度の自動化は行えますが、公式のツールやAPIがないとハック的な対応にならざるをえません。根本的な対応としては、ゲーム内の仮想通貨を使うなどが考えられますが、そこは売り方を決める人間との相談が必要です。
テストに関してもプラットフォームが増えればそれだけ時間的なコストがかかります。そのあたりは現在、ツールを開発し自動化を進めているそうです。
このように、追加機能が多く課題も残るマルチプラットフォーム化ではありますが、新規のユーザーにリーチするという意味では得るものが多く、夢のある施策であると会場に訴えてセッションを終えました。
