Goto (trpg-xml ML) HTML Log homepage
Date: Wed, 08 Sep 1999 08:35:11 +0900
From: skoba@vox.tutkie.tut.ac.jp (KOBAYASHI Satoshi)
Subject: [trpg-xml:00092] Re: 【質問】システム関連情報
Sender: skoba@caine.vox.tutkie.tut.ac.jp
To: trpg-xml@trpg.net
Message-Id: <199909072335.XAA10894@caine.vox.tutkie.tut.ac.jp>
In-Reply-To: Your message of Wed, 08 Sep 1999 00:29:13 +0900. <199909071526.AAA13834@pk.highway.ne.jp>
X-Mail-Count: 00092
小林＠豊橋技術科学大学です。
In Subject : [trpg-xml:00091] Re: 【質問】システム関連情報
Message-ID : <199909071526.AAA13834@pk.highway.ne.jp>
梶田晃一 さん wrote:
>
> 梶田＠デープモードです。
> こんばんは。
ども。
> シナリオ自動生成のソースが91年から書かれていたのには驚きました。
> （Java化したい〜〜 笑）
あー、あれは遊びですんで、真面目に考えられても... 当初は、あれで
も遊べるかなぁと思ってたんですが、自動生成をあの形式でやるには、ちょっ
と人間がやらなければならない記述量が大くなりすぎます。ですから、オブジェ
クト指向あるいはエージェント指向方面に行くか、あるいはシーンの接続の制
約をきちんと書く方面でUnification 系 (Prologみたいなものかな) に行くか
しないと、実用というか使い易いものにはならないと思います。
>skoba> いずれにせよ、システム固有の情報が欲しければ、あるいはシステム固有
>skoba> の情報に基づいてアプリケーションの動作を制御したければ、基礎となるDTD
>skoba> に対してそれなりの拡張を施して使えば良いではないかというのが私の考えで
>skoba> す。幸いにもネームスペースとか有るわけですし。
>
>【意思疎通の為の質問】
>
> 上の文章を、小林さんのページ的に言うと
> 「DTDとして汎用シェル（またはエンジン）を用意しておけば、良いのではないか」
>
> と言う事でしょうか？
えーと、シェル、エンジンというのはやはりシステム部分の用語だと思い
ますので、ちょっと...ただ、概念的にはそういう感じです。汎用部分を用意
しておくか(こっちがエンジン的発想)、記述形式として汎用のものを用意する
か(こっちがシェル、あるいはメタシステム的発想)という感じですね。
>【答えられるだけの回答】
>
> 上の疑問が「シナリオの中に、特定のシステムに関連した要素、構造がどれくらいあるのか？」
> と言う事で答えさせてもらいます。
はい。
> 要素：具体的にすぐにあがらない
> 構造：具体的にすぐにあがらない
>
> たぶん、抽象的なシステムの立場から考えると、〈よほどシステムを見詰ない限り〉
> シナリオに特定のシステムの固有の要素や構造が出てくる事はあまりないと
> 思います。
ですよね。
> しかし、話が少し変わって
> 「シナリオXMLファイルに、特定のシステムに関する要素、構造が在る必要性は
> あるのか？」を考えると
>
> 要素：シナリオをセッション中に利用する為に、特定のシステムに依存した
> 要素である事が望ましい
> 構造：シナリオをセッション中に利用する為に、特定のシステムに依存した
> 構造である事が望ましい
>
> と考えます。
> この違いは、前者がシナリオという漠然とした存在の話しであったのに対して、
> 後者が、セッションに利用するシナリオを対象にして話をしているからです。
えーと、この辺は私も理解しています。以前も書きましたように、本来特
定のRPG A用に作ったシナリオを、別の人がその RPG A で使い難くなってしま
うのでは、本末転倒だとは思っています。ただし、特定のRPGの情報を記述す
る構造が必要かと問われると、「それ専用の記述形式は必要ないのではないか?」
と考えています。
> 小林さんが、シナリオやシステムの抽象化を行う理由は、〈少しずつでは
> ありますが）
> 理解してきているつもりです。ただ、具体的なシナリオを考えると、その中に
> システムに関係する情報を載せる必要があると思います。
何らかの、システム依存の情報を載せる必要は有ると思います。ただし、
それをどういう形式で載せるかはまた別の話であって、システム依存情報を含
めるからシステム依存のタグを使わなければならないわけではありません。
更に、拡張というのも有りですし。
>skoba> 適切な抽象化が行なわれれば、汎用シナリオ (ジャンル、システムに
> とらわれな
>skoba> いシナリオ) として扱うことが可能だと思っているわけです。また、DB化する
>skoba> のであれば、そこまでしなければ意味が無いのではないかとも思っています。
>
>【意思疎通の為の質問２】
>
> ここで小林さんが、仰られているシナリオは、
> 「ストーリーの骨組み、ストーリーの構造体」
>
> という扱いでしょうか？それとも
> 「実際にすぐに使える、セッション運営書を含んだストーリー体」
>
> なのでしょうか？
えーとですね、私としては「実際にすぐに使える」という既成シナリオは、
存在しえないと考えています(あー、RPGの導入シナリオは別かな...?)。とい
うのも、どうしてもそれぞれのグループに合わせた調整が必要になるはずだか
らです。で、あるならば、「ストーリーの骨組み、ストーリーの構造体」と、
どう違うのでしょうか?
もちろん、運営上の注意などは含むべきであると思いますが、それらは
「運営上の注意」という項目を設けて書いておけば良いことですよね?
>skoba> > 後者は、シナリオの中にあるシステムと関連する構造を捕らえる必要がある。
>skoba> > （しかも、昔と違いシーン管理等もシステムで規定され始めている為、これも
>skoba> > 簡単な話ではないと思われます。）
>skoba>
>skoba> えーと、最近のシーン管理のルール化ってどういうものが有りましたっけ?
>skoba> そういう情報あるいは制約はシステム固有の問題でしょうから、その旨の註釈
>skoba> として扱えば良いことではないかと思います (もちろん、それでは不十分であ
>skoba> るという考えがあることも理解しています)。
>
>
> この文章で想定していたのが、
> ・「トーキョーＮ◎ＶＡ」や「ブレイド オブ アルカナ」 の登場判定〈ら辺〉
>
> です。これらのルールがどの様にシーンに関わってくるのかとかも、上の
> シナリオの構造の様に考えなければならない話だと思います。
登場判定って、どんなのですか? ご都合主義的「実はそこに居た」という
系統でしょうか? もしもそうであれば、それはセッション運営上の問題であり、
シナリオ記述の問題では無いように思います。
-----