シナリオの構造化と記述のためのフォーマット形式

本書は1998年頃に書いたもので、現在では私自身この内容に従った書式でシナリオを記述していません。メンテナンスもせず放置しておくつもりでしたが見直してみるとそれなりに役立つことも書いているのでタグの打ち直しをしました。

はじめに

しばらく前から、私はシナリオを作るときに「シナリオには一般的なパターンがある。また、一般的な導入の方法や展開をその要素ごとに切り出しておいて、決まった(もしくは簡単に組み立てられる)骨格に組み込んでゆけば簡単にシナリオを作れるならば便利だ」と思っていました。

また、「他人の作ったシナリオは読みにくい」とよく言われます。これは、自分がシナリオを書くときと記述の仕方が同じではなく、シナリオが小説などのように長い文章で記述されるため要点をつかみにくいためだと思います。また、市販のシナリオなどは一度きちんと読んで理解し、それをわかりやすくまとめる必要のあることがよくあります。

それでは、シナリオの記述形式をある程度の論理構造によって決定し、そこに部品としてシナリオの要素を組み込んでゆくようにできればシナリオの記述が簡単になるのではないでしょうか。また、シナリオを作る度に使った要素を部品としてライブラリー化しておけば次にシナリオを作るときに便利ではないでしょうか。そして、シナリオ全体の構造が容易に把握できればいわゆる「一本道シナリオ」、「吟遊詩人マスター」と呼ばれる類のシナリオを(本意ではなく)作らなくてすむのではないでしょうか。

また、TRPGのシナリオは読んでおもしろいことよりも実際にセッションで遊んでみておもしろいことが重要です。そのためには、シナリオの意図を正確に理解してもらう必要があります。そして、それはシナリオ内に記述されている内容で全て分からなくてはなりません。小説などのように「行間を読む」必要があるなどということがあってはいけないのです。つまり、1つのシナリオを複数の人間が読んだならば同じようにシナリオの目的、要点が理解できなければいけないのです。

以下に、この様な考えに基づいて作られたシナリオの記述形式を示します。

全体をとおして共通の概念

この形式では基本的にシナリオはその要素ごとに部品化して記述します。この様な部品のことをシナリオのオブジェクト、または単にオブジェクトと呼びます。そして、シナリオはオブジェクトの集合体であると考えます。更に、シナリオ自体もオブジェクトであると考えます。オブジェクトは基本的に以下のものに分類されます。

ファクター

シナリオを構成する最小要素です。シナリオ中の一つ一つの細かな出来事のことを言います。

例えば、「依頼人がキャラクターのところへやってくる」、「依頼人が依頼の内容をキャラクター達に告げる」などの細かな出来事のことを指し示します。

ファクターは別のファクターを呼ぶことが出来ます。

上記の例で言えば「依頼人がキャラクターのところにやってくる」というファクターは「依頼人が依頼の内容をキャラクター達に告げる」を呼びます。

ファクターはその内容に分岐する条件を持つことが出来ます。また、分岐の条件によって異なるファクターを呼ぶことができます。

ファクターは次のファクターを指し示す場合、次にどこを(何を)呼び出せ(参照しろ)という記述しかできません。

イベント

シナリオにおける連続性のあるファクターやイベントの集まりをイベントと呼びます。シナリオ中の一つのシーンのことと考えてもらってもかまいません。ただし、イベント自体には実体がないことに注意してください。イベントは関連性の強いファクターやイベントをまとめた入れ物の様な物です。イベントは最低1つ以上のファクターを含まなくてはなりません。

例えば、「依頼人がやってきて依頼を引き受けるまで」や「依頼を受けた町から目的の遺跡までの移動」などがイベントと言うことになります。

また、イベント内のファクターはイベントの途中でも別のイベント中のファクターを呼び出すことが出来ます。そして、呼び出されたイベントの内容と進行状況によっては更に別のイベントへと進むことが出来ます。もちろん元のイベントの元のファクターに戻ることも出来ますし、別のファクターに進むことも出来ます。これらのイベントの呼び出しはファクターによって記述されます。

グループ

グループは基本的にはイベントの一種ですがグループ内のイベントやファクターは時間的な順番が決まっていません。逆にいえば、キャラクターの行動によってどのような順番で起こるかはわからないが、同様の目的やあるシーンにおいて関連性の強いイベントやファクターをまとめたもの、ということができます。

スケルトン

