FDRによるRPGシナリオの検証

FDR によるRPG シナリオの検証
長久勝†
アブストラクト
本修了制作では，RPG のシナリオ開発に対して，従来手法の拡張として，キャラクタ指向開発を
提案し，それを支援する検証ツールを作成した．まず問題を同定するために，従来のゲームシナリ
オ開発手法を分析した．その結果，ストーリ指向に原因があると判断した．問題を解消するために，
シナリオをストーリの集合ではなく，キャラクタ行動の集合としてモデル化する，キャラクタ指向を導
入することとした．従来手法に組み合わせることで，シナリオ構造を把握しやすくなると考えた．シナ
リオをキャラクタ行動全体として見ると，シナリオは合成された並行プロセス群と見なせるので，プロ
セス代数CSP を基盤とするFDR 記述によるモデル化を採用し，検証にFDR2 を採用した．FDR 記
述で簡潔に同期遷移を表現できるため，パーティを組むRPG シナリオの記述を適切に表現でき
た．大規模なシナリオを扱うためには更に研究が必要であるが，キャラクタ指向開発の有用性は確
認できた．
The verification of RPG scenario by FDR
Masaru Nagaku†
Abstract
I proposed the character oriented development of RPG scenario, and I made the verification tool
for the character oriented development. To identify the problem, I analyzed a past RPG scenario
development technique, and I judged that there was a cause in the Story oriented. I thought RPG
scenario to be not the Story set model but a character action set model. I adopted the model
expression by CSP and the verification by FDR2. The model expression by CSP was suitable for the
description of RPG scenario. I confirmed the utility of the character oriented development.
1. はじめに
家庭用ゲーム機やPC 上で動作するソフトウェアに，
娯楽の提供を主目的とした，コンピュータゲームがある．
コンピュータゲームは，その娯楽性や操作体系などに
よって，いくつかのジャンルに分類される．その一種で
あるRPG(ロールプレイングゲーム)では，プレイヤが，
操作するキャラクタの役割を演じることで，ストーリ(物
語)を進めていく．
RPG では，キャラクタの行動可能な選択肢が適時に
与えられ，その選択によってストーリが異なる進行を見
せるのが一般的である．このため，RPG におけるストー
リは，図1 のような，映画などの一般的な映像メディアに
おける一本道なそれではなく，図2 のような，複雑な分
岐によって実現される複数のストーリの集合と捉えること
ができる．本稿では，このストーリの集合を，シナリオと
† ハイパーコンテンツ(株)
HyperContents Corp.

