Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Shadowverse流開発手法 ~QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発~

Cygames
September 05, 2019

Shadowverse流開発手法 ~QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発~

2019/09/05 CEDEC 2019

Cygames

September 05, 2019
Tweet

More Decks by Cygames

Other Decks in Technology

Transcript

  1. Shadowverse流開発手法
    1/76
    ~QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発~
    株式会社Cygames

    View full-size slide

  2. Shadowverseでは膨大なカードの組合せによるQAコストが開発、
    運営をしていく中で大きな課題となった。
    その課題に対して、プランナー自身がカードの振る舞いをテスト
    できる環境や、AIの調整、システムの
    堅牢性を担保するテストツールなどを駆使することにより
    大幅改善を実現した。
    本講演では、これらの実践方法と運用方法にShadowverse
    での実例を交えつつ解説する。
    2/xx
    本講演の主旨

    View full-size slide

  3. 柴田 有輝
    2015年度新卒として株式会社Cygamesに入社。
    エンジニアとして、リリース前からShadowverse
    の開発に携わる。
    現在はバトルパートのリーダーを担当、開発と
    運用を行いながらバトル開発全体の管理を行って
    いる。
    3/xx
    自己紹介

    View full-size slide

  4. 4/xx
    自己紹介
    鄒 一舟(ソウ イッシュウ)
    中国出身。2012年来日し、早稲田大学に修士入学。
    2015年新卒として株式会社Cygamesに入社。
    Shadowverseリリース前から
    UI、バトルロジックやAIなどの実装に携わる。
    現在はAIの設計と実装を担当している。

    View full-size slide

  5. • ジャンル:デジタルTCG(Trading Card Game)
    • 2016年6月17日リリース
    • 運用4年目に突入
    • 現在(9/5時点)までに2100万DLを突破
    • 4プラットフォーム展開
    (GooglePlay、AppStore、DMM、Steam)
    5/xx
    Shadowverseとは

    View full-size slide

  6. 6/xx
    Shadowverseにおけるリリースサイクル

    View full-size slide

  7. Agenda
    7/全ページ
    1. Shadowverseの課題と解消手段
    2. AI開発におけるテスト駆動開発
    3. スキル開発におけるテスト駆動開発
    4. 全体のまとめ

    View full-size slide

  8. Agenda
    8/全ページ
    1. Shadowverseの課題と解消手段
    2. AI開発におけるテスト駆動開発
    3. スキル開発におけるテスト駆動開発
    4. 全体のまとめ

    View full-size slide

  9. 9/xx
    Shadowverseの課題

    カードプール増加
    バグ増加
    テスト工数増加
    堅牢性の低下
    QAコストの増加
    組み合わせ
    爆発

    View full-size slide

  10. 直近の1年間カードスキルの組み合わせ数(理論値)が
    カードパック更新ごとに平均18.5%増えている
    10/xx
    Shadowverseの課題
    0
    200
    400
    600
    800
    1000
    1200
    Ver2.2.0 Ver2.3.0 Ver2.4.0 Ver2.5.0
    スキル組み合わせ数
    /万

    View full-size slide

  11. 11/xx
    QAコスト削減と堅牢性強化に我々が必要だったこと
    1. 実装から既存機能を守る
    2. 手戻りの発生しないことを保証
    3. 組み合わせに対して網羅的なデバッグ
    これらを踏まえテスト駆動開発を提案

    View full-size slide

  12. 12/xx
    テスト駆動開発導入に当たっての問題点
    挙動的に非常に高い不確定性を持っており、機能の正確性と
    有効性を両方担保できるテストシナリオは作れない
    スキルの組み合わせ数が膨大すぎて、
    シンプルなテストシナリオでは堅牢性の担保をするには不十分で
    QAコストが右肩上がりに増えていく
    ■AI開発において
    ■スキル開発において

    View full-size slide

  13. 13/xx
    問題点に対する解決方法
    • AIの不確定性に対して、要件の細分化で良し悪しの判断を
    シンプルにし、テストシナリオを作りやすく。
    • 回帰テストと網羅的自動 デバッグを併用し、
    膨大なスキル組み合わせの堅牢性の担保とQAコストの削減を実現。
    • ツール開発時にゲームの既存機能を流用し、
    ツールの開発コストおよび学習コストを抑える

    View full-size slide

  14. Agenda
    14/全ページ
    1. Shadowverseの課題と解消手段
    2. AI開発におけるテスト駆動開発
    3. スキル開発におけるテスト駆動開発
    4. 全体のまとめ

    View full-size slide

  15. AI開発におけるテスト駆動開発
    15/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  16. AI開発におけるテスト駆動開発
    16/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    • AIのテスト駆動開発フロー
    • 不確定性による影響と導入要件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  17. 17/xx
    AIにおけるテスト駆動開発フロー
    要件作成
    テストケース作成
    コーディング
    単体テスト
    回帰テスト
    AI調整
    デバッグ
    効果検証
    プランナー主導の仕様段階
    エンジニアによる実装段階
    プランナーによるバランシング段階

    View full-size slide

  18. 18/xx
    AIにおけるテスト駆動開発フロー
    要件作成
    テストケース作成
    コーディング
    単体テスト
    回帰テスト
    AI調整
    デバッグ
    効果検証
    プランナー主導の仕様段階
    エンジニアによる実装段階
    プランナーによるバランシング段階
    今回はプランナー主導の要件作成/テストケース作
    成について話します

    View full-size slide

  19. AI開発におけるテスト駆動開発
    19/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    • AIのテスト駆動開発フロー
    • 不確定性による影響と導入要件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    2.3 テストケース作成ツール
    2.4得られた成果

    View full-size slide

  20. 20/xx
    AIの不確定性
    ゲームの不確定性

    実戦では…
    AIの取るべき行動を
    定義しづらい
    対戦相手のデッキは不明
    カードドローはランダム
    ランダム性の高いスキル

    View full-size slide

  21. 21/xx
    AIの不確定性によるテスト駆動開発の難点①
    プランナーがテストプレイし、
    主観で判断する
    自動的にテストを実行することはできない
    ■AIのプレイング優劣はどうやって判断する?

    View full-size slide

  22. 22/xx
    AIの不確定性によるテスト駆動開発の難点②
    ■開発中によく起きるエンジニアへの手戻り
    バグが発生した
    仕様通り動いたけど、やっぱり使えなかった
    20%未満
    80%超え
    エンジニア
    プランナー

    View full-size slide

  23. 23/xx
    AIの不確定性によるテスト駆動開発の難点②
    AIの不確定性により、カードの振る舞いに対して
    正確な仕様が作りづらい
    ■なぜテストプレイしないと「使えない」ことがわからない?
    仕様の信頼度低下

    View full-size slide

  24. 24/xx
    テスト駆動開発を導入するための必要条件
    AIの不確定性
    自動的にテストを実行することはできない
    機能要件の有効性を保証
    挙動の正確性を機械的に判断
    仕様の信頼度低下
    テスト駆動開発を導入するための必要条件は…

    View full-size slide

  25. AI開発におけるテスト駆動開発
    25/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    • 要件細分化とその実例
    • プランナーによるテストケース作成
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  26. プランナー
    26/xx
    問題を解決する「鍵」はプランナーにある
    人的判断 仕様の信頼性
    判断する人は誰? 仕様を考える人は誰?
    虎の首に鈴を付けた人がその虎から鈴をはずすことができる
    原因を作った人こそが、問題の解決に最も適任

    View full-size slide

  27. 27/xx
    AI開発においてのプランナーの重要性
    スケジュール
    管理
    AI設計思想
    とデータ構造
    TCGプラン
    ナーが担当
    新規カードの設計と
    バランス調整を担当する
    TCGゲームデザインに
    特化したプランナー

    View full-size slide

  28. AI開発におけるテスト駆動開発
    28/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    • 要件細分化とその実例
    • プランナーによるテストケース作成
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  29. 29/xx
    不確定性を回避するための提案
    エンジニア
    では、簡単な要素単位で実装して、その組み合わ
    せをプランナーで調整できるようにしましょうか。
    プランナー
    一つ一つの思考要素は簡単だが、実戦では考える
    要素が多すぎて…
    要件を細分化してロジックをシンプルにする

    View full-size slide

  30. 30/xx
    要件細分化により不確定性の影響が収束される
    子要件A
    子要件B
    機能A
    機能B







    複雑な要件





    AIの不確定性に影響されるのは
    組み合わせ調整だけ
    実装&テスト
    テストA
    テストB
    任せて^_^
    プランナー

    View full-size slide

  31. 31/xx
    要件の細分化にはエンジニアリングの考え方が必要
    複雑な要件 複雑なシステム
    細かい要件A
    細かい要件B

    コンポーネントA
    コンポーネントB

    プランナーとエンジニアの
    さらなる連携が求められる
    エンジニア
    プランナー

    View full-size slide

  32. デモンストーム
    お互いのリーダーとフォロワーすべてに3ダメージ。
    これはどういう意味なのか
    実際のゲーム画面をご覧ください
    32/xx
    要件細分化の実例:全体ダメージ能力

    View full-size slide

  33. 33/xx
    要件細分化の実例:全体ダメージ能力
    フォロワー
    リーダー
    リーダー
    赤い盾:体力

    View full-size slide

  34. 34/xx
    要件細分化の実例:全体ダメージ能力

    View full-size slide

  35. 35/xx
    全体ダメージの運用要件
    相手を倒す
    味方フォロワーを生存
    させる
    相手のフォロワーを
    倒す
    相手リーダーの体
    力を削る
    味方を生存
    させる
    味方リーダーを守る

    View full-size slide

  36. 36/xx
    全体ダメージにおいての「相手を倒す」要件の細分化
    相手を倒す
    相手リーダーの体力を削る
    相手のフォロワーを倒す
    なるべく多くの相手フォロワーにダメージ
    倒しきれない場合は自陣フォロワーを使う
    返り討ちを食らうかどうかを警戒

    なるべく大打点を出す
    自陣フォロワーをリーダーに攻撃

    View full-size slide

  37. AI開発におけるテスト駆動開発
    37/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    • 要件細分化とその実例
    • プランナーによるテストケース作成
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  38. 38/xx
    テストシナリオ設計の仕方
    プランナー
    自陣フォロワーをリーダーに攻撃
    この要件はどうのように定
    義する?
    テストシナリオは要件の元となる
    実戦ケースから生まれる

    View full-size slide

  39. 39/xx
    テストシナリオ①:自陣フォロワーをリーダーに攻撃
    相手を倒す
    相手リーダーの体力を削る
    相手のフォロワーを倒す
    なるべく多くの相手フォロワーにダメージ
    倒しきれない場合は自陣フォロワーを使う
    返り討ちを食らうかどうかを警戒

    なるべく大打点を出す
    自陣フォロワーをリーダーに攻撃

    View full-size slide

  40. 40/xx
    テストシナリオ①:自陣フォロワーをリーダーに攻撃
    相手のフォロワーは
    全体ダメージに任せる
    自陣フォロワーは
    相手リーダーの体力を削る

    View full-size slide

  41. 41/xx
    テストシナリオ①:自陣フォロワーをリーダーに攻撃

    View full-size slide

  42. 42/xx
    テストシナリオ②:倒しきれない場合は自陣フォロワーを使う
    相手を倒す
    相手リーダーの体力を削る
    相手のフォロワーを倒す
    なるべく多くの相手フォロワーにダメージ
    倒しきれない場合は自陣フォロワーを使う
    返り討ちを食らうかどうかを警戒

    なるべく大打点を出す
    自陣フォロワーをリーダーに攻撃

    View full-size slide

  43. 43/xx
    テストシナリオ②:倒しきれない場合は自陣フォロワーを使う
    全体ダメージだけで相手フォ
    ロワーを倒せない場合
    自陣フォロワーの攻撃も使う
    ダメージ:3
    体力: 4

    View full-size slide

  44. 44/xx
    テストシナリオ②:倒しきれない場合は自陣フォロワーを使う

    View full-size slide

  45. 45/xx
    テストシナリオをエンジニアに共有する手間
    図のように盤面を配置 AI場のファイターで敵場の
    デスドラゴンそれぞれに攻撃
    敵場のデスドラゴンが4/2になり
    AI場のファイターが破壊
    デモンストームをプレイ 双方の場のフォロワーが全部破壊
    この資料の作成時間は…
    30分

    View full-size slide

  46. 46/xx
    テストシナリオをエンジニアに共有する手間
    見づらい
    疲れた
    テストシナリオ遷移図を作成 N

    View full-size slide

  47. 47/xx
    プランナーにテストケースを作ってもらう
    エンジニアがテストシナリオを
    設計する
    プランナーにテストケースを
    作ってもらう
    テストケース作成
    ツールを実装する
    テストシナリオ共有の手間をなくす方法
    テストシナリオの設計は
    要件作成と分離出来ない
    プログラミングが出来ない

    View full-size slide

  48. AI開発におけるテスト駆動開発
    48/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  49. ■機能
    • テストケース登録
    – 手動スタート盤面再現
    – 手動行動再現
    – スタート盤面と正解結果の保存
    • テストケース再生
    – スタート盤面再現
    – AI思考呼び出し
    – 正解結果と比較し、差分がある
    ならNG、一致するならOK
    49/xx
    バトル機能を流用したツール「AITestKun」

    View full-size slide

  50. 50/xx
    テストケース登録

    View full-size slide

  51. 51/xx
    テストケース実行

    View full-size slide

  52. 52/xx
    AIのテストケースの判断において重要なのは「結果」のみ
    細かい行動の正解を定義する必要なし
    ホワイトボックステストも必要なし

    View full-size slide

  53. 53/xx
    プランナー主導のテスト駆動開発まとめ
    要件細分化
    テストケース
    作成ツール
    エンジニア
    プランナー
    テストケース作成
    実装+テスト

    View full-size slide

  54. AI開発におけるテスト駆動開発
    54/全ページ
    2.1 テスト駆動開発を導入するための必要条件
    2.2 テスト駆動開発の主導権をプランナーに渡す
    2.3 テストケース作成ツール
    2.4 得られた成果

    View full-size slide

  55. • AI開発の作業効率は約2倍に増加しスケジュール遅延の消滅
    • AIのバグ報告数が約25%減少し、システム安定化
    55/xx
    得られた成果
    0
    10
    20
    30
    40
    50
    60
    70
    80
    90
    2018年7月から年末 2019年初から6月末
    バグ報告数

    View full-size slide

  56. 56/xx
    得られた成果
    プランナーとエンジニア
    の連携力向上
    エンジニアリング思想を
    取り入れた要件分析
    TCG戦術に合わせた
    アルゴリズム設計
    開発チームの士気と
    スムーズなコミュニケーション

    View full-size slide

  57. Agenda
    57/全ページ
    1. Shadowverseの課題と解消手段
    2. AI開発におけるテスト駆動開発
    3. スキル開発におけるテスト駆動開発
    4. 全体のまとめ

    View full-size slide

  58. 58/xx
    スキル開発におけるテスト駆動開発
    3.1 スキルはどうやって動いているのか
    3.2 スキルの堅牢性を担保するテスト
    3.3 スキル開発で得られた成果

    View full-size slide

  59. 59/xx
    3.1 スキルはどうやって動いているのか
    • スキルの仕組み
    3.2 スキルの堅牢性を担保するテスト
    3.3 スキル開発で得られた成果
    スキル開発におけるテスト駆動開発

    View full-size slide

  60. スキルは以下のような構成で、独自のスクリプト言語で制御
    60/xx
    スキルの仕組み
    Skill=メイン挙動の指定
    Timing=発動タイミング
    Condition=発動条件
    Target=発動対象
    Option=ダメージ量などの細かい制御

    View full-size slide

  61. 冥府への道
    自分のターン終了時、自分の墓場が30枚以上なら、
    相手のリーダーと相手のフォロワー
    すべてに6ダメージ。
    これを分解すると
    61/xx
    スキルの仕組み

    View full-size slide

  62. 冥府への道
    このように分解される
    62/xx
    スキルの仕組み
    Skill=ダメージ
    Timing=自分のターン終了時
    Condition=自分の墓場が30枚以上なら
    Target=相手のリーダーと相手のフォロワー全て
    Option=6

    View full-size slide

  63. 63/xx
    発動時の実際のゲーム画面
    相手のリーダー
    相手のフォロワー
    すべてに6ダメージ
    墓場×30
    ターン
    終了時

    View full-size slide

  64. スキル開発はこれら5つの要素に対して
    新たな振る舞いを追加することで新規実装を行う
    64/xx
    スキルの仕組み
    どのような形でスキルの堅牢性を
    担保しているのか?

    View full-size slide

  65. 65/xx
    3.1 スキルはどうやって動いているのか
    3.2 スキルの堅牢性を担保するテスト
    • 回帰テストツール
    • テストシナリオ作成からテスト実行までの流れ
    • 網羅的自動デバッグ機能
    3.3 スキル開発で得られた成果
    スキル開発におけるテスト駆動開発

    View full-size slide

  66. 1. 単体テスト
    スキル最小要素ごとの単体動作のテストシナリオを使用したテスト
    2. 結合テスト
    スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト
    3. 回帰テスト
    以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト
    4. 自動テスト
    カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト
    66/xx
    スキル開発におけるテスト

    View full-size slide

  67. 1. 単体テスト
    スキル最小要素ごとの単体動作のテストシナリオを使用したテスト
    2. 結合テスト
    スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト
    3. 回帰テスト
    以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト
    4. 自動テスト
    カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト
    67/xx
    単体テスト

    View full-size slide

  68. 68/xx
    単体テスト
    テストシナリオ作成
    エンジニアが主導
    テスト
    テスト
    テスト
    テスト
    テスト
    Skill=メイン挙動の指定
    Timing=発動タイミング
    Condition=発動条件
    Target=発動対象
    Option=ダメージ量などの細かい制御

    View full-size slide

  69. 1. 単体テスト
    スキル最小要素ごとの単体動作のテストシナリオを使用したテスト
    2. 結合テスト
    スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト
    3. 回帰テスト
    以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト
    4. 自動テスト
    カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト
    69/xx
    結合テスト

    View full-size slide

  70. 70/xx
    結合テスト
    テスト
    テストシナリオ作成
    エンジニアが主導
    Skill=メイン挙動の指定
    Timing=発動タイミング
    Condition=発動条件
    Target=発動対象
    Option=ダメージ量などの細かい制御

    View full-size slide

  71. 1. 単体テスト
    スキル最小要素ごとの単体動作のテストシナリオを使用したテスト
    2. 結合テスト
    スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト
    3. 回帰テスト
    以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト
    4. 自動テスト
    カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト
    71/xx
    回帰テスト

    View full-size slide

  72. バグ報告の件数
    72/xx
    回帰テストを行わなければならない理由
    結合テスト
    (カード単体)

    複雑なカード
    組み合わせ
    複雑なカードの組み合わせ挙動を
    厚めにカバーしなければならない

    View full-size slide

  73. 73/xx
    テストシナリオの作成に関して問題が…
    プランナー
    複雑なカードの組み合わせの算出を正確かつ迅速に
    できるが、プログラミング知識がない
    エンジニア
    複雑なカードの組み合わせの算出を正確かつ迅速にできない
    テストシナリオ作成手段と正確性に問題

    View full-size slide

  74. 74/xx
    テストシナリオ作成、検証にあたっての要件
    複雑なカード組み合わせの
    バグ報告を減らしたい
    面倒なテストシナリオの作成
    手順は踏みたくない
    再開機能の流用を検討

    View full-size slide

  75. 75/xx
    再開機能とは
    中断 再開
    プレイログ バージョンごとに
    変動をしない
    バージョンをまたいでも結果が不変な
    プレイログを生み出すことが可能

    View full-size slide

  76. 76/xx
    再開機能を回帰テストツールに流用する利点
    プランナー
    エンジニア
    プログラミング知識無しで
    テストシナリオ作成が可能
    車輪の再発明回避
    再現性が非常に高い
    再開機能をもとに
    回帰テストツール開発を決断!

    View full-size slide

  77. 77/xx
    3.1 スキルはどうやって動いているのか
    3.2 スキルの堅牢性を担保するテスト
    • 回帰テストツール
    • テストシナリオ作成からテスト実行までの流れ
    • 網羅的自動デバッグ機能
    3.3 スキル開発で得られた成果
    スキル開発におけるテスト駆動開発

    View full-size slide

  78. 78/xx
    回帰テストツールで保証したいこと
    プレイログ プレイログ バトル
    バトル
    バトル 回帰テスト
    バトル結果(プレイログ) = 回帰テスト結果
    新規実装、ソースコード改修、リファクタリングの結果
    以前と挙動(結果)が同じであることを保証する

    View full-size slide

  79. 79/xx
    回帰テストツールに必要な追加情報
    追加情報をもとに挙動の差分チェック
    カードの位置情報
    カードパラメーター
    その他
    各カードがどの位置にあるかの情報
    カードのパラメーターの数値
    ターン数、リーダー別の状態等の情報
    アクション情報 ユーザー任意のアクション情報(手順情報)
    回帰テストツール用の追加情報

    View full-size slide

  80. 80/xx
    追加情報の記載、チェックのタイミング
    スキルの発動A
    ユーザー任意のアクション
    スキルの発動B
    スキルの発動C



    各スキルの発動後
    情報の記載 or チェック
    アクション完了後
    情報の記載 or チェック
    アクション開始

    View full-size slide

  81. 81/xx
    なぜこんなに細かく行う必要があるのか?
    テストの過程を無視してテストを行うと
    結果の保証が得られなくなってしまう
    テストA
    テストB
    過程A
    過程B
    希望通りの結果
    過程C
    希望通りの結果
    ではない
    重要度低
    重要度高
    過程B

    View full-size slide

  82. 82/xx
    3.1 スキルはどうやって動いているのか
    3.2 スキルの堅牢性を担保するテスト
    • 回帰テストツール
    • テストシナリオ作成からテスト実行までの流れ
    • 網羅的自動デバッグ機能
    3.3 スキル開発で得られた成果
    スキル開発におけるテスト駆動開発

    View full-size slide

  83. 83/xx
    回帰テスト用のテストシナリオ作成の流れ
    テストしたいカードの組み合わせをプレイ
    プレイログを保存する

    View full-size slide

  84. 84/xx
    回帰テスト用のテストシナリオの作成方法

    View full-size slide

  85. チェックタイミングで記録時と差分がない
    85/xx
    テスト実行時の正常パターン
    相手の場に体力1のカードが1体存在
    ダメージスキルを持っているカードをプレイ
    相手の場の体力1のカードに1のダメージを与える
    相手の盤面が空になる
    チェック

    View full-size slide

  86. 86/xx
    正常パターンのイメージ

    View full-size slide

  87. 何らかの改修で記録時との差分が発生
    87/xx
    テスト実行時の異常パターン
    相手の場に体力1のカードが1体存在
    ダメージスキルを持っているカードをプレイ
    相手の場の体力1のカードに0のダメージを与える
    相手の盤面が空にならない!
    チェック

    View full-size slide

  88. 88/xx
    異常パターンのイメージ

    View full-size slide

  89. 89/xx
    差分が発生!!!

    View full-size slide

  90. 90/xx
    エラー内容が出力される
    [スキル(damage)発動後] でエラー発生
    記録されていないカードが存在しています
    :フェアリー (場)
    相手の場の体力1のカードに0のダメージを与える
    相手の盤面が空にならない
    チェック

    View full-size slide

  91. チェックタイミングで記録した情報と
    差異がなければOK
    91/xx
    最終的に
    相手の場に体力1のフォロワーが1体存在
    ダメージスキルを持っているカードをプレイ
    相手の場の体力1のカードに1のダメージを与える
    相手の盤面が空になる
    チェック

    View full-size slide

  92. • バージョンごとにフォルダ分けして管理
    92/xx
    回帰テストのテストシナリオの管理
    recovery_single_0001.json

    View full-size slide

  93. 93/xx
    回帰テストツールによりできた事と不安な事
    発覚済みの組み合わせバグの
    再発を防止とQAコストを削減
    未発覚バグは依然として人力で
    見つけるしかない
    人的コストをかけずに
    未発覚のバグを検知できないか…?

    View full-size slide

  94. 94/xx
    3.1 スキルはどうやって動いているのか
    3.2 スキルの堅牢性を担保するテスト
    • 回帰テストツール
    • テストシナリオ作成からテスト実行までの流れ
    • 網羅的自動デバッグ機能
    3.3 スキル開発で得られた成果
    スキル開発におけるテスト駆動開発

    View full-size slide

  95. 1. 単体テスト
    スキル最小要素ごとの単体動作のテストシナリオを使用したテスト
    2. 結合テスト
    スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト
    3. 回帰テスト
    以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト
    4. 自動テスト
    カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト
    95/xx
    自動テスト

    View full-size slide

  96. 1. モンキーテスト (無差別、対象指定タップデバッグ)
    2. 自動デッキ編成機能
    3. AI同士の自動バトルデバッグ機能
    4. 社内SNSへの自動レポート送信機能
    96/xx
    網羅的自動デバッグ機能とは

    View full-size slide

  97. 1. モンキーテスト (無差別、対象指定タップデバッグ)
    2. 自動デッキ編成機能
    3. AI同士の自動バトルデバッグ機能
    4. 社内SNSへの自動レポート送信機能
    97/xx
    網羅的自動デバッグ機能とは

    View full-size slide

  98. 98/xx
    モンキーテスト
    シーン遷移やタッチ操作に不具合がないか網羅的に調査する

    View full-size slide

  99. 1. モンキーテスト (無差別、対象指定タップデバッグ)
    2. 自動デッキ編成機能
    3. AI同士の自動バトルデバッグ機能
    4. 社内SNSへの自動レポート送信機能
    99/xx
    網羅的自動デバッグ機能とは

    View full-size slide

  100. • 自動デッキ編成機能で作成したデッキを使用し、網羅性と偶発性の高いAI
    により膨大な組み合わせを自動でバトルする機能
    ■規模
    • 1バトル当たり5分
    • 10:00~19:00まで動作
    • 2端末で約108試合/日
    • 約25セットで実行 = 約2700試合/日
    100/xx
    自動バトルデバッグ
    ①デッキ編成
    ②マッチング
    ③バトル
    ④レポート
    実行サイクル

    View full-size slide

  101. 101/xx
    自動バトルデバッグの様子

    View full-size slide

  102. 1. モンキーテスト (無差別、対象指定タップデバッグ)
    2. 自動デッキ編成機能
    3. AI同士の自動バトルデバッグ機能
    4. 社内SNSへの自動レポート送信機能
    102/xx
    網羅的自動デバッグ機能とは

    View full-size slide

  103. 網羅的自動デバッグ機能の起動中に発生した
    エラーを社内SNSに 自動投稿する機能
    103/xx
    社内SNSへの自動レポート送信機能

    View full-size slide

  104. • ユーザー情報(ID等)
    • バージョン情報
    • 接続先情報
    • 端末情報(GPU、メモリ等)
    • カード情報(バトル時)
    • スタックトレース
    • スクリーンショット
    104/xx
    実際に社内SNSに投稿された内容

    View full-size slide

  105. 105/xx
    高頻度でバグ報告されるカード
    バグ報告 NGカード登録
    自動デッキ編成
    自動バトルで使用不可
    バグ報告
    無駄な報告が減る

    View full-size slide

  106. 106/xx
    網羅的自動デバッグ機能を使用することで
    チェックリストから漏れたバグの
    検知
    パフォーマンス検証も
    手軽に実施可能に
    回帰テストでカバーできていなかった
    未発覚バグの検知をカバー

    View full-size slide

  107. 107/xx
    3.1 スキルはどうやって動いているのか
    3.2 スキルの堅牢性を担保するテストの種類
    3.3 スキル開発で得られた成果
    スキル開発におけるテスト駆動開発

    View full-size slide

  108. • バトル全体でのバグ報告が約40%減少
    108/xx
    スキル開発で得られた成果
    1.6.0 1.7.0 1.8.0 2.0.0 2.1.0 2.2.0 2.3.0 2.4.0
    2か月後
    1か月後
    大型アップデート
    1.6.0以降から
    回帰テストツール
    動作開始

    View full-size slide

  109. Agenda
    109/全ページ
    1. Shadowverseの課題と解消手段
    2. AI開発におけるテスト駆動開発
    3. スキル開発におけるテスト駆動開発
    4. 全体のまとめ

    View full-size slide

  110. • カードの継続的増加により、対策としてテスト駆動開発の
    導入を考案した
    • AIの不確定性に対して、AI要件の細分化とプランナーによるテス
    トケース作成を実現し、実装の有効性と正確性を担保
    • 回帰テストツールと網羅的自動デバッグ機能を採用することで、
    QAコストの削減と堅牢性の強化を実現
    • 既存ゲーム機能を流用し、テストツール開発を低コストで実現
    110/xx
    全体のまとめ

    View full-size slide

  111. Shadowverseは
    10年以上続くタイトルを
    目指しています
    111/xx

    View full-size slide

  112. 今回の手法で構築した
    高効率な開発基盤は
    その礎になります
    112/xx

    View full-size slide