シナリオの構造を規定するもので「導入」、「展開」、「結末」という3種類のものに別れます。基本的に1回で完結する単発のシナリオではこの構造には大きな意味は有りませんが、キャンペーンシナリオのようにシナリオが次のシナリオを呼び出すような場合に意味を持ちます。このような場合は前回の結末によって導入をいくつか用意する必要が有るでしょうし、次回のことを考えるといくつかの結末を準備することになります。特に、キャラクターごとに結末や導入がが異なる場合には重要です。そして、キャラクター同士が関わり合いになるシナリオの本体は「展開」として記述します。基本的にあるキャラクター(グループ)だけが独立してシナリオが進行する場合は「展開」が複数有ってもかまいません。

スケルトンもイベント同様に実体を持ちません。スケルトンにはそれぞれ最低1つのイベントもしくはファクターを含まなくてはなりません。

グローバルデータ

シナリオ中で用いられるNPC(ノンプレイヤーキャラクター)やアイテム、地図、等のデータ類のことです。

シナリオ

これらのオブジェクトすべてをまとめたものをシナリオと呼びます。

以下に、これらのオブジェクトについての詳細な説明を行います。

オブジェクトに共通の記述形式

ファクター以外のそれぞれのオブジェクトは次の様な共通の記述形式を持ちます。

まず、オブジェクトの記述は「ヘッダ」部分と「ボディ」部分に別れます。そして、ヘッダ部分とボディ部分は線を引いて区別します。ヘッダ部分は必要がなければ書く必要は有りません。ボディ部分が存在しないオブジェクトは存在しません。

ファクターは基本的にヘッダ部分を持ちません。ただし、他のファクターから呼ばれる物は参照しやすいようにヘッダ部分に題名を持ちます。なお、ヘッダ部分をもてないわけでは有りません。ファクターはイベントやスケルトンとは記述の仕方が異なります(もっと単純になります)ので別に説明します。

グローバルデータも基本的にヘッダ部分を持ちません。

ヘッダ部分の記述

ヘッダ部分にはそのオブジェクトの題、開始時間等の初期状況を示すパラメータ、前提条件等を記述します。わかりやすいようにオブジェクトの題名以外は箇条書きにしてください。また、参照すべきデータや地図なども記述しますがそのようなものについてはそれぞれ参照すべきオブジェクトの題名を記入します。ヘッダ部分に書かれた前提条件はそのオブジェクト内に含まれるすべてのオブジェクトの前提条件になります。

前提条件はシナリオ作成者が決めたものであり最初から書き込まれています。それに対して初期状況とはイベントなどが始まった時点で記録しておくべきことを言います。ですから、チェック項目が書き込まれているだけで内容は後から書き込む場合がほとんどです。

また、それぞれの項目には項目名を付けてください。例えば「日付:」、「天候:」、「キャラクターの平均レベル:」、などと言う具合にです。

なお、ヘッダ部分に記述することがないならば書かなくてもかまいません。

ボディ部分の記述

ボディ部分には具体的な内容を文章やデータとして記述します。イベントやスケルトンではファクターが書き込まれますし、グローバルデータではデータやその説明が書き込まれます。

題名の付け方

オブジェクトを参照する場合に検索性を増すため題名の付け方に次の様な規則を設けます。

まず、そのオブジェクトがなんであるのかを区別するために分類名を付けます。下のリストの「導入:」や「イベント:」などです。そして、その後ろにシナリオを作ったものが自分でつけた題名を記述します。また、下記の様な分類名の下に更に分類名を付けてもかまいません。例えば「アイテム:武器:~~~」のようにです。工夫して行えばより検索性が増し、オブジェクトの再利用を行いやすくなるでしょう。しかし、むやみに分類を増やすことは逆に検索性、理解しやすさを損ないます。分類名はせいぜい3段階程度に押さえるべきです。

  • スケルトン
    • 導入:~~~
    • 展開:~~~
    • 結末:~~~
  • イベント
    • イベント:~~~
  • グループ
    • グループ:~~~
  • グローバルデータ
    • アイテム:~~~
    • NPC:~~~
    • 地図:~~~
    • etc.

図で表すと以下のような形式になります。なお、イベント、スケルトン、グローバルデータはそれぞれ別の紙に記述することを推奨します。例えば、データならばモンスター1種類につき1枚、アイテム1つにつき1枚などです。このようにすればデータをプレイヤーに見せる場合に便利です(そのデータを書いてある紙を渡せば良い)し、イベントなどはスケルトンの中に埋め込むよりも検索性が増します。

