受託型開発会社が実現する3DゲームのQA自動化~去年からのアップデートと千里の道を踏破するBot開発～

受託型開発会社が実現す る3DゲームのQA自動化 ~去年からのアップデートと千里の道を踏破するBot開発～ 2023年8月24日 株式会社テックフラッグ 山中亮 & 間世田剛志

自己紹介 山中 亮 株式会社テックフラッグ Game Development Sect. Engineering Manager 兼 Technical Product Manager 複数の開発会社でゲームプレイプログラマーとして 主にバトルpartの新規/運営開発を経験 2021年テックフラッグ入社 ゲーム開発の自動化チームに参加しつつ、Engineering Managerとして 組織ビルディング・チームビルディングを行う ゲームAI全般好き 01

自己紹介 間世田 剛志 株式会社テックフラッグ Game Development Sect. エンジニア 2022年に株式会社テックフラッグへ入社。 ゲーム開発の自動化チームに参加し、 取り組みの中ではコリジョンチェック等を自動化するBotの開発を行っています。 02

テックフラッグについて 2020年設立 NJホールディングス100%子会社 ※NJHDは「ゲームスタジオ」「トライエース」「ウィットワン」などのゲーム開発会 社をグループに持つデベロッパー集団 外 部 開 発 会 社 AIなどの最先端技術を用いてグループ内外のゲーム 開発やソフトウェア開発の自動化・効率化のためのソフ トウェアを研究・開発を行う 03

このセッションを聞いて得られるもの • 受託型開発会社で共通基盤となるQA自動化の取り組みを進める事例 • 開発チームと協力してQA自動化を実現する事例 • NavMeshを使わずにMapを踏破するNavigationアルゴリズムの知見 04

注意事項 • UnrealEngineの用語が頻出します • 対象プロジェクトが非公開タイトルのためサンプルゲーム の環境を作成し、スライド中の画像は全てサンプル環境の モノになります ※出典：ランドスケープマウンテン（Epic games） https://www.unrealengine.com/marketplace/ja/product/landscape-mountains 05

• https://www.unrealengine.com/marketplace/ja/product/landscape-mountains

アジェンダ • 去年の振り返りと去年からのアップデート • バグの再現方法の明確化 • • クラッシュレポーター • アラートレポート 自動テストでのインゲームプレイ時のバグ検知 • 独自のNavigationSystemについて • コントローラ入力で動作するBotによるコリジョンチェックテスト • 今後の展望 • まとめ 06

去年の振り返り 07

昨年までに作成した機能 1. 2. 3. 4. ワープBotによる自動負荷計測テスト アラートレポート クラッシュレポート RuntimeProfiler 08

システムアーキテクチャ 09

自動負荷計測テスト 計測項目 • • • • • fps CPU処理時間 Render Thread Time GPU処理時間 物理メモリ使用量 010

クラッシュレポーター UEには標準のクラッシュレポーターがあり、それを用いて PC環境専用の クラッシュレポーターの作成をすることにした 拡張したクラッシュレポーター機能 • • • • • コールスタックなどが記録されたXml 設定ini Logファイル Dumpファイル クラッシュする瞬間のスクリーンショット（FrameGrabber ） • クラッシュする瞬間の座標やゲームの状態を保持した 独自レポートファイル 011

Runtime Profiler • メモリ状況の可視化 • Load済みUClass/UPackageの一覧表示 • CPU/GPUの負荷Summary 012

アラートレポート 検知方法 FOutputDeviceを用いてWarningや Errorを検知 一度Serverへ送信したものを記録し同 じモノは送信しないようにフィルタする 情報の集約 AlertレポートはIssue単位で集約 収集する情報は以下の通り • • • • • ChangeList PC環境 LevelName 座標 スクショ（※機能停止状態） 013

去年時点での課題 • 「自動負荷計測テスト」がまだ活きる状態ではない 今のテスト結果から、具体的にどうアクションを起こせばいいのかの情報が足りない Runtime Profilerと組み合わせてより具体的な情報を取る自動テストが必要 • 探索と検知にコストをかけているが再現方法がわからないケース が多い クラッシュレポートやアラートレポートにより修正するべき内容は把握しやすくなったが、それを再 現するための情報が足りない • 自動で修正タスクを作成し高速で修正フローを回す必要がある 自動でタスクを作成するには担当者を判別しなければならない それに加え優先度判断などの仕組みづくりが必要 • 自動テストでインゲームプレイ時のバグ検知が出来ていない 自動でマップを徘徊したり、戦ったりするテストを作成しなければならない 014

