ゲーム・オブ・スローンズのモバイル版ウェスタロスを建設する：ドラゴンファイア

ワーナー・ブラザース向けゲームズボストンにとって、ウェスタロスの世界をモバイルに移植するには、愛されているフランチャイズを単に翻案するだけでは不十分だった。『ドラゴンの家』を土台として、ゲーム・オブ・スローンズ：ドラゴンファイア大規模なマルチプレイヤー戦略とドラゴンとの戦闘を組み合わせ、最新のモバイル端末向けに設計された無料プレイ体験を提供します。

プレイヤーはヴァリリア人の子孫となり、ドラゴンを孵化させ、育て、指揮する任務を負いながら、何千人もの他のプレイヤーと鉄の玉座の支配権をかけて競い合いステップ。そのファンタジーを実現するには、高品質なビジュアル、拡張性の高いパフォーマンス、そして範囲デバイスに対応したリアルタイムマルチプレイヤーシステムをバランス良く組み合わせる必要があった。

私たちは、テクニカルディレクターのアラ・イェサヤン氏と、上級テクニカルアーティストのタイア・リー氏に、モバイルハードウェア向けにドラゴンを制作すること、大規模な戦略ゲームプレイをサポートすること、そしてUnityを使ってウェスタロスの世界を生き生きと表現することについて話を聞きました。

プレイヤーの初回セッション体験に関して、あなたの主な目標と制約は何でしたか？

アラ・イェサヤン：初回セッションでは、プレイヤーの集中力を維持し、没入感を妨げるような中断時間を避けたいと考えています。ゲームの基本要素と、「ハウス・オブ・ザ・ドラゴン」の世界で語るべき物語を、段階的に紹介していくことが重要です。

新規プレイヤーと復帰プレイヤーの両方において、ロード時間を最小化ためにどのような戦略を採用しましたか？また、これらのプレイヤーの体験はどのように異なりますか？

AY :新規インストールの場合、初期段階で必要なデータをできるだけ少なくすることに重点が置かれます。私たちは、プレイヤーをゲーム体験の開始に導く前にダウンロードまたはメモリにロード必要のあるデータ量を削減するための技術を模索するとともに、画面遷移を利用してそれらの読み込みの一部を処理できるようにしました。復帰プレイヤーの場合、プレイヤーの状態をビルド、マップ上の適切な場所に配置するために、より多くのデータが必要になります。前提は似ているものの（データ待ち時間を最小化）、これらの技術は逆シリアル化コストと、初期準備を削減するための戦略的な方法に重点を置いている。

開発中に、読み込み時間の最大のボトルネックをどのように特定しましたか？

AY:ロード時間を改善するために、いくつかの手法を用いました。ボトルネックがどこにあるのかを全体的に把握するために、ロードプロセスの各段階ごとにカスタムプロファイリングイベントを設定し、それらをCSVファイルに書き出しました。複数のセッションにわたる値を集計し、どの段階がホットスポットであったかを特定しました。また、これらのデータをChromeトレースイベントとOpenTelemetryトレースに変換することで、各ステージがどのように並列でロードされているかをより視覚的に把握できるようにしました。

そこから、私たちは特定のステージに焦点を絞って調査を進めた。Unity ProfilerのCPUモジュールのおかげで、非効率なコードについてより深く理解することができ、それらをクリーンアップことが可能になりました。場合によっては、複数のプロファイルを記録し、 Unity Profile Analyzerを使用することで、いくつかの読み込み値を調整することでロード時間がどのように改善（または悪化）するかを評価することができました。

CPUプロファイラは、フレームレートの低下が著しい箇所を調査し、フレームレート低下の原因を突き止め、より良い手法を見つける際に非常に役立ちました。

読み込み以外にも、レンダリングモジュールはゲーム開始後のレンダリングにおける非効率性を掘り下げるのに役立ちました。また、 RenderDocは、ランタイムの問題をより詳細に分析する必要がある場合に活用したツールの1つです。

最後に、セッションを継続させるためには、メモリ使用量を適切に管理する必要がありました。Memory Profilerのスナップショットを通して、特にマップや行軍に関する不要なアセットやオブジェクトの読み込みを特定し、その結果、ゲームを起動するための読み込み要件を低減することができました。

UnityのMemory Profilerを使用して、アセットバンドルのメモリ使用量を分析しましたか？（重複の検出やアセットのアンロードの検証なども含めて）。具体的な例を共有いただけますか？

