受託型開発会社が始める3Dアクションゲーム開発効率化のためのQA自動化への道のり~千里の道も一歩から~

受託型開発会社が始める 3Dアクションゲーム 開発効率化のための QA自動化への道のり ~千里の道も一歩から~ 2022年8月25日 株式会社テックフラッグ 山中亮

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

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

このセッションを聞いて得られるもの • 受託型開発会社でQA自動化を進める場合の知見 • 新規開発タイトルの初期からQA自動化を進める際の知見 03

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

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

アジェンダ 1. 受託型開発会社のジレンマ 2. 求められるQA自動化 3. 取り組みの軌跡 自動負荷計測テスト クラッシュレポート 最適化サポート Runtime Profiler アラートレポート 4. QA自動化による途中経過Resultと今後の課題 5. まとめ 05

受託型開発会社のジレンマ 06

自社開発型と受託開発型の主な違い 自社開発型 受託開発型 開発する ある程度ジャンルは ゲームジャンル 決まっている 全く決まっていない 開発体制 自社で主導権を握っている 自社に主導権はなく 関係各社との協議が必要 開発人員 同じ主要スタッフ 異なるスタッフ • プロジェクトごとの異なる事情・人員により共通基盤への投資ハードルが高くなる • 共通基盤の開発人員がゲーム開発のタスクを割り当てられてしまうリスク 全てのケースでこの表に当てはまるわけではないが 自社開発型と比較すると受託開発型はプロジェクトを跨いだ共通基盤を開発しにくい傾向にある 07

受託型開発会社のジレンマを解消する 受託開発型 開発する 全く決まっていない ゲームジャンル 開発体制 自社に主導権はなく 関係各社との協議が必要 開発人員 異なるスタッフ • 3Dアクションゲームであれば動作するQA自動化の仕組みを開発する 汎用的な機能群によりプロジェクトを問わず適用できるようにする • QA自動化チームのみで意思決定を行う ゲーム開発チームからは独立することで複雑な座組からは切り離す • ゲームのソースコードには介入しない設計にする ゲーム開発側の人員事情には左右されずアップデートし続けることを可能にする 08

共通基盤開発に専任する組織としてのテックフラッグ • グループ内外の各開発会社と密接に連携しつつも 独自の判断で開発を進めることができる組織 取り組むべき 共通基盤 高品質化が著しい家庭用ゲーム機向けの 3Dアクションゲームの汎用的なQA自動化 外部 開発 会社 ゲーム品質の底上げ 09

求められるQA自動化 010

求められるQA自動化 制約 • 様々なプロジェクトに対応できるようにするため、UnrealEngine上で動作させる • ゲームアプリケーション側のソースコードに変更や対応が必要な実装はしない • Engineのソースコードに変更を加えるのは避ける。避けられない場合は最小限にとどめる 汎用性の高い機能群 • • • • • fpsが低下するような場面がないかどうか ユーザのストレスとなるような要素がないかどうか クラッシュした時の情報収集 人力で見つけて特定するのは困難なバグの発見 プレイには影響はされないが、解消するべきWarningなどの検知 バグ情報の収集と発生検知に焦点を絞る 011

千里の道の果て （不具合修正のフェーズと想定する機能群） 修正依頼 修正対応 修正確認 クラッシュレポート 集約した 情報の閲覧 現象の自動再現 自動修正確認 自動徘徊Bot ゲーム内情報収集 タスク管理 ツール対応 リプレイ機能 デグレ確認 負荷計測 エラー検知 担当者＆ 優先度判定 簡易Profile 仕様に沿わない 現象の検知 自動タスク割当 不具合の 探索 不具合の 発見 自動テスト環境 まずはこの部分に注力 012

取り組みの軌跡 013

開発体制 プラットフォーム PC＆家庭用ゲーム機 ゲームエンジン UnrealEngine4.27.0/5(対応中) チーム人数 エンジニア4名（サーバ1名,クライアント3名） 決定権 ゲーム開発チームとは独立した裁量 014

