人気ブログランキング | 話題のタグを見る

シーンのアクセス構造(4):(・_・)

 めんどくさい「シーン制」の話を済ませたので(笑)、やっと本論に入ります。

 あ、一応CMS(コンテンツマネジメントシステム)の参考は下記で。
http://www.bk1.jp/product/02952150
http://www.bk1.jp/product/02972007



シーンのアクセス構造(3):(・_・)
 めんどくさい「シーン制」の話を済ませたので(笑)、やっと本論に入ります。

--


1.目的
 本論の目的は、

1)シーン間の関連を整理、理論化する
2)あるシーンをプレイしたときに、次にプレイすべきシーンを論理的に算出できるようにする

である。

--
2.コンポジットパターン
 オブジェクト指向的にシーン間の構造を考えた場合、シーン=インスタンスと捉えてその構造を記述するパターンとして「コンポジットパターン」というものがある。
シーンのアクセス構造(4):(・_・)_b0056599_16434119.jpg

シーンのアクセス構造(4):(・_・)_b0056599_16465687.jpg

 いちおう、「コンポジットパターン」の子要素を探すロジックを適切に設定すればシーン間の関連を全部記述可能ではあるが、「コンポジットパターン」のお約束として

1)インスタンスの共有は避ける
 ※主にデータの直列化の問題で
シーンのアクセス構造(4):(・_・)_b0056599_16474285.jpg

2)循環参照は避ける
 ※無限ループに陥るので
シーンのアクセス構造(4):(・_・)_b0056599_16484629.jpg

というローカルルールがあって、これに従うとシーンの構造は書けないことになって適合しない問題がある。もともとコンポジットパターンは、ガチガチのデータ構造を書くためのパターンで、シーン間の連携というのは基本的に「緩やかな連携」で、方向性が違う。

--
3.アクセス構造とCMS
 ものとものとの緩やかな関係を記述する理論としてCMS(コンテンツ・マネージメント・システム)における「アクセス構造」という考え方がある。

 CMSというのは何かというと、現在はWebサイトの管理をするシステムという認識が一般的で、具体例としては

1)大規模Webサイトで、CMSツールを使用したもの
 公共系サイトなど(例:2009年12月にホワイトハウスのサイトがCMS化)
2)Wikipedia
3)ブログ
4)SNS
5)買い物サイト
6)Twitter

といったものがある。

 厳密に言うと「コンテンツ」というのはひとまとまりの指向性を持ったデータの集まりでしかなくて、アウトプットはWebページに限定されない。何でも良い。ということで、最近だと動画サイトの動画コンテンツもコンテンツだし、印刷帳票の類はもちろんコンテンツの一種であるし、出力されるあらゆる電子データもコンテンツだし、もっと言うと、別に電子データに限る必要もなくて、手作業で創りだしたひとまとまりの意図を持ったデータのまとまりも全部コンテンツと言えるので、例えばTRPGの場合は

デザイナーが作成
 →「ルールブック」というコンテンツが発行される
  →キャラクターデータというコンテンツが発行される
  →シナリオというコンテンツが発行される
  →セッションというコンテンツが発行される
   →セッションログというコンテンツが発行される
   →リプレイというコンテンツが発行される

という感じにツリー状にコンテンツがインプットされ、アウトプット(発行)されているととらえることができる。

 何でもかんでもCMSにおけるコンテンツと捉える事が出来てしまって切りがないので、本論では「シーン管理」における「シーン」のみをコンテンツと捉えて、その関連性について解説する。

--
4.コンテンツとは何か?
 コンテンツとは

1)誰にどのようにどんな情報を伝えたい、という目的を持ったひとまとまりの情報である
2)さまざまなデータの塊である。テキストデータ、画像データ、音声データetc...

というものである。TRPGセッションにおける「シーン」は

1)PLに何らかの情報を伝えるためのひとまとまりの情報である
2)下記のようなデータの塊である
 音声データ:GMやPLの発話による情報伝達
 画像データ:キャラクター、舞台などの画像、マップなど
 テキストデータ:ハンドアウト、プリントアウトした手掛かり情報など

--
5.アクセス構造
 アクセス構造というのはコンテンツ間(TRPGの場合にはシーン間)がどのようにリンクされてるかを示すものである。下記の4種類がある。

1)階層
 階層構造によるリンク。Yahoo!のカテゴリ別の記事など

2)索引
 「カテゴリ」などのキーワードでまとめられたコンテンツ

3)クロスリファレンス
 通常のリンク