分類名:題名
  • 初期状況
    • 時間:~~~
    • キャラクターの平均レベル:~~~
    • etc.
  • 前提条件
    • 地図:~~~
    • 季節:~~~
    • etc.
  • etc.

スケルトン、イベントならばそこに含まれるファクターを記述する。

データならばデータのないようを記述する

グローバルデータ

シナリオの個々の要素を記述する前に、シナリオ全体を通して重要な情報を記述しておきます。記述しておくべき情報としては次のようなものがあるでしょう。また、これらの情報の詳細は別の紙に記述しておいた方が参照しやすいと思います。

なぜ、最初にこの様な情報を記述しておくかというと、如何によく考えられたシナリオでもTRPGである限りPCがマスターの予想外の行動をとることがあるからです。当然、そういうときは今まで市販のシナリオでもマスターのアドリブで切り抜けなければなりませんでした。それはこのフォーマットに基づいてシナリオを記述したとしても同じです。ですから、そのようなときに必要となる情報をよりわかりやすくするため、一番最初に記述する必要があるのです。従って、シナリオ中でマスター(シナリオデザイナー)がPCの行動を予測して記述したそれぞれの要素では判断できないことが起こったときに判断の基準となるものを最初に全体的な情報として記述する必要があるのです。

スケルトン

シナリオの骨格についての記述の仕方を説明します。この構造はキャンペーンの様な巨大なシナリオを想定したものです。単発のシナリオの場合はそれほどの必要性が有るわけでは有りませんが、前回の結末を利用したい場合などには必要になります。

まず、どんなシナリオでも基本的に次のような構造をとるはずです。

導入 → 展開 → 結末
導入
キャラクターが依頼を受けたり、事件に巻き込まれたりといった、キャラクターがシナリオに絡むための要素のことをいいます。
展開
導入を受けて依頼をはたすために働いたり、事件を解決するために捜査を行ったり、敵を倒したりするシナリオの本筋の部分をいいます。この部分にはシナリオを解決するまでの部分が含まれます。
結末
とはシナリオが解決された(失敗した)後の事後処理の部分をいいます。例えば、仕事を終わらせて報酬をもらたっりするという部分です。

時間的な経過としてこの3つの流れは前後することはありません。ただし、導入、展開、結末はそれぞれ複数存在する可能性はあります。例えば、キャラクターごとに導入を変えるとき、導入の結果によってシナリオの展開が大きく異なる(別のシナリオになる)ときやシナリオの展開の途中でも別のシナリオに展開する可能性のあるときなどです。この様な場合は導入と導入といった区切りは時間的に平行しても問題ありません。

この様な大まかな区切りを組み合わせたものがシナリオの骨格であり、「スケルトン」と呼びます。シナリオはこのスケルトンごとに、記述してゆきます。シナリオの大体の骨格をこれによって記述したら、次にその中身になる個々の要素を記述してゆきます。

ここのスケルトンは次のような様式で記述します。まず、紙の一番上にスケルトン名を書きます。スケルトン名とは導入、展開、結末という名称です。またいくつかのパターンが有るならば「導入:~~~」、と~~~の部分に題を書くか「導入:No.1」のように番号を書きます。番号の前には「No.」や「番号-」のように何か言葉をつけてください。これは、「展開:1」と書いた場合その番号が「ファクター」であるか「スケルトンの名前」であるかを区別するためです。

スケルトン名(導入、展開、結末):題、番号
  • スケルトン内のファクター。
  • イベントを呼び出す条件。
  • スケルトン終了時に呼び出すスケルトンの記述。

スケルトンも当然オブジェクトですので本来ならば別々の紙に記述してゆくのが正しいのですが、それではシナリオの流れがつかみにくくなることが多くなります。これでは本末転倒ですので、そのシナリオにおいて主要な流れであると考えられるスケルトンは「導入」、「展開」、「結末」と一枚の紙に書いて問題ありません。また、「結末」はいくつも考えられるが、「導入」と「展開」は基本的に一つの流れであると言う場合などは「結末」だけをいくつか別々の紙に書いても問題ありません。

イベント

イベントはシナリオ中の個々のシーンを表現する単位です。イベントは基本的に1つのシーンが開始してから終了するまでを記述します。

