これは、RPGにおけるシナリオの記述法の1つとして推奨できる基準を 作り上げようという企画である。
一言で言ってしまえば読みやすさと再利用性のためです。 RPGのシナリオの多くは、それぞれのGM が独自に作成しています。 しかし、考えてみてください。 それぞれのGMが、それぞれのシナリオを何本も持っているわけです。 だとしたら、そのシナリオを互いに利用しあえたらどんなに良い事でしょう。 その目的のために、Nifty-serveのFRPGMには"シナリオ・ストック"という会議室が 用意されています。
ナンダ、じゃぁ、それで良いじゃないか」
ちょっと待ってください。 ここで一つ問題があるのです。 つまり、
『人の書いたものは読みにくい』
という問題なのです。 しかも、GMが用意するシナリオの大多数は、GM自身にさえ内容が分かれば良いという、 いわばメモのようなものなのではないでしょうか? つまり、他人の作ったシナリオを理解するためには、 非常な労力を必要とされるのです。
そしてその労力は、シナリオの各部分の依存間の関係等のような、 簡単には読み取りにくい部分に対して注がれているのではないでしょうか? だとしたら、そのような手間のかかる部分をはっきりと示すような書き方の、 それも多くの人が用いるような書き方の基準のようなものがあれば、 読み取りにかかる労力の多くは削減できるはずです。
だだし、ここで考えるのは単なる読み易さではありません。 というのも、私としては『シナリオのデータベース』という考え方の方が重要でして、 その形式がしっかりしたものでかつ統一されていれば検索もし易いし、 またそうであれば人間にとって実際に読み易い形式にも(多分)簡単に変換できると 思うからです。 そんなわけで、シナリオ記述形式の基準となるようなものを考えてみたら どうだろうというアイディアが出てくるのです。
具体的には、SGMLと呼ばれる形式にもとづいて考えてみたいと思います。 と、以前は言っていたのですが、SGMLはその規格が大きいこと、また Web上ではSGMLのパーザーを組み込んだブラウザが一般的ではないことなどから、 若干路線を変更します。 現在は、SGMLではなく、XMLに基づいたものにしようと考えています。
例えば、この文章にもある種の構造があります。 その構造とは、「はじめにタイトルと著者などが書かれ、 次にいくつかの章が並び、 最後に参考文献がつく。 章の中には節と、あるいは段落やリストなどが並ぶ。 節の中にもやはり段落やリストなどが並ぶ」 というものです。 これを、SGMLの形式で書いてみると次のような感じになるでしょう。
<book>
<title-page>
<title> シナリオ記述形式検討会議(?) </title>
<autoher> 小林聡 </autoher>
</title-page>
<chap>
<chap-title> はじめに </chap-title>
<sec>
<sec-title> シナリオ記述形式検討会議って何だ? </sec-title>
<p>これは、RPGにおけるシナリオの記述法の1つとして
推奨できる基準を作り上げようという企画である。
</p>
</sec>
:
:
</chap>
:
:
</book>
説明は無くても分かると思いますが、 SGMLではある項目を示すタグが <x> であれば、 その項目の終了を </x> という形で書きます。
上の例は、 そのままではちょっとばかり人間には読み難い形になってしまいますが、 構造の要素の1つ1つにきっちりタグが付くわけです。 このような形式は、TeXなどの テキストフォーマッタに慣れている人には、 違和感が少ないと思います。 実際、SGMLももともとはと言えば (というよりもSGMLの先祖はというべきか)、 TeXなどのようなテキストフォーマッタのための記述方式として構築が始まった ものなのです。 まぁ、文章を記述するためのみであれば、 SGMLよりもTeXなどの方が良いかも知れません。 ただし、SGMLは具体的なフォーマッタとは独立である点、 つまりどのようなフォーマッタにかけるのであれ、 ソースファイルがSGMLで書いてあれば特定フォーマッタのための形式に簡単に 変換できる点が良いと言われています。 まぁ、このあたりは、私個人としては今一つ眉つばものと感じていますが (TeXでの、図表の位置合わせに苦心された方は、 この気持ちが分かってもらえるものと思います)。
しかし、SGMLの良さは、文章処理を考えただけでは分かりません。 たとえば、先の例をもう一度見て下さい。 良いですか、SGMLは文章の構造を示すタグが付いています。 それは、見方を変えれば、そこに書かれていることが構造上どのような位置に 位置するものかを表している訳です。 あるいは、形式上どのような内容のものであるかを表していると捉えても 良いでしょう。 どちらでも同じことです。 このことを説明するのに、次の例を見て下さい。
名前 小林聡
読み こばやしさとし
住所 静岡県浜松市布橋3-7-20.....
なんかピピっと来ませんか? では、これをSGMLの形式で書いてみましょう。
<address>
<name> 小林聡 </name>
<read> こばやしさとし </read>
<where> 静岡県浜松市布橋3-7-20..... </where>
</address>
私の言いたい事が分かりましたね。 つまり、SGML文章は、そのままデータベースになりうるのです。 それもフリー・テキストの。 もっとも、これだけでは、その辺のデータベースソフトに 任せておけば良いと思われることでしょう。
さて、SGMLを使う事の最大の利点は、上記2つを統合できるという点に有ります。 つまり、データベースでありながら、 文章処理のソースともなりうるということなのです。 たとえば最近流行のmosaicですが、 mosaicの処理する文章はHTMLという形式で書かれています。 このHTMLはSGMLのサブセットというか、SGMLに基づいた一つの定義セットなのです。 ですから、 いかなるものであれSGMLで書かれた文章をHTMLに変換可能ですし (まぁ、だいたいにおいて)、 それによってマルチメディア、 もしくはハイパー・テキストとしてmosaicなどのソフトウェアによって 表示可能になるのです。 また、その文章はデータベースとしても使用可能なのです。
というわけなのですが、Sun microsystems や、 Microsoft もそして確か Netscapeも、XMLをサポートするということを表明しております。 ですから、XMLの規約が確定した場合には、 NetscapeもIEもXMLのパーザーをそれぞれのWebブラウザに組み込むことに なると思われます。
また、HTMLでは独自の内容のためのタグセットを定義できなかったのですが、 XMLではそのようなタグセットが定義できますし、 またCSSやDSSLなどの、まぁタグと表現との関係を処理する方法も XMLに合わせて標準化されつつあります。
このような状況を考え、また現時点では私個人のですが要求を 考え合わせると、XMLにおいてRPGのシナリオを記述するための タグセットを考えることには十分に意味が有ることだと思います。
これで、SGML(XML)を使おうという理由が分かっていただけたと思います。 こんな良い環境が整っている、もしくは整おうとしているのに、 それを無視する理由はどこにも有りません。
なお、その文書をデータベースとして使うためには、そのための ソフトウェアが必要になります。 できれば、そういうソフトウェアを作ってくださる方にもこの企画に 乗っていただきたいと思います。
まずはシナリオを大雑把にその要素に分割してみましょう。 シナリオには次のような要素があるとおもえるのですがいかがでしょうか?
1. シナリオ名など シナリオ名、著者、ジャンル、想定RPGなどを書く
2. シーン シナリオをどのような部分に区切れるか。
3. 登場人物 どのような人物が登場するか。
またそれらの間の人間関係は。
4. 場所 どのような場所が登場するか。
またそれらの間の地理的な位置関係は。
5. アイテム 何か特殊なアイテムを用いているか。
では、以下ではこれらのそれぞれについてより詳しく考えてみましょう。 ここから先は、現在、簡略化を行なっている最中ですので、 見てもらってもあまり意味はないかもしれません。 ただ、これまでどういう考えかたでいたのかについては 多少なりとも分かっていただけるかもしれません。 その上で、後に簡略化したタグセットを記述すると思いますので、 それに対して、あるいは今にでも何らかのご意見を頂ければ幸いです
<feature>
<name> 名前 </name>
<size> シナリオの大きさ </size>
<genre> ジャンル </genre>
<system> システム </system>
<mission> PCの目的 </mission>
<author> 著者 </author>
<date> 日付 </date>
<desc> ちょっと付記的な内容。
そのために段落(<p>)や発言(<u>)、
リスト(<list>)、
図(著者によって既にフォーマットされているテキスト)
(<pre>) が必要でしょう。
また、HTMLに変換して読む場合のために、目次もここに
<list>環境を使って書いておくと良いでしょう。
</desc>
</feature>
これらの現れる順番は自由です。
しかし、検索の場合を考えると、たとえ内容は無くとも、書かれているべきでしょう。
例えば、<system>で考えてみた場合、
「想定しているシステムは無い」という場合でも、<system>そのものを
書かないのではなく、<system>の内容として「不特定」というような内容を
書いておくべきです。
というのも、<system>の内容が「不特定」であるものという条件で検索を
行なう可能性が有るためです。
もちろん、その項目が書いて無ければ、それはデフォルトで「不特定」であると
する方法もありますがそれは検索ソフト次第であり、
どのような検索ソフトもそのように動作するとは限らないからです。また、<feature>にはIDが必要です。 というのもHTMLなどに変換して眺める場合ですが、 他のシナリオ(例えばキャンペーンの別のシナリオ)などからリンクが張られる場合が 考えられるからです。
なお、</feature>,</desc>,</u>,</pre>, </fig>,</sound>,</list>を除き、 他の終了タグは省略できます。 また、<p>,<u>,<pre>,<fig>,<soud>,<list>に ついては、後に シーンの記述のところで説明します。
また、それぞれのシーンには、そのシーンの名前、 シーンの機能(シナリオの作り方"stmk "をお読み下さい)、 そこで使われるアイテム、場所、人物、次のシーン、 そして内容となるパラグラフや発言や箇条書きが必要となるでしょう。 そうすると、シーンの内部構造は次のようになると思います。
<scene id="this-scene">
<name> シーンの名前 </name>
<function> シーンの機能 </function>
<U.cast> このシーンで使われる登場人物
=-=
</U.cast>
<U.item> このシーンで使われるアイテム
=-=
</U.item>
<U.stage> このシーンで使われる場所
=-=
</U.stage>
<N.scene> 次ぎに続くシーンの名前。
もちろん複数書ける。
<if> 条件 <then> 条件が満たされた場合に移動するシーン。
ここで、<then>はそのまま<link>を表す。
</then>
</N.scene>
<desc>
<p> 段落 ここから下は、当然複数回づつ書けます。
<u> セリフ
<who> 発言者の名前。
もちろん<link>..</link>も書ける。
<ln> 発言の内容。
もちろん<link>..</link>も書ける。
</u>
<pre>
とりあえず、一番貧弱な環境では、テキストしか表示できない訳だから、
地図なんかもテキストで書くのが良いと思います。
あるいは、そのほか特別な体裁で書いておきたい場合もあるでしょう。
そのような場合に、このタグを使います。
</pre>
=-=
=-=
</list>
<fig ref="filename"> 絵を指定します。
<link> と同じ機能を想定しています。
</fig>
<sound ref="filename"> 音を指定します
<link > と同じ機能を想定しています。
</sound>
</desc>
</scene>
ここでは、</name>,</function>,</li>,</if>,
</who>,</ln>,</p>を除き、終了 タグは省略できません。
また、<fig>や<sound>は後にパソコン上でも
良いHTML(or SGML)-Viewerができた時のことを考えてのものです。
一般に使われるということをおこがましくも考えると、
現状ではまだまだグラフィックや音声を手軽にコピーというわけには行かない
状況にあります。
そこで、グラフィックや サウンドデータを用いたシナリオの提供はまだしばらくは
主流とはならないであろうというお気楽な考えによる決定です。では、それぞれについて説明して行きたいと思います。
@@@@@ まだここまでです。
参考文献
[3] SGMLの活用 (総合マルチメディア選書)
根岸 正光 石塚 英弘 共著
オーム社 刊
ISBN 4-274-07808-6