4)シーケンス
 コンテンツの順列に従った参照

TRPGではどんな感じになるかというと

1)階層
 ・オープニング→ミドル
 ・ミドル→クライマックス
 ・クライマックス→エンディング
 ・ミドルの中で、シーンがツリー構造で繋がってる場合など
 (※シーン制で使われている用語に準拠)

2)索引
 ・「***について」で追って行って現れるシーンのリスト
 ・特定キャラクターに同行し続けて登場できるシーン

3)クロスリファレンス
 ・情報収集で得た情報をキーにショートカットするリンク

4)インデックス
 ・リンクとか関係なく、とにかく、前から順番にシーンをプレイして行く場合の関連

こんな感じ。

 DXのサプリメント「ムーンレスナイト」だと、シナリオに書かれたシーンを前から順番にプレイする旨が書かれているが(原則)、これは上記の「インデックス」によりシーン参照になる。また「ムーンレスナイト」のフローチャートにある、情報収集でシーン間をショートカットする矢印が記述されているが、これは「クロスリファレンス」による参照となる。

 その他に、「オープニングのシーンが全部終わったからミドルのシーンに入ろう」「このサイクルが終わったので次のサイクルに入ろう」とかは「階層」になる。

 「索引」によるシーン探査は見当たりませんのう。
 SNSとして有名なmixiで言うと、コミュニティに入ったり、ブックマークしたりしてアンテナを張っておくと、勝手に既存&追加されたコンテンツがコンテンツに上がって来てダイレクトにチェックできるのですが、TRPGだと

・***というキャラクターと同行したり、何らかの方法で常時監視しておく
・***という場所を常時監視
・***という話題/トピックについて、ネット上で常時監視したり、人づてに、何かあったらすぐ連絡をしてくれるよう、唾を付けておく

という感じのプレイとなりますが。Javaで言うと、リスナを登録して、イベントドリブンな処理を実装しておくような感じ。Cだとハンドらか?この辺は、

・PLがプレイ中にリアルタイムにどんなフラグを立てているか/伏線を張っているか

に、注意してマスタリングする必要がありますな。情報収集と関連しますが、即時に結果がわからなくても「***について調べさせておく」とかいう、

・「PLがタスクを登録しておく」

というアプローチを評価する必要があります。

--
6.次のシーンはどのシーンをプレイすべきか?
 下記の手順によって選出を行います。

1)どのPC/PLのシーンをプレイすべきかを評価、決定する
 →基本的には、公平規範に従う。機会均等。

2)前のシーンを鑑みて、次にプレイすべきシーンを検討する
 次にプレイすべきシーンというのは、上で説明した4種類の「アクセス構造」によって算出できます。

<1>階層
 このフェーズ、段階で遭遇すべきシーンはすべて終わったのであれば、次の階層のシーンに進む。
 あるいは、次の階層に行くフラグを立てている場合も。

<2>索引
 PLがセッション中に立てたフラグ(例えば特定NPCと、あとで会う約束をしていた、とか)に応じて発生するシーンを提示する

<3>クロスリファレンス
 情報収集や思い付きなどで、直接、突発的に「PLがやりたい」という要望がはっせいしたら、それをやるシーンに飛ぶ

<4>インデックス
 上記のどれにも該当しなかったら、とりあえず同階層の次のシーンを発生させる

3)2)で出てきた次にプレイすべきシーンの候補の中から、実際プレイするシーンを選出する

 現状「GMの勘」とか「適当(いいかげん)」な観点で次のシーンというものが選出されているのが大半と思われますが、論理的に整理すると、こんな感じになります。

--
7.ダンジョン探索とシーン管理の違い
 ダンジョン探索とシーン管理の違いですが、その前に類似点としては

・ダンジョンの「部屋」とシーン管理の「シーン」は、扱いが似ているのではないか?

という点があります。確かにこう、導入/範囲限定で得られる情報とか/脱出条件という辺りは似ていると思います。
 決定的に違うと思われるのは

・引き返せば同じ部屋に入ることができる

という点でしょうか。シーン管理の場合、同じ所に戻って来ても「別のシーン」になるので。

・シーン管理は、原則不可逆