去年からのアップデート 015

開発体制 プラットフォーム PC＆家庭用ゲーム機 ゲームエンジン UnrealEngine4.27～5.1 チーム人数 2ライン体制（SVE1名、CLE5名） 決定権 ゲーム開発チームとは独立した裁量 016

去年からのアップデート内容 去年までで自動QAテストの基盤は出来たが、まだ簡易的な機能が多く、実践的ではなかった部 分もあった 去年までの課題を踏まえて、テックフラッグでは大きく2点に注力を行った • バグの再現方法の明確化 去年時点では、クラッシュレポートやアラートレポートは発生した現象はわかったが、その経緯などの情報はなかった この状態だと修正タスクを投げられた担当者が何から調べればいいのかわからないというケースが多発した このため、クラッシュレポートやアラートレポートの機能改善を行った • 自動テストでのインゲームプレイ時のバグ検知 去年あったのはワープBotだけだったが、マップ上をユーザと同じ入力で自由に歩く踏破Botを開発しコリジョンチェックテストを行うこ とでインゲームプレイ時のバグを検知へ 017

バグの再現方法の明確化 018

クラッシュレポート 019

Issue単位での集計 当然ながら、クラッシュレポートは同じ原因によるレポートが多く送信されてくる その際バグ調査を行うときに困るポイントが発生していた • なにか大きな不具合が発生した際に一斉に送信されレポート一覧画面が埋まってしまう • 他にも異なる状況下で発生していたのか、どのVersionから発生しているのかわからない これを回避するために、アラートレポートと同様にIssue単位でまとめるように対応した Issue判定はCallstackとBuildConfigなどで判定を行っており、数値やPathなどはマスクすること により1文字違いのCallstackなども同一のIssueと判定できるようにしている 020

Issue単位での集計 021

クラッシュ時の動画添付 クラッシュの瞬間の直近30秒前を常に録画しておき、それをクラッシュ時にmp4ファイルを生成 出力先はクラッシュレポートのディレクトリにすることで自動でSentryへ送信されるようにした 今回私たちが挙げた動画撮影機能の要件は以下の5点 1. 動作が軽量であり、ゲームプレイの邪魔にならない ゲームプレイを常に録画し続けるため、明らかに動作が重くなるようでは使うことができない 2. 出力されるファイルのサイズが小さいこと Sentryには送信されるデータサイズが20MB以下であることが求められているため、高解像度でデータ容量が大きい動画ではダメ 3. 常に一定期間の録画データのみを保持しencodeできること 一定時間前までのデータを保持していつでも動画としてencodeできるようになっている必要がある 4. EditorのPIE、Win向けROMの双方で動作すること ROMで動作するだけではなくクラッシュする際の多くはEditorで確認中になることが多いためEditorのPIEでも録画できることが必要 5. Gamethreadがクラッシュしていてもencodeすることができる クラッシュ時にはGamethreadは破壊されているため、Gamethreadでしか動作しないような設計はNG 022

クラッシュ動画添付のために独自の録画プラグインを作成 録画機能はEngineの提供のものや、マーケットプレイスなど既存の録画機能を検証したが、どれも様々な 事情で本件の要件を満たさなかった そのため、テックフラッグでは要件を満たす動画撮影プラグイン「StreamRecorder」を独自に作成しそれを 用いることで解決をした StreamRecorderはHardwareEncodersとGameplayMediaEncoderというUE5のAPIを利用して開発されている それに伴い、Engineに以下のような修正を加えた • 起動オプションによりHardwareEncodersの機能自体を無効化する機能の追加 DDCビルドを行っているとエラーが頻出した。DDCビルド中は無効にして問題ないので無効にできるようにした • GameplayMediaEncoderのキャプチャ対象を指定ビューポートに制限する修正 録画機能で利用しているGameplayMediaEncoderにおいて、画面キャプチャを行うViewportをあらかじめ指定したもののみに限定した これを行わないとエディタ内のすべてのViewportをキャプチャしてしまうため 023

