Article by: Ivan Tustanivskyi
あなたのUnrealゲームはエラーゼロの状態でリリースできたとしても、それだけで優れた体験になるとは限りません。戦闘中のスタッター、大型ボス戦での急激なフレームレート低下、マルチプレイヤーでのラバーバンディング。これらはいずれもクラッシュとしては現れず、Sentry にも表示されません。そのため、実際にプレイヤーが現場で何を体験しているのかを把握する手段がありませんでした。少なくとも、これまでは。
Unreal Engine には、ゲームパフォーマンスを測定し、実行時統計を収集するためのツールがすでに豊富に用意されています。しかし、そのデータはすべて開発者のマシン内に留まったままでした。
Unreal SDK の新しい自動パフォーマンスメトリクス機能は、このギャップを埋めます。FPS、フレーム時間、ネットワーク状態、そのほか一般的なゲームテレメトリを直接 Sentry に送信することで、どこでパフォーマンスが低下しているのか、どのハードウェアで発生しているのか、どのプレイヤーに影響しているのかについて、チームが実用的なインサイトを得られるようになります。Release & Health と組み合わせれば、各リリースが時間経過とともにパフォーマンスへ与える影響も追跡できます。
本題に入る前に、一点だけ触れておきます。すべてのゲーム開発者は、これまでに一度はプロファイラを使ったことがあるでしょう。自動パフォーマンスメトリクスはそれとは異なるものですが、関連するツールです。両者は同じ問題を異なるレイヤーから扱います。メトリクスは「どこでゲームが遅くなっているか」を見つけ、プロファイリングは「なぜ遅くなっているのか」を説明します。
Sentry が現在追跡するもの
現在、Unreal SDK は、全体的なパフォーマンスへ影響するいくつかの主要領域について、メトリクスを自動インストルメントします。対象には、フレーム時間、ネットワーク、ゲーム固有の統計などが含まれます。
フレーム時間
ゲームが快適に感じられるかどうかを最も直接的に示す指標です。フレーム時間は、「各フレームの処理にエンジンがどれだけ時間を使ったか」を示します。また、スレッドごとに分解することで、どのサブシステムがボトルネックになっているかを確認できます。
- 平均FPS
- 総フレーム時間
- ゲームスレッド処理時間
- レンダースレッド処理時間
- GPUフレーム時間
ゲームスレッド、レンダリングスレッド、GPUの処理時間を比較することは、CPUがボトルネックになっているのかGPUがボトルネックになっているのか、そしてどのチーム（ゲームプレイ、レンダリング、コンテンツ）が修正を担当すべきかを判断する古典的な方法です。
FPSメトリクスの例（GPU別にグループ化）
ネットワークインサイト
マルチプレイヤーのパフォーマンスは、接続品質によって成否が決まります。しかし、クラッシュレポートだけではその状態を把握できません。これらのメトリクスによって、パケットロス、レイテンシ、帯域不足が、気づかれないまま体験品質を低下させていないかを確認できます。
- 送受信帯域幅
- パケットスループットとパケットロス
- クライアントの ping と jitter
- アクティブ接続数
サーバービルドではさらに、ロードシェディング分析のために、クライアントごとの平均 ping、クライアントごとの帯域幅、飽和状態の接続数も取得できます（ネットワークメトリクスの完全な一覧を参照）。
これらのメトリクスは、マルチプレイヤーセッションがアクティブな間のみ存在します。ネットワーク機能を持たないシングルプレイヤーゲームでは、ここにデータは送信されません。また、一部の値はクライアント専用（ping、jitter）、あるいはサーバー専用（アクティブクライアント数、接続飽和）です。
Pingメトリクスの例
ゲーム統計
フレーム時間の内訳だけでは説明できないヒッチの原因を把握する際に役立つ、エンジンレベルのシグナル群です。
- アクティブな UObject 数
- プロセスが使用している物理メモリ量
- ブロッキングGC停止時間
GC の間で UObject 数が継続的に増加している場合、それは典型的なリークの兆候です。また、それを GC 停止時間と関連付けることで、リークがいつプレイヤー体験へ悪影響を与え始めたのかを特定できることがあります。
フレーム時間とは異なり、これらの値はより低頻度でサンプリングされます。メモリ使用量とオブジェクト数は60秒ごと、GC停止時間は各GCサイクル終了後に送信されます。これらの値は変化が比較的遅いため、フレーム単位で取得しても無駄なスループットになるからです。
使用メモリメトリクスの例（プラットフォーム別にグループ化、コンソールのみ）
パフォーマンスメトリクスのサンプリング
毎フレームごとにメトリクスを送信すると、それ自体がオーバーヘッドになります。それを避けるため、SDK は固定間隔でサンプリングを行います。フレーム時間や FPS のようなフレーム単位メトリクスでは N フレームごとに1回、メモリ使用量やネットワーク状態のように変化が遅いメトリクスでは N 秒ごとに1回データポイントを送信します。デフォルト設定は保守的になっており、プロジェクトごとに調整可能です。
- 60 FPS 環境で、フレーム時間は1秒あたり約2サンプル
- ネットワーク関連は10秒ごと
- ゲーム統計は60秒ごと
単一クライアント単位で見ると、このサンプリングは疎になります。サンプリング対象外のフレームで発生したヒッチは記録されません。しかし、多数のプレイヤー全体で集計すると、分布は実際の状況へ収束します。重要なのは、「RTX 3050 環境における p95 フレーム時間はどれくらいか」であって、「開発者のノートPC上のフレーム #47312 がどうだったか」ではありません。より高い解像度が必要であれば、サンプリング間隔を短くするだけです。
メトリクス属性
FPS の集計値だけでは、多くのことは分かりません。重要なのは、それをどのように分解するかです。GPU別、プラットフォーム別、レベル別などです。すべての自動メトリクスにはコンテキスト属性が付与されており、それによってこうした分析が可能になります。
- GPU モデル名
- CPU コア数
- 物理RAM総量
- 画面解像度
- 現在のゲームマップ／レベル名
さらにメトリクスには、リリースバージョン、OS、そして重要なものとして、そのメトリクス送信時に発生していた trace ID も含まれます。この点こそが、Sentry 上のメトリクスを単独の監視ツールと分ける特徴です。ダッシュボード上でフレーム時間スパイクを見つけたら、そのサンプルをクリックすることで、その瞬間の完全なトレースへ移動できます。そこでは、同時に記録されたエラーや span も確認できます。
たとえば、FPS（game.perf.fps）を GPU（gpu.name）単位でグループ化すれば、「RTX 3080 のプレイヤーと RTX 3050 のプレイヤーは、実際にどれくらいの FPS を体験しているのか」という問いに、1回のクエリで答えられます。グループ化を OS（os.name）へ切り替えれば、Xbox、PlayStation、Switch 間でメモリ使用量を比較できます。
ぜひ試して、次に必要なものを教えてください
自動パフォーマンスメトリクスは、Unreal SDK 1.11.0 でデフォルト有効になっています。エンジンバージョン要件や高度な設定については、Unreal SDK メトリクスドキュメントを参照してください。自動メトリクスは、デスクトップ、コンソール、Android で利用可能であり、iOS 対応も近日予定されています。
自動パフォーマンスメトリクスを有効にしたビルドをリリースし、数セッションほど動作させてみてください。それだけでも、ハードウェア差異、フレーム時間パーセンタイル、ネットワーク状態などから、修正すべき問題がすでに見え始めることがあります。
また、この機能はまだ実験段階です。次に何を計測するべきかは、まだ決まっていません。「このシグナルも取得してほしい」というものがあれば、Unreal SDK リポジトリに issue を作成してください。それが、この機能の方向性を決める最良の方法です。
質問やフィードバックがありますか？
- Discord で会話に参加してください
- gaming-updates@sentry.io までメールしてください
Sentry をまだ使ったことがないですか？
Original Page: Monitor Unreal Engine Game Performance with Application Metrics
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