呼ぶこととする．RPG の進行はシナリオによって制御さ
れる．
RPG のシナリオ開発では，複雑な分岐を作り込み，
品質の高い複数のストーリを成立させる必要がある．特
に重要なのは，あらゆるストーリが矛盾無く成立すること
である．演出的な意図からではなく，想定外の事象とし
て，死んだはずのキャラクタが登場したり，ストーリが示
唆してきたキャラクタの人格が一変したりすると，ソフト
ウェアとしての品質はさておき，娯楽作品としての品質
を損なってしまう．
RPG のシナリオが無矛盾性を満たすことは重要であ
る．しかし，実際の開発において，効率的な手法が取ら
れているとは言えない．分岐を設計し，管理するフラグ
(変数)を用意し，ゲームプログラム上で進行管理を行う
DSL に書き下されたあとは，実プログラム上でストーリの
進行を確認する試験と修正が繰り返される．RPG のシ
ナリオ開発は，一般的に，このような流れで行われてい
る．こうした方法で矛盾の無い複雑さを実現することは
容易ではないため，設計時のレビューなどで検証でき
る程度に複雑さを制限するか，経験豊富な専門家が独
自のノウハウの及ぶ範囲で複雑さを実現するかの，何
れかとなっている．
また，コンピュータゲーム開発は，構成員の殆どが
非ソフトウェア技術者であるチームによって行われてお
り，RPG のシナリオ開発も，非ソフトウェア技術者である
脚本家が中心となって進められる．しかし，脚本家の仕
事は魅力的なストーリを提供することであり，ソフトウェア
技術者と同じレベルで無矛盾性について考察すること
は困難である．このことも，RPG のシナリオに矛盾の無
い複雑さを与えることを難しくしている．
本修了制作では，ここまで述べたようなRPG のシナ
リオ開発の現状に対し，TopSE の受講で培った知見を
活かし，改善策を提案する．
2. ストーリ指向開発の問題
RPG のシナリオ開発について，脚本家がどのように
考えているのか分析を加え，問題点を明らかとしてお
く．
川邊[1]や佐々木[2]には，脚本家として，どのように
考えるか，実例を交えて述べられている．例えば，川
邊[1]には，シナリオを書く前に，環境，主人公，超ボス，
クライマックスを整えておき，主人公が環境の歪みを正
すことを何度か繰り返し，超ボスとクライマックスに至るこ
とを書いていけば良いと述べられている．佐々木[2]に
は，「構成とは：クライマックスを頂点として，そこに向
かって伝えるべき内容の順番を整えていくこと．」と述べ
られている．こうした開発手法では，話の流れを中心に
考え，その部品としてキャラクタを用いている．脚本家
の視点がストーリを重視していることは明らかである．こ
のストーリを中心にシナリオ開発を行う立場を，ストーリ
指向開発と呼ぶこととする．
ストーリ指向開発では，高品質なストーリの提供を目
的としているため，分岐の複雑さの管理については，効
果的な手法を内包しない．そもそも，何らかの基準でス
トーリの品質を考えれば，複数の選択肢があっても，最
も品質の高いストーリとなる選択肢は一意に決まる．映
画などの一般的な映像メディアでは，そうして一本道の
シナリオを開発してきた．しかし，RPG のシナリオでは，
ストーリの品質と共に，ストーリを選択できることも重要
である．選択が多く分岐による変化が多様なシナリオは，
自由度が高いと評され，支持されることも多い．した
がって，ストーリの品質を保ちつつ，分岐の複雑さを実
現することが求められる．分岐を制限する力が働きがち
なストーリ指向開発には問題がある．
分岐の複雑さによって損なわれやすいストーリの品
質に，キャラクタの性質の一貫性がある．例えば，熱血
で先走りがちなキャラクタが，突然，冷静な判断を下す
シーンがあると，プレイヤの心情に違和感を与えてしま
う．シナリオ開発においては，キャラクタの設定資料など
を作成し，キャラクタの性質の一貫性を担保する．特に，
複数の脚本家が分担作業するような大規模開発では，
必ず行われる．しかし，それでも完全に防ぐことができ
ていない．これは，プレイヤの操作する主人公キャラク
タ以外は，ストーリの中で常に登場しているわけではな
いため，キャラクタの置かれた状況や行動を俯瞰的に
見ることが難しいことに起因していると考えられる．ある
キャラクタについて，シナリオの中での置かれた状況や
行動を，全てまとめて見ることができれば，キャラクタの
性質の一貫性の観点からのレビューが容易になると考
えられる．ストーリ指向開発では，キャラクタを見るため
の方法が不足している．
分岐の複雑さによって達成が困難となるのが，シナ
リオのバグをなくすことである．シナリオのバグには，死
んだはずのキャラクタが登場するようなストーリの破綻と，
ストーリを先に進められない状態に陥るソフトウェアとし
てのバグの2 種類がある．これらのバグは，シナリオの
分岐を完全に把握していれば防げる．しかし，分岐が
複雑となることで把握ができなくなり，バグが生まれる．
把握しきれない複雑さを扱うためには，何らかの検査を
適用することが有効であるが，現在の開発では十分に

