【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～
•
5 likes•3,557 views
Developers Summit 2019【15-C-4】太田様の講演資料です。
Recommended
Recommended
More Related Content
More from Developers Summit
More from Developers Summit (20)
【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～
- 2. 目次 • スクウェア・エニックス テクノロジー推進部のご紹介 • ゲームのQAとAI for QA • 事例 • 確率表示確認ツール • 排出率確認ツール
- 5. ｜メンバー構成 • 60名以上の非常に国際的なスタッフ • エンジニア、リサーチャー、アーティスト、テクニカルアーティスト • 非ゲーム産業や学術界出身のメンバーもいます ｜ミッション • ゲーム関連技術の研究開発（R&D） • 技術デモ、論文などの発表 • ゲーム制作の支援 • 先進的なゲームの機能 • 効率的なツールとワークフロー • 新しいマーケットの開拓 • 技術と知見の共有 Advanced Technology Division, 2018
- 7. ゲームのQA • ゲームが正しく動くことを保証する • 当たり前品質 (後述) • 他の分野と同じく比較的容易 • ・・・だが量が膨大 • ゲーム固有 • データ＞ロジック • ゲームが面白いことを保証する • 魅力品質 (後述) • 定義が難しい
- 8. 参考：狩野モデル • 当たり前品質 • 不充足だと不満、充足されて当たり前 • 地味だが満たしていないと致命的 • 一元的品質 • 不充足だと不満、充足されると満足 • 工業製品のグレード (機能、素材、容量) • ゲームではあまりない • 魅力品質 • 不充足だと仕方ないが、充足されれば満足 • ゲームでは非常に重視 出典：https://www.juse.or.jp/departmental/point02/08.html
- 9. ゲーム内AIとゲーム外AI ゲーム内AI （内部 = コンテンツ） メタAI キャラクター ナビゲーション ゲーム外AI （外部 = 開発、現実世界）
- 10. ゲーム外AI • 開発支援 • PCG (Procedural Content Generation, 手続き型コンテンツ生成) • QA • データ検証、静的コード解析、自動プレイ、チート検出、チャットボット • インタフェース • ジェスチャー認識、音声認識
- 11. AI for QA • 当たり前品質 → 本講演ではここにフォーカス • データ検証 • コリジョンチェック • 自動プレイ → 研究と業界でホット • 魅力的品質 • AIエージェントによるチューニング → モバイルタイトルでホット
- 12. ガチャのテストの種類と担当 • タイトルごとの開発会社様が担当 • 画面や実機を使用しないシミュレーターによる排出率の正しさの確認 • マスターデータで定義されている確率通りに排出されるか • スクウェア・エニックスが担当 • お客様から見える最終的な確率の保証 • 実機＋ステージング環境で実施 • 確率表示確認 • 実機に表示されているアイテムと確率がマスターデータと一致しているか • 排出率確認 • 実機で所定の回数ガチャを回したときにマスターの確率分布と近似しているか • 各アイテムは少なくとも1回本当に排出されるか
- 13. 事例
- 14. 確率表示確認ツール
- 15. テストの内容とツールの説明 • テスト内容 • 実機の画面キャプチャにある確率表示とマスターデータを突き合わせる • ツールによる支援 • OCR (Google Vision API) により画面キャプチャを読み取り、マスターデータと 自動的に突き合わせる • C++, Qt, OpenCV • 参画時に既に現行バージョンのツールが開発・運用を実施中
- 16. 参画前に思っていたツールのアーキテクチャ ～AIといえば深層学習～ タイトルのフォ ント タイトルのフ レーズ 転移学習 学習済み OCRモデル 画面キャプチャ マスターデータ 判定 判定結果 1. フォントが自前であることが多い 2. キャラクター名やアイテム名は 普通の日本語辞書にはない
- 17. 参画時の現状把握
- 18. 判明した事実 • Google Vision API • Pros • SaaSとして提供されるOCRとしては日本語の認識精度は高い • 1実行当たりの認識のコストが安い • 最初の1,000ユニットまで無料、その後も格安 • 参考 : https://cloud.google.com/vision/pricing?hl=ja • Cons • OCRの機能は現状転移学習を提供していない • 画像分類に関してはAutoML Visionが提供されている • 転移学習 • モバイルのタイトルは外部委託(外部開発会社様)が多い • 学習のためのフォントやフレーズを自動で入手することは難しい
- 19. 現行バージョンを触ってみた感触 • フォント • 作りこんでいることが多い • →認識精度が落ちる • キャラクター名やアイテム名 • 辞書にあるような言葉ではない • →辞書にある名称に誤認識される • レイアウトや背景 • 文字と背景のコントラストが低い場合があ る • そもそも読み取れない 注：アイテム名と確率はタイトルのもの ではなく、仮データです
- 20. ヒアリングと仮説による課題 • 作業フロー • ツールの自由度が高いため、OCRの認識がうまくいかなかったアイテムに対 する作業がガチャ検証担当のスキルに依存していた • この結果タイトルによってはツールを利用することで逆に合計作業時間が増 えてしまうことがあった • 使い方 • UIが英語のみだったため、簡易的なマニュアルをガチャ検証チームで作成して いた • 日本語のUIでかつツールの提供側から公式に標準的な作業フローのガイドがあ るとありがたい
- 21. 改善の目標 • ツールを使った場合のワークフローの明確化 • ある程度標準的なフローを確立し、標準的なガチャ検証担当であれば迷わず使えるようにする • ツール上での作業の完結 • OCRで正しく認識できなかったアイテムも含め、ツール上で確認作業を完結できるようにする • 最後に結果だけExcelにコピペすれば十分なようにする • 適用タイトルの拡大 • OCRの認識率の問題でツール適用外だったタイトルでもトータルの時間でツールを使った方が作業時間 が減れば、適用対象になる可能性がある
- 23. 実際に取り組んだ改善 • 日本語化 • UIの日本語化 • 日本語マニュアルの充実 • 下記の機能を使った標準ワークフローをステップバイステップで解説 • UI/UXの改善 • リンク／アンリンク機能 • 誤った行マッチングの解除、再度の結びつけをできるようにする • フィルター機能 • アイテム名で絞り込めるようにする • ステップ機能 • 各ステップでできる操作をあえて制限し、目的の操作にたどり着きやすくする
- 24. 実際のツール画面で解説 1. リンク／アンリンク 2. フィルター 3. ステップ
- 25. 参考：既に改善済みな機能 3. Google Vision APIへのパラメータ制御 2. 反転やグレイスケール化 1. 認識領域の設定 4. マッチングの並列実行
- 26. 改善効果 • Pros • 元々ツールとの適合性が高かったタイトル • 過去バージョンと比較したツールを使った 場合の時間 • 最大1/3まで削減 • 全手動との実行時間の差 • 1/3から1/4 • OCRの認識率が90%を超えると上記に近づ く • Cons • UI/UXを改善しても、OCRの認識率が70%を下 回る場合、全手動で実行した方が早い • UI/UXを改善しても、ツールとの適合性が高 いタイトルがまだ限定的 • Next Action • 行間を空けることにより認識率が高まるタイ トルがあるため、前処理で行間を追加する • Vision APIの縦横2,000ピクセルの制限に引っ かかって、ツール対象外となっているタイト ルがあるため、行の区切りで2,000ピクセル以 下に画像を分割する前処理を追加する
- 27. 排出率確認ツール
- 28. テストの内容とツールの説明 • テスト内容 • ステージング環境において、実機でガチャを回し、マスターにあるアイテム が本当に排出されることを確認する • ツールによる支援 • 自動テストツールのAirTestによって、実機でガチャを回し、画面キャプチャ • OpenCVで画面キャプチャからアイテムのクリッピング、分類 • Python, AirTest, OpenCV
- 29. 実現可能性と運用可能性の検討 • 実現検討 • タイトル0 • 同時に同じカードが出た場合まとめられるため、クリッピングの難易度が高い • カードの分類数は少ないため、分類は容易だと予想できる • 実運用検討 • タイトル1 • カードの分類数が非常に多くかつ、似て非なるカードが多い • タイトル2 • カード間で背景が重複しており、映り込んだカードに対する考慮が必要
- 30. 再び最初に考えたツールのアーキテクチャ ～AIといえば深層学習～ 転移学習 学習済み モデル 画面キャプチャ 判定と分類 分類結果 お手本分類
- 31. 確率表示確認で既に分かった事実 • 転移学習 • モバイルのタイトルは外部委託が多い • →そもそも事前に教師データは入手できない • →学習を前提にはできない • →学習なしの既存のアルゴリズムを使う必要がある
- 33. タイトル0による実現検討結果 • Pros • 機械学習なしの特徴量比較のみで分類できそう • 実は、分類数が非常に少なかったための誤認 • 教師データやお手本分類がなくても分類できそう • 同じく、分類数が非常に少なかったための誤認 • Cons • クリッピング(AirTestのキャプチャ画面からカードの切り取り)はタイトルごと に実装のカスタマイズが必要
- 34. 課題に出てくる用語 • 特徴量 • 物体の形、色の強さ、色の変化などを分析対象の画像の特徴を表す数値 • OpenCVではベクトル (A-Kazeだと列が61要素の2次元ベクトル) • 画像の解像度に(大きく)依存しない • 異なる解像度間の画像でも特徴量の比較によって、似ているかを検証できる • 誤分類 • 別とみなしてほしい画像(カード)を同じだと判断してしまうこと • 過分類 • 同じとみなしてほしい画像(カード)を別だと判断してしまうこと • 誤分類と過分類はトレードオフであり、誤分類を減らそうとすると過分類が多くなる
- 35. 誤分類と過分類のイメージ • 誤分類 • 過分類 距離A 距離B こう分類してほしい こうなってしまう こう分類してほしい こうなってしまう
- 36. タイトル1による実運用検討からの課題 • 背景 • 実運用検討タイトルのタイトル1の特徴 • 1. 同じ形で色違いのカードがたくさんある • 2. スクリーン座標の最終処理でポストエフェクトがかかっている • 現状のアルゴリズムの課題 • 3. 前から順番に分類を決定しているため、分類の端と比較されてしまう可能性がある • 4. 特徴量の単純平均による比較のため、形の違いと色の違いが同じ1つの条件につぶされてしまう • 課題 • 特徴量比較の閾値を上げる • 実用的でないレベルまで過分類が発生する • 過分類が多すぎて手動の方が早い • 閾値の条件を下げる • 実用的でないレベルまで誤分類が発生する • 結局全部の分類フォルダを見て再分類しないといけない
- 37. 再検討途中での試行 • カラーヒストグラム • 形と色の違いがつぶされてしまう問題に対処したい • 色の違いを厳しく判定できるようにカラーヒストグラムを特徴量の補助に用いる→精度が出たので採用 • K-meansクラスタリング • イベントごとにカードの分類数は決まっているので適用できるのでは？ • →なんとなくは分類できたが自前のアルゴリズムよりさらに悪い精度 • →しかし、K-meansの適用の中で発見が • VGG16で転移学習 • 分類された一部の5種類のアイテムで検証 • →サンプル数が十分あればもちろん一番精度が高いことが判明 • →分類されたアイテムが十分揃ったら適用を検討
- 39. K-meansからの着想 行列でのイメージ • K-means • 特徴量から各クラスターの重心を求める • 1行61列の1次元ベクトルができる • 各アイテムの特徴量 • N行61列の2次元ベクトル • 行の要素数は異なるが列の要素数は61 個で固定 • 分類の総量の特徴量 • 同じ分類のアイテムの特徴量の行をすべて 足し合わせる • →分類の総量の特徴量になるのでは💡 • dir_descriptors[-1][1] = np.vstack((dir_descriptors[-1][1], descriptors)) • 試しに計算してみるとそのような結 果に • →これで行けそう
- 40. 再検討アーキテクチャの指針 • 1. お手本分類を使った分類 • お手本分類を用意する • 最初のお手本分類を使わないアルゴリズムによる分類(80%ぐらいの分類精度)から作る • 前回までのお手本にあるものはお手本分類と同じフォルダへ分類される • 2. 最初のアルゴリズムによる分類 • イベント専用などお手本にないもの • お手本の数が少なすぎて、うまく一致できなかったもの • 3. 手動での再分離 • 2. が対象 • 次からも継続的に出現するものは、次の分類のためにお手本分類へ追加する • 誤分類と過分類のための適切な閾値 • お手本分類への誤分類はないレベルまで分類の閾値(特徴量間の距離)を上げる
- 41. 精度が上がる根拠 • お手本分類と対象を比較 • お手本分類ごとの特徴量の総量とアイテムの特徴量を比較するので、比較の 閾値を上げれば、正しく分類される可能性が高くなる • 少なくとも分類ごとにお手本は3つ以上あるとほぼ正しく分類される • →分類を繰り返し、お手本を追加するたびに分類精度があがっていく • 注意点 • お手本分類とその要素の量に従って計算時間が上がるので、お手本への追加 の上限を決める • 各分類で20個ぐらいまでに抑える、10個あればほぼ正しく分類できる
- 43. お手本分類を利用した再検証結果 数値 タイトル お手本分類 枚数 検証カード枚 数 お手本分類へ の分類枚数 お手本分類外 の分類 お手本分類外 の分類枚数 分類精度 タイトル1 5655 4580 4303 265 277 93.95% タイトル2 1570 1570 1217 86 353 77.52% タイトル2 補正 1570 1570 1217 +239 86 -3 353 -239 92.74% タイトル1 対象はカードの一部 (8割程度) PNGでキャプチャされたものをお手本データ に JPGでキャプチャされたものを検証データに タイトル2 JPGでキャプチャされたもののうち、10連のみを対象 10連のデータの半分をお手本データに 10連の残り半分を検証データに → この方針は若干偏 りがあった
- 44. お手本分類を利用した再検証結果 個別分析 • タイトル1 • お手本分類への分類には誤分類なし • お手本分類ごとの枚数が2枚以下の分類は分類できず過分類が発生しやすい • お手本分類外への分類には誤分類、過分類ともあり • レア度が高いものは最初のお手本分類では少数もしくは存在しないため、何度か分類を繰り返 して、お手本分類の数を増やす必要がある • タイトル2 • お手本分類データと検証データを真っ二つに割ったため、若干出現に偏りがあり、検証データ のうち、3分類は数が多く正しく分類されていたが、お手本にないもの • 上記を加えると、92.74%まで分類精度は向上する • 初期データとしては、連ガチャごとに5,000データぐらいあると高い分類精度から始められる
- 45. お手本分類を利用した再検証結果 総括 • Pros • お手本データとお手本分類があれば、最初から90%以上の精度で分類が可能 • 95%が自動分類の効果が出る損益分岐点である感触 • 難易度が高めのタイトル1とタイトル2でも3回分類を繰り返し、お手本分類を 充実させると損益分岐点を超えそう • Cons • お手本分類を作り出す手動の最初の工数がかなりかかる • クリッピングの精度が高くないと、分類精度が大きく落ちる • 連ガチャごとにクリッピング領域固定 ＞＞＞ 矩形認識を駆使する →ガチャ検証チームで実運用タイトルを決定、開発＆運用へ
- 46. 地味で大変だけど役に立つ前処理と後処理 • 確率表示確認支援ツール • 前処理 • OpenCVによるキャプチャの事前加工 • 後処理 • 手動の検証をサポートするUIとワー クフロー • 排出率確認支援ツール • 前処理 • お手本分類の作成 • 後処理 • お手本分類外の再分類とお手本分類 への追加 地味で大変な前処理と後処理があってこそAIやアルゴリズムが実用になる
- 48. © 2018 SQUARE ENIX CO., LTD. All Rights Reserved. Google はGoogle LLCの商標または登録商標です。 AirTestはNetEaseの商標または登録商標です。 その他、掲載されている会社名、商品名は、各社の商標または登録商標です。