アラートレポート 024

アラートレポートのCallstackを表示 アラートレポートではOutputLogで表示されるメッセージ内容とChangeListやPC環境はわかるが、そもそもどういった内容のアラートなの かメッセージだけではわかりにくいアラートが数多くあったため、各アラートのCallstackを追加する対応を行った 今回求められる要件は以下 1. 2. 3. 既存のUE_LOGの動作を妨げない 1frameで大量のワーニングなどが発生しても大きな負荷をGamethreadへ与えない アラートを収集しているFOutputDeviceから直接の参照関係にないCallstackを取得できること 独自のCallstack管理クラスを追加 UnrealEngineのCallstackを作成する機能ではこれらを満たすことはできなかったので、独自のCallstack管理クラスを追加する必要があ った Callstack管理クラスはEngineのクラスであるFPlatformStackWalkを用いながら、Callstackをアプリケーション側から任意に取得できる仕 組みとした この仕組みのおかげで、各アラートのCallStackを取得してもヒッチが起きるようなことはなくCallStackを取得することができるようになっ た 025

アラートレポートのCallstackを表示 026

改善を行ったうえでの実績 去年 クラッシュレポート アラートレポート 検知数 131件(※1277件) 628件 作成した修正タスク数 12件 50件 クラッシュレポート(Issue) アラートレポート 検知数 1033件（※14432件） 8457件 作成した修正タスク数 70件 360件 今年 ※Ensureなどを含めた件数 027

去年からの課題への取り組み • バグの再現方法の明確化 • 自動テストでのインゲームプレイ時のバグ検知 028

自動テストでの インゲームプレイ時のバグ検知 029

独自のNavigationSystemについて 030

独自のNavigationSystemとは プレイヤーの周囲の情報を収集する事で、事前情報なしで経路探索用のマップ を作成・訂正を行い、コントローラの入力によって移動する テスト用のNavigationSystemである 031

なぜ独自のNavigationSystemを作成したのか ゲームと求められるものが異なる為、通常のNavigationSystemだと不満があった • 地形のテストも行うため、地形ついて事前に設定できず、事前情報なしで実行できる必要がある • 人間が操作した場合と同様に、コントローラ入力で移動して欲しい • 自然な移動をすることが目的ではなく、人間の操作の範囲で問題が発生するか調べる事が目的 UEのNavigationSystemの改造を避けた理由 • 別環境へ容易に移せるようにしたいため、エンジンの改造は避けたい • テスト用の仕組みで、本番には使用しない為、ゲーム側へ影響は最小限にしたかった • 目的が異なる為、改造するにしても新規に実装する部分が多くなる 032

独自のNavigationSystemのデモ 033

独自のNavigationSystemの仕組み 経路探索用マップを生成し、そのマップを元に経路探索を行っている ※経路探索にはA*を使用している 経路探索用マップはグリッド状になっており、各セル毎に８方向に対して、移動可否、 移動にジャンプが必要かなどを記録している。 経路探索用マップ生成には、以下の３種類の方法を用途別に使い分けて使用している • Raycastを使用して、高低差情報を取得し生成 • Raycastを使用して、深度情報を取得し生成 • Playerを動作させて、移動可否を確認して生成 034

経路探索用マップ生成 経路探索用マップ生成方法 • Raycastを使用して、高低差情報を取得し生成 • Raycastを使用して、深度情報を取得し生成 • Playerを移動させて、移動可否を取得し生成 035

経路探索用マップ生成：高低差情報から生成 屋外を得意とする手法で、上から見た場合に重なっているものが少ない場合に有効 全体を一度に生成する事ができる 生成手順 1. 経路探索用マップの各セルに対して、上からRaycastし高度を収集し、高さマップを生成 2. 高さマップをPlayerサイズを考慮した高さマップに変換する 3. Playerサイズを考慮した高さマップから、傾斜角やジャンプして届く高さか等で移動可能か判 定し、経路探索用のマップを生成 036

経路探索用マップ生成：高度情報から生成のデモ 037

