[note] ゲームシステムを自作する遊び。(6):QSKとテストプレイ

(T)RPG の遊びの一つに「ゲームシステムを自作する遊び」があって、でもその方法ってあんまり語られてこなかったよね? じゃあ実際にゲームシステムをどうやって作るの? という話。

の、第10段。

もっとサクっとやる気になってもらってオシマイ! くらいの軽い記事が書きたかったんですが、なんだかんだ整理してたら長々とこんな有様に。しかもまだ終わらないというから救えない。

ちょっとでもお役に立ってればいいんですが。

クイックスタートキットを作ろう!

今回のテーマは「クイックスタートキットを作ろう!」です。

クイックスタートキット(QSK)とは、それだけで遊べるサマリー(抄訳)集を指します。ジャンプキットとかスターターキットとか言うこともあります。

ここでの (T)RPG の QSK は、それだけあればとりあえず1回セッションが遊べるもの、と考えてくれれば良いでしょう。ということで QSK には以下のサマリーが必要になります。

QSK に必要な要素

  • セッションを遊ぶためのシナリオ
  • シナリオを遊ぶために必要なプレイヤーキャラクター(PC)のデータ
  • シナリオで必要になるルール

セッションを遊ぶために必要なシナリオ

一番に必要になるのはシナリオです。具体的にどういうセッションを遊びたいか。これが一番です──なにしろ QSK はそれだけのために作るものですから!

とりあえず遊びたい物語(おはなし)の概略をザッと書き出してみましょう。詳細は必要ありません。プロットとかログラインとか言われる程度の、大雑把な流れが把握できる物があれば充分です。

ゲームシナリオにする

だいたい書けたら、次にそれをゲームシナリオへ落とし込んでいきます。

シナリオの書式はゲームシステムによって異なりますが、シナリオに最低限必要となるものは、概ね進行管理ルールによって決まります。

  • フリースタイル
    • 開始時の PC たちの立場
    • 導入から結末までの大まかな流れ
    • 登場する NPC
  • シーン(場面)制
    • 開始時の PC たちの立場
    • 導入から結末までに必要なシーン
    • シーンごとの大まかな内容
    • 登場する NPC
  • サイクル(手番)制
    • 開始時の PC たちの立場
    • PC それぞれの目的
    • PC の目的に関係する NPC やオブジェクト
    • 隠されている情報

遊びたい物語を、上の必要なものに合わせて整理していきましょう。それが下敷きになります。

障害(課題)を作る

障害とは、物語において解決すべき課題です。その障害を乗り越えることで、登場人物は何かを手に入れます──それは謎解きの鍵や財宝、あるいは信頼や確信、愛や成長であるかもしれません。

基本的には解決不可能な障害を用意するべきではありません。ただし簡単すぎる障害ばかりでも、あまり意味はありません。このあたりはシナリオ制作者のセンスに依存するものです。

余談ですが、物語上のボトルネックになっている場面では、解決できなくても資源を消費することで失敗を穴埋めし、解決できるようにしておくと、セッション中に立ち往生することはなくなると思います。

解決方法を決める

障害が決まったら、その解決方法を考えます。解決方法については以下のどちらか、あるいは両方になるようにしておきましょう。

  • ゲームマスターが指示をする
  • キャラクターシートを見れば分かる
ゲームマスターが指示をする
課題の解決方法について「〇〇で判定して」や「××するなら〇〇に成功する必要がある」のようにゲームマスターが指示をする場合、セッションはスマートに進行しますが、プレイヤーは物語に対して受動的になりがちです。ただし既存のゲームシステムとあまり似ていないゲームシステムを作った場合、最初はそうしてガイドしなければならない場合もあります。
キャラクターシートを見れば分かる
課題の解決に有効そうな能力値や技能、特殊能力などが、キャラクターシートに分かりやすく書かれている場合、プレイヤーに「どうする?」と訊ねても良いでしょう。この場合、プレイヤーは自分で考えて行動するので能動的になります。ただしプレイヤーが適切な答えを出すまでに時間がかかる場合もあるので、セッションのテンポは悪くなりかもしれません。

ゲームシステムはここで必要になります。大抵の場合、解決方法は「成否判定」となりますが、それ以外の方法によるものもあるでしょう。ここで注意することは、以下の二点です。

  • 解決方法を一つにしない
  • 失敗してもゲームを進行できるようにする
解決方法を一つにしない
たとえば「鍵の掛けられた扉」があるのは良いのですが、扉の開け方については、正しい鍵を使う、道具を使って錠前を外す、蝶番を壊す、扉を打ち破る、など複数の解決方法を考慮しておくか、「プレイヤーからの提案を検討/受諾する」ということです。
失敗してもゲームを進行できるようにする
古来、シナリオ作成に慣れてない折にやりがちな失敗が「判定に失敗した時点でシナリオが頓挫する」──「成否判定が必要です。成功すると〇〇できます」があっても「失敗したら〜」の記述がない、あるいは「できません」で終わっている──というものです。乱数を使った判定は水物で、ほとんど考える必要がないような低確率が、セッション中に偶然発生してしまうことも無いとは言えません。そのため想定外の展開になった際には、何らかのペナルティ(HPや所持品の減少、あるいは余計な時間を浪費するなど)を課しつつ進行できるようにしておくことをおすすめします。