行われていない．適切な検査方法がないため，分岐の
複雑さを把握できる程度に抑えることが一般的である．
ここまで述べたように，ストーリ指向開発と，RPGのシ
ナリオの複雑な分岐の実現は，上手くかみ合っていな
い．キャラクタの性質の一貫性などの品質を，適切な検
査で確保し，複雑な分岐を実現する手法が必要であ
る．
3. 先行研究
本修了制作に関連する先行研究として，次の3 つを
取り上げ，その概要と，本修了制作との関係について
述べる．なお，本修了制作の詳細については，次章以
降に詳細を述べる．
柴崎[3]は，ゲームシナリオ検証の分野で最も先駆
的な研究である．ゲームブックと呼ばれるコンピュータ
上の実装を伴わないADV(アドベンチャーゲーム)のシ
ナリオで，複数のプレイヤによって遊ばれるものを対象
に，通信ソフトウェア開発システム上での記述と検証を
試みている．ADV とはRPG におけるシナリオ進行シス
テムのみを抽出したものと見なして概ね構わない．記述
言語SAL を用いてストーリを列挙すれば，通信ソフト
ウェア開発システムSDE でそれらをシナリオに合成し，
想定されていないストーリの存在やデッドロックを検証
できるとしている．但し，SALの表現能力やSDEの検証
能力が，どの程度のスケーラビリティを有するかは不明
である．検証を伴うシナリオ開発を，実際に動作する
ツールを利用して行う点は，本修了制作と共通である．
一方，本修了制作と異なる点としては，シナリオをストー
リの集合と捉えている点や，想定されていないストーリを
許さない点が挙げられる．本修了制作では，シナリオを
キャラクタ行動の集合として捉えており，検証項目を満
たすのであれば想定されていないストーリも許容する立
場である．
鬼塚[4]は，独自のシナリオ進行システムを実装した
ADV をヒントに，ADV やRPG のシナリオが持つ分岐に
対し，事象軸の概念を導入して，シナリオのモデル化を
試みている．提案されているモデルは，分岐によって生
じる並行世界の間を遷移可能としており，特殊な世界
観を背景としたゲームの実現を意図している．提案され
るモデルをベースとしたシナリオ開発手法や検証につ
いては扱われていない．本修了制作においても，並行
世界間の遷移は考慮しないが，ストーリを事象の列とし
て捉えることとした．本修了制作では，事象の進行は，
キャラクタ行動によって起こるとし，キャラクタ行動の違
いが事象の違いをもたらし，ストーリの違いをもたらすと
する．図3 を参照のこと．
清木[5]は，ゲームシナリオ検証に対して，明確にモ
デル検査を持ち込んだ点で画期的である．柴崎[3]が

通信ソフトウェア開発システムの転用を意図したことと，
清木[5]が通信プロトコルの検証で利用されているモデ
ル検査の導入を意図したことは，ゲームシナリオと通信
プロトコルの間に類似性があることを示唆している．本
修了制作も同じ文脈でモデル検査器FDR2 を用いる．
清木[5]では，ADV のシナリオの分岐を取得して，終了
状態への到達可能性が完全であるかを検証している．
また，その実現のために，モデル検査器の実装と最適
化を行い，評価を行っている．本修了制作では，既存
のモデル検査器を用いるため，終了状態への到達可
能性以外にも複数の性質について検証可能である．但
し，最適化は考慮していないため，実行効率は劣る．ま
た清木[5]では，ADV が対象であるため，シナリオをス
トーリの集合として捉えているが，本修了制作では，そう
でない．
4. 対象範囲
先行研究に鑑み，それらとの差異も意識した上で，
本修了制作の扱う範囲について述べる．
本修了制作ではRPG のシナリオについて，検証も
含めた開発手法の提案を行う．
ここで扱うシナリオは，1 つのシナリオの中に，プレイ
ヤの操作する可能性を持つ，複数のキャラクタが存在
するものとする．例えば，ゲーム開始時に，プレイヤの
操作するキャラクタを選べるRPG が，これに該当する．
こうしたシナリオにおいては，プレイヤが操作する可能
性のある全てのキャラクタについて，矛盾の無い複数の
ストーリが存在し，それら全てのストーリを正しく終了で
きることが必要である．本修了制作では，この性質を検
証可能とする．
複雑なシナリオにおいては，事前に全てのストーリを
漏れなく列挙し，仕様を定めることは困難である．そこ
で考え方を転換し，成り立つべき性質の全てを満たす
ことから逸脱しないことではなく，在ってはならない性質
の全てが現れないことをもって，正しいシナリオとする．
終了に到達できない状態に陥ったり，失われたものが
再び現れたり，さまざまな矛盾を含まないことの検証を
中心に考える．これに加えて，必ず含まれて欲しいス
トーリの存在が確認できれば良いと考える．正しいシナ
リオをこのように定義することで，シナリオは想定してい
なかったストーリを含むようになり，プレイヤの選択の自
由度が上がる．
本修了制作では，提案の実現を，既存のツールの
組み合わせで行うこととする．その理由には，TopSE で
学んだ成果を活用することもあるが，実務への適用を
考えた場合のコストも意識している．既存のツールを組
み合わせる部分で，対象となる問題領域への対応を行
うことで，本修了制作の成果物の利用者に，形式手法
やモデル検査についての理解を求めずにすむ．本修
了制作の取り組みを，形式手法やモデル検査と問題
領域の間の関連付けに特化させ，少ないリソースで成
果が出せることを示す．実行効率については，今後の
課題とする．
5. キャラクタ指向開発の提案
すでに述べたように，これまでのシナリオ指向開発
には，登場するキャラクタを管理し難いという問題点が
ある．これは，俯瞰的に1 人のキャラクタの全挙動を追う
ことがサポートされていないためである．そこで，キャラ
クタ単位で情報を集約したモデルを導入すれば，キャ
ラクタの挙動を追いやすくなると考えた．シナリオの中
でのキャラクタの振る舞いを，その行動と事象の進行の
連鎖で捉えると，FSM(有限状態機械)として表現可能
であることが分かる．シナリオ開発において，従来のシ
ナリオ指向開発の持つ全体の流れの視点に加え，
FSM によるキャラクタ毎の振る舞いの視点を導入すれ
ば，2 つの視点を用いて多角的なレビューが可能となる．
これは，UML ベースの開発手法において，1 つの問題
を，さまざまなモデル記述で多角的に見ることで，もれ
や誤りを防ごうとするのと同じである．キャラクタ毎の振
る舞いの視点を導入したシナリオ開発を，キャラクタ指
向開発と呼ぶこととする．図4 に概念図を示す．
キャラクタ指向開発では，キャラクタ毎のFSM が合
成されてシナリオが形成されると考える．キャラクタ同士
は，行動を共にしたり，1 つの事象に異なる立場で関
わったりするので，FSM の間で何らかの通信が行われ
るモデルとなる．もしシナリオを構成するFSM の間に全
く相互作用がない場合，シナリオは単に全てのFSM を
足し合わせたものでしかない．しかし一般的には，複数
のFSM の間の相互作用がシナリオに含まれるので，全
てのキャラクタのFSM の複雑さを合わせたものより，シ
ナリオの持つそれは，より複雑である．これは，FSM の
複雑さを管理することで，より複雑なシナリオを実現で
きることを示している．シナリオの複雑さを，キャラクタ毎
のFSM で，間接的に，効率良く，管理可能と考えられ
る．複雑なシナリオをあきらめることや，複雑なシナリオ
の実現のために職人芸を必要とすることから，ゲーム開
発を解放できる可能性がある．
互いに通信しながら動作するプロセス群全体に対し
て，さまざまな性質を検証しようとするのがモデル検査