開発体制 クライアントエンジニアチーム サーバエンジニアチーム キャラクターアーティストチーム ディレクター ・ ・ ・ 自動化チーム 015

最新のシステムアーキテクチャ 016

開発初期～中期 017

自動負荷計測テスト 018

自動負荷計測テスト 開発経緯 開発初期のため、仕様が固まっていないため以下の2点を最初に確立するべきと考えた • • テストの実行～インゲーム開始までの動作フローの確立 キャラクターがマップ内を自動で移動する方法の確立 開発チームから影響を受けづらい「マップの負荷計測」を 毎晩自動テスト 019

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

マップ内の移動方法の模索 プレイヤーキャラクターを移動させるキャラクター操作Botが必要 1. NavMeshを使用したBotを作成する 当初は1で試していたが、本タイトルにはプレイヤーキャラクター用のNavMeshは仕様上 存在せず、このためだけの保守が必要となってしまったためオミット 2. コントローラーパッドの入力で動作するBotを作成する 本来は2が望ましいがこの時点でゲーム仕様が変更となる可能性や開発工数を考えると 適していないと判断 3. キャラクターを無理やり座標移動（ワープ）するBotを作成する ワープBotを作成することに 021

ワープの仕方
Raycast（LineTraceSingleByChannel）

Hit!
Next Location!

"args" : {
"warpTraverse":{
"areaMinX": -200000,
"areaMinY": -200000,
"areaMaxX": 200000,
"areaMaxY": 200000,
"gridNumX": 32,
"gridNumY": 32,
"rotationNum": 1,
"profilingTime": 1.0,
"traverseType": "Hilbert",
}
}

ステージ

022

自動負荷計測テストのアーキテクチャ 1. 2. ユーザorJenkinsがテスト開始 する テストエージェントがゲームプ ロセスを実行 3. ゲーム上でテストを実行 4. ゲームのログ情報を受付 5. ① ① ③ ③ ⑤ ③ テストコンソール上から 結果を確認 ④ ② 023

動作デモ 024

実行結果デモ 025

想定されるNext Action 1. テスト用PCを複数台用意して同時に並列に対応する オープンワールドのような広いマップでテストを行うと1回のテストに大きく時間を消費し てしまうことを解決する 2. 本来ユーザが届くはずのない場所にもワープしているので 事前に計測するべき範囲を定める ユーザが到達するはずのない箇所を測定しても意味はないので、時間短縮につながる 3. より詳細な負荷計測のための値を収集する 最適化や課題発見によりダイレクトにつながる値を用いる 4. ワープをせずに実際にキャラクター動かしてマップを踏破する ワープだと実際のユーザと同じ移動方法を行うことで より実際のプレイに近いテストを行う 026

千里の道 進捗 不具合の 探索 DONE! 自動テスト環境 修正依頼 修正対応 修正確認 クラッシュレポート 集約した 情報の閲覧 現象の自動再現 自動修正確認 ゲーム内情報収集 タスク管理 ツール対応 リプレイ機能 デグレ確認 エラー検知 担当者＆ 優先度判定 仕様に沿わない 現象の検知 自動タスク割当 不具合の 発見 ちょっと 自動徘徊Bot DONE! ちょっと DONE!負荷計測 簡易Profile 027

クラッシュレポート 028

クラッシュレポート 開発経緯 納品が迫っていたがQA会社様に発注などはしておらず、開発チームのプランナーがクラッシュ を見つけ次第手動で状況をまとめてプログラマへ修正依頼を出していた 自動化チームでは以下の点をクリアするためのクラッシュレポート機能を独自に作成することで プランナーの負担と担当プログラマの負担を軽減することを目指した • 自動でクラッシュが発生した際のインゲーム内情報を収集/作成する • 集めた情報をServerへ送信し、担当プログラマはWebブラウザを閲覧するだけでそれらの 情報を一覧化できる 029

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

UE4のクラッシュレポーターを拡張へ 独自のレポートファイルの中身 • • • • • • • • ブランチ名 ChangeList 実行プラットフォーム GameVersion EngineVersion UserName 実行環境スペック（グラボなど） ゲーム内の座標や角度など 031