タイア・リー：通常、Memory Profilerを使用して、ゲーム内でアセットが予期しないタイミングでロードされ、メモリ上に保持されているケースを特定します。例えば、テクスチャが複数の場所で使用されているにもかかわらず、単一のバンドルにまとめられている場合に、そのテクスチャだけが必要な場合でも、バンドル全体が読み込まれてしまうという事態が発生する可能性があります。

これもまた、このような事態を防ぐために、特定の共有バンドルを作成することを目指している理由の一つです。このツールは、特に私たちが気づいていなかったものや、予想以上に容量が大きいものなど、より大きなメモリを消費しているものを検出するのにも役立ちます。

初期段階で遭遇した、特にコンテンツ配信とゲームプレイのパフォーマンスに関する、最も予想外のパフォーマンス上の問題は何でしたか？

AY:驚いたのは、マップのレイアウトを示すマップファイルデータをロードのに、どれだけのメモリが必要だったかということだ。でゲーム・オブ・スローンズ：ドラゴンファイアプレイヤーは軍隊とドラゴンを使ってマップ上の領土（タイル）をキャプチャ。これらは、プレイヤーが資源を集めたり、軍隊を派遣できる場所を制限したりするのにヘルプ。これは、プレイヤー自身または所属する派閥の別のメンバーが隣接するタイルを所有している必要があるという要件に基づいています。

コンテンツをロードには、マップデータをチャンクに分割する必要があることは分かっていました。このデータは、ゲームが各座標に何があるかを理解するために必要であり、特に複数のタイルをカバーするノードのために保存する必要のある追加データを考慮すると、なおさら重要でした。2000×4000のマップに関連付けられたすべての構造体を読み込む際に、一部のデバイスがクラッシュするほどのメモリが消費されました。

マップ全体ではなく、関連する部分のみをロードように改善と最適化を進めた結果、リピータープレイヤーのロード時間を大幅に短縮することができました。

マップをさらに最適化するために使用したもう1つの手法は、マップ上のTerrain (地形)を表すGameObjectを、メッシュの直接レンダリングに置き換えることでした。これにより、それらのゲームオブジェクトをインスタンス化する際のメモリコストを回避することができました。これに加えて、周辺エリアに必要なメッシュとモデルのみを戦略的に読み込むようにすることで、マップへのエントリーとスクロールのパフォーマンスの両方が向上しました。

ローンチ時に必ず公開すべきコンテンツと、後からストリーミング配信または読み込み可能なコンテンツをどのように決定するのですか？

AY:最初のステップは、プレイヤーがゲームのマルチプレイヤー段階に入る前に、初回ユーザー体験（FTUE）に必要なものを特定することです。これにより、プレイヤーがフルゲームにアクセスした際に使用するあらゆるデータをダウンロードする機会が得られます。

ライブ運用や最終段階の機能に関連するその他の種類のコンテンツも、プロセスの後半でダウンロードできます。私たちは、プレイヤーがシステムに触れた瞬間からゲームを楽しめるようにしたいと考えています。

今後の読み込みにおいては、正面に読み込むもの（ロード時間が長くなる可能性がある）と、非同期的にロードもの（画面やエリアに入る前に読み込みスピナーがアクティベート可能性がある）との間で、慎重なバランスを取る必要があります。私たちは、可能な限り最高のユーザーエクスペリエンスを実現するために、この分野で継続的に改善を重ねています。

ダウンロードサイズ、メモリ使用量、ランタイムの柔軟性のバランスを取るために、アセットバンドルパイプラインをどのように構造体、自動化しましたか？

TL:通常、アセットバンドルのサイズは8MB未満に抑えるようにしていますが、使用例やバンドルに必要なアセットによっては例外もあります。このため、ランタイムに一緒に使用されることが多いアセットが同時に利用できるように、バンドルを構造体ことにしました。

逆に、資産の一部しか使用されないような極端に大規模なバンドルは避けます。ゲームのエリア、特徴、または共有アセットの種類ごとに整理されたバンドルをご用意しています。例えば、私たちのマップには様々なバイオームがあり、それぞれのバイオームにはその場所に合わせた個別のアセットが用意されています。

北部の雪山と南部の砂漠の山々を同じグループに含める必要はない。ただし、一部のメッシュとテクスチャはバイオーム間で共有されているため、それらのアセットは共有バンドルに含まれます。

パフォーマンスを最適化するためには、ゲーム全体でアセットがどこで使用されているかを理解する必要がある、バランス感覚が求められる。他のライブゲームと同様に、これは継続的なプロセスであり、機能が追加されるにつれて見直しと再編成が必要になります。

AY:Addressablesがリリースされる以前、私たちは社内で一連のツールを開発し、現在Addressablesが解決している多くの問題に対処できるヘルプにしていました。これらの内部ツールの中には、バンドルの構成を理解し、パッチをダウンロードして更新するための高度な技術（これを「バイナリパッチ適用」と呼びます）を可能にするものがあります。

