Apple ArcadeデバイスのFPS目標を達成するためにSonic Dream Teamを最適化

『Sonic Dream Team』は、Hardlight が開発し、セガが公開しているプラットフォーマーです。『Sonic the Hedgehog』シリーズの一作であるこのゲームでは、Sonic と仲間たちが邪悪なドクターエッグマンの歪んだ夢の世界を駆け抜け、世界征服の冒険を阻止します。

Apple Arcadeでは、サポートされているすべてのデバイスで同じパフォーマンス目標を達成することがスタジオに求められており、iPhone 6s PlusからiPhone 16まで、あらゆるデバイスで素晴らしいゲームがプレイできるように最適化することが強く求められています。ここでは、ローエンドとハイエンドの両方のデバイスで必要なフレームレートを達成した方法をご紹介します。

Sonic Dream Team：Unity のケーススタディ

ローエンドデバイスとハイエンドデバイスの両方で必要なフレームレートを達成するには、どのように最適化すればよいのでしょうか？

『Hardlight』は、ハリネズミと10年間一緒に仕事をした後、ストーリーラインを強化し、より多くのキャラクターを登場させ、アクションやアドベンチャーのスタイルを忠実度の高いビジュアルと融合させることで、新しい課題に取り組んでいました 。これは、Apple Arcadeのゲームをプレイできるすべてのデバイスで快適に動作するものでした 。これらの目標に向かって作業している間、チームは CPU と GPU に関連するパフォーマンスの問題に直面し、最適化を続けることになりました。

成果

CPU フレーム時間を 52 ミリ秒から 16 ミリ秒に短縮（中・高負荷デバイス）

iOSのビルド サイズを4 GBから2 GBに半減

シェーダーバリアントのランタイムメモリを 1 GB 以上から 100 MB 未満に削減

レンダリングの問題への対応

パフォーマンスを分析するために、チームはUnityが提供するさまざまな分析ツール、特にプロファイラー、フレームデバッガー、Memory Profilerを活用しました。これにより、チームは問題の原因をよりよく理解し、デバイス全体で30 FPSと60 FPSを達成することができました。

特にローエンドデバイスでは、レンダリングが全フレーム時間バジェットの大部分を占めていました。チームはこのコスト削減のヘルプにSRPバッチ処理を活用しました。

「ユニバーサルレンダーパイプライン(URP)を選択した理由は、そのモダンなレンダリングアプローチと、Unityからの将来にわたる継続的なサポートにあります」と、HardlightのテクニカルアーティストであるFraser Hutchison氏は述べています。チームは、SRPバッチ処理やShader Graphなどの機能に優先順位を付け、モバイルデバイスでビジュアルをレベルアップさせる新しい方法を採用しました。「SRP Batcherは私たちにとって非常に負担の大きい作業で、アーティストは標準的な静的バッチ処理のようにマテリアルの制約を気にする必要がない柔軟性をもたらしてくれました」とHatchson氏は続けます。「私たちは平均で100~200個のバッチを使用し、主に不透明なキューに格納しました。これはうまく機能しました。」

また、チームはリフレクション プローブを減らし、マテリアル ソーティング キューとベイクしたライティングを使用してバッチ処理効率を高め、レンダリング コストを削減しました。

ステージのサイズが大きいため、カスタムの階層型音量カリングシステムを実装して、レンダリングのオーバーヘッドを削減しました。「各レベルは『アイランド』と呼ばれる大きなチャンクに分割され、プレイヤーの位置に応じて無効または有効になっていました」と、Hatchson 氏は言います。「また、これらの島のアニメーターとパーティクルエフェクトも無効にすることができました。全体として、これは私たちのニーズによく合った軽量なソリューションでした。」

「チームのアーティストは、制作している世界の夢のような品質を高めるのに役立つ、ユニークなメッシュデータ、シェーダーエフェクト、ポストプロセッシングを多用した忠実度の高いグラフィックスを必要としていました。URP にポストプロセッシングなどの機能がビルトインされているため、完全にカスタムのソリューションを常に必要とせずに、ビジュアルのモックアップを素早く作成することができます。」 - Simon Dew 氏（Hardlight 社アートディレクター）

CPU フレーム時間の短縮

すべての iOS デバイスで一貫したゲームプレイを実現するために、Hardlight 社のチームは物理頻度数をデフォルトの 50Hz から 60Hz に設定しました。FixedUpdate を使用して、特定のオブジェクトの更新間隔に予想タイムステップを適用し、決定論を強化しました。

パフォーマンスの問題によりフレーム時間が大幅に増加すると、Unity で 1 フレーム内に複数の FixedUpdate 呼び出しが行われ、目的の物理演算更新レートが維持されます。

「結局、シミュレーションが必要な更新をすべて時間内に処理できず、フレーム時間がさらに長くなりました」と、Hardlight のチーフソフトウェアエンジニアである Louis Macan 氏は言います。物理演算のタイムステップが同じであったため、ローエンドデバイスでフレームごとの FixedUpdate コールが増加し、ゲームは 30 FPS で実行されました。