まず、イベントはシナリオを書くものが自分でそのイベントの名前を決定します。そして、その中にはそのイベントが終了するまでのファクターが記述されます。その、イベントが終了するためのファクターでは次に呼び出されるイベントを記述するか、スケルトン内のどの位置に戻るかを記述しておきます。イベント終了の要素は複数存在して問題ありません。また、その途中で別のシーンへと移行することも可能です。

例えば、NPCがキャラクターに依頼を持ってきたとします。そこでNPCは基本的な条件と目的を最低限しゃべっていてそのまま次のイベントに進むことが可能であるとします。しかし、報酬が不満だとして交渉を行おうとするキャラクターは当然いるでしょう。この様な状況を考えると交渉シーンは別のイベントとして独立させておくことができます。そして、この交渉シーンのイベントはは依頼にきたというイベントの途中に存在するであろう「キャラクターが報酬などの交渉を行うなら・・・」というファクターによって呼び出されます。

さらに、一つのまとまったシーンであると考えられるものや、まとまった情報を持ちいろいろなところで参照される可能性が高い、と考えられるものは独立したイベントとしておくことを進めます。例えば、先ほどの「NPCが依頼を持ってきた」という例で依頼の内容は「ゴブリン退治」であったとしましょう。そして、「ゴブリンは依頼主の村の近くの森に住み着いている」ということを聞かされたとします。この様な場合、キャラクターはもっと情報を求めるでしょう。「イベント:情報収集」と言うイベントを作るべきです。そして、このイベントには村の近くの森に住み着いたゴブリンの情報で村人が知っていること全てを記述しておきます。この様にしておけば、例えば「村に着いてから聞き忘れがあったからもう一度情報収集をする」という行動をとった場合でも同じ「イベント:情報収集」を参照すればよいだけです。

この様な方法は巨大なシナリオで、何度も情報収集を繰り返さなくてはならないときに役にたちます。

イベントを記述する場合、イベントの題名、ヘッダ部分とボディ部分に別れます。

ヘッダ部分にはそのイベントの初期条件を記述したり、そのイベントに入った時にメモしておくべきことを記述しておきます。

ボディ部分にはそのイベントに存在するファクターを記述して行きます。

イベント書式は以下のようになります。

イベント名
  • イベントが開始されるゲーム内時間
  • 参照する地図
  • 参照するNPCデータ
  • 参照するアイテムデータ
  • etc.

イベント内のファクター。

イベントはそれぞれ別の紙に記述します。その様にした方が検索性、参照のしやすさがまします。また、シーンの切り替えが明らかになるためシナリオ中のチェックポイントとしても利用できるはずです。

イベントがファクターによって呼び出される場合はその題名「イベント:~~~」を使って参照します。例えば次のように記述します。「キャラクター達がゴブリンにつても情報を聞こうとするなら「イベント:情報収集」へ。」という具合です。

ファクター

ファクターとは、シナリオ内の1つ1つの小さな出来事を指します。それぞれの要素のことをファクターと呼びます。1つのファクターはある出来事が起こってその結論が出て次のファクターを呼ぶまでのことを記述します。

 ファクターが特に分岐することもなく進んでゆく場合は題名を持ちません。

しかし、他のファクターから参照されるファクターには参照先を指し示すために題名が必要ですがイベントのようにいちいち題名を考えるのは面倒です。ですから番号を振ってください。番号は1、2、3、・・・と順番に振られます。しかし、一つのファクターから更に分岐してゆくことがあると思います。その場合は親になるファクターの番号のしたに更に番号を振ります。そして、親を示す番号とその子供の番号は「-(ハイフン)」で区切ってください。例えば3番のファクターを親にしてそのしてに分岐してゆく場合は3、3-1、3-2、3-3、・・・となります。

また、他のイベントやスケルトン内のファクターを参照する場合は「イベント:イベント名:ファクターの番号」という風に書きます。例えば「イベント:情報収集:1-3」という風にです。

なお、ファクターに次に参照するファクターの番号が書いてない場合は真下のファクターへと進みます。なるべく自然な文章にするためにもこの方法は使った方がよいでしょう。

それぞれのファクターは次のような書式で記述します。わかりやすいように途中で改行などを入れるのは自由です。ファクターとファクターの間には1行もしくは2行の改行を行ってください。

番号

ファクターの内容

判断の方法

判断の結果「その結果呼ばれるファクターの番号」

例えば、ある商人が午前10時にPC一人あたり金貨10枚で護衛を引き受けてくれるようにという依頼を持ってきたとします。そのとき、キャラクターは報酬の交渉を行うだろうと予測します。その場合は次のように記述します。