経路探索用マップ生成方法 経路探索用マップ生成方法 • Raycastを使用して、高低差情報を取得し生成 • Raycastを使用して、深度情報を取得し生成 • Playerを移動させて、移動可否を取得し生成 038

経路探索用マップ生成：深度情報から生成 室内など閉鎖空間を得意とする手法で、ジャンプ等の考慮が難しいが、 移動可能な場所が立体交差しなければ、使用できる方法 生成手順 1. Playerの周囲にRaycastを行う、Rayが通過した地点には空間があり、Rayが衝突した地点に は障害物があるとして、マップに記録 2. １.で作成したマップを元に、Playerサイズを考慮して変換する事で、マップを作成 3. Playerサイズを考慮したマップから経路計算用のマップを生成 039

経路探索用マップ生成：深度情報から生成のデモ 040

経路探索用マップ生成 経路探索用マップ生成方法 • Raycastを使用して、高低差情報を取得し生成 • Raycastを使用して、深度情報を取得し生成 • Playerを移動させて、移動可否を取得し生成 041

経路探索用マップ生成：Playerの移動可否から生成 実際にPlayerが移動した際の移動可否を利用する為、精度が高い 一方で構築に時間がかかる為、長距離移動には向いていない手法 生成手順 1. 2. 3. 4. 全ての場所を移動可能として経路探索用マップを初期化 目的地に向かって経路探索を行い移動 移動できない地点があれば、場所・方向を経路探索用に移動不可として記録 目的地に到達できるまで、２と３を繰り返す 042

経路探索用マップ生成：Playerの移動可否から生成のデモ 043

NavigationSystemまとめ 良かった点 • ジャンプをして障害物を乗り越える経路や、落下する事を前提とした経路など、経路生成の ルール設定が比較的容易でコントローラ入力での動作の再現が行いやすい • テストで使用するデータ構造とNavigationSystemが使うデータ構造を揃えた事で、実装がし やすく、動作の確認が行いやすい 044

NavigationSystemまとめ 課題 • 経路探索用マップの精度不足 • 本来は移動できる場所、移動できない場所を、誤って検出する問題がある • コントローラ入力での移動の課題 • コントローラ入力で、狙った経路通りに移動させる事は難易度が高く精度に課題がある 課題の改善案 • 経路探索用マップの精度不足 • 収集した情報を収集した位置などから補正を行う事でグリッドを細かくせずに精度向上を目指す • コントローラ入力での移動の課題 • Playerの旋回半径を考慮させる等、移動の制約を行える手法を取り入れ精度向上を目指す 045

コントローラ入力で動作するBotによる コリジョンチェックテスト 046

コリジョンチェックテストとは 一般的な定義（おそらく） • • • • マップ上を正常に通ることができるか 一度入ったら抜け出せなくなるようなデッドスポットがないか コリジョンが抜けてすり抜けるような場所がないか コリジョンが過剰に張られて浮いてしまっている場所がないか ※デッドスポットとは 地形にハマる、地形に引っかかってスタックする、といった一度入ったら抜け出せなくなり他の場所へ移動できなくなる 場所をデッドスポットと呼んでいる 047

コリジョンチェックテストとは 一般的な定義（おそらく） • • • • マップ上を正常に通ることができるか 一度入ったら抜け出せなくなるようなデッドスポットがないか コリジョンが抜けてすり抜けるような場所がないか コリジョンが過剰に張られて浮いてしまっている場所がないか ※デッドスポットとは 地形にハマる、地形に引っかかってスタックする、といった一度入ったら抜け出せなくなり他の場所へ移動できなくなる 場所をデッドスポットと呼んでいる 048

コリジョンチェックテスト画面 以下の二つを確認する事ができる • マップ上を正常に通ることができるか • ヒートマップでの表示 • デッドスポットがないか • • • ヒートマップ上のピンと、問題個所一覧に表示 デッドスポットへ入る経路 Excel形式でダウンロード 049

コリジョンチェックテスト画面：デッドスポット表示詳細 デッドスポット表示詳細 デッドスポットを確認しやすくするための機能 • • • ヒートマップ上にピンを立てる スクリーンショットを表示 デッドスポットへ入る経路を表示する デッドスポットを管理しやすくするための機能 • Excel形式でダウンロードできる 050

