2008/8/19 15:54
TRPGのフレームワーク
Rauru Blog の「RPG とフレームワーク」を読んで考えてみました。いや、途中で詰まっちゃったんですが。
まずは話の整理から。
タイトルにも含まれている「フレームワーク」ですが、枠組みとか構造といった意味の単語ですが、ここではプログラミングの世界で使われる「フレームワーク」を指しています。
Wikipedia で調べても、いまいち分かりにくい説明が付されていますが、プログラミングを楽にするためのコードの集まり、くらいにとりあえず理解しておいてください。フレームワークを利用することで枠組みが決まるので、プログラマは枠の中を埋めればいいだけになり、見通しが良くなったり、他人の書いたコードでも理解しやすくなるといたメリットがあります。
図で表すと右のような感じです。
青い矢印がフレームワークで、フレームワークが各処理を適切なタイミングで呼び出して次々実行しています。プログラマは、アプリケーションごとに、角丸の四角内の処理を差し替えてアプリケーションを作るのです。
え、何がうれしいのか分からない？ フレームワークがない頃は、「データベースからの読み込み」の後に「フォームの表示」処理を呼び出して、といった流れをそれぞれのプログラマが記述していました。その順番などがプログラマによって違っているので読んでいるコードが何の処理なのか分かりづらかったり、プログラマによっては面倒くさいから「値の検証」処理（無くても動くことは動く）をすっ飛ばしたりして品質もまちまちでした。
フレームワークを使うと、処理の大きな流れはフレームワークが制御してくれますし、「これだけ記述しなさい」という「プログラマが書くべき処理」を指定してくれるので、比較的均質な品質のプログラムが書けるのです。
同じようにTRPGのシナリオも、何もないところから作り始めると大変で、特にはじめたばかりの段階では途方に暮れてしまいます。あるいは、何とか作ってみたけど、お手本にしたリプレイのように面白くならなかったり。
そこで、TRPG にもフレームワークを導入するのが良いのではないか、というのが元記事の主旨です。
さて、元記事へのブックマークコメントを見ると、「今ではNOVAやエンゼルギア、シナリオクラフトがあるぞ」という意見が見られます。それに対し、「NOVAやエンゼルギアはフレームワークではなく個別部品ライブラリだ」と補足されています。
じゃあ「シナリオクラフトは？」というと、これは「ストーリィのためのフレームワーク」と呼べるだろうと僕は思います。何らかのイベントが起きることは決まっていて、その具体的な中身は差し替え可能（ランダムチャートを振って決める）になっているのはフレームワーク的と言えます。
が、元記事で言及されているフレームワークは「ゲームのためのフレームワーク」であり、シナリオクラフトで提供されている機能とは別のものを求めています。
じゃあ「ゲームのためのフレームワーク」とは何か？ というと、元記事でも書かれているようによく分かりません(^ ^; 「ゲームマスターもハリウッドの原則に従ってルールフレームワークから呼び出される」とか、まぢ？ってかんじです。
というと終わってしまいますので、幾つか言及されている手がかりからフレームワーク実現の可能性を考えてみたいと思います。
まず、フレームワークが必要とされるのは、「リソース管理とかの戦略的面白さまで織り込んだ全体図を描」けるようにするためです。フレームワークで要求されるところだけを定型的に作れば、自然とゲーム性の高いセッションが実現できる、そんなものが出来ればいいわけです。
さて、ここでTRPGからちょっと離れて、高いゲーム性を備えているボードゲームで考えて見ましょう。
ボードゲームは一般に、盤面全体を見渡すことができ、何回かプレイすればどのタイミングでリソースをつぎ込むべきか、どのタイミングでどれだけの差があるともう逆転できなくなるか、といったことが大雑把に把握できてきます。
そのため、初期状態で戦略を定め、ゲームが進むうちにライバルとの差を見ながら戦略を修正したりして勝負どころを見極めながらトップを目指します。
ところが、TRPG では様相が異なります。まず、TRPGではシナリオは基本的に何回も遊ぶものではありません。それから、多くのセッションでは、プレイヤたちは盤面全体を見渡すようにシナリオを見渡すことは出来ません。見えない部分がほとんどで、どこでどれだけのリソースをつぎ込むかは、ほとんどギャンブルです。「会場が閉まるまでまだ3時間あるから、リソースとっといたほうがいいかな」といったメタゲームに頼りがち。
ダンジョンの中では光が届くより先は見えませんし、クトゥルフなどの謎解きシナリオでは「謎」を魅力的にするため、徐々に徐々に真相は明らかになっていくものであり、最初から全体が見通せるなんてもってのほかです。
つまり、ボードゲームのようなゲーム性を持とうとすると、ダンジョンのマップと敵の戦力は全部、とは言わないまでも半部以上明らかになっている、謎も明らかになっている、といったシナリオが必要になります（僕は時々やる）。
ちなみにTRPGのシナリオがこういう風になっているのには理由があって、ボードゲームでは展開の多様性を対戦相手のプレイヤが保障しているのに対し、TRPGは（PARANOIAなどの一部の例外を除き）協調型ゲームなので、シナリオで保障しなければならないからです。
以上の考察より、ゲームのためのフレームワークが機能するには、そもそも情報開示度の高いシナリオという環境が必要ではないかと考えます。
ここから先はまだぐだぐだ。
むかし『TRPGシナリオ作成の道具箱』というシナリオの部品ライブラリを作りました。
このライブラリの中からシーンをピックアップし、制限と課題というプロパティを決めるとそれなりのゲーム性を持ったシナリオが出来る、というものですが、全シーンで制限を共通して持たせると、フレームワーク的なものが出来ないかなあ……。シーン1，2，3で合わせて「5日間」という「時間の制限」があって、……うーん、おぼろげなイメージしか浮かばないけど。
もうひとつの可能性としては、シナリオ単位で使えるフレームワークは諦めて、キャンペーン単位でフレームワークを作ろう、というものが頭にあります。もうちょっとしっかり説明できるようになりましたらまたいずれ。
そもそもフレームワークってどんなの？
まずは話の整理から。
タイトルにも含まれている「フレームワーク」ですが、枠組みとか構造といった意味の単語ですが、ここではプログラミングの世界で使われる「フレームワーク」を指しています。
Wikipedia で調べても、いまいち分かりにくい説明が付されていますが、プログラミングを楽にするためのコードの集まり、くらいにとりあえず理解しておいてください。フレームワークを利用することで枠組みが決まるので、プログラマは枠の中を埋めればいいだけになり、見通しが良くなったり、他人の書いたコードでも理解しやすくなるといたメリットがあります。
図で表すと右のような感じです。
青い矢印がフレームワークで、フレームワークが各処理を適切なタイミングで呼び出して次々実行しています。プログラマは、アプリケーションごとに、角丸の四角内の処理を差し替えてアプリケーションを作るのです。
え、何がうれしいのか分からない？ フレームワークがない頃は、「データベースからの読み込み」の後に「フォームの表示」処理を呼び出して、といった流れをそれぞれのプログラマが記述していました。その順番などがプログラマによって違っているので読んでいるコードが何の処理なのか分かりづらかったり、プログラマによっては面倒くさいから「値の検証」処理（無くても動くことは動く）をすっ飛ばしたりして品質もまちまちでした。
フレームワークを使うと、処理の大きな流れはフレームワークが制御してくれますし、「これだけ記述しなさい」という「プログラマが書くべき処理」を指定してくれるので、比較的均質な品質のプログラムが書けるのです。
同じようにTRPGのシナリオも、何もないところから作り始めると大変で、特にはじめたばかりの段階では途方に暮れてしまいます。あるいは、何とか作ってみたけど、お手本にしたリプレイのように面白くならなかったり。
そこで、TRPG にもフレームワークを導入するのが良いのではないか、というのが元記事の主旨です。
ストーリィのフレームワークとゲームのフレームワーク
さて、元記事へのブックマークコメントを見ると、「今ではNOVAやエンゼルギア、シナリオクラフトがあるぞ」という意見が見られます。それに対し、「NOVAやエンゼルギアはフレームワークではなく個別部品ライブラリだ」と補足されています。
じゃあ「シナリオクラフトは？」というと、これは「ストーリィのためのフレームワーク」と呼べるだろうと僕は思います。何らかのイベントが起きることは決まっていて、その具体的な中身は差し替え可能（ランダムチャートを振って決める）になっているのはフレームワーク的と言えます。
が、元記事で言及されているフレームワークは「ゲームのためのフレームワーク」であり、シナリオクラフトで提供されている機能とは別のものを求めています。
ゲームのためのフレームワーク
じゃあ「ゲームのためのフレームワーク」とは何か？ というと、元記事でも書かれているようによく分かりません(^ ^; 「ゲームマスターもハリウッドの原則に従ってルールフレームワークから呼び出される」とか、まぢ？ってかんじです。
というと終わってしまいますので、幾つか言及されている手がかりからフレームワーク実現の可能性を考えてみたいと思います。
まず、フレームワークが必要とされるのは、「リソース管理とかの戦略的面白さまで織り込んだ全体図を描」けるようにするためです。フレームワークで要求されるところだけを定型的に作れば、自然とゲーム性の高いセッションが実現できる、そんなものが出来ればいいわけです。
さて、ここでTRPGからちょっと離れて、高いゲーム性を備えているボードゲームで考えて見ましょう。
ボードゲームは一般に、盤面全体を見渡すことができ、何回かプレイすればどのタイミングでリソースをつぎ込むべきか、どのタイミングでどれだけの差があるともう逆転できなくなるか、といったことが大雑把に把握できてきます。
そのため、初期状態で戦略を定め、ゲームが進むうちにライバルとの差を見ながら戦略を修正したりして勝負どころを見極めながらトップを目指します。
ところが、TRPG では様相が異なります。まず、TRPGではシナリオは基本的に何回も遊ぶものではありません。それから、多くのセッションでは、プレイヤたちは盤面全体を見渡すようにシナリオを見渡すことは出来ません。見えない部分がほとんどで、どこでどれだけのリソースをつぎ込むかは、ほとんどギャンブルです。「会場が閉まるまでまだ3時間あるから、リソースとっといたほうがいいかな」といったメタゲームに頼りがち。
ダンジョンの中では光が届くより先は見えませんし、クトゥルフなどの謎解きシナリオでは「謎」を魅力的にするため、徐々に徐々に真相は明らかになっていくものであり、最初から全体が見通せるなんてもってのほかです。
つまり、ボードゲームのようなゲーム性を持とうとすると、ダンジョンのマップと敵の戦力は全部、とは言わないまでも半部以上明らかになっている、謎も明らかになっている、といったシナリオが必要になります（僕は時々やる）。
ちなみにTRPGのシナリオがこういう風になっているのには理由があって、ボードゲームでは展開の多様性を対戦相手のプレイヤが保障しているのに対し、TRPGは（PARANOIAなどの一部の例外を除き）協調型ゲームなので、シナリオで保障しなければならないからです。
以上の考察より、ゲームのためのフレームワークが機能するには、そもそも情報開示度の高いシナリオという環境が必要ではないかと考えます。
ここから先はまだぐだぐだ。
むかし『TRPGシナリオ作成の道具箱』というシナリオの部品ライブラリを作りました。
このライブラリの中からシーンをピックアップし、制限と課題というプロパティを決めるとそれなりのゲーム性を持ったシナリオが出来る、というものですが、全シーンで制限を共通して持たせると、フレームワーク的なものが出来ないかなあ……。シーン1，2，3で合わせて「5日間」という「時間の制限」があって、……うーん、おぼろげなイメージしか浮かばないけど。
もうひとつの可能性としては、シナリオ単位で使えるフレームワークは諦めて、キャンペーン単位でフレームワークを作ろう、というものが頭にあります。もうちょっとしっかり説明できるようになりましたらまたいずれ。