という法則があります。(どうしても逆行したい場合は、タイムトラベルをするという手がありますが、それは例外ということで)。
 ただ、実際のダンジョン探索だと戻って同じ部屋を通るときは「その部屋の処理は省略して」新しい部屋に着いた所から新たにプレイします。ここら辺は、ダンジョン探索がシーン管理的にプレイされる例と言って良いかと思います。

 ダンジョンの構成とか、ダンジョンを抽象化したわかりやすい例としてセイクリッド・ドラグーンの「魔境」というルールがありますが、あれのマップを考えてみるとわかりやすいんですけど、同じ部屋(エリア)に戻っていちいち処理していると場面数がむやみに増えてセッションのテンポが遅くなるという問題があります。

 B
 │
→A─D
 │
 C

こういうマップは、全エリア通らないといけないとすると、

ABACAD

という感じに4エリアしかないのに、処理上6エリアもの処理をしなくてはならなくなって大変です(1.5倍)。
なので

→A─B─C─D

という感じに1本道にしちゃうか

 B┐
 ││
→A┼D
 ││
 C┘

という感じに、中間経路を通らなくてもショートカットできるようにする。

 あるいは、あえて不便さを表現したい、しかし同じエリアの同じ描写をいちいちやるのは面倒という場合は、ショートカットにコストを付加して、コストさえ払えば一気に次の新しいエリアに飛べるようにする。

 B┐
 │0.5
 ││
→A┼0.5─D
 ││
 │0.5
 C┘

書き方が苦しいけど(笑)、

・B-C、B-D、C-Dのショートカットをする場合は0.5+0.5=1のコストを払う必要がある
・A-Dは0.5→端数切り捨てで、コストなしで行ける

とかいう感じに処理する。

という感じに、ダンジョン探索もシーン管理的に処理できるようになります。

--
8.ゲーム的コンテンツ管理「全網羅要求分岐」
 コンテンツ管理システムは、別にゲームじゃないので、「7.ダンジョン探索とシーン管理の違い」で、ダンジョン探索における「後戻り」を、どう「シーン管理」的に処理するかを書きましたが、コンテンツ管理システムの場合にも同じ「後戻り」の問題があって、それは上記で書いた「4つのアクセス構造」でも解決されません。

 というわけで、「シーン管理」としては「不可逆性」を表現した、第5のアクセス構造というものを考案する必要があります。それを、本論では「全網羅要求分岐」と命名することにします(わかりにくい(笑))。

 要するに、アドベンチャーゲームでは、結局全部のシーンを全網羅したいので、ゲームの選択肢としては、
 

・「まだプレイしてないシーンの一覧が出てくれさえすればいいんだよ」


という要求に基づいた、「次にプレイすべきシーンの一覧」を抽出するための考え方です。

 「全網羅要求分岐」というのは、「7.ダンジョン探索とシーン管理の違い」で書いた、後戻りをコスト表記することで一次元化する考え方で、例えば


├B
│├D
│└E
└C
 ├F
 └G

というややこしい構造のシーンのツリー構造があった場合に、

A→B→D→(B)→C

という順序でプレイしたとして、次にプレイすべきシーンは

・E(2)
・F(0)
・G(0)
※カッコ内はコスト

という感じになるっつーことです。

 ここで書いている「コスト」は、

・フローチャートを書かないとイメージできないだろう
・状況によっては端折って良いのでは?

という懸案があったりなんかしますが、この辺のコストとか格差を図示したルールとしては、サイコロフィクションシリーズの、スキル判定ルールなんかがあります。代用判定の修正値って「いい加減、適当」に判定することが多かったのですが、一つの指標の付け方として、2次元のマス目上で何マス離れているから、修正値いくつになるね、という考え方は基準を明確にしてくれる1手段と言って良いと思います。

同様に、シーン間のコストも図示することで定量的に測定できるようになると思いますが、その辺の処理が確立しそうかなと思われるのは、

・「迷宮デイズ」のダンジョン生成ルールとか(3×3)
・りゅうたま、サプリメント2にある「探索ルール」(りゅうたまでは移動のコスト(食事、水)がゲーム的にきわめて重要なので、安易に端折れない(原則))

という辺りかなあと思います。

--
9.シーン間のコスト
 というわけで、シーン管理をゲーム的に処理する上で、「シーン間のコスト」を考慮するのは、リアリティとかゲーム性の点で、まだまだ開拓の余地があるなあと思います。

--
10.まとめ
 現状のシーン間のアクセス構造の分析をしたが、他に開拓の余地があるものとして

・PL側からのフラグ立て(索引)
・シーン間のコスト

というものが考えられる。



以上。
by namizusi | 2010-02-07 16:50 | TRPG


<< コンテクストの共有とTRPG:... シーンのアクセス構造(3):(... >>