コリジョンチェックテスト画面：デッドスポット表示詳細 デッドスポットのExcelファイル 検出したデッドスポットの管理しやすくするために、 Excelファイルでダウンロードできる 051

コリジョンチェックテストの分割と並列実行について コリジョンチェックテストは一度にマップ全体を実行 するわけではなく、 幾つかの範囲に分割した上で実行し、結果表示の 際に結合して表示している Doing これは、テスト範囲が広くなると経路探索用のマッ プ等も大きくする必要があり、テスト時間が長くなる ため分割している この分割されたテストは、複数並列して実行するこ とで、 テスト時間の短縮を行っている 052

コリジョンチェックテスト全体の流れ テストの流れ 1. マップ上を正常に通る事ができるかの検証 2. デッドスポット候補の算出 3. デッドスポット候補の検証 一度に様々な判断を行おうとすると、テストがあまりに複雑になりすぎる為、 三段階に分けてチェックを行っている 053

コリジョンチェックテスト全体の流れ テストの流れ 1. マップ上を正常に通る事ができるかの検証 2. デッドスポット候補の算出 3. デッドスポット候補の検証 054

マップ上を正常に通る事ができるかの検証 指定したテスト範囲の移動可能な場所全てに移動させる事で検証 具体的には、範囲全体をグリッド上で管理し、全てのセルに到達できるように Playerを移動させ、正常に到達できた場所を記録 また、到達が難しいと判断した場所は、二重チェックを行っている こちらの移動を行うのに、独自のNavigationSystemを使用して行っている 開けた場所では、高低差から生成する手法を使用し、 屋根があるような場所には深度情報から生成する手法を使用している 055

マップ上を正常に通る事ができるかの検証：動作デモ 056

コリジョンチェックテスト全体の流れ テストの流れ 1. マップ上を正常に通る事ができるかの検証 2. デッドスポット候補の算出 3. デッドスポット候補の検証 057

デッドスポット候補の算出 テスト開始位置の移動可能面積と、各箇所の移動可能面積を比較する事で、 デッドスポットらしさ（デッドスポットレート）を求め、この値が一定値以上の場合 にデッドスポット候補とする デッドスポットレート = 1.0 - (移動可能面積 / 開始地点の移動可能面積) 058

デッドスポット候補の算出：詳細 デッドスポットレート算出の具体的なステップ 1. 相互に移動できる場所を１つのグループとして、テスト範囲全体をグルーピング • • 2. 各グループ毎に移動可能面積の計算 • 3. 理想的にはグルーピングした結果は、３つグループ（デッドスポット・移動可能・移動不可能）になるが、テストの 範囲はマップ全体よりは狭い為、範囲外を経由してつながっている等が発生する為、細かく分割される NaivgationSystemの経路探索用マップを使用して、相互に移動できるか判定 NaivgationSystemの経路探索用マップを使用して、移動可能範囲を計算 開始地点と各グループの移動可能面積から、デッドスポットレートを計算 • • 開始地点から移動可能な場所の中で計算している為、開始地点の移動可能面積を基準にしている 式：1.0 - (移動可能面積 / 開始地点の移動可能面積) ※開始地点から到達できない場所は、Playerが到達不可能な場所であるため、候補から除外する 059

デッドスポット候補の算出：詳細 ①上から見た地形 ②地形の高低差 ④相互移動できるグループ ③経路探索用マップ ⑤デッドスポットレート 060

コリジョンチェックテスト全体の流れ テストの流れ 1. マップ上を正常に通る事ができるかの検証 2. デッドスポット候補の算出 3. デッドスポット候補の検証 061

デッドスポット候補の検証 デッドスポット候補の地点からPlayerを移動させて脱出を試み、 脱出ができない事を確認する 具体的なステップ 1. デッドスポット候補の位置にPlayerをテレポートさせる 2. デッドスポット候補以外の場所を目指して移動を試みる • 誤差を抑える為、デッドスポットから一定値以上離れた場所を指定している 3. 到達できた場合、デッドスポットでないと判定 到達できない場合、デッドスポットであると判定 ※Playerの移動可否から経路探索用マップを生成する方法を使用して、脱出経路の探索と移動を行っている 062

デッドスポット候補の検証：動作デモ 063