Sentryへ集めた情報をフックして一覧化 クラッシュレポーターが収集した情報はUE4に対応しているSentryへ SentryのAPIやWebhookを利用し情報を自社サーバへ収集 ※Sentryとは エラー監視サービス UE4,Unityのようなゲームエンジ ンだけでなく様々なライブラリや 言語に対応している 032

Unreal Engineに改修を加えた部分 • 独自のデリゲートイベントを追加 UnrealEngineにはクラッシュした時に 呼ばれるイベント「OnHandleSystemError」があるが これはクラッシュ直後にCallされる Callされた後に生成されるディレクトリのPathを取得する方 法がデフォルトだと存在しないため 独自のデリゲートイベントを作成し、そのイベントに ゲーム内情報ファイルやスクショ画像を生成する処理を追 加した クラッシュ発生 OnHandleSystemError ディレクトリ作成 DumpFile、XML 生成 ディレクトリ作成 デリゲートイベント クラッシュ レポーター起動 033

クラッシュレポート一覧画面 034

クラッシュレポート詳細画面 035

詳細画面から直接対応タスク作成へ 036

千里の道 進捗 不具合の 探索 不具合の 発見 修正依頼 自動テスト環境 DONE! クラッシュレポート 集約した DONE! 自動徘徊Bot DONE! ゲーム内情報収集 タスク管理 DONE! 情報の閲覧 ツール対応 負荷計測 エラー検知 担当者＆ 優先度判定 簡易Profile 仕様に沿わない 現象の検知 自動タスク割当 修正対応 修正確認 現象の自動再現 自動修正確認 リプレイ機能 デグレ確認 037

開発中期～現在 038

最適化サポート 039

最適化サポート 自動化チーム 開発チーム どのような負荷計測の指標を 開発チームが 望んでいるのか把握が難しい 開発フェーズの移り変わりの中 どのようなFeedbackをすればいいのか 解決策 自分達が最適化に関わることで改善点や足りない機能を把握へ ゲームアプリケーション側のソースコードは余り把握できていないため 直接ソースコードを変更したりすることは極力控え、現在のボトルネックの調査や その対処方法をまとめて担当者へタスクを依頼するようなやり方を選択 040

実施したサポート内容 • 一部最適化の実施しその最適化フローの提案 • ボトルネックの特定と今後の最適化手順の策定 • 各Platformにおける快適なPerformanceの条件調査 見つかった課題 負荷計測の環境がバラバラで気軽且つ一覧化できるような仕組みがない CPU GPU メモリ Unreal Insight Nsight Graphics, Render Doc MemPro, Memory Profiler2など ※Stat系のコンソールコマンドでも参照できるが情報の整理が必要だった 041

Runtime Profiler 042

Runtime Profilerの目的 想定する効果 非エンジニアでも簡易的に指標となる負荷の値を確認することが可能になる 考えられる応用 自動負荷計測テストと組み合わせることで より具体的な負荷計測テストを行えるようにする データ取得元 UnrealEngineが提供しているAPIの範囲内で取得し必要な情報のみを抽出・加工する Ex) Stat系、HealthSnapshot、LLMなど 043