アセットバンドルを扱う際に、どのようなトレードオフや課題に直面しましたか？また、それらにどのように対処しましたか？

TL:私たちが直面する最大の課題は、既存のプレハブを編集したり、バンドルのサイズや構成への潜在的な影響を認識せずに多くの新しいアセットを追加したりすると、アセットバンドルのサイズが大幅に増加する可能性があることです。

バンドルのサイズがユーザーに知られることなく一度に5MB以上増加した事例があり、最悪の場合、これにより.aabファイルがストアへの提出サイズ制限を超えてしまうことがありました。それ以来、私たちはビルドパイプラインにアラート機能を追加し、こうしたケースを検知できるようにしました。また、開発者が変更によってバンドルサイズが予期せぬ形で増加する可能性がある場合をよりよく理解できるように支援しています。

重複ダウンロードや不要なメモリ使用を避けるために、アセットの依存関係をどのようにハンドルいますか？

TL:社内のアセットバンドルツールでは、バンドル間で重複したアセットを確認できます。一般的に、重複したアセット、特にサイズの大きいアセットは多く存在したくないため、複数のバンドルから依存関係として取り込まれるのではなく、それらのアセットを直接バンドルに追加します。様々な場所で使用できるバンドルに追加されるようにする必要がありますが、通常は別の共有バンドルを作成します。

アプリ起動時のアセット逆シリアル化によって発生するCPUスパイクや遅延を軽減するために、どのような手法を用いてきましたか？

AY:設計データに用いる手法の一つとして、一般的なJSON形式ではなく、プロトコルバッファ（Protobuf）形式をストレージに使用することが挙げられます。Protobuf（gRPCで使用されるバイナリ形式）は、よりコンパクトなストレージと高速な逆シリアル化を提供します。

関連付けられた構造化スキーマファイルを使用することで、JSON文字列の内容を解析したり、その構造体をトークン化したりすることなく、データをはるかに高速にメモリにロードできます。データの保存とデシリアライズをより効率的に行うために、BSONやOdin Serializerといった他の選択肢も検討しましたが、gRPCを使用してサーバーとの通信をより効率的に行える点が、私たちにとって最適な選択となりました。

効果的なスレッド管理も非常に重要です。Unityのメインスレッドから移動できる作業を特定し、アセットやシーンの読み込みに集中できるようにしましょう。

パッチ適用とコンテンツ更新を迅速化するために、ビルドサイズとデプロイメントパイプラインをどのように最適化しますか？

AY:私たちが用いる手法はいくつかあります。まず第一に、ゲームのバイナリに組み込まれている必須アセットと、後からダウンロードできるアセットとの適切なバランスを取ることに重点を置いています。私たちのゲームには数分で完了するチュートリアルがあり、プレイヤーの初回ログインを妨げることなく、必要に応じて追加リソースをダウンロードできるようになっウィンドウいます。

AndroidのPlay Asset Deliveryを活用することで、より多くのリソースを正面に利用できるようになりました。私たちは、一部のデータが古くなっていることを想定して、特定の動的データテーブルをゲームクライアントにバンドルし始めました。変更されたテーブルのみをダウンロードすることで、ロード時間を短縮しました。

そこで、バイナリパッチング技術を導入し、新しいバージョンを直接ダウンロードするのではなく、より軽量なバイナリ差分をダウンロードして変更されたファイルにパッチを適用できるようにしました。アセットバンドルにもこれを適用でき、新しいライブイベントに合わせて必要に応じてゲームコンテンツにパッチを適用できます。

振り返ってみて、プレイヤーのロード時間を改善するために行った変更の中で、最も効果的だったものは何ですか？

AY:簡単な答えは、プレイヤーが必要なものだけをロードようにすることです。ソフトローンチに先立ち、マップが読み込み時間の最大のボトルネックの一つであることが判明しました。当時、ゲームはプレイヤーの本拠地周辺の地域のみをディスプレイように最適化を開始する前に、すべてのマップリソースを正面に読み込んでいました。

必要なものを特定し、残りの部分を後で非同期的にロード技術を導入することで、ハイエンドデバイスでさえも数秒のロード時間を短縮することができました。私たちのチームは、プレイヤーのロード時間を改善し、より良いユーザーエクスペリエンスへの道筋をつけるという使命を遂行してくれました。彼らの尽力には感謝してもしきれません。

Unityで作成されたプロジェクトについてさらに詳しく知りたい場合は、リソースページをご覧ください。