コンテストのデータを作成する

シナリオのクライマックスとなるコンテスト(戦闘など)のデータを作成します。コンテストも課題の一種なので、基本的にはそちらの注意点を前提にしています。そのうえで QSK では次のポイントにも気を配るようにしておくと良いでしょう。

  • 各PCに最低1回の見せ場を作る
  • 全員の見せ場が終わったら終了する
各PCに最低1回の見せ場を作る
要は各 PC がそれぞれ活躍できるようにする、ということです。大抵のゲームシステムで、 PC は何らかの役割分担をするようになっています。その役割ごとの能力を発揮し、それぞれ活躍の場面を演出するということです。
よく有る戦闘の例を挙げると、狙撃のような遠距離攻撃が得意な PC のために先制攻撃可能な狙撃ポイントを作ったり、それだけで戦闘が終わらないように敵がすぐに隠れて接近できる遮蔽物を用意したり、回復魔法の使い手がいるなら敵に一回だけ強力な攻撃をさせて回復の場面を作ったり、範囲に効果の及ぶ攻撃魔法の使い手がいるなら数だけは多いザコを出して一掃させたり、といった具合に。
全員の見せ場が終わったら終了する
全員の見せ場が終わったら速やかに終了するようにしておきましょう。これは初めてのゲームシステムで遊ぶと、慣れたゲームシステムで遊んだ時よりもずっと疲れやすいためです。コンテストが終わっても、それでセッション終了とはなりません。物語の結末を語らなければならないのです。そのときにプレイヤーが疲労困憊、話をまともに聞いてもらえなかったら折角作ったゲームシステムも、心待ちにしていたその日のセッションも、みんな台無しというものです。やることやったらさっさと終わりにする。これもまた大事なことだったりします。

シナリオを遊ぶために必要なプレイヤーキャラクター(PC)のデータ

※順番に紹介していますが、これはシナリオを作っている最中──たとえば課題やコンテストの光景を考えたりしている間──に並行して作っても構いません。

遊びたかったおはなしをゲームシナリオに落とし込めたら、次は PC のデータを用意します。前回「システムの仮組み」でも触れたとおり、QSK に必要な PC のデータは以下のとおりです。

QSKに必要な最小限のPCデータ

  • クラスやスタイル(種族や氏族、職業など)
  • 成否判定用の値(能力値、技能のうち共通のもの、よく使うものなど)
  • コンテスト(戦闘など)に使うデータ(テストプレイ用なので決め打ちでOK)

シナリオで必要になるルール

作成したシナリオの中で、課題の解決に必要となるルールをまとめます。こちらも QSK 用ですので最小限で構いません。

ルールの文章はなるべく簡潔に、必要なことだけを書くようにしましょう。また原則として「PCがNPCに対して行う」視点で書くようにすると良いと思います。これは逆でも構いませんが、とにかく視点を変えないようにすることが重要です。

QSKをまとめる

以上が出来たら暫定的に QSK としてテストプレイ用に用意します。コピーするなりプリントするなり、最低でも以下の部数は用意するようにしましょう。

  • キャラクターシート:各1部
  • ルールサマリー:人数分
  • シナリオ:ゲームマスター用に1部

余談ですが、自分は冊子の体裁を好むので、キャラクターシートとルールサマリーを一冊にまとめてしまうことが良くあります。こうしておくと、全 PC のキャラクターシートがテストプレイの全参加者に回るため、クロスチェックを期待できるようになります。

ただしテストプレイ参加者の中に、自分の手番に他のプレイヤーから提案されることを嫌がる人がいる場合、クロスチェックがマイナスに機能することもあるので、敢えてキャラクターシートを分離することもあります。

あくまで遊びである以上、テストプレイとはいえ、大前提となるのは快適にセッションを楽しむことです。特にテストプレイの参加者は、その後もそのゲームで遊ぶ機会を設けやすい、一番のユーザになってくれる可能性が一番高いメンバーです。決して粗略には扱わないように。

これが商業的な成功を目指すのであればまた別の意見もあると思いますが、仲間内で遊ぶ程度のものであれば、そちらを優先しておいたほうが良いと思われます。

テストプレイを行う

QSK が出来上がれば、あとはテストプレイを行うだけです。

メンバーを募集する

テストプレイをしようと思ったら、テストプレイの参加者を募集しなければなりません。まあ基本的には普段よく遊んでいるメンバーに声をかけることになると思いますが。

この際、注意することはテストプレイでどこまでテストを重視するかです。

なにしろ自分が遊んでみたいおはなしを遊ぶために作っているのですから、試しに遊んでみて「あー面白かった」で終わらせても構わないのです。

逆に PDF や同人誌などの体裁で公開し、より広い人々に遊んでもらうことを期待することもあるでしょう。そうした際には運用テストとしてルールがきちんと機能しているか、 PC のデータがプレイヤーにどう読まれているかなど、ひとつひとつ確認作業を繰り返すことになるかもしれません。

どちらにせよ、テストプレイのメンバーを募集する際には、そうした目的を開示しておく必要があります。こうした目的意識のズレは、セッションの運営に大きく関わってきます。

今回はここまで

最後は駆け足になりましたが、ひとまずここまで。

次回はテストプレイの結果を受けてのブラッシュアップ作業について書きたいと思います。