Navegante と Roll7 からのマルチプラットフォーム向けローンチのためのヒント

マルチプラットフォームでのゲームのローンチには困難が付きまといます。そこでよく見られる課題は処理能力の不足です。 

Navegante 社のリードプログラマー Rodrigo Fernandez 氏とリードプロデューサー Anahit Fernandez 氏、そして Roll7 社のテクニカルディレクター Andrew Brechin 氏と共に、『Greak: Memories of Azur』と『Rollerdrome 』で体験したことの舞台裏を見ていきましょう。

この Q&A セッションでは、マルチプラットフォームでのローンチを選択した理由や、ゲームのリリースを成功させるための実践的なアドバイスが紹介されています。

まずは、根本的な質問からです。すなわち、なぜ皆さんはマルチプラットフォームゲームを検討しようとしているのでしょうか。また、皆さんにとって「マルチプラットフォーム」とは何なのでしょうか。

Andrew Brechin 氏（以下 Andrew）：マルチプラットフォームは、皆さんのゲームを多くのプレイヤーの手に届けるための最良の方法です。家では 120Hz の 4K テレビでプレイして、外出先ではハンドヘルド機でプレイするというのがいいですよね。

Anahit Fernandez 氏（以下 Anahit）：私たちにとってマルチプラットフォームとは、PC、コンソール、モバイルで遊べるゲームを指します。インディーのスタジオにとって、マルチプラットフォームでゲームをローンチするということは、より多くのプレイヤーにリーチし、ゲームのオーディエンスを拡大するための手段です。また、各プラットフォームホルダーから露出の機会を与えられるチャンスも増える可能性があります。

ゲーム制作を始める際、プラットフォームについて前もって考えておくのか、それともまず制作を始めて、その結果に基づいて最適なプラットフォームを決定するのか、どちらでしょうか。

Andrew：開発の初期や開発の本格化の許可が出た段階で、どのようなプラットフォームでゲームをリリースするかは考えてありますね。私たちは、最初は PC で開発を行います。パブリッシャーが決まると、プラットフォームリストが洗練され、制作の初期段階で知っておく必要のある最小・最大スペックもわかってきます。

Anahit：私たちの場合は、まず自分たちが作りたいゲームをよく理解することから始めました。また、いくつかのイベントに参加した後、プレイヤーからゲームをやりたい場所について意見を聞きました。

マルチプラットフォーム開発のためのプロジェクトは、どのように立ち上げるのでしょうか。ターゲットとなるプラットフォームが複数あることを承知の上で、事前にどのような計画を立てているのでしょうか。

Andrew：独自のビルドツールで、各プラットフォームの Unity 設定を更新しています。ボタンを 1 回クリックするだけで、どのマシンでも同じように実行ファイルをビルドし、コンスタントにビルドを供給し続けられるようにしています。これをもとに、6 つのプラットフォームすべてについてビルドを行い、テスト用にデプロイできる自動ビルドシステムを構築しています。このように多くのプラットフォームを扱うとなると、こういうシステムが欠かせません。

プラットフォームごとに最適なテクスチャ解像度を割り出し、そのプラットフォームがサポートする画面解像度に合わせてソースグラフィックを縮小するという処理を行っています。このスケールは、新しいオブジェクトを追加する際のプロセスの一部となります。

Rodrigo Fernandez 氏（以下 Rodrigo）：技術的な面では、各プラットフォームに特化したコンテンツに取り組むために、きちんと異なるブランチを作るようにしました。また、パブリッシャーからは、認証プロセスを支援するコンプライアンスチームや、各プラットフォームの経験豊富な QA チームの派遣も受けました。

各プラットフォームごとに独自のコードベースをメンテナンスするのでしょうか。それとも 1 つのコードベースだけでやりくりしようとするのでしょうか。

Andrew：各プロジェクトにはそれぞれコードベースが 1 つだけあります。プラットフォーム固有のコードはそれぞれのクラスで管理し、ビルド時には条件付きアセンブリを使用して、各プラットフォーム向けの処理を有効にするようにしています。私たちのビルドプロセスでは、その最中にプラットフォームファイル（サポートファイル、パッケージなど）をプロジェクトにコピーして、すべてを区分けできるようになっています。

