モデル検査のゲーム開発への適用事例

Okayama Prefectural University
モデル検査のゲーム開発への適用事例
横川智教（岡山県立大学）長谷川勇（スクウェア・エニックス）
2019/7/1 ソフトウェア開発における産学協創フォーラム

ゲーム開発 QA における課題とその解決へのアプローチ
 ゲーム開発 QA の課題
 スクリプト巨大化によりメンテナンスが困難に・バグの見落としも増加
 QA フェーズのコストの増大
 解決へのアプローチ
 スクリプトに対してモデル検査等の自動化技術を適用しバグを事前検出
© 2018 Luminous Productions Co., Ltd. Okayama Prefectural University All Rights Reserved
QA
Game
Designer
Bug Report
Game Designer
© 2018 Luminous Productions Co., Ltd. Okayama Prefectural University All Rights Reserved
Game
Designer
(Bug)
引用元：モデル検査のゲーム開発への適用～FINAL FANTASY XVの開発を例として～（CEDEC2018）
https://cedil.cesa.or.jp/cedil_sessions/view/1904

研究開発の方向性
 単純だが良く起こるバグを検出する
 イベントフラグの戻し忘れ，など
 false-positive（誤検出）はある程度許容する
 バグ「かもしれない」ものをできるだけ多く見つける
 バグではなくてもその要因になるかもしれない
 その代わり，検証プロセスの完全自動化を目指す
 導入コストを限りなく 0 に近づける
 現場では，追加の仕事が増えるとなると使ってもらえない

モデル検査とは
 システムを自動かつ網羅的に検証する技術
 以下の３つのステップで検証を行う
1. モデル化：検査対象となるシステムを状態遷移グラフで表現
2. 仕様記述：システムが満たすべき性質を時相論理による検査式として記述
3. 検証：モデルが検査式を満たすか否かをグラフ探索によって判定
 いいところ：自動的，網羅的，反例生成
 悪いところ：状態爆発，モデル作成にコツがいる
 多くの実装がツールとして公開されている
 どう使う？
 ツール固有の入力言語でモデルと検査式を記述
 あとはツールを実行するだけ
 SMV の機能強化版である NuSMV を利用する

Visual Script のモデル化
 検証したいこと
 スクリプト内のシグナルやグローバルフラグが
望ましい/望ましくない値を取り得るか
 モデル化する部分
 ノード間のシグナルのフロー
 シグナル・フラグ変数の変化
 モデル化の方針
 ノードごとに動作をモデル化して，それらを結合する
 ノード内部の動作は思い切って抽象化する
Set Event Mode
Enable
Disable
Out
If
In True
False
Script Start
Out
Set Event Mode
Enable
Disable
Out
Fade In
In Out
Finished
EventMode = 1
EventMode = 0

Visual Script のモデル化
 モデル化の手順
1. ノードの入出力シグナルを変数として抽出
2. 入力シグナルの変化をモデル化
 ノード間の接続関係をもとに定義
3. 出力シグナルの変化をモデル化
 ノード内部の動作をもとに定義
 ノード内部の動作（ノードセマンティクス）は
あらかじめ分類してテンプレート化する
– 大部分のノードは決まったパターンに落とし込める
– テンプレートの作成は，今のところ人手で作成

ノードセマンティクスのモデル化
 以下の分類に従ってテンプレート化
1. 単一の出力
 シグナルが入力されるとシグナルを出力
2. 複数の出力（条件分岐）
 シグナルが入力されると条件に依存してシグナルを出力
3. 複数の出力（状態遷移）
 シグナルが入力されると内部状態に依存してシグナルを出力
4. 複数の出力（条件分岐＋状態遷移）
 2. と 3. の組み合わせ
5. 開始ノード
 無条件にシグナルを出力
6. 上記のどれにも当てはまらないもの
 例：グローバルフラグの更新，入力シグナルに依存した状態遷移，など
If
In True
False
Fade In
In Out
Finished
Set Event
Mode
Enable
Disable
Out
Script
Start
Out
Node
In1
In2
Out

入出力シグナルのモデル化
Script
Start
If
Fade In Node Script End1
Out In True
False
In Out
Finished
In1
In2
In3
Out1
Out2
In
Script End2
In
VAR
Node_In : {none, In1, In2, In3};
Node_Out : {none, Out1, Out2};
ASSIGN
init(Node_In) := none;
next(Node_In) := case
FadeIn_Out = Out : In1;
FadeIn_Out = Finished : In2;
If_Out = False_ : In3;
TRUE : none;
esac;
• ノードの入力・出力シグナルを
それぞれ変数として定義する
• どの入力シグナルもアクティブでないことを
表すため，値 none を用意しておく
• 入力シグナルの値が，接続された
出力シグナルの値に依存して変化するよう
モデル化する

