LLMを用いたゲームQA機構でコスト79%削減！ ｜MISTROGUEのQA自動化事例
Polyscapeでは、自社タイトル「MISTROGUE：ミストと生けるダンジョン」の開発において、AIを用いてオートプレイと異常検知を行い、自動でゲームQAを行うQA機構を作成していました。
本日から、「Polyscape QA Tech Lab」というQAサービスが公開されましたが、MISTROGUEでの自動QA機構の開発の経験がそのサービスのコアになっています。なぜコンテンツ事業を営んでいたPolyscapeがそのようなサービスを展開するのかといったことは代表によるこちらの記事で書かれていますが、本記事では、QA Tech Labの第一号事例として、MISTROGUEにおけるQA自動化の取り組みをご紹介します。
課題
MISTROGUEはスキルとその組み合わせによる爆発的なシナジーが特徴の３D見下ろし型ローグライクですが、本開発期間が6ヶ月（2022/10 ~ 2023/4, 本開発期間前から1,2人で制作はされていましたが、全員フルタイムで開発が開始をした期間は6ヶ月）というかなり短い期間で開発されました。そのため、開発当初は全く問題にならなかったものの、開発が進んでいくにつれて以下のような原因でリグレッション（巻き戻り）が多発したという問題がありました。
短期開発ゆえに、長期の堅牢性より短期のスピードを重視した設計になっていた箇所が多かった
スピードを意識して、コードレビューベース・プルリクエストベースの運用を行っていたわけではなかった
スキルの数と種類が増加して、ロジックや相互依存関係が複雑化していった
開発中盤ということもあり、真っ当なテストを書くのは現実的ではない状態であったので、実装側にインジェクションするテストコードではなく、テストコードをインジェクションするパターンでのテストと、オートプレイによって定点観測的に異常検知を行えるQAプラグインの開発を開始しました。
AIによる自動QAプラグイン
基本的な動き
一般に、基本的なテストを行う機構としては単体テストも複合テストも以下のようになっていると思います。
この一般的なケースを、複雑な3Dゲームに適応するには以下の課題があります。
依存関係と正しく整理できてなければ、循環参照でTestが書けない
一つの実装しかないものを、Testの為にInterfaceとして保守しなければいけないものが増える
テスタビリティを意識したコード設計をする必要がある
単体テストをしっかりしたい場合、DummyのInterfaceの実装が沢山必要になるので、Dummyだらけになりテスト自体の信頼性が下がる
良いゲームの為に仕様変更を嫌わない姿勢を取るとInterfaceレベルでの変更が良く起こる
また、MISTROGUEで導入しようとした固有の問題として、Assemblyが分かれてなく依存関係が複雑だったという物もありました。
そこで、直接的な参照を持ったテストを行うのを辞めてゲームコード側からデータ送信を行い、実際のテスト条件はコード外のデータとして管理し、GUI上から設定出来るようにしました。コード外で扱うことによって実際に実装するエンジニア以外が条件設定を付けることが出来るようになり、仕様依頼者がデータ設定をすることで、タスク毎のQAコストを下げることが出来ました。
テストの条件（Validation）は以下のようなもので、初期段階はプレイヤーのステータスや座標など、内部的に数値として表せることについて「これが必ず成り立っているはずである」という条件を記載します。
また、全てのValidationは、ScriptableObjectとJSONの両方のパターンで記述出来るものになっていて相互に互換性があります。以下はJsonの例です。
{
"class": "FloatDataConditional",
"data": {
"Key": "Player.Hp",
"Operation": 1,
"Value": 0.0
}
}このような仕組みで、以下のようなロジック的なリグレッションを検知することができます。
「敵・プレイヤーのステータス値がいかなるときもマイナスにならない」
「ボスのカウントダウンタイマーは、ボス踏破で止まる」
「生ける洞窟クリア後、フェリル遺跡が開放する」
「拠点移動時点ではHPが必ずMAXである」
「プレイヤーのY座標が - 10以下になることはない」
「ダメージの表示数字と、プレイヤーのHPの減少量が一致している」
「百戦錬磨 第一の道で、ボス以外は経験値が入らない」
また、Validationの条件（Conditional）はInterfaceとなっており、追加の実装をするだけで安易に追加出来るようになっています
public interface IConditional
{
bool IsSync { get; }
bool IsTrue(DataReceiver dataReceiver);
Task<bool> IsTrueAsync(DataReceiver dataReceiver);
string ToReadableString();
}Jenkinsとオートプレイによる自動異常検知の実現
ゲームコード側にはログのような形で、多数のDataSend が含まれており、Playerのステータスや座標といったValidationに必要なパラメータをValidator側に送信していました。DataSendがパフォーマンスネックにならないように、リリース時は完全に無効化出来るように作りました。
最終的に、Jenkinsから呼び出されるオートプレイによって、常に最新のものが正しく動いているかチェックされ続ける環境にして、問題があった場合Slackで名指しメンションをすることで死にシステムにならないようにしました。テストのプレイログと共にレポート自体もCSVで保存してJenkins上でArtifactとして保存されます。
オートプレイ機構は、人間が一度プレイしたデータをレコードし、その通りに実行するという形でプレイが実行されます。MISTROGUEはダンジョンの地形アイテムドロップにランダム性があるゲームではありますが、ダンジョンの生成SEEDを固定することで、実質レコードした状態を再現することができました。
Jenkinsからビルドが実行されるたびに社内の端末にビルドが降ろされ、オートプレイが実行され、実際にチュートリアルダンジョンやメインダンジョンでオートプレイテストが走っていて、専用のSlackチャンネルに結果が送信されるようになっていました。
想定通りワークしてくれた部分も多くありましたが、うまくいかない部分もありました。
DataValidationが複雑
送られてくるデータ量が増え続けて、適切にValidationの条件を設定するのに知識が必要。うまく活用してくれる人と、活用してくれない人が居た。
見た目に関するチェックが出来ない
MISTROGUEでは、「スタン状態のときにスタンモーションが再生されなくなる」「HPが減ったときにピンチを示す赤枠が出なくなる」といったリグレッションが生じたが、このようなモーションやエフェクト等が本当に正しく再生されているかは、人間が見た目で判断しなければわからない
サウンドに関するチェックが出来ない
DataValidationが複雑な問題： LLMで自然言語からValidation作成
そんな苦労をしていた中、ChatGPTのAPIが公開されて自然言語からDataValidationが作成できると思い実装しました。結論としては、プロンプトを工夫して情報を与えることによって大体正しいDataValidationを作成することが出来ました。
具体的には以下のようなフローを用いて、自然言語からJSON形式のDataValidationを作る事が出来るようになっています。
1.「RootgarSceneに入った瞬間は、PlayerのHPが常に100%である必要がある。」というテキストを打ち込んで、生成ボタンを押す
2. GPTに内容を送信して、返答をJson形式で受け取る
{
"class": "TriggerConditional",
"data": {
"Trigger": {
"class": "StringDataConditional",
"data": {
"Key": "ActiveScene",
"Operation": 0,
"Value": "RootgarScene"
}
},
"Conditional": {
"class": "FloatDataConditional",
"data": {
"Key": "Player.HpWeight",
"Operation": 3,
"Value": 1
}
}
}
}3. JsonからScriptableObjectの形に変換します
体感的には、実装されているDataValidationで表現できるものであれば，7~8割くらいは正しい結果を返してくれるという精度でした。これにより、複雑なDataValidation設定を出来る人が増えて、元々設定できる人の時短にも役立ちました。ChatGPTがサンプルを沢山作ってくれる状況になったので、DataValidationを作るラーニングの始めとしても機能して、元々余り活用してくれない人もChatGPTが生成したDataValidationをベースに変更して使えるようになるという副作用もありました。
将来的には、普段の開発QAやデバッグ会社がQAですでに用いている項目書といったものをCSV形式でまとめて取り込んで、一挙にValidationを作成するという流れを実現できれば、他のチームやプロジェクトにおいてもほぼオンボーディングコストゼロで導入が可能になります。
見た目に関するチェックが出来ない問題： LLMの画像認識を用いたValidationを作成
突然ですが、以下はMISTROGUEのゲーム内の1カットです。
HPが一定以下になると画面端が赤くなって、警告をする演出が存在しています。
ChatGPTにこの画像に対して「HPが減ると画面が赤くなるんだけどなっとるか？」と聞いてみるとどのように返ってくるでしょう？
このような形で、視覚的にしか判断出来ない情報をある程度的確に説明してくれます。
このブラウザでやっていることを、ChatGPTのAPIを利用してチェックすれば見た目に関するチェックが出来ない問題が解決出来るのでは？と考えました。実際にチェックする機構を実装してみたところ、比較的良い精度で検知してくれました。
GptVisionDataConditionalというものをConditionalのひとつとして実装して、チェックする内容、Triggerの条件が整った後にディレイしてスクリーンショットを撮影出来るようになっています。
このようにChatGPTを利用したエラーチェックも組み込むことにより、通常のコード上でのテストでは出来ないレベルでチェックすることが可能になり、飛躍的にPolyQAの信頼性が上がりました。
この形式により、以下のようなテストケースのチェックが可能になります。
「初めて生ける洞窟をクリアしたときに、『フェリル遺跡が解放した』旨の解放メッセージが表示されている」
「フェリル遺跡クリア後のメッセージスキップ後、街に遷移している」
「エクスポーション使用後、緑色のエフェクトが表示されている」
「ボスを討伐後、金色の宝箱が1個でている」
もちろん、この GptVisionDataConditional も、前述の機構により「HPが30%以下になった0.1秒後に、ゲーム画面が赤くなっているかをチェックして」といった自然言語から作成することができます。
金銭面とコスト削減成果
こんなにChatGPTのAPI叩いて、常に動かし続けてたら金銭面で問題にならないか？という話になると思うのですが問題にはなりませんでした。
自然言語からのDataValidationの作成
動かさないといけない回数が少ないので問題にならない。
そもそも、１回あたり約6円ほどで安い。 500のテスト項目を作成しても、3000円ほど。
VisionAPIによる異常検知
こちらに関しては、コミット毎に動かすには少しコストが高かった
テスト項目として 237件、VisionAPIを使うところがあった
１回あたり$0.0155 (2.33円)なので 1ワークフロー辺り552.21円
マイルストーンの切り替わりや、リリース前に数回動かす事で回数を節約した
そもそも常に問題は起きないので、頻度を下げても十分に期待通りワークしていた
一般にテスト会社に頼むと、この237件のテスト項目の項目作成（テスト設計）に約5万円、実際にテスターを動かしてプレイするのに約20万円といったコストがかかりますが、自動で実行する場合、テストの実行自体にはAPI費用とオートプレイを動かす端末の電気代程度しかかからないため、約2,200円ほどとなり、理論上約99%のコスト削減が可能となります。テストの設計・項目の作成は依然として人間の手が必要なため、全体としては約79.2%のコスト削減が実現可能ということになります。
今後の展望について
ここまでいくつかの機能を実装してきましたが、まだ改善点も多く残っています。
オートプレイの質と対応力の向上
レコードベースのオートプレイなので、実装が追加されたりするとオートプレイが頻繁にうまく動かなくなってしまっていました。実際にはそういった保守が大変なので、開発途中からはほとんどTutorialダンジョンのみを自動テストしていました。
また、レコードプレイはいろいろなゲームに対応できる汎用性はあるものの、網羅性がなく、レコードしたシナリオしかテストができないという問題があります。
オートプレイに関しては、今後レコードベースだけでなく、BehaviorTreeを使った乱数にも対応できるものや、細かいルールを入れなくとも強化学習を用いて汎用的にプレイできるという物、言語モデルで行動決定を行うといったものの検証を進めていこうと考えています。
サウンドやモーションに関するチェック
「スタン時にスタンモーションが再生されているか」という部分はMISTROGUEでも頻繁にリグレッションが起こっていた箇所ですが、モーションに関しては静止画像だけでは誤判定が起こることもしばしばでした。また、サウンドに関して、変に爆音になってないか、逆に変に小さすぎないか、スキルに音が割りあたっているか、といった部分に関しては画像認識では判断ができないという問題があります。
先日のOpen AIのSoraの発表もありましたが、AIのマルチモーダル化が急速にすすむ中で、ChatGPTのような大規模言語モデルが動画と音声を扱えるようになる未来はそう遠くないと考えています。実際に、Audio-Visual LLM for Video Understanding (Fangxun Shu et al, 2023) といった論文もでているように、音声データと動画データを扱えるLLMの研究も2023年末にかけて進み、2024/2/16には1時間以上の動画をインプットとして推論タスクを行うことができる Gemni 1.5 Pro がGoogleから発表されました。大規模言語モデルが動画や音声を扱えるようになれば、GptVisionDataConditionalに近い仕組みでモーションの判定やサウンド判定なども行っていけるようになると考えられます。
DataSend組み込みの簡素化
現在の仕組みでは、Validationに必要なデータをDataSendという形で送信するコードをプロダクトに組み込む必要があります。この送るデータを増やしていけば増やしていくだけValidationのカバレッジを上げることが可能ですが、それだけDataSendのコードを増やしていく必要があります。
理想形は、人間と同じように画面情報のみからインプットを得て行動を決定するという、プロダクトコードとの癒着がゼロのValidation機構です。
前述の赤い画面エフェクトの例でも、GPTの出力をよく見ると画像からHP値を正しく判定していることが読み取れますが、このようにLLMを使うことによって画面情報のみからゲームのパラメータ情報を得ることは可能であると考えられます。そのような実験も行いましたが、まだ実用レベルで精度・レスポンスタイム・コストの面で現在のLLMの性能がネックになっている部分は大きいので、今後の性能向上に期待をしています。
Polyscape QA Tech Lab を開始します
Polyscapeは、このようなQAに関する知見を社内とどめておくのはもったいないという考えから、QA自動化機構を武器としたゲームQAサービス「Polyscape QA Tech Lab」を2024年2月より開始しました。
このサービスでは、専門の人のデバッグチームによるゲームデバッグと、PolyQAを用いた自動化ソリューションを組み合わせたゲームQAソリューションを提供しています。
人によるデバッグサービスを基本としつつ、今回紹介したようなAI連携を通常のデバッグサービスの価格内で行うというサービスを通じて、AI連携機能の改善を行っていき、最終的に、汎用的に動作する完全自動型のAI QAソフトウェアを開発していこうと考えています。
これにより、インディー開発チームや小規模の事業者でも利用できる価格帯のQAサービスを提供したり、WEBサービスのような1週間レベルの短いリリースサイクルをゲームでも実現できるようにしていく、というような「QAの変革によりゲームリリースをより自由にする」という質的な変化をつくっていこうと考えています。
このようなAI機構を自社サービスにも組み込みたい、リグレッションに困っているのでなんとかしたい、とにかく安くQAをしてほしい、こういったQA機構を一緒に作っていきたい、というゲーム開発者の方がいましたら、ぜひPolyscape QA Tech Lab よりお問い合わせをいただければと思います。
今ならサービス開始記念として特別割引キャンペーンも実施しています！一緒にゲーム開発の未来を作っていきたいという方、ご連絡をお待ちしています！（ちなみに資金調達中でもあるので、VCの方のご連絡もお待ちしております！）
また、本日弊社代表の島田から今回の事業展開に込められた想いに関する公開されました：
PolyscapeがゲームQAサービスを開始しました | エンジンとコンテンツの二刀流で目指すPolyscapeの事業ビジョン
なぜコンテンツを作っていたPolyscapeがゲームQAエンジン事業を開始したのか、これから何を目指していくのか、といったことを書いていますので、合わせてこちらの記事も御覧ください。
サービス利用や提携資金調達に関するお問い合わせ：
代表取締役 島田寛基 （hiroki.shimada@polyscape.io）
この記事が気に入ったらサポートをしてみませんか？