である．互いに通信しながら動作するキャラクタ毎の
FSM 群全体がシナリオであるから，キャラクタ指向開発
のモデルは，そのままモデル検査可能である．シナリオ
のデッドロックは，ゲームを終了できないストーリが存在
する不具合であるし，シナリオのライブロックは，ゲーム
を終了させない遊び方の存在を示す．全てのキャラクタ

に，ゲームを終了するためのストーリが用意されるべき
であるし，どのようストーリであっても何らかの結末が用
意されるべきである．こうした観点から，開発中のシナリ
オが正しいものかどうか，検査することが可能である．ま
た，あり得るべきストーリ，あってはならないストーリの確
認も行えるので，シナリオにバグが含まれないかも判別
できる．
6. キャラクタ指向開発の実現
キャラクタ指向開発を実現するために，キャラクタ毎
のFSM を与えればモデル検査を行えるツールが必要
となる．本修了制作では，実際に要件を満たすツール
を作成した．
ツールの制作にあたっては，実用につなげることを
考え，プラットフォームに依存しない性質を持たせること
とした．ゲーム開発に関わる全ての人に，普段使い慣
れたプラットフォーム上でのツールを提供するためであ
る．この観点から，主要な実装技術にJava を採用した．
モデル検査を行うために，TopSE のさまざまな講義
で使用した既存のモデル検査ツールのうちの1 つを用
いることとした．多くのモデル検査ツールがLinux 上で
しか動かないため，さまざまなプラットフォームで動作す
る本修了制作ツールと，そのバックエンドでLinux 上で
動作するモデル検査ツールの間に，何らかの通信が必
要となる．本修了制作ではモデル検査ツールをPHP で
Web アプリケーション化して利用した．
本修了制作ツールにはFSM の入力が必要となる．
FSM は，通常，UML のステートチャート図で表現され
るので，入力となるFSMの記述にはJUDEを採用した．
JUDE には，TopSE で使用されていること，Java で書か
れておりプラットフォームに依存せず動くこと，API を使
えばUML をJava で簡単に扱えること，などの特徴があ
り，本修了制作の用途にとても適合したため採用した．
モデル検査ツールには，FDR2 を採用した．互いに
通信しながら動作するプロセス群を扱うモデル検査
ツールは他にもあるが，プロセス代数CSP に基づく記
法の一般性を評価した．CSP-Prover など，他のツール
との連係も視野に入れ，プロセス代数記法のハンドリン
グを技術的に蓄積しておくことを考えた．モデル検査
ツールへの入力は一種のDSL であり，DSL による拘束
を弱くしたいと考えた．
一般的に，RPG では，キャラクタはパーティと呼ばれ
るグループを組む．FDR 記法は，簡単な記述で，同期
したいイベントの集合を使ってプロセスを並行合成でき
る．この仕組みによって，一緒に同期して行動する，一
人で非同期に行動する，を実現し，キャラクタのパー
ティ組みを表現できた．図5 に，同じ行動の同期版，非
同期版を示す．move.{R,G}で並行合成しておくと，2
人で行動している時は同期遷移となり，1 人で行動して
いる時は非同期遷移となる．
多くのモデル検査ツールでは，時相論理式による検
証をサポートする反面，時相論理式で表現し難い性質
の検証に，オブザーバと呼ばれる検証専用のプロセス
を用いることがある．記述上，検証対象とオブザーバは
同じプロセスであり，オブザーバが割り込むことで検証
対象の性質を壊さないように注意が必要となる．FDR
記法では，抽象化によるイベントの隠蔽と等価性検証
を組み合わせて，オブザーバで検証するような性質を，
検証対象に影響を与えずに調べることができる．例え
ば，検証対象がイベントmove を3 回起こすことを調べ
たければ，move を除くイベント全てを隠蔽し，move を3
回起こして終了するプロセスと等価であることを調べれ
ば良い．FDR 記法の等価性検証は，詳細化の観点か
ら，抽象的な仕様と，具体的なシステム全体の間でよく
行われるが，シナリオは抽象的な総体，ストーリは具体