Runtime Profilerの構造 Runtime Profiler Unreal ImGui,ImPlot(※) Runtime Profiler Core Unreal Engine FPlatformMemoryStats, FHealthSnapshot, FLowLevelMemTracker etc… ※Unreal ImGui(https://github.com/segross/UnrealImGui) ImPlot(https://github.com/epezent/implot) 044

プロト版 045

メモリ状況の可視化 メモリのシンプル表示モード。使用メモリが10GBに近づくと黄色になり超えると赤になる LLMで 取得できる 値一覧 消費メモリの カテゴリー別内訳 カテゴリーの内訳 MeshとTextureに対応 046

Load済みUClass/UPackageの一覧表示 Count数は重複してしまってい るがおおよその内訳を表示で きる 047

CPU/GPUの負荷Summary • CPU summary 各threadでどのくらい処理 時間がかかっているかを 折れ線グラフで可視化 • GPU summary DrawCallsの割合を 帯グラフで可視化 ※Stat機能のDrawCallsの値は NsightなどのProfileツールの値と 異なるが割合は信用して良い 048

千里の道 進捗 修正依頼 修正対応 修正確認 クラッシュレポート 集約した 情報の閲覧 現象の自動再現 自動修正確認 自動徘徊Bot ゲーム内情報収集 タスク管理 ツール対応 リプレイ機能 デグレ確認 負荷計測 エラー検知 担当者＆ 優先度判定 仕様に沿わない 現象の検知 自動タスク割当 不具合の 探索 不具合の 発見 自動テスト環境 DONE! 簡易Profile 049

アラートレポート 050

アラートレポートとは？ 定義 ゲーム中に発生したWarningやAssertionなどのクラッシュこそしないものの 修正するべきインシデント この時点のワークフロー 目指すワークフロー 発見方法 リードエンジニアが気づいたら ゲームプレイ時に自動検知 情報の集約と対応 スプレットシートに情報を 書き込む 自動でサーバへ送信 051

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

アラートレポートIssue一覧画面 新しく発生したモノはメールでお知らせ 053

アラートレポートIssue詳細画面 054

千里の道 進捗 不具合の 探索 不具合の 発見 修正依頼 修正対応 修正確認 現象の自動再現 自動修正確認 リプレイ機能 デグレ確認 さらに 自動テスト環境 クラッシュレポート 自動徘徊Bot ゲーム内情報収集 負荷計測 簡易Profile DONE! エラー検知 仕様に沿わない 現象の検知 集約した DONE! 情報の閲覧 タスク管理 ツール対応 担当者＆ 優先度判定 自動タスク割当 055

QA自動化による 途中経過Resultと今後の課題 056

QA自動化による途中経過Result 自動負荷 合計182回実行 計測テスト クラッシュレポート アラートレポート 検知数 131件(※1277件) 628件 作成した修正タスク数 12件 50件 ※Ensureなどを含めた件数 057

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

今後の課題 修正依頼 修正対応 修正確認 クラッシュレポート 集約した 情報の閲覧 現象の自動再現 自動修正確認 自動徘徊Bot ゲーム内情報収集 タスク管理 ツール対応 リプレイ機能 デグレ確認 負荷計測 エラー検知 担当者＆ 優先度判定 簡易Profile 仕様に沿わない 現象の検知 自動タスク割当 不具合の 探索 不具合の 発見 自動テスト環境 NextActionとしてはこれらの機能群へ着手 059

まとめ 060

まとめ • 自動負荷計測テスト テスト自動化の基盤の構築 マップ全体の定期的な負荷計測により修正するべき座標の検討がつくように • クラッシュレポート 手動で収集していたクラッシュ情報を自動で収集、一覧化することで QAチームの修正タスク作成コストを軽減 • 最適化サポート 最適化フローの提案と最適化をするための課題の発見 開発するQA自動化ツールの参考にした • Runtime Profiler 誰でも簡単に負荷を計測することができるツールの提供 • アラートレポート QAチームでは見つけづらく、リードエンジニアが収集にコストをかけていたアラートを自動 で収集、一覧化 061

所感 • QA自動化の基盤となりえる一連のシステムは構築できた • まだ手動で行っている部分（対応するべきタスクの選別など）を 自動化する必要がある • 収集した情報を元にさらなる発展の手ごたえを得られた • 千里の道１０歩目くらいはいけた 062

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

質疑応答 • 自動負荷計測テスト テスト自動化の基盤の構築 マップ全体の定期的な負荷計測により修正するべき座標の検討がつくように • クラッシュレポート 手動で収集していたクラッシュ情報を自動で収集、一覧化することで QAチームの修正タスク作成コストを軽減 • 最適化サポート 最適化フローの提案と最適化をするための課題の発見 開発するQA自動化ツールの参考にした • Runtime Profiler 誰でも簡単に負荷を計測することができるツールの提供 • アラートレポート QAチームでは見つけづらく、リードエンジニアが収集にコストをかけていたアラートを自動 で収集、一覧化 064

発表中に出た質問 Q.自動負荷テストのマップは、地図アプリのようなTileMap等で作られているのでしょうか？またそこはどのように更新 がかけられているのでしょうか？ A.その通りです。地図自体はLeafletというライブラリで構築されており、UE上でマップのタイルマップ画像を生成しそ れを手動でサーバへアップロードしています。マップの更新自体が高頻度ではないので手動で行っています。 Q.指定位置からレイを飛ばしてヒット位置にワープと言う方法だとダンジョンや建物内に対応しづらいように思えるの ですが、そういう場所でも負荷計測は出来るのでしょうか？ A.自動負荷計測テストを作成した時点で、屋内のエリアはかなり限定的だったので、屋内は考えなくてもOKとしました 。ただ、今後正確に計測するのであればワープではなく、コントローラパッドの入力で動くBotなどが必要になると思い ます。 Q.誤検知や誤認識などは、発生しなかったのでしょうか また重複してIssueが発行されないような仕組みなどはある のでしょうか A.現在クラッシュやアラートに関しては誤検知などは見受けられていません。Issueに関してはルールベースで判定し てIssueが重複しないようにはしています Q.今後、インゲーム側のQAテストを一部自動化するにはどのような方針がありますでしょうか A.2段階必要だと考えています。マップを自由に踏破するBotと対戦を行うAIが必要です。後者に関しては強化学習 などを用いて作成できないか考えています 065

発表中に出た質問 Q.収集した情報は開発者に能動的に見てもらったのでしょうか。メールで通知ということでしたが見落としなどはなか ったのでしょうか？ A.はい、能動的に見てもらっています。定例も行っていますのでそこでも今の状態を見るようにしています。 Q.負荷計測に関しては、マップ単体というよりも、NPCや敵の数、バトルによるエフェクト状況などの影響が大きいかと 思います。現状としてはそのあたりは手動プレイして計測でしょうか？今後の自動化の課題でしょうか？ A.認識の通りエフェクトなどの影響が大きいと考えています。よって、次の課題として対戦AIなどを用いてよりリアルな テストを行う必要があります Q.クラッシュレポートやアラートレポートは件数が多くなると、確認などのコストがかかるかと思いますが 回避策や対 策などはあるのでしょうか? A.自動で修正するタスクの選別し自動で作成するという仕組みの構築が必要だと考えています。 Q.千里の道の一歩がかなり速い印象だったのですが、開発に携わった方の人数や時間はどの程度だったのでしょう か？ A.開発人員は4人です。期間は2年となっています。 Q.聞き逃していたら申し訳ございませんが、オンプレとクラウドの分け方はどのような指標だったのでしょうか？ A.明確に分けているわけではないのですが、Jenkinsやテストエージェントについてはクラウド化のコストが高かった のでオンプレになっています。将来的には全てクラウド化をしたいと思っています。 066

Appendix 067

開発期間や使用したライブラリ 開発期間：2年程度 QA自動化システムの横転する場合： 今できているモノを他プロジェクトへ適応させる場合は1～2週間程度 地図ライブラリ：Leaflet 068

自動負荷計測テストのワープ時の座標決定方法 次にレイキャストを実行し移動可能な座標か調べる際にはヒルベルト曲線を用いている 理由は以下 • 大きな座標移動をしなくてよい • 大きなマップを計測した際に複数のロード領域を跨がずに済む ただし、本来はこのようなことをせずともユーザが使用するべきところを巡回するべきであり 現時点の実装はこの時点での妥協ラインを探った結果である 参考画像出典：ヒルベルト曲線(Wikipedia) https://ja.wikipedia.org/wiki/%E3%83%92%E3%83%AB%E3%83%99%E3%83%AB%E3%83%88%E6%9B%B2%E7%B7%9A 069

• https://ja.wikipedia.org/wiki/ヒルベルト曲線