Jam City がハイパフォーマンスを実現するために Disney Magic Match 3D をどのように構築したか

Disney Magic Match 3D では、プレイヤーは魔法にかけられた魔法の本に秩序を取り戻すことができます。魔法の本は、ディズニーとピクサーのアイコンアイテムをページ全体に散りばめています。プレイヤーは魔法にかけられたオブジェクトとマッチし、気まぐれな場所を整理し、片付けの楽しさを再発見して、魔法の書の秩序を回復させなければなりません。これは 1 つずつ居心地の良いレベルにしていきます。

Jam City の各チームは、開発全体を通して、野心的な目標を設定しました。アートチームは厳しいポリゴン予算の中で高いビジュアル忠実度を追求し、製品チームは理想的なセッション時間目標に合わせて最適化し、デザイナーは新鮮なコンテンツの安定したフローを確保し、QA テスターは強力なツールを必要としました。一方、『Jam City』のエンジニアは、ワールドクラスの技術パフォーマンス、安定性、スナップ性などをすべてのプラットフォームで優先しました。彼らがビジョンを実現するために複雑な課題を乗り越えた方法をご紹介します。

Disney Magic Match 3D：Unity のケーススタディ

スタジオはどのようにしてパフォーマンスを維持しながら、過熱、コンテンツ配信、その他の技術的な問題などの課題に対処しているのでしょうか？

制作中、何百もの 3D オブジェクトを 1 つのレベルで物理演算でレンダリングするには、ライティング、ポストプロセッシング、ポリゴン数に注意が必要です。

Jam City のソフトウェアエンジニアリングマネージャーで Disney Magic Match 3D の技術リードである Hebby Mathew 氏は、「特に 20 分のセッションでは、早い段階から過熱が大きな問題でした。スマートフォンが快適で熱くなるからです。「パフォーマンスを改善し、さまざまなハードウェアでデバイスの熱を一貫して測定する方法を開発することで、この問題に対応しました。」

もう 1 つの課題は、フレームレートに影響を与えることなくアセットを非同期的にストリーミングするコンテンツ配信でした。「Unity の拡張可能なエディターは、コンテンツのロード時間と方法を管理するための効率的なツールを構築するのに役立ちました」と Mathew 氏は言います。

最後に、ローエンド、ミッドエンド、ハイエンドのデバイスにわたってゲームをプロファイリングし、パフォーマンスのボトルネックを特定する中で、チームは特にローエンドの GPU について、過剰なコリジョンコールやハイポリゴンモデルなどの重要な問題を特定しました。

「これらを最適化することでパフォーマンスが向上し、過熱する問題を解決するのにも役立ちました」と Mathew 氏は言います。

成果

- フレームレートがローエンドで 40fps、ミッドエンドの Android デバイスで 35fps 向上

- ドローコール数を iOS で 40%、Android デバイスで 45% 削減

- RAM 使用量を iOS で 30%、Android デバイスで 15% 削減

- ネットワーク処理以外のロード時間を 55% 短縮

- 10,000 以上の三角形を持つメッシュの数を 33 から 0 に縮小する

- 5,000 から 10,000 個の三角形を持つメッシュの数を 324 から 235 に削減

- ライト数を 67% 削減

フレームやシステム全体のパフォーマンスのトラッキング

パフォーマンスの問題に直面したチームは、より深い洞察を得るためにプロファイリングツールに目を向けました。

Jam City のソフトウェアエンジニア Kevin Johnson 氏は、「Unity プロファイラーマーカーは、マルチフレームタスクを追跡するのに特に役立ちました。「Profiler Analyzer も比較に使用しました。」

別のエンジニアである Andrea Ramirez 氏は、バイナリログファイルを使用して分析を拡張し、特定のフレームのスナップショットをキャプチャしました。「これにより、プロファイラーをライブで使用せずにパフォーマンスを分析できます」と彼女は説明します。

チームはプロファイラーをさらにカスタマイズし、使い捨てアイテムを追加してトリガーとロギングを効率化しました。CPU プロファイリング以外にも、メモリプロファイラーでメモリを監視し、フレームデバッガーでレンダリングの問題を解決しました。Profiler Recorder により、反復可能なテスト中にグローバルパフォーマンスの統計を追跡できるようになりました。

「エンジンの最大の強みの 1 つは、エディターの拡張性です」と Ramirez 氏は付け加えます。「マルチフレームスナップショットをキャプチャし、テストをスクリプティングすることで、一貫した信頼性の高いパフォーマンスデータを収集しました。」

大きなパフォーマンススパイクの削減

プロファイリングにより、レベル開始時の主なパフォーマンスのスパイクが明らかになりました。これは、アセットが最初に登場したときのシェーダーコンパイルが原因です。Addressables を使用して、チームは不要なシェーダーのコンパイルをトリガーする重複アセットを特定しました。

開発者の John Enney 氏は次のように述べています。「UI 要素とゲームピースはあらかじめロードされています。「アセットバンドルが適切にグループ化されていないことが大きな問題で、これがシェーダーのコンパイルを繰り返す原因となっていました。最初は見落としていました。」

早い段階で、Quick Outline を統合し、ピースのハイライトをすばやく追加しました。オーバードロー（余分なレンダリングオーバーヘッド）が発生する一方で、最適化により完全な書き換えなしで維持できるようになりました。

オーディオもパフォーマンスのスパイクの一因となりました。「各ゲームピースが独自の衝突音をトリガーしました」と Enney 氏は説明します。「最初は問題なく動作しましたが、300 個のピースが同時にドロップすると、フレーム時間が 500ms に急増しました。それらの複数のサウンドを 1 つのアンビエントドロップサウンドに置き換えると、それが 20～30ms に短縮され、実際により良いサウンドになりました。」