Rodrigo：私たちはゲームプレイのコアとなるシステムは 1 つのコードベースにまとめ、プラットフォーム固有の機能や Unity のバージョンごとにブランチを作っています。

プラットフォーム間でコードが混在しないように、ファイル、入力デバイス、ビデオ、実績、ローカライズのシステムを分離することが非常に重要でした。

プラットフォームの最適化はどのように行っていますか。コアな制作フェーズの一部として行われているのでしょうか、制作完了後に専用のフェーズを設けるのでしょうか。

Andrew：開発中、チームが作業やテストを行っていたメインプラットフォームである PC の FPS を 60 に近づけることが非常に重要でした。プロジェクト期間中は、開発者の分析によってコンソールのパフォーマンスに目を配り、スプリントにタスクを追加して、コンソールが大きく遅れをとらないようにしました。

各マイルストーンにおいて、最後の 1 週間はバグ修正と既存の成果物の洗練のみに集中し、必要に応じてここでいくつかの最適化も行いました。

開発の最後の 6 か月間（プレアルファ版）の段階では、ゼネラリストとしてシニアエンジニアを追加雇用し、対象としているうちで最もスペックが低いプラットフォームの最適化とシェーダーに集中してもらいました。それをすることで、すべてのプラットフォームで連鎖的に改善が起きると見込まれたからです。

Rodrigo：プラットフォーム開発のベースとして Nintendo Switch™ を使用しました。これにより、毎月ビルドを実行してパフォーマンスをテストし、将来の問題を回避することができました。

プラットフォーム認証の申請を開始する前に、『Greak: Memories of Azur』を最適化するために追加で時間を割き、すべてのプラットフォームで 60 FPS で動作するようにしました。

最適化のために予定していた期間が短い中でこれを達成するには、Unity プロファイラー、Frame Debugger、動的解像度の活用が鍵でした。

複数のプラットフォームでプレイするユーザーに対して、どのように一貫したゲーム体験を提供するのでしょうか。

Andrew：すべてのプラットフォームで同じゲームプレイコードを使用しています。違いがあるとすれば、入力設定、閾値、デッドエリア、振動などでしょうか。こういうわけで、同じゲームを各プラットフォームのコントローラーでプレイしても違和感がありません。

Rodrigo：各プラットフォームで可能な限り最高のプレイヤー体験を保証するために、さらなる工夫を凝らしてみました。例えば、キーバインドやウルトラワイドモニターへの対応、Steam 版でのグラフィックオプションなどを手がけました。Nintendo Switch 版では、設定メニューに UI スケーリングオプションを追加しました。PlayStation®5 版では、コントローラーのハプティクスと新しい属性を利用し、Xbox 版ではスマートデリバリー機能を追加しています。

ゲームのリリースに向けて、マーケティングの計画を立てるのはいつ頃からですか。

Anahit：私たちの場合、『Greak: Memories of Azur』については発表後にいくつかのイベントに参加しましたが、マーケティングキャンペーンの開発は、ゲームのローンチの半年前から始まりました。

ゲームのマーケティング戦略で最も重要なことは何でしょうか。

Anahit：私たちは、ゲームのマーケティング戦略の最も重要な側面の 1 つは、プレイヤーに対する露出を増やしていくためにプラットフォームホルダーと協力することだと考えています。

また、ゲームのメッセージは非常に明確であるべきで、オーディエンスの関心を確実に理解することが非常に重要です。

マルチプラットフォーム向けの仕事をしている開発者にとっての大きなポイントは、潜在的なコストや課題を予測・先取りし、各プラットフォームでのプレイヤー体験を最適化し、利用可能なすべてのプラットフォームにわたって市場のポテンシャルを最大化するよう計画することです。

もっと知りたい方は、マルチプラットフォームゲームを成功させるための 5 つの基礎的なことを学べる、私たちの新しい e ブックをお読みください。また、Made with Unity フォーラムで、他のユーザーと成功の秘訣を共有していただければ幸いです。

Nintendo Switch は任天堂の商標です。