iPhone 6s Plus などの古いデバイスでフレームレートを維持するために、チームは FixedUpdate のたびに最適化を行いました。個々の FixedUpdate コールをプロファイリングしている間、FixedUpdate 時間の大部分は、何百ものスクリプトインスタンスからの更新コールによって保持されていることに気付きました。これらのスクリプトがアーリーアウト状態ですぐに終了しても、FixedUpdate の呼び出しは依然として実行されました。

「条件が満たされないとFixedUpdateが何も実行していないように見えても、スクリプトで宣言されているすべてのUnityイベント関数はオーバーヘッドを引き起こします」とMacan氏は言います。「それ自体のオーバーヘッドは小さいですが、レベル作成中に追加されたスクリプトによって実行される何千回もの Update、FixedUpdate、および Late Update の呼び出しは大きな影響を与えました。」

これを修正するには、複数のアプローチが必要でした。まず、スクリプト自体を登録するマネージャーが追加され、マネージャーが必要な更新頻度で各オブジェクトを順番にチェックするようになりました。つまり、Unityイベント機能をすべて削除でき、CPUの時間を浪費する必要がなくなりました。最後に、プレイヤーの物理演算と相互作用しないオブジェクトはUpdateをオンにするように設定し、ローエンド デバイスでの計算コストを半分にしました。

ゲームのパーティクルシステムの強化

また、チームはシーン内のパーティクルシステムが多すぎることが CPU のパフォーマンスに影響を与えていることに気付きました。チームは、パーティクルプーリングシステムの一部として、カスタムの ParticleEffectsWrapper コンポーネントを通じて、ParticleSystemRenderer API を使用するパーティクルシステムを有効または無効にしました。500 を超えるパーティクルシステムの更新がメインスレッドとワーカースレッドで処理された場合、CPU フレーム時間は約 5.2 ミリ秒でした。

「Unity の Visual Effect Graph は、ローエンドデバイスの多くがそのシステムが依存する GPU コンピューティングをサポートしていないため、このプロジェクトではオプション肢にありませんでした」と、Hatchson 氏は言います。「この機能を使用できていれば、より優れたカリングおよびインスタンシングテクノロジーの恩恵を受けたでしょう。」

Unity のパーティクルシステムは、プロシージャルなものと非プロシージャルなものの 2 つがあります。プロシージャルパーティクルシステムは、任意の時点まで自由に巻き戻しや早送りを行えます。

「Unity はプロシージャルを使用することで、パーティクルシステムがオフスクリーンに出ているときにパーティクルシステムと関連するすべての処理を安全にカリングし、再び表示されたときに正しい状態にフォワードすることができます」と、Hatchson 氏は言います。「これにより、パフォーマンスが大幅に向上します。しかし、これはパーティクル効果作成では見落とされがちな部分で、誤って効果を非プロシージャルにしてしまいがちです。」

これを避けるために、ParticleEffectsWrapper コンポーネントは、カメラ錐台に基づいてパーティクルをカリングするだけでなく、カスタムのレンダーバウンドを定義し、パーティクルがプロシージャルとマークされていても、手動で設定されたバウンドによってシステムをカリングできるようにしました。

「シーン内に多数のパーティクルシステムがある場合は、できるだけ多くのシステムをプロシージャルにし、そうでない場合は ParticleEffectsWrapper コンポーネントでレンダーバウンドを設定することが重要でした」と Macan 氏は言います。「これにより、不要な計算や描画呼び出しが回避され、パフォーマンスが大幅に向上しました。」

チームはカリングに加えて、エフェクトの優れた制作プラクティスを優先しました。必要な数のパーティクルシステムのみを使用し、最大パーティクル数を抑えてアルファオーバードローとメモリ割り当てを削減しました。また、テクスチャアトラスの扱いや、長継続時間の使用を避けることにも注力しました。また、URPのレンダリング設定の「Show All Hidden Properties(すべての非表示プロパティを表示)」トグルからダイナミックバッチ処理を有効にし、今回の小さな変更により、パーティクルの描画コールを削減してレンダリングをスピードアップしました。

GPU ボトルネックに遭遇する

Sonic Dream TeamのVisionには、上級者向けグラフィックスと迅速なゲームプレイが必要でした。カスタマイズのために、スクリーンスペースアンビエントオクルージョン、カスタムフルスクリーンエフェクト、スクリーンスペースデカールなどの特定のエフェクトのレンダリング機能を使用しました。このため、レンダリング遅延とメモリの問題が発生しました。

「開発中に、キャラクターや敵のブロブのシャドウに深度ベースのスクリーンスペースデカールを使用すると、レンダリングの特徴により不要な深度法線プリパスが発生することがわかりました」とHatchson氏は言います。「つまり、レンダリング時間の大部分は、通常のバッファを必要としないため、不要な作業とレンダーターゲットメモリの増加に費やされていました。Unityチームと協力してこの問題を解決し、エンジン パッチ リリースで修正を加えました。」