的な断片と見ることもでき，本修了制作でも，この考え
を利用した．
検証結果を分かりやすく提供するため，結果の一部
を図によって表現することとした．結果の再利用性や，
プラットフォームに依存しない性質を持たせるために，
一般的な画像形式での出力ではなく，Graphviz のdot
形式による出力を採用した．
7. ツールの構成
JUDE 上のステートチャート図群をFDR 記述に変換
し，Web アプリケーション化されたFDR2 で検証し，結
果を整形出力するツールFSM2FDRをJava で開発した．
おおまかな構成は図6 に示す．
FSM2FDR は，JUDE 上のステートチャート図群を
JUDE-API によって取得し，予め用意されたFDR 記述
によるテンプレートに情報を埋め込み，FDR 記述による
シナリオを生成する．
ゲームシステムに関する記述はテンプレートに書い
ておき，ステートチャート図群からはシナリオ進行に関
する記述のみを取り込む．この2 重化は，技術者の構
築したゲームシステム上で，脚本家がシナリオを記述
することに対応している．FSM2FDR とテンプレートを適
切に改変することでゲームシステムを変更でき，その制
約の上でのシナリオを開発できる．現状のFSM2FDR と
テンプレートでは，与えられた状況下でのみ可能な
パーティの組み替えや，パーティの最大構成人数の制
限などを実装している．
FSM2FDR が扱う検証項目としては，JUDE 上のコメ
ントで与えられるストーリの存在確認，そのストーリにつ
いて全てのキャラクタが必ず終了状態に到達することの
確認，全てのキャラクタが取り得る全てのストーリについ
て必ず終了状態に到達することの確認，一部のキャラ
クタが終了状態に到達できないストーリの検出，があ
る．
シナリオと検証項目を含むFDR 記述は，http を経由
して，PHP で書かれたFDR2 のWeb アプリケーション化
スクリプトに送られる．PHP のスクリプトは，checker によ
るFDR記述の構文確認の後，FDR2 のコマンドライン呼
び出しを使って検証を行う．検証結果は，http リクエスト
に対するレスポンスとして，FSM2FDR に送られる．今回
開発したPHP のスクリプトは，ブラウザで利用する対話
型インタフェースも有しており，Windows やMac から
FDR2 を部分的に利用可能である．
最終的にFSM2FDR は，標準出力とdot 形式ファイ
ルの生成によって，シナリオの検証結果を返す．dot 形
式ファイルをGraphviz で一般的な画像に変換し，キャ
ラクタ毎のストーリ全てを確認できる．
8. FDR 記述の詳細
本修了制作で行った，FDR 記述によるシナリオ表現
について述べる．
RPG のシナリオ表現としては，パーティが組めること
と，2 値の変数が利用できることを最低条件と考え，この
2 つの機能を実現した．
パーティの表現については，FDR 記述の持つ同期
遷移の機能を利用している．行動を表す全てのイベン
トに，キャラクタの集合によるバリエーションを持たせ，
キャラクタ毎のプロセスが保持するパーティメンバに対
応したイベントが駆動するようにした．また，これらのイ
ベントで，集合に含まれる全てのメンバの同期がとられ

