Goto (trpg-xml ML) HTML Log homepage
Date: Thu, 09 Sep 1999 20:57:37 +0900
From: 梶田晃一 <kajita@trpg.net>
Subject: [trpg-xml:00097] Re: 【質問】システム関連情報
To: trpg-xml@trpg.net
Message-Id: <199909091154.UAA21342@pk.highway.ne.jp>
In-Reply-To: Your message of "Wed, 08 Sep 1999 08:35:11 +0900" <199909072335.XAA10894@caine.vox.tutkie.tut.ac.jp>
References: <199909072335.XAA10894@caine.vox.tutkie.tut.ac.jp>
X-Mail-Count: 00097
梶田＠システム関連モードです。
こんばんは。
> >【意思疎通の為の質問】
> >
> > 上の文章を、小林さんのページ的に言うと
> > 「DTDとして汎用シェル（またはエンジン）を用意しておけば、良いのではないか」
> >
> > と言う事でしょうか？
>
> えーと、シェル、エンジンというのはやはりシステム部分の用語だと思い
> ますので、ちょっと...ただ、概念的にはそういう感じです。汎用部分を用意
> しておくか(こっちがエンジン的発想)、記述形式として汎用のものを用意する
> か(こっちがシェル、あるいはメタシステム的発想)という感じですね。
メタシステム？。
すいません。頭がついて行きません。（笑）
（多数の役に立つ具体的なDTD → エンジン
きちんと統一性の取れた小さなDTD → シェル ？？？）
一応こちらの理解としては、
「大体、意思疎通が出来ている」
って事で構いませんか？〈不安〉
skoba> >【答えられるだけの回答】
skoba> >
〈中略〉
skoba> > この違いは、前者がシナリオという漠然とした存在の話しであったのに対して、
skoba> > 後者が、セッションに利用するシナリオを対象にして話をしているからです。
skoba>
skoba> えーと、この辺は私も理解しています。以前も書きましたように、本来特
skoba> 定のRPG A用に作ったシナリオを、別の人がその RPG A で使い難くなってしま
skoba> うのでは、本末転倒だとは思っています。ただし、特定のRPGの情報を記述す
skoba> る構造が必要かと問われると、「それ専用の記述形式は必要ないのではないか?」
skoba> と考えています。
大体、ここら辺はわかりました。
XML的に言うと
「個々のシステムに依存した要素名や属性名、属性値等を出来るだけ
無くした方が良い。（よっぽどの時はネームスペースとかを使って・・・〉
しかし、そこで用意した要素名、属性名、属性値が、個々のシステムの情報を
表現できないと言うのは望まない。」
skoba> >【意思疎通の為の質問２】
skoba> >
skoba> > ここで小林さんが、仰られているシナリオは、
skoba> > 「ストーリーの骨組み、ストーリーの構造体」
skoba> >
skoba> > という扱いでしょうか？それとも
skoba> > 「実際にすぐに使える、セッション運営書を含んだストーリー体」
skoba> >
skoba> > なのでしょうか？
skoba>
skoba> えーとですね、私としては「実際にすぐに使える」という既成シナリオは、
skoba> 存在しえないと考えています(あー、RPGの導入シナリオは別かな...?)。とい
skoba> うのも、どうしてもそれぞれのグループに合わせた調整が必要になるはずだか
skoba> らです。で、あるならば、「ストーリーの骨組み、ストーリーの構造体」と、
skoba> どう違うのでしょうか?
skoba>
skoba> もちろん、運営上の注意などは含むべきであると思いますが、それらは
skoba> 「運営上の注意」という項目を設けて書いておけば良いことですよね?
ちょっと、私の方が言葉足らずでした。
質問を投げる前は、
「どのシステムにも対応するシナリオを求めているんだから、システム依存の
情報は切り捨ててある、一種のストーリーだけの文章を求めているのかな？」
「それの対比としては、システム依存の情報（数値とか〉を含めた、セッションが
運営できるストーリーって所だろう。」
と思っていましたが、今回の一つ前のお答えで、それが勘違いである事が
判りました。
（ちょっと舌足らずでスイマセンでした。）
skoba> > この文章で想定していたのが、
skoba> > ・「トーキョーＮ◎ＶＡ」や「ブレイド オブ アルカナ」 の登場判定〈ら辺〉
skoba> >
skoba> > です。これらのルールがどの様にシーンに関わってくるのかとかも、上の
skoba> > シナリオの構造の様に考えなければならない話だと思います。
skoba>
skoba> 登場判定って、どんなのですか? ご都合主義的「実はそこに居た」という
skoba> 系統でしょうか? もしもそうであれば、それはセッション運営上の問題であり、
skoba> シナリオ記述の問題では無いように思います。
これに関しては２つ。
【登場判定について】
・今までシーン毎にセッションを運営する事はマスタリングとして行われていたが
それを、システムに取り入れ、各シーン（GMが規定する）にどのPCが登場しているかを
判定で決めるもの。（当然GMが登場して良いPCを決める事も出来る〉
PLが判定を望み、判定に成功したPCは、そのシーンに居る事が出来る。
例：
GM「じゃぁ、スラム街の路地裏のシーンです。登場しているのは、フロック（PC)だけ。」
梶田(PL)「GM、登場させたいから、登場判定して良い？」
GM「良いよ。」
梶田（PL)「成功ね。」
GM「オッケィ。じゃぁ梶田のPCのマイケルも、路地裏に居るって事で。」
【セッション運営とシナリオ記述】
これはかなり個人的な意見ですが、セッション運営の方法書を書くとしたら、それは
シナリオであると思いますです。シーン管理もそうですが、その他のセッション運営を
どうするかを、その場で決めるのがマスタリングであり、前もって決めとくのが
シナリオとして形になると思います。
skoba> > シナリオ自動生成のソースが91年から書かれていたのには驚きました。
skoba> > （Java化したい〜〜 笑）
skoba>
skoba> あー、あれは遊びですんで、真面目に考えられても... 当初は、あれで
skoba> も遊べるかなぁと思ってたんですが、自動生成をあの形式でやるには、ちょっ
skoba> と人間がやらなければならない記述量が大くなりすぎます。ですから、オブジェ
skoba> クト指向あるいはエージェント指向方面に行くか、あるいはシーンの接続の制
skoba> 約をきちんと書く方面でUnification 系 (Prologみたいなものかな) に行くか
skoba> しないと、実用というか使い易いものにはならないと思います。
これまた、難しい言葉が・・・。
（エージェント指向？ Unification？ Prolog？）
個人的には、だいぶもったいないと思いました。
もっと大々的にやっちゃえば良いのに。 ← かなり勝手な言い分ですね。（笑）
TRPG.netの掲示板にも、「シナリオ作成ツール求む」って話が
出てた様な気がしますし、今の所まともなTRPG用ツールなんて何処にも無いですし
面白いと思ったんですけど・・・。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
梶田晃一（ＫＺ → ＫＡＨ）
Email：kajita@trpg.net TRPG用
kajita@pk.highway.ne.jp 個人用
WWW：http://www.trpg.net/user/a-GoGo/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━