さて、随分前のことになりますが、NIFTYのFRPGM, Mes9会議室で(#265)、 [an error occurred while processing this directive] 「RPGのシステムを、いくつかのサブシステムの集合としてとらえる」 [an error occurred while processing this directive] というような ことをちょっとだけ書いたことがあります。 ここではまず最初に、 【Σ】 という 私のオリジナルRPG をそのような観点から眺めてみるとどのように 見えるかということを考えてみたいと思います。 ただ、サブシステムという言葉をモジュールという言葉に置き換えて説明します。 [an error occurred while processing this directive]
いや、まぁ「モジュール」でも「サブシステム」でも「プロシージャー」でも 「ファンクション」でも何でも良いんだけどね。
この考え方を押し進めるとオブジェクト指向に行くのかなぁ? あぁ、 A.I.よ、今どこにいる!? (分かる人しか分からないなぁ ^^;)
おっと、そうそう、改訂後のΣでは、ちょっとこのモジュールが ここで書いてあるような形では理解しにくくなるかもしれません。 というのもクラスをあまり表に出さないようにしようかと考えているもので。 [an error occurred while processing this directive] [an error occurred while processing this directive]
まず、【Σ】 というシステムの本当の中心は何かから考えてみましょう。 Σの中心となっているのは、その判定方法です。 特に「一般判定」です。 これは、Σ-Basic システムにも書いてありますが、 Σを作った時の目的からそうなります。 つまり、「成功率が、100%を平気で超えるのは変」とか 「判定にはもっと能力値が影響すべき」と考え、これらの問題に対する私なりの 解決策を判定システムとして作り込んだためなのです。 このような、システムの中心と言えるドライバ・モジュールをコアと 呼ぶことにします。 Σの場合であれば、一般判定がコアということになります。 そうそう、ちなみに、コアというのはシステムのウリの部分とは限りませんよ。 [an error occurred while processing this directive]
とは言え、ウリがシステムに有るとしたら、コアは少なくとも ウリの周辺の部分になるとは思うんですけどね。 [an error occurred while processing this directive]
もしかしたら、あるRPGにおいてはワールドのほうの、 何らかのデータ・モジュールこそがコアと呼ぶに相応しい場合も有るかもしれません。 [an error occurred while processing this directive] 私個人の感覚で言わせてもらえば、データ・モジュールがコアになることは ちょっと考えにくいのですが...。 これは、私が理系デザイナー的な 考え方をしているからかもしれません。理系デザインと文系デザインについては 【RPGを作るとはどういうことなのか?】とか、 参考文献 [ ゲームのタネ! ] を ご覧ください。
ただ、もしかしたら「ワールド・コア」と「システム・コア」というのを 分けて考えるべきなのかもしれません。 [an error occurred while processing this directive]
さて、このコアだけではシステムと呼べるようなものではありません。 Σの場合であれば、キャラクター・メイキング・モジュールや ダメージ処理モジュール、それと対応して治療モジュールも必要でしょう。 さらに、Σではクラスという概念がかなり重要なモジュールになっています。 [an error occurred while processing this directive]
Σのクラスは、クラスと言っても、職業じゃないのよ。 [an error occurred while processing this directive]
どの程度でシステムと呼べるのかは判断が難しいところですが、 私としてはシステム製作者の意向を反映した上で、最低限遊べるような モジュールをまとめたものをカーネルと呼び、 そのあたりからシステムであると考えることにします。 [an error occurred while processing this directive]
このカーネルになると、明確にドライバ・モジュール と データ・モジュール が含まれることになります。 例えば、能力値の解説や技能の解説 のようなデータ・モジュールが入って くるからです (もしくは能力値や技能そのものもデータ・モジュールに含めても 良いかもしれませんが)。
さて、モジュールには2種類あります。先程からドライバ・モジュールと データ・モジュールと言っていますが、そのことです。 ドライバー・モジュールとは、 なんらかの処理を行なうための手続きを記述したモジュールを指します。 もう1つのデータ・モジュールというのは、 手続きを記述したものではないモジュールです。 簡単に言ってしまえば、背景世界の記述や、技能リスト、物品リストに 含まれる、それぞれの説明、およびそれらを表現する数値などが データ・モジュールにあたるでしょう。 [an error occurred while processing this directive]
もちろん、ドライバ・モジュールとデータ・モジュールを 明確に分離できるわけではありません。 例えば、多くのRPGに能力値が存在しますが、 これはドライバ・モジュールに入れて考えるべきなのか、 データ・モジュールに入れて考えるべきなのか、 それとも両方にまたがったものと考えるのかは 非常に怪しい部分です。 [an error occurred while processing this directive]
ところで、【Σ】 では、上記のカーネル以外にも、魔法モジュールと精密化モジュール (実際には、肉体技能モジュール、精密化ダメージ処理モジュール、 追加成長モジュール位に分割できるでしょう) があります。 この両者は、カーネルに対してかなり付加的な モジュールとなります。 どちらもカーネルに対して変更を加えるものであることや、特に魔法モジュールに 関してはΣが汎用システムということもあってシステム全体にとって必須とは 言えないからです。 [an error occurred while processing this directive]
では、ここで、 【Σ】 の Basicシステムに記載されている モジュールの関係を大雑把 に図にしてから、次に進みたいと思います。 なお、ここで魔法モジュールがドライバ、データモジュールの両方の領域に かかっていますが、これは魔法モジュールという大雑把な分類ではその中に両方の 要素が入っているためです。
また、一般判定モジュールとクラス・モジュールはきっちり重なっていますが、 別にクラス・モジールが一般判定モジュールにオーバーライドしているわけでは ありません。
さらに言えば、最下行の「ドライバ・モジュール」と「データ・モジュール」は、 その上の「||」のラインとずれていますが、 これは能力値モジュールなどにもドライバ・モジュールとデータ・モジュールの 両者が含まれている可能性が有るからです。
そのほか、縦横に重なったりしているものもあります。 これはもちろん何らかの関係が有るからこそ隣接もしくは近接して 書いているのですが、かならずしも置き換えなどの関係を 表わしているわけではないことを覚えておいてください。
あと、Σにとってはクラス・モジュールもかなり重要なものであるため、 大雑把には一般判定モジュールとクラス・モジュールをまとめたものをコアと 考えた方が良いかもしれないという判断で下のように書いておきます。
*CMM キャラクター・メイキング・モジュール
*TM 他の判定方法モジュール(戦闘など)
*ETM 自動成功 & 自動失敗 & 気迫 & 手加減モジュール
*DAMM ダメージ処理 & 治癒モジュール
*EDPM 精密化ダメージ処理モジュール
*成長M 成長関係モジュール
*ECDM 追加成長モジュール
ここで、それぞれのモジュールの関連を書いておきましょう。 まず一般判定モジュールが、このシステムの基盤に有ります。 その上にクラス・モジュールが乗っていますが、これは Σにおいては距離や重さその他の数量をクラスというまぁlog尺度で表現している ためです。 つまり、一般判定に関連するさまざまな数値がクラス尺度で表現されて いるため、一般判定モジュールと、そのほかのドライバ・モジュールの間に、 クラス・モジュールを入れてあるのです。
で、さらにその上にあるCMM, TM, DAMM, 成長Mなどは、 遊ぶために必要な付加的なルールを追加するモジュールになります。 ETMはTMに付加するルール、EDPMはDAMMを精密化するルール、 ECDMは成長Mに付加するルールということになっています。 ここで、もちろんTMとDAMMは、戦闘とダメージ処理という関係で強く 関連していますし、ほかのモジュール間においても様々な関係が有ります。
また、データ・モジュールについては、Σでは能力値を基本として考えるため、 能力値モジュールが一番下に有りますし、判定でも能力値が基本に有るため、 一般判定モジュールの横に置いています。 さらに、Σのベーシック・ルールにおいて設定されている基本技能モジュールが その上に乗り、さらに基本技能モジュールに付加する形で肉体技能モジュールが 存在します。 [an error occurred while processing this directive]
ところで、【Σ】 は汎用システムです。 例えば、上記の カーネル+αには背景世界に関するような情報は (基本的に) 一切含まれていません。 ですから、実際に遊ぶためには背景世界を設定しなければなりませんし、 それにともなって新しい技能や、物品を設定しなければなりません。 [an error occurred while processing this directive]
「含まれていない」ってったってどうしても入てってきちゃうのは もうどうしょうもないから、無視して考えた場合の話ね。 [an error occurred while processing this directive]
つまり、実際に遊ぶ環境としては、追加技能モジュール、 物品モジュール、背景世界記述モジュールが追加されるということです。 これらはデータ・モジュールですが、場合によってはドライバ・モジュールが新たに 必要となる場合もあるでしょう。 例えば、追加技能モジュールについては、その技能の処理のしかたを記述した ドライバ・モジュールが必要になるでしょう。 [an error occurred while processing this directive]
はたして、RPGのシステムを、このように モジュール化してとらえる事が正しい 判断なのかどうかは分かりません。 また、オリジナルRPGを作る際に、こんな モジュール化と いう概念が役に立つかどうかはまったくの未知数です。 というのも、結局のところ、このようにシステムをモジュール化して とらえたところで、 それぞれのモジュール間の相互関係はそれほど単純ではないのではないかと 思うからです。
また、データ・モジュールとドライバ・モジュールというように簡単に記述内容を 分類すること自体も難しいかもしれませんし、 またそれらをルール・ブック上でまで別々の部分に書きいてしまうような ことが可能なのか、またそういうやりかたが書き易いか、 また読み易いのかという問題も有るからです。 [an error occurred while processing this directive]
きっちり分離して書いたら、まず間違いなく理解しにくいような気がする けどな... [an error occurred while processing this directive]
しかし、モジュールという概念がまったく無意味というわけでも無いと思うのです。 例えば、ハウス・ルールを作る場合、ハウス・ワールドを作る場合、 既存システムを理解する場合など、何らかの示唆を与えてくれる可能性はかなり 大きいのではないかと思うのです。 さらに、上記構成図はΣのものですが、多少の読み替えや抽象化などで、 多くのシステムをこういう構成で捉える事が可能なのではないかと思うのです。
そこで、ちょっと一般的なものに、この構成図を書き直してみましょう。
*CMM キャラクター・メイキング・モジュール
*TM 他の判定方法モジュール(戦闘など)
*DAMM ダメージ処理 & 治癒モジュール
*成長M 成長関係モジュール
だいたいこんな感じになると思います。 もちろん、実際には、Σの例のようにもうちょっと細かいものが付くでしょうが、 できるだけ一般的なものをと考えるとこんな感じになると思います。 つまり、私の判断では、一般判定モジュールというのが、システムの基盤となり、 それに対してその他のドライバー・モジュールが付加されるということです。
また一般判定モジュール以外のドライバー・モジュールとしては、 キャラクター・メイキング、その他の判定方法モジュール (戦闘など。もう少し細かく 分類できるかもしれない)、 ダメージ処理モジュール (傷を追うのは戦闘の場合のみとはかぎらないため、 ちょっと別に考えます)、成長モジュールの4つが基本的なものと言えるでしょう。 これら5つのモジュールが有れば、とりあえずRPGシステムと言えると思います。 あと考えるとしたら技能 (もしくは / および、特殊能力) モジュール (データ、ドライバ共) も含めて考えたほうが良いかもしれません。
また、ここで上げた構成図ではコアが示されていません。 これは、先にも言ったようにどこまでがコアかということについては 作者の判断が多分に影響すると思うからです。 とは言え、コアは「システムの中心と言えるドライバ・モジュールをコアと 呼ぶことにします」という定義ですから、あまり細かい部分をコアと呼ぶべきでは ないでしょう。すると、やはり大体においては一般判定モジュールが コアになる場合が多いものと思いますけど。 [an error occurred while processing this directive]
さらに、この構成図ではワールド設定からの影響が明確ではありません。
世界設定と言っても実は3種類有ります。
1つは、システムに組み込まれるもの、 例えば、Call of CthulhuにおけるSANチェックのように 世界感を表現するためのルールです。 このような世界設定は、それらのモジュールやルールを通して、 PCの行動などに影響を与えます。 これらは、ワールドの雰囲気を醸し出すことを助けることを意図して 作られるシステム、ルール、そしてデータ・モジュールの一部となります。
もう1つは、プレイヤーにその世界を伝えるためのものです。 こちらは、背景世界記述 (もしくは背景世界説明) モジュールという、 データ・モジュールとして書かれることになるかも しれませんが、このモジュール自体は判定などには影響を与えません (...と書くと語弊が有るかなぁ...)。 まぁそういうわけで、上記の構成図では世界設定からの影響が明確では なかったわけです。
そして最後の1つが、前からしつこく言っている 、 システムやドライバやルールによって 表現してしまうワールド、もしくはその一部です。 つまり、判定方法あたりですね。 [an error occurred while processing this directive]
【なぜオリジナルRPGを作るのか?】の ［ワールドが気にいらない!］で 挙げている D&D の例は、PCが役割分担をするなどの D & D にとっては非常に基本的な考え方に根を持っているので、 私はこちらと考えていますが。 [an error occurred while processing this directive]
この3つのうち、ワールドとシステムを最も深い部分で関連してしまうのが、 最後の3つめのものです。 そして2つめのものは、ゲームを遊ぶためにどうしても必要な、世界についての 情報を明示的にプレイヤーに伝えるものと言えるでしょう。 そして1つめのものは、適切なものを用意することが一番難しい ものと言えるでしょう。 というのも、これは適切なものでなくとも、 あるいはSANチェックのようなものは無くともゲームとしてとりあえずは 遊べてしまうからです。 しかし、適切な能力や技能、そしてSANチェックのようなルールが 存在するかどうかは、そのワールドをプレイヤーに感じさせるのに 非常に重要な要素です。 [an error occurred while processing this directive]
えと、これで役に立つかどうかは分かりませんが、 とりあえずRPGシステムの構成というものは上のような感じにとらえることが できるということを考えてみてください。 この感覚を掴めているかどうかで、オリジナルRPG作成のやりやすさは かなり違うものと思います。
Kuzu-ware, Presented by Kuzu-Production
[an error occurred while processing this directive]