コリジョンチェックテストまとめ 今後の課題 • テスト範囲の境界で精度が低下する 実績 導入プロジェクトA テストした面積 8.4㎢ 検出したデッドスポットの数 216件 導入プロジェクトB 16㎢程度の面積のMapを複数マップ 定期実行して数百件のバグ報告を提出 ※プロジェクトごとにアルゴリズムを一部変更しているので参考値 • 境界線上にあるデッドスポットなどは、テスト範 囲外を考慮しなければ正しく判定できない • 立体的交差のある地形に弱い • 洞窟や建物の中など立体交差のある地形の場 合、デッドスポットを検出できない場合がある 課題の改善案 • テスト範囲の境界で精度が低下する • テスト範囲より広い範囲の情報でテストを行う事 で改善できるが、テスト時間が肥大化する為、テ スト時間との兼ね合いになる • 立体交差のある地形に弱い • NavigationSystemの立体交差対応を行う 064

去年からの課題への取り組み • バグの再現方法の明確化 • 自動テストでのインゲームプレイ時のバグ検知 065

今後の展望 066

今後の展望 • コリジョンチェックテストの非対応部分への対応 メッシュすり抜けなど多発しそうな問題への対応 • 踏破Botを用いたE2Eテストやバグ再現・修正確認の自動化 Mapをある程度自由に動けるようになったことで自動テストの幅が広がった 067

まとめ 068

実現できたこと • 検出したバグの再現性向上のための機能 追加 ⇒クラッシュレポートをIssue単位で収集 ⇒クラッシュレポートに動画を追加 ⇒アラートレポートにCallstackを追加 ⇒修正タスク件数が大幅に増加 • 踏破Botを用いたコリジョンチェックテスト の実現 ⇒マップ上を正常に通ることができるか ⇒デッドスポットの検出 ⇒検出座標への経路表示 ⇒検出結果をExcelでDL ⇒2つのプロジェクトで稼働実績あり 069

千里の道30歩目へ To be continued… ば昇よ僕 かりうた り始やち めくは た 070

質疑応答 • 検出したバグの再現性向上のための機能 追加 ⇒クラッシュレポートをIssue単位で収集 ⇒クラッシュレポートに動画を追加 ⇒アラートレポートにCallstackを追加 ⇒修正タスク件数が大幅に増加 • 踏破Botを用いたコリジョンチェックテスト の実現 ⇒マップ上を正常に通ることができるか ⇒デッドスポットの検出 ⇒検出座標への経路表示 ⇒検出結果をExcelでDL ⇒2つのプロジェクトで稼働実績あり 071

Appendix 072

実際の質疑応答 Q：踏破Botを用いたコリジョンチェックテストはUE上で構築したもの？ A：UE上でプラグインとして作成しており、ゲーム側とは独立している Q:踏破Botでの到達可能性のテストでは、マップ全体を塗り潰す必要性があると思うが、確実に全グリッドを網羅する、あるいは塗りつぶ し効率を上げる方法は何か行っているか？ A:新しく塗り潰せる場所がなくなった際に完了となるが、その前に一度開始地点に戻して再度塗り潰せる場所が無いか確認を入れている 。 効率化に関しては、精度とのトレードオフだが、Playerのサイズより広い範囲を到達したとみなす事で高速化している。 Q：コリジョンチェックテストBotに関して、ドアといったアクションが必要な地形はどうしている？ A:現状の対応しているタイトルでは不要であったため非対応。ただジャンプといったものと同じように対応できる Q：Playerの移動方法によるマップ生成に関して、スピードハック的な方法でアプリケーションを高速に動かす事で高速化できないのか？ A：行っているが、これを原因とした不具合も考えられるので、３倍程度が限界と考えている Q：去年の時点でもテスト時間がかかるので、複数台でテストしたいとしていたが、今回のテストも時間がかかりそうだが、現状はどのよう になっているのか？ A:複数のPC、マルチプロセスで実行できるようにしている、一つのプロセスで実行しようとした場合は導入プロジェクトAで8.4㎢が５日か かってしまった 導入プロジェクトBで20プロセス並列させ、16㎢を12時間前後（マップによってさまざま）で踏破できるようになっている。 PCをたくさん用意すれば並列して高速化できるようになっている。 073