セッションについて(9)

気がつけば8回目。大体二ヶ月目。思えば遠くに来たものだ。(註:どこにも行ってません)
嘘つきました。9回目でした。
ともあれ。今回は「ロールプレイについて」です。
追記:見直したら読みづらかったので若干追記修正。氷川TRPG研究室さんからリンクもらってたので。(Hikawa TRPG Laboratory - 氷川 TRPG 研究室


最近のGMをする際の課題の一つとして、「NPCのロールプレイ」があります。
「煮え系」という表現が広く通用するのかどうかはわかりませんが、「ジレンマの発生するシチュエーションにおいて回答を模索し、その過程において煩悶する」のを「煮え系」と定義することにします。
この「煮え系」を最近よくやる、というかPL一人のソロセッションが多いので、必然、あまり戦闘に重点を置けない展開からそういった傾向になるんですが*1、これをやってると、NPCというのは「問題提起役」になります。
そうなると必然的に、ある程度までは「なにが問題なのかは自分で考えなさい」というスタンスをとらざるをえなくなります。「なにが問題なのか」を把握し、「それはどうすれば解決できるのか」を自分で考えなければ、回答の模索も過程における煩悶も薄くなるからです。*2
それは「ロールプレイとしては正しい」し、「コンセプトとしても正しい」んですが、「で、PLは面白いの?」という疑問が湧いてきます。ぶっちゃければ、「NPCに難癖つけられて楽しいか」ということですから。
その根底にあるのは、「煮え系」というコンセプトではなく、「ロールプレイ」という要素であるように思えます。極端な話、「ジレンマの過程を楽しむ」のであれば、ロールプレイというのは二次的な要素として捉えるべきなのではないか、と。
「煮え系をやるのであれば、ジレンマについて事前に提示する」のが正しい、というかその上でないとロールプレイなんてできないんじゃないかと思います。「煮え系」で「ロールプレイ」をするのであれば、という条件での話ですが。
そう考えた場合、「ロールプレイ」というのは、やはり制約、ルールの一つであることになります。その上でどう立ち回るか、という要素として考えた場合、本質は「ゲーム」、つまり「煮え系」であるなら情報交換の過程にあり、「ロールプレイ」はその味付け、「別の要素として両立させるもの」になるんでしょう。


しかし裏を返した場合、というのは、「ロールプレイを無視して煮え系をやろうとした場合」ですが、果たして煮えられるものでしょうか? PLにとってPCというのは、「自分のキャラクター」であり「自分の一部」ですらあるかもしれませんが、場合によっては「まったくの他人」として処理することもできる、「自分と他人の境界線上の存在」でもあります。
煮え系において煮えるためには、「自分の問題としてジレンマを感じなければならない」=「他人の問題としてジレンマ構造を俯瞰して眺めて解決してはいけない」という制約がある程度ついてきます。「AとBという選択肢があります。あなたはどちらを選びますか?」という状況において、Aを選択する、あるいはBを選択する、そしてTRPGの醍醐味でもある「選択肢Cを提示する」のは、「PCの立場にとってどれが最適であるか」を基準に選定されるからです。*3
こうした状況要素、「煮え系の成立要素」を考えると、「ロールプレイは二次要素」とずっぱり切ってしまうのも、それはそれでうまくないことが想定されます。「PCの立場になって考える」その上で「PLの立場でよりよい選択肢を探る」というのは、PCに対して感情移入しすぎていても難しいし、感情移入していなくても難しい。難しいというか、「感情移入した選択をしないと白ける」という部分だと思いますが。*4
まとめとしては、「煮えるにはロールプレイが必要、煮え切るにはロールプレイが邪魔」という感じになるでしょうか。PCの感情に任せて煮え切ろうとすると、大概情報を見落としたり、情報収集が失敗したり、(GMもPLも)望まない結論に辿り着いたり、猪突してしまうのではないかな、と。*5


最近ちょっと気になってるのが、「情報交換シーンでロールプレイを優先させた結果、情報交換が行われない」というパターンです。これはGM側が妥協すべき点なのかもしれない、とは思うんですが、ストーリーを重視しなければ展開が成立しない「煮え系」の場合、妥協点を見出すのが非常に困難になります。
それでもまあ、なんとなく展開させることはできるので、破綻はしないわけですが。PLは暗中模索の領域を超えてしまう状況に投げ出されることになるようです。手がかりすらない状態でNPCに喧嘩吹っかけられて「お前はダメだ」と言われても、そりゃあ反応のしようがありません。
果たして「ロールプレイ」というのは、*6どこまでするべきで、どこまで重要視するべきものなのか、そして、「ゲーム」という本質の前で妥協点を見出そうとした場合、GM側がそうするべきなのか、PL側がそうするべきなのか、どちらがその切っ掛けを作るのがスムーズなのか*7、この辺りが今後の課題になりそうです。

*1:私がそういうのを作りやすい芸風の持ち主だというのもありますが

*2:というポリシーを私が持っている、だけかもしれませんが

*3:実際に「選択肢Cを提示する」には、ある程度は状況に対する俯瞰が必要ですが……

*4:なのでPLがクレバーに状況を理解し、把握してPCを誘導する分にいは、影響はないと思います。この辺はやはりバランス感覚に帰結しますが……

*5:でもPC特性にも左右されますね、これは

*6:状況に応じて

*7:これは環境要素・状況要素が大きすぎますが

アルシャードff

実はログの保存形式をどうしようかずっと考えていた。
実際のチャット中はテキスト表示のほうが軽くて好ましい。それはまあいい。
でも書き出すログまでそのままじゃなくてもいいんじゃないだろうか? と。
つまり、色分けして出力するようなログ機能を実装したほうが、後々楽なんじゃないだろうか、ということだ。主にweb公開を念頭においての考えである。
現在のエンギアチャットの機能を敷衍するに、「通常メッセージ」と「サーバメッセージ」をわけて色分けできれば、まあ大体問題はない。
なので、「メッセージを受信する度にHTML形式でテキストファイルを吐き出し、クライアント終了時にこれを一つのHTMLファイルに合成する」というのを考えた。こうすると、ログ保存時にヘッダ情報を考えないで済むわけだ。
手元の編集済みのセッションログで一番大きいものでも、行数にすると3000行強だ。60000行ぐらい出力可能にしていれば、普通の使い方で困ることはなさそう。
問題は、膨大な数のファイルに対する合成コマンドがものっそいHDDに負荷をかけるという事実である。
考えただけで実装することはやめにした。
もしかしたら裏モードとして実装するぐらいのことはするかもしれない。


よくよく考えたらHTMLを直接弄った場合の編集効率の悪さは眩暈がしてくるのでめんどくさいからやめることにする。……いまのRTF形式の編集とそう変わらない手間かもしれない、とも思いながら。