シェーダーの事前処理も懸念事項で、レベル全体で CPU/GPU のスパイクが顕著になり、スタッターが発生しました。「Metalでシェーダーを効果的に事前準備するには、シェーダーが必要なキーワードをすべて含み、レンダリングされる各メッシュの特定の頂点レイアウト グループを持っている必要があります。つまり、エディターのみのキャッシュは不可能でした」と、Hatchson 氏は言います。

これに対処するため、Hardlightのエンジニアは、ロード時にカメラ正面のローディング画面の背後にあるすべてのオブジェクトを「フラッシュレンダリング」するシステムを構築しました。

「私たちのアイランドカリング技術により、シーン内のすべてのレンダラーのリストに簡単にアクセスできました。デバイス上でこれを行うと、プレイヤーが正式にレベルに入る前に、品質設定からすべての正しいパイプライン状態データとキーワードを取得できました」とHatchson氏は言います。「これにより、レベルのロード時間が若干増加しましたが、プレイヤー体験にとってはそれだけの価値がありました。」

シェーダーの事前実装を凌駕する結果に満足しつつ、Hatchison氏はフォワードの他のオプションも検討しています。「ゲームのリリース以来、Unity は GraphicStateCollections を通じて PSO キャッシュと戦前処理をリリースしており、将来はそれを使用したいと考えています。」

Addressables によるメモリサイズの削減

開発中、ゲームはランタイムで 1.35 GB のメモリを使用しました。iPhone 6s Plus の物理メモリが 2 GB しかないことを考えると、オペレーティングシステムがアプリケーションを終了するリスクなどの問題につながる可能性があります。

「アセット複製は大きな障壁でした。ゲームには 3,000 以上のアセットが重複していたため、サイズが膨れ上がり、ランタイム中に同じアセットが複数回読み込まれることになりました」と Macan 氏は言います。

当時、Unity Addressable Systemがマネージしていたゲームアセットはほんの一部だけでした。そのため、アセットがバイナリ内と Addressable Groups 経由で参照され、重複が生じていました。

開発の初期段階では、チームは 1 つの Addressable Group を使用し、それを別々にパックするように設定していました。つまり、グループ内の各アセットは、それぞれ別個のアセットバンドルを持っていたのです。このきめ細かなアプローチは特定のケースで役立ちますが、同時に大量のアセットの重複にもつながりました。すべてのアセットがAddressableであることを保証し、Addressable Groupsに対する構造化されたアプローチを採用することで、iOSのビルドサイズが4 GBから2 GBに半減しました。

シェーダーバリアントメモリの削減

シェーダーバリアントは、ゲームの制作全体を通してチームが大きく注力した領域で、ランタイムシェーダーメモリは1 GB以上に膨れ上がりました。バリアントの数もビルド時間を増加させました。彼らはさまざまな方法を使用して問題に対処しました。主に、IPreprocessShadersによるシェーダー ストリッピング、Unityの事前フィルタリング、Unityのダイナミック シェーダー ロード、シェーダー分岐の削減などです。

「私たちは独自のカスタムIPreprocessShadersストリッピング実装を使用しました。これにより、すべてのシェーダーからシェーダーキーワードをグローバルに削除し、Unity Asset Storeのシェーダー制御によるローカルアプローチを採用しました」とHutchison氏は言います。「シェーダーでキーワードを使用するタイミングをより意図的に設定できたことも大きな利点でした。」

同社のシェーダーはShader Graphを使用しました。Shader Graphには、Unityによって事前定義されたキーワードが本質的に含まれており、これに追加のキーワードを追加することで指数関数的な効果をもたらしました。一部のロジックをダイナミック ブランチにスワップしたり、キーワードを完全に削除したりすることで、総バリアント数が大幅に削減されました。

「これらの方法をすべて組み合わせることで、ランタイムシェーダーバリアントのメモリを平均100 MB以下に削減できました」とHatchson氏は言います。「Unity の Project Auditor も使用しました。これはビルド内のすべてのアセットと設定のグローバルビューを提供します。これを Memory Profiler と組み合わせて使用し、インポートプリセットの改善によってメリットが得られるテクスチャとメッシュを特定しました。これにより、アートアセットやオーディオのメモリ使用量がさらに削減されました。」

受賞を祝い、今後の展望

10年以上にわたり、UnityとHardlightはスタジオが信頼を置くテクノロジーの共有レイヤーを構築してきました。Macan氏は次のように述べています。「10年前にUnityで制作したゲームは今でもサポートしています。

Unityは長年にわたって多くの機能を追加しており、同スタジオはUnityのAPIのネイティブ コードをいくつか削除することでメンテナンスを簡素化したと彼は述べています。「Unity は低レベルのデバイスサポートの多くに対応しているので、実際のゲームの制作に集中できます。テクノロジーが進化する中、Unityがそれに追いついていくのに役立つと確信しています」と彼は絶賛します。

Sonic Dream Team なら、古いハリネズミに新しいテクニックを教えることができます。また、Sonic と同様に、Hardlight と Unity にも強力な実績と明るい未来があります。

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

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