導入

導入のヘッダを記述

商人がPC(誰でもよい)にパーティー全体でPCの数×10枚の金貨で護衛をしてくれるように依頼にくる。

交渉を行う場合は「1」

素直に引き受ける場合は「2」

1

“交渉”の技能の対抗ロールで判断。達成値の差1毎に銀貨5枚ずつ報酬を増やす。ただし最高でも一人、金貨15枚まで。

2

翌朝、6時に町の東門に来るように、PCに告げて商人は帰ってゆく。「イベント:村」

グループ

基本的にこれまで説明してきた方法はイベントやファクターが時間的に順番に並んだものを扱うことを想定しています。しかし、イベントなどが順不同で起こっても問題無い、もしくはキャラクターの行動によって順不同に起こるのが普通だ、という場合が存在します。

例えば、キャラクターが殺人事件の捜査のために聞き込みを行う場合を考えてみます。このような場合では、どの人物からどんな順番で聞き込みをするかはわかりません。

この様に順不同に起こるイベントやファクターをひとまとめにして、そのまとまりの中では順不同に扱えるというオブジェクトとして「グループ」というものを定義します。グループは実際のところイベントの一種なのですが、その中に記述できるものの特異性からイベントとは区別して扱います。

グループもオブジェクトですのでほかのものと同様にヘッダ部分とボディ部分を持ちます。そして、次のような条件を満たした上で記述します。

例えば、ある殺人事件に関する聞き込みをする場合の「殺人事件に関する聞き込み」というグループの記述は以下のようになります。

グループ:殺人事件に関する聞き込み
  • 発生条件:PCが聞き込み捜査を行うことにしたときならいつでも
  • 時間経過:何時のイベントごとに半日経過
  • 登場人物:目撃者A、目撃者B、被害者の家族、被害者の友人A、被害者の友人B
  • 目撃者Aに聞き込みに行く -> 「イベント:目撃者Aに聞き込み」
  • 目撃者Bに聞き込みに行く -> 「イベント:目撃者Bに聞き込み」
  • 被害者の家族に聞き込みに行く -> 「イベント:家族に聞き込み」
  • 被害者の友人Aに聞き込みに行く -> 「イベント:友人Aに聞き込み」
  • 被害者の友人Bに聞き込みに行く -> 「イベント:友人Bに聞き込み」

全体を通して

基本的に、以上でこの形式に基づいたシナリオの記述の仕方は全てです。ただし、この方法で記述したシナリオは実際にセッションを運用するときには参照を行いやすいと思いますが、全体の流れをつかむには不向きです。そのため、全体の内容をつかみやすくするためそれぞれの要素の中から本道だと思えるものを抽出して簡単な文章にした要約を付けるべきです。

それでは、以下に全体をどのように記述するのかを示しておきます。

また、添え字としての1、2、・・・m・・・nはいくつ目のものかを表すだけで大きな意味はありません。

「シナリオの題名」
シナリオの要約を書く。

シナリオ全体のヘッダ

  • 季節:
  • 大まかな場所:
  • 文化的背景:
  • 前回から引き継ぐ情報:
  • etc.
  • グローバルデータ:NPC
  • グローバルデータ:地図
  • グローバルデータ:アイテム
  • etc.
導入
導入のヘッダ

ファクター

内容を記述する

呼び出される[イベント等]

:

:

:

n

ファクター

内容を記述する

呼び出される[イベント等]

展開:1
展開のヘッダ

ファクター

内容を記述する

呼び出される[イベント等]

:

:

:

n

ファクター

内容を記述する

呼び出される[イベント等]

結末:1
結末のヘッダ

ファクター

内容を記述する

呼び出される[イベント等]

:

:

:

n

ファクター

内容を記述する

呼び出される[イベント等]

グローバルデータ:地図

内容を記述する

グローバルデータ:NPC

内容を記述する

グローバルデータ:etc.

内容を記述する

イベント:~~~
イベントののヘッダ

ファクター

内容を記述する

呼び出される[イベント等]

:

:

:

n

ファクター

内容を記述する

呼び出される[イベント等]

イベント:~~~
イベントののヘッダ

イベントのボディ

:

:

:

イベント:~~~
イベントののヘッダ

イベントのボディ

実際にこの例に従って記述したシナリオの例を示しておきます。シナリオの例

『The Lunatic』