ノードセマンティクスのモデル化：2. 複数の出力（条件分岐）
Script
Start
If
Out In True
False
In Out
Finished
In1
In2
In3
Out1
Out2
In
Script End2
In
VAR
If_In : {none, In};
If_Out : {none, True_, False_};
ASSIGN
init(If_Out) := none;
next(If_Out) := case
If_in = In : {True_, False_};
TRUE : none;
esac;
（入力シグナルのモデル化部分は省略）
• 条件分岐をもつ場合，出力シグナルの値が
非決定的に選ばれるようモデル化する
• If ノードの入力シグナルがアクティブに
なると出力シグナルのいずれかが
非決定的に選ばれてアクティブとなる
• ノード内部の条件判定部分は
完全に抽象化される

ノードセマンティクスのモデル化：3. 複数の出力（状態遷移）
Script
Start
If
Out In True
False
In Out
Finished
In1
In2
In3
Out1
Out2
In
Script End2
In
VAR
FadeIn_In : {none, In};
FadeIn_Out : {none, Out, Finished};
FadeIn_St : {ini, out, wait, fin};
ASSIGN
init(FadeIn_St) := ini;
next(FadeIn_St) := case
FadeIn_In = In : out;
FadeIn_St = out : wait;
FadeIn_St = wait : {wait, fin};
TRUE : ini;
esac;
init(FadeIn_Out) := none;
next(FadeIn_Out) := case
FadeIn_St = out : Out;
FadeIn_St = fin : Finished;
TRUE : none;
esac;
（入力シグナルのモデル化部分は省略）
• 状態遷移をもつ場合，ノードの状態を
新たに変数として定義する
• Fade In ノードは以下の４状態をもつ
1. ini：初期状態
2. out：入力シグナルを受け取り，
Out シグナルを出力する
3. wait：フェードイン処理の終了を待つ
4. fin：フェードイン処理を終え，
Finished シグナルを出力する
• 状態に応じて出力シグナルをアクティブにする

ノードセマンティクスのモデル化：その他
 イベントモードの設定を行うノード
 グローバルフラグを変数として定義する
 Set Event Mode ノードの
入力に応じて変数の値を更新
 グローバルフラグの
望ましい/望ましくない振る舞いを
検査式で表現
Set Event
Mode
Enable
Disable
Out
VAR
g_EventMode : {enabled, disabled};
ASSIGN
init(g_EventMode) := disabled;
next(g_EventMode) := case
EventMode_In = Enable : enabled;
EventMode_In = Disable : disabled;
TRUE : g_EventMode;
esac;
（入出力シグナルのモデル化部分は省略）
SPEC AG(g_EventMode = enabled
-> AF(g_EventMode = disabled))

 プロダクトで使用されているスクリプトから
ランダムに選んだ 8 つのスクリプトに対して適用
 イベントモードを使っているスクリプトに対して，
イベントモードの戻し忘れがないか検査
 反例が出力された際は，本当にそれがバグなのか確認
 実験環境：
 CPU：Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
 メモリ：32GB
 OS：Windows 7 Enterprise Service Pack 1 (64 bit)
 NuSMV：バージョン 2.6.0
予備実験

予備実験の結果
No. ノード数変数数変換時間 [s] 検証時間
[s]
反例あり？実際のバグ？
1 156 356 5.434 192.786 -
2 94 214 3.878 3.330 -
3 37 84 1.746 0.056 -
4 49 119 2.301 0.111 -
5 177 414 6.625 36.675 あり〇
6 73 162 2.768 0.173 -
7 162 408 9.187 98.102 あり〇
8 430 980 13.286 - -

予備実験の結果の考察・対策
 実際にバグを検出できた！
 反例を解析したところスクリプト上で実際に起こり得るバグだった
 該当するスクリプトは体験版の一部
 比較的大きなスクリプトでも数分以内に検証可能
 ノードセマンティクスについて：
 164 種類のノードが存在
 98/164 種がタイプ1（単一の出力）
 30/164 種がタイプ6（特殊なセマンティクス）
– 全てのノードを NuSMV のモデルとして表現できた
– ノードの 80 %以上は事前に作成したテンプレートでモデル化できる
 大きなスクリプトは数時間放置しても検証が終わらなかった
 モデルの最適化による検証の高速化が必要

 ビジュアルスクリプトの利点・課題
 習得・記述が容易 => ゲームエンジンで採用が進む
 メンテナンスが困難な巨大スクリプトになりがち
 エッジのつなぎ忘れ，必要なノードもれといった単純なバグも気づきにくい
 モデル検査によりこういったバグの自動検証が可能
 実験により実際にバグを検出できたことを確認
 巨大なスクリプトでなければ十数秒以内に検証できた
 内製エンジンのビジュアルスクリプト用に試作したが，
他のゲームエンジンにも適用可能
 これからの課題
 ノードセマンティクスの自動抽出・モデル化
 モデルの分割・最適化によるサイズ削減
まとめ

モデル検査のゲーム開発への適用事例

Recommended

Recommended

More Related Content

What's hot

What's hot (6)

Similar to モデル検査のゲーム開発への適用事例

Similar to モデル検査のゲーム開発への適用事例 (20)

モデル検査のゲーム開発への適用事例

Editor's Notes