触覚フィードバックも微調整が必要でした。テックディレクターの Troy Lee 氏は次のように述べています。「この制限を適用することで、ゲーム全体で一貫してパフォーマンスが向上しました。」

ライティングにも課題がありました。ディファードレンダリングによってパフォーマンスは改善されましたが、芸術的な目標と相反していました。「フォワードレンダリングでは、オブジェクトごとに高価なパスが必要になるため、複数のライトに苦労します」と Ramirez 氏は説明します。品質と効率のバランスを取るために、Enney はビジュアルの忠実度を維持しながらランタイムのパフォーマンスを向上させるベイク済みライティングソリューションを開発しました。

ジオメトリの複雑さも懸念事項でした。リードテクニカルアーティストの Kristen Weeks 氏は次のように述べています。「初期のモデルは 10,000 トライアングルを超えました。「ローエンドのデバイスで良いパフォーマンスを実現するために、ほとんどのモデルを 2,500 以下の三角形に減らしました。」

初期化とアセット処理の効率化

初期段階では、Web 呼び出しを伴うアセットのロードやシステムの初期化が大きな課題となっていました。ゲームプレイ中や UI インタラクション中の速度低下を避けるために、チームは最初にすべてのアセットを事前にロードしました。しかし、ゲームの機能やアセットが拡大するにつれて、起動時間が極端に長くなりました。

一部のアセットをバックグラウンドで非同期的にロードするように移動することで最適化し、スムーズなゲーム内体験を維持しながら初期ロード時間を短縮しました。また、.NET のタスクシステムを使用して読み込みタスクを並列化し、ネイティブアセットバンドルの読み込みに伴うこれらの改善により、大幅な改善を実現しました。

特に初期ロード時のネットワーク遅延もパフォーマンスに影響を与えました。これに対処するため、チームは Unity のコルーチンからネットワーク呼び出しを C# の非同期/待機に切り替え、待ち時間を削減しました。「また、Newtonsoft のリフレクションベースのアプローチをコード生成に置き換えることで JSON のデシリアライズを最適化し、パフォーマンスを改善しました」と Johnson 氏は言います。

インスタンス化のコストはさらに初期ロード時間に影響し、ローンチ直後にゲームが多数の UI と背景プレハブを作成するため、ミッドレンジデバイスでは約 0.5 秒と大幅な遅延が発生しました。

「コストの大部分は、多くのオブジェクトで Awake() の初期化が重かったことです」と Johnson 氏は説明します。「オブジェクトの作成時に無効にし、必要な場合にのみ有効にすることで、インスタンス化を最適化しました。また、インスタンス化を一度に行うのではなく、遅延や時差を置いて行うことで、目に見える待ち時間を減らしました。」

パフォーマンスをより正確に測定するために、チームは System.Diagnostics.Stopwatch を使用してインスタンス化間隔を測定し、コードのさまざまな部分を計測しました。

これらの最適化にもかかわらず、実際のネットワーク品質は依然としてロード時間に影響を与えます。これに対処するため、チームは遅延読み込みの実験を行っています。遅延読み込みとは、すべての設定を含んだ状態でゲームをリリースし、バックグラウンドで設定を非同期的に更新しながらすぐにプレイヤーが入るようにするというものです。「初期のテストは有望に見えますが、ライブ結果を慎重に監視しています」と Mathew 氏は言います。

ローエンドデバイスでの GPU の制限への対応

チームはパフォーマンスの最適化中に、一部のローエンドデバイスで最小限の改善しか見られないことに気付きました。彼らは、これらのデバイスが主に Mali GPU を使用しており、ゲームの目標アイテム数を効果的に処理するのに苦労していることがわかりました。しかし、すべてのデバイス層で 60 fps の目標を維持することができました。

Weeks は、これらの制限について詳しく説明しています。「旧型の第 3 世代および第 4 世代の Mali GPU は、ジオメトリバウンドになりやすい厳格なタイルベースのレンダラーです。これとは対照的に、他の多くの GPU は、このボトルネックを回避するのに役立つハイブリッドレンダリング技術を使用しています。最近のPixel Phoneに搭載されているような、より新しいMali GPUは、より多くのプロセッシングユニットを搭載し、ジオメトリをより良く処理します。」

これらの制約をよりよく理解するために、Mathew は開発の早い段階で、フレームレートの低下を追跡するために、さまざまなデバイスで増え続けるオブジェクトをインスタンス化するツールを構築しました。このツールでは、特定の GPU のしきい値が低いことが明らかになっており、アートの品質を犠牲にすることなくゲームモデルを慎重に最適化する必要性が強調されています。

「プリプロダクションでは、アートディレクターからポストプロセッシングエフェクトと複数の動的ライトの多用の要望がありました」と Weeks 氏は言います。「しかし、デバイスのオーバーヒートやパフォーマンスのヒットに大きく影響するため、製造用のポストプロセッシングは削除しました。」

また、Enney 氏はポイントライトをシェーダーに直接ベイクすることで効率を高め、アクティブなライトの数を 3 つか 4 つか 1 つに減らしました。

このコラボレーションアプローチにより、チームはビジュアル品質とパフォーマンスの最適なバランスを取り、幅広いデバイスでスムーズな体験を実現できました。

Unity Pro を今すぐダウンロード

強力なツール、サポート、公認パートナー、活発なコミュニティの力を利用して、大規模スタジオがリリースするタイトルの品質と成功に勝るとも劣らないゲームの制作を開始しましょう。