Goto (trpg-xml ML) HTML Log homepage
Date: Wed, 08 Sep 1999 00:29:13 +0900
From: 梶田晃一 <kajita@trpg.net>
Subject: [trpg-xml:00091] Re: 【質問】システム関連情報
To: trpg-xml@trpg.net
Message-Id: <199909071526.AAA13834@pk.highway.ne.jp>
In-Reply-To: Your message of "Tue, 07 Sep 1999 14:17:59 +0900" <199909070517.FAA09649@caine.vox.tutkie.tut.ac.jp>
References: <199909070517.FAA09649@caine.vox.tutkie.tut.ac.jp>
X-Mail-Count: 00091
梶田＠デープモードです。
こんばんは。
メール的に纏まりがない文章です。スイマセン。
〈順番を少し変えています〉
skoba> >──────────────────────────────→
skoba> > これに関して、少し思ったのは
skoba> >
skoba> > 「この小林さんが挙げている問題には、二つの大きなポイントが在る。
skoba> >
skoba> > 1. システムの抽象的な構造
skoba> > 2. シナリオの中のシステム関連構造 」
skoba> >
skoba> >
skoba> > 前者は、今在る大量のシステム（D&D 〜 魔獣の絆 など) のシステム成らしめている
skoba> > 抽象的な構造（能力値〜登場判定 など → 更なる抽象化）は何かを知る必要がある。
(中略)
skoba> で、この両者についてはですね (主に上のほうかな?)、
skoba> http://jinny.cs.inf.shizuoka.ac.jp/~skoba/hobby/rpg/advanced/
skoba> に、いい加減なものですし途中だったりするのですが、いくつか書いてありま
skoba> す。
はい、見させていただきました。
シナリオの自動生成
シナリオの汎用性
シナリオ記述方式について
汎用システムについて考える
ぐらいを見ました。
面白い事を沢山、しかもかなり前から書かれていらっしゃいますね。
シナリオ自動生成のソースが91年から書かれていたのには驚きました。
（Java化したい〜〜 笑）
skoba> いずれにせよ、システム固有の情報が欲しければ、あるいはシステム固有
skoba> の情報に基づいてアプリケーションの動作を制御したければ、基礎となるDTD
skoba> に対してそれなりの拡張を施して使えば良いではないかというのが私の考えで
skoba> す。幸いにもネームスペースとか有るわけですし。
【意思疎通の為の質問】
上の文章を、小林さんのページ的に言うと
「DTDとして汎用シェル（またはエンジン）を用意しておけば、良いのではないか」
と言う事でしょうか？
skoba> で、「シナリオの中にあるシステムと関連する構造を捕らえる必要がある」
skoba> という点については、私は特に注意を払っていません。システムと関連した要
skoba> 素あるいは構造というのが、どれくらい有るでしょうか? ちょっと分からない
skoba> のですが。
【答えられるだけの回答】
上の疑問が「シナリオの中に、特定のシステムに関連した要素、構造がどれくらいあるのか？」
と言う事で答えさせてもらいます。
要素：具体的にすぐにあがらない
構造：具体的にすぐにあがらない
たぶん、抽象的なシステムの立場から考えると、〈よほどシステムを見詰ない限り〉
シナリオに特定のシステムの固有の要素や構造が出てくる事はあまりないと思います。
しかし、話が少し変わって
「シナリオXMLファイルに、特定のシステムに関する要素、構造が在る必要性はあるのか？」
を考えると
要素：シナリオをセッション中に利用する為に、特定のシステムに依存した要素である事が望ましい
構造：シナリオをセッション中に利用する為に、特定のシステムに依存した構造である事が望ましい
と考えます。
この違いは、前者がシナリオという漠然とした存在の話しであったのに対して、
後者が、セッションに利用するシナリオを対象にして話をしているからです。
（だからと言って、DTD化のときに要素名や構造がシステムに依存しなければ
ならないとは思いません。）
小林さんが、シナリオやシステムの抽象化を行う理由は、〈少しずつではありますが）
理解してきているつもりです。ただ、具体的なシナリオを考えると、その中に
システムに関係する情報を載せる必要があると思います。
skoba> 適切な抽象化が行なわれれば、汎用シナリオ (ジャンル、システムにとらわれな
skoba> いシナリオ) として扱うことが可能だと思っているわけです。また、DB化する
skoba> のであれば、そこまでしなければ意味が無いのではないかとも思っています。
【意思疎通の為の質問２】
ここで小林さんが、仰られているシナリオは、
「ストーリーの骨組み、ストーリーの構造体」
という扱いでしょうか？それとも
「実際にすぐに使える、セッション運営書を含んだストーリー体」
なのでしょうか？
skoba> で、「抽象的な構造とは何かを知る必要が有る」という点については、抽
skoba> 象化したとして、それが適切なものであるようにするために、可能なかぎり大
skoba> くのRPGに共通する要素を取り出したいという意味であれば、まさにその通り
skoba> です。
この辺りの話しを、今後このMLで行えたらと思っています。
skoba> > 後者は、シナリオの中にあるシステムと関連する構造を捕らえる必要がある。
skoba> > （しかも、昔と違いシーン管理等もシステムで規定され始めている為、これも
skoba> > 簡単な話ではないと思われます。）
skoba>
skoba> えーと、最近のシーン管理のルール化ってどういうものが有りましたっけ?
skoba> そういう情報あるいは制約はシステム固有の問題でしょうから、その旨の註釈
skoba> として扱えば良いことではないかと思います (もちろん、それでは不十分であ
skoba> るという考えがあることも理解しています)。
この文章で想定していたのが、
・「トーキョーＮ◎ＶＡ」や「ブレイド オブ アルカナ」 の登場判定〈ら辺〉
です。これらのルールがどの様にシーンに関わってくるのかとかも、上の
シナリオの構造の様に考えなければならない話だと思います。
でｈ。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
梶田晃一（ＫＺ → ＫＡＨ）
Email：kajita@trpg.net TRPG用
kajita@pk.highway.ne.jp 個人用
WWW：http://www.trpg.net/user/a-GoGo/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━