るように並行合成し，パーティメンバ全員が同じ行動を
とるようにした．
変数の利用については，キャラクタ毎のプロセスから
アクセスされる変数を，変数毎にプロセスとして実装し
た．変数プロセスは，ONの時はOFF への書き換えを受
け入れ，OFF の時はON への書き換えを受け入れる．
また，ON の時はON かどうかの問い合わせを受け入れ，
OFF の時はOFF かどうかの問い合わせを受け入れる．
受け入れるかどうかによって変更や参照が行われる仕
組みなので，ガード条件のような振舞いを示す．実装の
容易さから，一般的な変数とは異なる実装を選択した
が，一般的な変数の実装がFDR2 に負荷を与える可能
性もあり，今後，慎重に検討したい．変数プロセスの
FDR 記述は，次のようなものである．
検証については，基本的にトレースモデル上で行っ
ている．
ストーリの存在確認については，プロセスの合成に
よって得られたシナリオに，ストーリが含まれるか，トレー
ス等価を用いて検証している．しかし，そのストーリがシ
ナリオに含まれたとしても，全てのキャラクタが終了状態
に到達できない場合は，操作中に突然ゲームが止まっ
てしまうキャラクタの存在を示しているので，注意が必要
である．そこで，そのストーリの最後に，全キャラクタの
終了状態への遷移を確認する記述を追加したストーリ
も生成し，合わせて存在確認を行っている．
キャラクタ毎に，終了状態に到達しないことがあるか，
必ず終了状態に到達できるかも重要な性質である．前
者は，シナリオに，そのキャラクタが終了状態に到達し
ないストーリがあるかで確認できる．後者は，そのキャラ
クタが終了状態に到達するという仕様を，シナリオが満
たすかで確認できる．両者は対偶命題なので，本質的
に同じであるが，次のような記述で両方を確認してい
る．
9. 評価
制作したツールを使って簡単なシナリオを記述，検
証，修正した．
C1，C2，C3，C4 の4 人のキャラクタが登場するRPG
について考える．4 人は魔王を倒すことを目的とするが，
競合関係となるため，他の誰かに魔王を倒されてしまっ
てゲームを終了する場合もある．魔王を倒す方法は何
通りかあり，最初の状態でパーティを組んだ後は，何れ
かのストーリを，そのパーティのまま，ゲーム終了まで一
緒に行動する．パーティの最大構成人数は3 人とす
る．
各キャラクタのFSM を図7 から図10 に示す．
各図に現れる状態は，ストーリ上の何らかの状態を
表しており，各図で同じ名前のものは，同一の状態を
指す．ツールで使用しない，状態のエントリー動作の記
述部に，便宜上，コメントを記入している．
パーティの組み替えが可能な状態には，ステレオタ
イプで指定を入れる仕様としており，この例では，S1 の
みパーティの組み替えが可能である．S1 にいるキャラク
タもしくはパーティの間でパーティの組み替えが行える
が，遷移して他の状態に入ってしまうと，パーティの組
み替えは行えない．
各図に現れる状態間の遷移も，イベント名，ガード
条件，変数操作，遷移元状態，遷移先状態が同じであ
れば，同じ遷移を表す．遷移の内容を変更する際には，
図の間で同期を取るのが手作業となるため，注意が必
要である．
変数操作とは，変数のON/OFF，参照のことで，遷
移アクションの記述部に「()」で括って記述する．「()」の
外側はコメントとして扱われる．
遷移のガード条件は，そのままFDR 記述に持ち込
まれるため，記述の際には注意が必要である．
なお，遷移に際しては，ガード条件にもよるが，パー
ティ内に1 人でも遷移e を持つキャラクタがいれば，
パーティ全員で遷移e を実行できる．ガード条件で，特
定のキャラクタがパーティ内にいることを禁止している場
合は遷移できない．
各図に置かれた，要素と関連のないコメントは，ツー
ルの設定情報と，存在を検証したいストーリである．
図7 上方のコメントは，ツールの設定情報であり，
FDR2 にアクセスするためのURL や，その際の認証情
報，パーティの最大構成人数が記されている．
存在を検証したいストーリについては，存在が真で
あって欲しいものだけでなく，存在が偽であって欲しい
ものも記述し，確認することができる．この例では，各図
Flag(F, S) = (S == OFF) & flag?x!F.ON ->
Flag(F, ON) []
(S == ON) & flag?x!F.OFF ->
Flag(F, OFF) []
qflag?x!F.S -> Flag(F, S)
C1NoSuccessPath = STOP
C1SuccessHiding =
diff(Events, {| success.C1 |})
assert (AllScenarioFlag C1SuccessHiding) [F=
C1NoSuccessPath
C1SuccessPath = success.C1 -> STOP
assert C1SuccessPath [F=
(AllScenarioFlag C1SuccessHiding)

に2 つずつ書かれたストーリにおいて，1 つ目は存在し
て欲しいもの，2 つ目は存在して欲しくないものを記述
しており，1 つ目が真，2 つ目が偽となることを確認しよう
としている．
この4 つの図を入力して検証した結果が図11 から
図15 である．
図11 から図14 は，シナリオの中で，各キャラクタが
取り得る全てのストーリを示している．ストーリは状態遷
移の履歴として表現されている．菱形の状態は，パー
ティの組み替えが起こる状態であり，2 重線の状態は，
終了状態に無条件で遷移する，事実上の終了状態を
示している．
黄色で塗られた状態と，そこへ至る赤字の遷移は，
そのストーリ進行が行われた場合に，正常終了できな
図7：C1 のFSM
図8：C2 のFSM

いキャラクタが存在することを示している．これはシナリ
オのバグなので，シナリオを修正する必要がある．他の
キャラクタに悪影響を与えるとされたストーリが，必ず入
れたい重要なストーリの場合，そのストーリの遷移はそ
のままに，そのストーリの裏で進んでいるストーリを特定
し，不具合を見つけ，修正することが必要であるが，現
状のツールでは支援する機能がないため困難である．
今後の課題としたい．今回は，該当する遷移をガード
条件で封じることで修正した．
図15 は，ツールが標準出力に書き出す検証結果で
ある．存在して欲しいストーリ，存在して欲しくないストー
リについては，望んだ結果が得られている．しかし，C3
について，正常終了できないストーリが存在することが
分かった．図13 を見ると，aweak 系のストーリにおいて，
先に魔王を倒されてしまった場合への対応が漏れてい
ることが確認できる．そこで，aweak 系のストーリにおい
て，tooLate を補う修正を行った．
図9：C3 のFSM
図10：C4 のFSM

図11：C1 のストーリ全体

translating start @ Tue Mar 18 03:54:17 GMT 2008
asserting step1 start @ Tue Mar 18 03:54:19 GMT 2008
(scenario11 = plan2_fromS1toS5.{C1, C3} -> toGoal_fromS5toS3.{C1, C3} -> STOP) is true
(scenario12 = plan1_fromS1toS2.{C1, C2} -> toGoal_fromS2toS3.{C1, C2} -> STOP) is false
(scenario31 = aweak1_fromS1toS6.{C3} -> aweak2_fromS6toS8.{C3} -> toGoal_fromS8toS3.{C3}
-> STOP) is true
(scenario32 = aweak1_fromS1toS6.{C1, C3} -> aweak2_fromS6toS8.{C1, C3}
-> toGoal_fromS8toS3.{C1, C3} -> STOP) is false
Checking (AllScenarioFlagC1SuccessHiding) [F= C1NoSuccessPath is false
Checking (AllScenarioFlagC3SuccessHiding) [F= C3NoSuccessPath is true
Checking C1SuccessPath [F= (AllScenarioFlagC1SuccessHiding) is true
Checking C3SuccessPath [F= (AllScenarioFlagC3SuccessHiding) is false
create step2 start @ Tue Mar 18 03:55:22 GMT 2008
(scenario11 = plan2_fromS1toS5.{C1, C3} -> toGoal_fromS5toS3.{C1, C3}
-> success.C1 -> success.C2 -> success.C3 -> success.C4 -> STOP) is true
create result start @ Tue Mar 18 03:55:29 GMT 2008
complete @ Tue Mar 18 03:55:29 GMT 2008
図15：検証結果
修正を行った，C2 以外のFSMを図16 から図18 に，
修正したものに対する検証結果を図19 から図22 に示
す．意図したとおりに修正が行われ，シナリオの不具合
が解消されたことが分かる．
ツールによる検証時間は，図15，図22 からも分かる
ように，この規模であれば2 分かからない．しかし，キャ
ラクタを1 人追加したシナリオを作成したところ，検証時
間が30 分ほどかかるようになった．モデル検査にはつ
きものであるが，状態爆発によるスケールの問題が生じ
ている．FDR 記述を精査して，モデル検査しやすい構
造を考慮したり，別のモデル検査ツールへの変換など，
今後の課題である．
ここに示した検証は，以下の環境にて実施した．
CPU : AMD Athlon 64 x2 5200+
Memory : 3GB
M/B : GIGABYTE GA-MA69GM-S2H
OS : Ubuntu 7.10

図16：C1 のFSM（修正後）

図19：C1 のストーリ全体（修正後）

translating start @ Tue Mar 18 03:55:48 GMT 2008
-> STOP) is true
(scenario32 = aweak1_fromS1toS6.{C1, C3} -> aweak2_fromS6toS8.{C1, C3}
-> toGoal_fromS8toS3.{C1, C3} -> STOP) is false
create step2 start @ Tue Mar 18 03:57:18 GMT 2008
create result start @ Tue Mar 18 03:57:23 GMT 2008
complete @ Tue Mar 18 03:57:23 GMT 2008
10. まとめ
図22：検証結果（修正後）
本修了制作では，RPG のシナリオ開発に対して，従
来手法の拡張として，キャラクタ指向開発を提案し，そ
れを支援する検証ツールを作成した．
まず問題を同定するために，従来のゲームシナリオ
開発手法を分析した．その結果，従来手法がストーリ指
向の立場であるため，複数のストーリやキャラクタ行動
の無矛盾など，RPG シナリオの満たすべき性質の実現
が困難であることが分かった．
問題を解消するために，シナリオをストーリの集合で
はなく，キャラクタ行動の集合としてモデル化する，キャ
ラクタ指向を導入することとした．キャラクタ行動はFSM
として表現可能であり，FSM の合成がシナリオである．
この考え方を従来手法と組み合わせることで，シナリオ
構造を把握しやすくなると考えた．
シナリオをキャラクタ行動全体として見ると，シナリオ
は合成された並行プロセス群と見なせるので，プロセス
代数CSP を基盤とするFDR 記述によるモデル化を採
用し，検証にFDR2 を採用した．
FSMの記述にはJUDE を用い，FSMからFDR 記述
への変換にはJava で実装した自作ツールを用い，

FDR2 はPHP スクリプトを経由して利用し，最終出力を
Graphviz に処理させるなど，プラットフォームへの依存
性を排除した．
FDR 記述で簡潔に同期遷移を表現できるため，
パーティを組むRPG シナリオの記述を適切に表現でき
た．特定のストーリの存在確認に，イベントの隠蔽と等
価性検証が，有効であることが確認できた．
モデルに持たせるゲームシステムや，スケーラビリ
ティ，ユーザビリティは今後の課題であるが，キャラクタ
指向開発の有用性は確認できた．
謝辞
本修了制作の指導教員を務めて下さった磯部祥尚
先生，TopSE プロジェクトリーダ本位田真一先生はじめ，
1 年半の間にお世話になった全ての先生方に感謝しま
す．また様々な刺激をくれた受講生の皆さんに感謝し
ます．ありがとうございました．
付記
本文書内で使用されたキャラクタ画像は以下に著作
権があります．
First Seed Material, REFMAP
http://www.tekepon.net/fsm/
参考文献
[1] 川邊一外, ゲームシナリオのドラマ作法, 新紀
元社, 2005
[2] 佐々木智弘, ゲームシナリオの書き方, ソフトバ
ンククリエイティブ, 2006
[3] 柴崎雅史, 多人数ゲームシナリオの記述と検証
法, 情報処理学会研究報告マルチメディア通信
と分散処理, Vol.47, No.5, 1990
[4] 鬼塚健太郎, マルチシナリオゲームにおける並
列世界のモデル, 情報処理学会研究報告数理
モデル化と問題解決, Vol.18, No.12, 1998
[5] 清木昌, モデル検査のゲームシナリオへの適用,
日本ソフトウェア科学会第1 回ディペンダブルソ
フトウェアワークショップ, 2004
[6] 磯部祥尚, 並行システムのモデル化と検証,
TopSE 講義ノート, 2007
[7] Formal Systems, FDR2 User Manual, 2005
[8] チェンジビジョン, JUDE API 利用ガイド, 2008

FDRによるRPGシナリオの検証

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Plus de Masaru Nagaku

Plus de Masaru Nagaku (8)

FDRによるRPGシナリオの検証