図 1: メッセージの流れ
これは、オブジェクト指向 (以下 OO) にもとづくRPG設計の試みを行なう ものです。はたしてうまくいくかどうか分かりませんが、とりあえずやってみ ます。 [an error occurred while processing this directive]
RPGの設計において OO 的な方法を導入する場合に 分かりやすいのは、何よりPCをオブジェクトとすることでしょう。 それと関連しておそらくは様々なアイテムもオブジェクトとするのが 理解しやすいと思います。
そこで、この試みでは、まずPCをオブジェクトとするところから 考えてみたいと思います。 [an error occurred while processing this directive]
オブジェクトとして考える場合には、 まず入出力関係をはっきりさせておきたいと思います。
まずゲーム内世界とゲーム外世界との入出力を考えると、 基本的には判定における修正値や目標値がGMから指定されるというのと、 あとはプレイヤーからPCの行動の指定が考えられます。 また、PCの存在位置やPCの健康状態、およびPCを表現する数値がプレイヤーに 示されるということになります。 ただし、後者はゲーム内世界においても意味を持つものですから、 そちらで考えたいと思います。
ここで、判定処理を行なう部分もオブジェクトとして考えようと思います。 いろいろなところで共通して使われるものですからね。 判定器と呼びます。
以下にメッセージの流れを挙げますが、 これは非常に概略的ではありますが、PCに可能な行為の リストアップとも考えられます。
で、基本となるのはPCと判定器とのメッセージのやりとりです。 PCからは、GMやPlayerから渡された処理条件を判定器に渡し、 その結果をPCに渡すわけです。
また道具を使う場合、これには判定の修正および結果の修正という 2種類が考えられますが、いずれにせよ何らかの処理条件がPCから Itemに渡され、Itemの持つ処理条件を含めて判定器に渡します。 またその結果がItemを通し、場合によっては処理結果を修正して PCに返されます。
ここで、別のモデルとしては、PCがItemに修正などを問い合わせ、 その結果を持って判定器にメッセージを渡すという方法も考えられます。 別にどちらが良いということは無いと思いますが、 ここではそれぞれの独立性を考慮し、上に挙げたモデルでやっていきます。
あるいは、PCが直接他のPCや物に影響を与える場合、 判定器かの結果が、他のPCや物に渡され、 場合によってはその渡された結果を参照もしくは処理条件として PCや物が再び判定を行ない、 その結果が元のPCに返されます。
さらには、道具を使ってほかのPCや物に影響を与える場合を考えましょう。 すると、 先の道具を使った場合の結果が、今度は他のPCや物に渡され、上の場合と同様に 処理され、結果が元のPCに返ってくるわけです。
この2つに関しても、道具の場合と同じように、ここに挙げたのとは 別のモデルも考えられますが、同様の理由により、ここに挙げたモデルで やっていきます。
これらを図にすると、次のようになります。
なお、上に書いたように、 ここに挙げたもの以外のモデル化も可能であることは言うまでもありません。 [an error occurred while processing this directive]
さて、判定に関するメッセージの流れは決まりました。 次はPCをどのように表現するのかを決定しましょう。 ここでは、PCを表現する数値を特徴値と呼びます。
さて、PCの特徴値としては、PCに可能な行動を表現したり あるいは処理可能なものを設定しなければなりません。 別の言い方をすれば (というか、一般的な用語を使えば)、PCの行為に必要な 能力値や技能を設定しなければならないということです。
さて、一般的な話ですが、PCにどのような行為が可能かを考えましょう。 おおまかには、上に挙げた「一人でカタがつく」などなどが PCに可能な行為であるとも言えるわけですが、 あれでは概略的すぎます。 そこで、ここではもっと具体的に考えましょう。
これは、もうこのまま特徴値としてもかまわないと思います。 ただ、これも考えかたしだいで、 例えば治療のしかたを知っているものは治療道具も使えるし、 医学や薬学についても知識があるでしょう。 また戦闘とは言っても、肉弾戦では体力が必要なのにたいして、 射撃では手先の器用さや視覚と手先の連携が重要だったりという ことも考えられます。 さらに言えば、他者に強い力を加えられるならば肉弾戦でも大きなダメージを 与えられてもよさそうな気がします。
そう考えると、上のリストをそのまま特徴値とするよりも、 もうすこし肉体の特性を表わすような基本となる数値があったほうが良い ように思えます。 そこで、それらをここでは能力 (その値は能力値)と呼びます。 能力には、上のリストから考えて以下のものを設定したいと思います。 また、":" の後に上のリストのうち関連しそうなものを 挙げておきます。 もっといろいろな関連があるでしょうが、 とりあえずという程度のものですが。
意思力が、交渉にしか効いていなくてちょっとバランスが悪いですが、 まぁとりあえず良いということで...
さて、これでとりあえずはPCを表現する数値が得られました。 場合によっては (世界など)、このような特徴値 (能力値) のみでも 充分にPCを表現できるでしょう。 しかし、ここではもうちょっと一般的に考えて、技能というものも 考えてみましょう。
技能 (値は技能値) としては、上のリストをもうちょっと 細分化したものを考えます。元というのは、上のリストの項目です。 そうそう、ここまで具体的なものになると、 世界を設定しないわけにはいきません。 そこで、とりあえず近未来のホラーものというのを想定します。
まぁ、現時点においては私の想像力不足からいまいち面白味のある技能は設定 できませんが、とりあえずこんなところからはじめたいと思います。
さて、では能力と技能のどちらに重きを置きましょうか? これは判定器の内容と関連しますので、 後ほど細かく考えますが、 とりあえず能力と技能の両方を同程度に重きを置いて処理をするように したいと思います。
おそらく、技能の数を少なくする、つまり技能は特殊能力に近い扱いとするなら、 能力に重きを置いても良いと思います。 あるいは、ほとんどの場合、技能のみで処理をするのであれば、 能力は技能が設定されていないような場合などの特殊な場合のみに 考慮すれば良いということになるでしょう。
あと、PCの能力ではありませんが、やはりPCの健康状態を表現する 必要があるでしょう。 結果の評価には戦闘による結果もありますので、 当然、PCの生死も表現できなければなりません。
このような情報を表現するためには、よくヒットポイントという 数値が使われます。 あるいは、ヒットポイントを使わずに、能力を直接減らしていく 方法も有ります。
このシステムではヒットポイントに似たダメージ・ポイントを使います。 つまり、残りを表わすのではなく受けたダメージをそのまま 表わすのです。 とりあえずダメージ・ポイント上限は能力の「力強さ」を基準に決定することに しましょう。
さて、ここではPCというオブジェクトの中に特徴値がデータとして 有るというモデルを使いました。 しかし、個々の特徴値をオブジェクトとし、その集約として PC を表現 することも可能です。
今回のモデルでは、PCの持つ判定処理メソッドが、判定器を呼び出したり、 あるいは上に挙げた、道具を使うだとか云々の処理の流れを 制御するわけです。 しかし個々の特徴値をオブジェクトとする場合では、 それぞれの特徴が判定処理メソッドを持ち、 判定の流れを処理することになります。
OO をつきつめて実践しようとすれば、PCは個々の特徴値というオブジェクトの 集約として表現されるというモデルのほうが良いかもしれませんが、 今回は試論ですし、そこまで細かくしないほうが話として分かりやすいと 思うので、このようなモデルを採用しました。 [an error occurred while processing this directive]
さて、上に挙げたような判定処理を行なうには、 ともかく判定器を考えないわけには行きません。 なにしろ、上に挙げた、PCやItemという構成要素のすべてが判定器を利用している のですから。
私の作っているオリジナルRPGを見てもらえば分かると思いますが、 通常であれば、私は変った判定方法を好みます。 しかし、今回は OO 的デザインの試みであって、 オリジナルRPGを作ることを目的としているわけではありませんから、 そんなことにおだわる必要もありません。 とは言え、一般的なのを使うのも面白くないので、ちょっと考えてみましょう。
特徴値の和の分の 6面ダイスを振り、1個でも1の目があれば 行為は成功というのはどうでしょうか? また成功の程度は、1の目が出たダイスの数で評価します。 また、行為の難易は振るダイスの個数と、成功するダイスの数で 表現するものとします。
ともかく、ダイスを多く振れば振れるほど、 成功もしやすいし 、 結果も良いものが得られる可能性が有るということですね。
あと、可能性として、1の目の増減も何らかの処理として 考えられますが、とりあえずここでは考えません。 後で何か考えるかもしれませんけど。
これでうまく機能するかどうかは分かりませんが、 とりあえずこれでやっていきたいと思います。 ほら、どうせ思案だし、機能しなくてもかまいませんよね (それはまずいか...)。
参考のために成功率を書いておきますね。 ちなみに、各行の最初にあるのが最後にあるのが、振るダイスの数、 その右に書いてあるのが成功率 (0 〜 1) です。
1: 0.167
2: 0.306
3: 0.421
4: 0.518
5: 0.598
6: 0.665
7: 0.721
8: 0.767
9: 0.806
この成功率の分布の場合だと、 判定に使うダイス数の平均は、4個くらいにするのが良いでしょうか? これだと成功率が50%に近くなります。 多少の訓練を行なっているとか、知識が有るというくらいでの 成功率をこれくらいと考えましょう。
先ほど、能力と技能の両方をほぼ同じ割合で、若干技能に重きを置くように 考えたいと書きました。 また、能力と技能のどちらに重きを置くのかということも書きました。 この判定方法だと、どちらに重きを置くのかということは 結局能力値の範囲と技能値の範囲をどう設定するのかという問題だと 言えます。 つまり、同じ4個を振るとしても、能力で3個、技能で1個というのが良いのか、 あるいはその逆、あるいは両方2個づつという3種類が考えられます。 つまり、能力に重きを置くのか、両方に同じ重きを置くのか、 それとも技能に重きを置くのかという違いですね。
ともかく、ここでは能力と技能を同程度の重きを置いて処理したいと したわけです。 そうすると、能力も技能も、1〜3の値を持つようにするというのが 分かりやすいですね。 まぁ少なくともPCを作る時点でのはなしですが。 とりあえず、後でそれくらいのとこであるということを念頭において、 キャラクター・メイキングを考えるようにしましょう。
さて、この判定器の処理を形式的に書くと、 判定器への入力は判定に使用する能力と技能、 そして判定の難易などによる修正となります。 こここで、 (能力値 + 技能値 + 修正) 個の6面ダイスを振ります。 判定の結果は、1の目が出たダイスの数、これを達成値と呼びます。 この達成値が判定器からの返り値となります。 [an error occurred while processing this directive]
次は具体的にどういうメッセージが流れるのかを考えなければなりません。 あるいは、PCやItemというオブジェクトの持つメソッドを考える、 あるいはPCや、Itemを1つのオブジェクトと考えてきましたがもしかしたら もっと分解して考える必要も有るかもしれませんが。
さて、メソッドを考えるにあたっては、PCにどのような行動が可能なのかを 考えなければなりません。 それは言うまでもなく、PCの行動を分類することに他なりません。 分類をすると、だいたい次のようになると思います。 ま、上に書いたのと同じなんですが。
もちろん、これ以外にももっと考えられるでしょう。 例えば、魔法や超能力、そしてスーパーパワーに関するようなものなどです。 しかし、ここでは特にそれらについては考えず、非常に基本的な行動のみですが、 上に挙げたもののみについて考えを進めていきたいと思います。 後に必要が有れば、追加しましょう。
この分類を、先に挙げた4分類に従って考えると、次のようになるでしょう。
さて、例えば治療にせよ戦闘にせよ複数の大項目に渡って表われています。 このことから、逆に同じ行為であるなら、大項目の違いが影響しても良いのか、 あるいは影響せず同じような処理方法で処理できるほうが良いのかという 問題が出てきます。
もちろん、一般的に言えば、同じ行為であるならば同じような処理方法で、 その一部が使われるか使われないかという程度の違いであるほうが理解 しやすいでしょう。 そして、幸いにも (というか、そうしたからだけど...)、 先の図1はそのような処理が可能なように組み立てられています。
さて、勘の良い人はもうお分かりと思いますが、 このモデルにおいてメソッドとは、 それぞのPCの行動をどう処理するのかということになります。
例えば、技能のみでPCが表現されるものを考えた場合、 個々の技能の設定や処理方法を決定することがメソッドを指定することに なると言えるでしょう。 あるいは、PCの行なう行為というのがメソッドとして 定義されると考えても良いでしょう。 また、先に書いたとおり、特徴値をオブジェクトと考えるのであれば 判定処理のメソッドはそれぞれの特徴値が持つことになります。
ここで用いているモデルだと PC というのは、PCの状態を保持すると ともに、判定処理のメソッドを持ち、 Player とのインターフェースのためのオブジェクトだと考えられます (これはこれで、分けたほうがシステムとして良いかもしれませんね)。 そのため、それぞれの行為の処理は、判定器のメソッドを作るという ことだとも言えます。
ともかく、上に挙げた技能が、行為の4分類のそれぞれにどう割り振られるのかを 見てみましょう。
ここで、「回避」技能が、自分 (および道具を使う) だけでカタがつくものに 入っています。 もちろん、回避というからには、何かが既に起こっていなければならない わけですが、回避によって相手に影響を与えるというわけではないので、 自分だけでカタがつくものに入れてあります。
以下では行為の4分類のそれぞれについてちょっと考えてみます。 [an error occurred while processing this directive]
これらは単に判定器に判定に使う能力、技能、難易度の修正を送り、 その結果として達成値が戻ってくるわけです。 達成値が 1以上であれば、もちろんその行為は成功となります。
ここで「走る」、「薬学」、「医学」については達成値の評価が必要でしょう。 これについては後程考えましょう。 また、「視覚」については距離などによる修正が必要でしょう。 これについても後程考えましょう。
ここで、達成値の評価を行なう必要が有るということが分かりました。 これも判定器と同様に1つのオブジェクト、評価器として 考えることにしましょう。 [an error occurred while processing this directive]
さて、道具には2種類あるという考え方があります。 つまり、行為を容易に行なえるようにするものと、 行為の結果に影響するものです。
そこで、カテゴリーの場合、判定に使う能力、技能、難易度の修正を道具に送り、 道具は判定に対する修正をさらに追加して判定器に送ります。 その結果として達成値が戻ってくるわけです。 それで、返ってきた達成値を、道具はPCに送り返すわけです。 達成値が 1以上であれば、もちろんその行為は成功となります (仮に、結果に対する影響を考慮するのであれば、 道具に返ってきた達成値が 1以上あれば、達成値に対する修正を達成値に 加えて PC に送り返すとすれば良いでしょう)。
また、結果に影響する場合は (もちろん判定と結果の両方に影響する数値を 持っている道具も考えられます)、達成値と達成値にたいする修正値を 共にPCに戻すことにします。 それを持って評価器 に渡すとしましょう。 [an error occurred while processing this directive]
さて、PCの行為はまず道具を使わずに行なう行為と同じです。 ただし、その結果を今度は対象となる他者に送り、 それを参照して判定を行ないます。
その他者が行なった判定の達成値をPCに返し、 PCは自分の達成値から他者の達成値を引いた値が1以上であれば PCの行為が成功だとします。
判定処理そのものは、2回ありますが自分に影響する行為と一緒です。 ただ、他者の行なう判定には、PCの行なった行為の結果による修正が 追加されますが。
PCの達成値から他者の達成値を引くという処理ですが、 この処理のために、達成の評価を行なうという部分を追加して考えましょう。 どうせ、「走る」云々の達成値の評価も必要ですし。
さて、すると問題は、PCの達成値を他者の判定にどう影響させるかです。 結果の評価として、達成値が1以上で成功という線は譲れません。 それに対して、PCの達成値と他者の達成値が同じだった場合、 その結果は 0 になってしまいます。 すると、PCの行為は失敗と評価されることになります。 まぁ、それはそれでも良いわけですが、 私としてはどうせ PC と他者が同じ結果であるならばPCの 成功として評価してあげたいという気持があります。
すると、その分、他者の成功の割合や達成値が低くなるように 処理を行なう必要があります。
そこで、 PC の達成値の 1/2 (小数点以下切り捨て) を、他者は判定の際の 負の修正値として追加をするとしたいと思います。 [an error occurred while processing this directive]
基本的には、上記の道具を使わずに他者に影響する行為と同じです。 ただし、PCの行為の際には道具を使うわけです。
なお、ここに限りませんが、他者に影響を与える場合、 その他者が道具を使う場合も考えられますが、 その場合、道具を使うだけですむという処理を行ない、 その結果をもって他者の結果とすれば良いでしょう。
ただし、道具による結果に対する修正は、比較の結果に対して 追加します。
さて、上の「道具を使うだけでOK」というところで、 でPCの達成値と、道具によって与えられる達成値を分けて PCに返すと書きました。 というのも、例えば戦闘においては相手の回避の正否と 結果のダメージは別の処理が必要だと思うからです。 [an error occurred while processing this directive]
さて、評価器というのが導入されましたので、まずは 先の図 1を改訂した図2を以下に示します。
で、この評価器では何を行なうのかを考えると、主なものは、 たぶん次のようなものになると思います。
ここで成功/失敗の評価はまったく問題ありません。達成値が1以上なら 成功だからです。 せいぜい、達成値が高ければよりよい結果が得られたという程度の評価で 充分でしょう。もちろん、もっと技能ごとに詳細に設定するほうが 良いかもしれませんが。
他者に影響を与えたときの結果評価というのは、 次のダメージや肉体的な結果の評価とも関係しますが、 それ以前の段階、つまり両者の達成値を比較するという 処理する部分と考えます。 具体的には PC の達成値から、他者の達成値を引いたものを PCの達成値と読み換え、その結果が1以上であれば成功とするわけです。
つぎに、戦闘におけるダメージ評価は、 ダメージをどのように決定するかという部分と、 そのダメージをPCのダメージ・ポイントに加えていくという2段階の処理が 考えられます。
肉体的な行為の評価ですが、達成値によって走る距離などを換えたい、 つまり達成値が高ければ速く走れたということを表現するための 評価を行なう部分です。
この4つのうちの、前の2つは全然問題は無いものと思います。 そこで、以下では残りの2つについてもうちょっと考えてみましょう。 [an error occurred while processing this directive]
さて、ダメージはどうやって決めましょうか? 達成値そのままでも良いですね。
で、そのダメージを、相手のダメージ・ポイントに追加していくことに します。
なお、達成値と、達成値に対する修正値が共に与えられている場合には、 まずPCの達成値と相手の達成値を比較してPCの行動の正否を決定します。 この時点でPCの行為が成功していた場合、つまりPCの達成値 - 相手の達成値が 1以上であった場合、 その値をPCの達成値として読み換えた上で達成値に対する 修正値を加え、最終的な結果とします。
もしも、両者の達成値の比較の時点でPCの行為が失敗していれば、 相手にダメージは与えられません。 ここで、場合によっては、返り打ち的な結果をもたらすことを可能に しても良いでしょう。 [an error occurred while processing this directive]
さて、これが問題です。 達成値をどのように走れる距離などに結びつければ良いのでしょうか?
とりあえず、ここでは、走る場合だと 100 + 10 * 達成値 m の走破が可能だと しましょう。 おっと、走る距離を決める場合には、1回のPCの行動時間がどれくらいに なるのかも決めておかなければ話になりません。 ここではとりあえず30秒だとしておきましょう。
また跳躍の処理も必要かもしれません。 立ち高飛びで 50 + 10 * 達成値 cm の跳躍にしましょうか? 幅鳶だと 150 + 10 * 達成値 cm としましょうか? それぞれ走ってやる場合だと、数m 以上走れば 高飛びでは 150 + 20 * 達成値 cm 、 幅跳びでは 200 + 20 * 達成値 cm としましょう。
持ち挙げるという場合だと、持ち挙げる対象があるわけですから、 その対象の重さ / 10Kg (切り捨て) 個のダイスを振って判定を行なうとしましょう。 成功した場合、50 * 達成値 cm だけ持ち挙げたり動かせたとしましょう。
投擲の場合、これも他者に働きかけるわけですが、 投げる物の重さ / 500g (切り捨て) 個のダイスを振って判定を行なうとしましょう。 成功した場合、20 * 達成値 m だけ投げられたとしましょう。
これらは、本当はちゃんと資料を調べて決定しなければなりませんが、 とりあえずここではだいたいこんな感じとしておきましょう。
ともかく、「走る」技能などによる移動なども、PCオブジェクトが 自分のいる位置を保持していると考えれば、 同様に判定の結果によって管理オブジェクトによって 内部状態を書き換えることで表現できるとするのも良いかもしれません。 [an error occurred while processing this directive]
えと、ここではとりあえず近未来のホラーという設定でしたので、 ホラー的な雰囲気を醸し出す部分も必要でしょう。
1つにはモンスターの設定でも表現できますね。
もう1つはCall of Cthulhu の SAN 度でやっているような 特徴をPCに設定することです。もちろん、そういう特徴も必要でしょうが、 今回は設定していません。 この場合、そのような特徴を管理するオブジェクトもしくはメソッドを PCに追加する必要があります。
今回は特に考えません。いずれこの文章の改訂時には追加するかも しれませんが。 [an error occurred while processing this directive]
さて、これまでRPGシステムを考えてきました。 しかし、まだこれだけではセッションの運営はできません。
まず第一にキャラクターを作らなければなりません。
また、セッションは時間的な視点から分解すると、シーンの連鎖になります。 シーンはラウンド、ラウンドはターンとフェイズに分解できるでしょう。 これらの特にラウンドとターン、フェイズがどのような手順で処理されるのかを 決めなければなりません。 例えばPCやNPCの行動順序はどうなるのか、 ラウンドやターンはゲーム内でのどの程度の時間に対応するのかなどなどです。 先に「走る」あたりの関係で 1ラウンドは 30秒としましたがね。
また、物品も設定しなければなりませんね。
こういう、運営に関するルールもきちんと決めなければなりませんし、 またこちらについても OO 的処理を考えるべきかもしれません。
ともかく、これらについてちょっと設定しておきましょう。 [an error occurred while processing this directive]
では、これらに基づいてキャラクター・メイキングの方法を 考えましょう。
キャラクター・メイキングは、能力値を決め、取る技能とその技能値を決め、 能力値「力強さ」にもとづいてダメージ・ポイントの上限を決めます。 最後に持ち物を決めます。
能力値の決めかたですが、ここではポイント割り振り制にしたいと思います。 先にだいたい能力値は2くらいと考えました。 能力の数は6個ですので 6 * 2 として 12ポイントを割り振ることにします。 この時点では、能力値は 1 以上、4以下の範囲に入っていなければならないと します。
次に技能と技能値ですが、現時点で設定してある技能が21個あります。 まぁ、ある程度の技能を取ってその技能値の平均は2と考えました。 そこで、 とりあえずだいたい半分の 10 個の技能を取るとして 10 * 2 ですから 20 ポイントを割り振って技能および技能値を取ることに します。 で、割り振らないものもあって良いわけですから、 技能値は 0 以上 6 以下になっていなければならないとします。
このあたりの数字は、あとでテストしながら修正すれば良いでしょう。
ダメージ・ポイントの上限は先に書いたとおり、「力強さ」を基準として 設定すると書きました。 そこで、とりあえずダメージ・ポイント上限は 10 + 「力強さ」としましょう。 ただし、ダメージポイントを3つづつに分け、1段階ごとに判定に負の修正が 付くことにしましょう。 0から2 は 修正は 0、 3から 5 の修正は -1、 6から 8 の修正は -2、 9から 11 の修正は -3、 12から 14 の修正は -4、 15から 17 の修正は -5 、... とします。 そして、上限を越えた場合にはPCは死亡とします。
物品は、現代日本において多くの人が持っているであろうものは 持っていて良いとします。 またPCの職業柄持っていると考えられるものも、持っていて良いとします。 その他は所持金を決めて買ってもらいましょう。 所持金は、1d6 * 10万円としておきましょう。 [an error occurred while processing this directive]
先に1ラウンドは 30秒としました。 この1ラウンド中にどういう順番でPCが行動を行なうのかを決めておきましょう。
行動順序としては「敏捷」の大きい順番に行動を行なうことにしましょう。 全PC、NPC全員がその行動を1順するのをラウンド、 それぞれのPC、NPCの行動の番をターンと呼びます。 [an error occurred while processing this directive]
どうしましょうか? 考えていません。ごめんなさい。 [an error occurred while processing this directive]
物品を表現する数値は、これまでの結果から、判定に対する修正と、 結果に対する修正とします。
あとは重さなんかも必要かもしれませんが、これまでの 考察では考えていませんので無視します。 重さも考慮するのであれば、PCの状態管理のメソッドで処理可能でしょう。
ところで、物品のリストは面倒なんで、今は作りません。 [an error occurred while processing this directive]
以上です。 まぁ、試論であることと、まだ考えがまとまっていないためです。 ただまぁ、これを書きながら少しですが光明が見えてきた気がします。 とりあえず、もう一回図を見てみましょう。 ここでは、PlayerとGMは省略しています。
なお、【オリジナルRPG作成について考える】 の［システムの全体像］で 書いたモジュール性、今回用いたモジュール (オブジェクト)とは 分割のしかたが違います。 もちろん、［システムの全体像］に基づいた モジュール化も可能でしょう。 今回は要素に分解しながら考えたため違うようなものになったわけですが。
今回やってみて思ったことは、RPGとはもともと OO 的思考によって作られている のではないかということです。 ただ、これまでのところ、技能などの処理についてはあまりOO的思考にはよらず、 経験的な部分に負うところが多かったのではないかと思います。
どういうことかと言うと、今回用いたような4分類に類するものを提示しておけば、 PCの様々な行為について一般的な処理方法が提示されることになります。 しかし、これまでのところ、そういう処理方法はGMがルール・ブックから 読み取らなければなりませんでした。
これらのような意味で、RPGはもともとOO的に作られていたものの、 メソッド定義にあたっては OO 的要素が少なかったと言えるのかも しれません。
さて、 OO というのは情報処理の分野では既にかなり一般的な 手法になっていると言っていいでしょう。 ただし、今回勉強して分かったのは OO プログラミングと オブジェクト指向 モデリング (以下 OOM)とは 非常に異なったものであるということです。 もちろん OOM に基づいて オブジェクト指向プログラミング (以下 OOP) を行なうのが 理想的なのだと思いますが、 OOM というのは OOP に比べていまいち知られていません。 OOP の場合であれば OOP 言語の処理系が有ればとりあえず出きてしまいます。
しかし、 OO 言語の開発の一因 となった 保守性を 実際に高めるには、やはり OOM からきっちりと やらなければならないであろうことも理解できました。 また、 OOM に基づくと、 機能単位の区分がはっきりしたり、機能単位間や機能単位とユーザーとの界面が はっきりしたりします。
これまでRPGシステムの開発は結局のところテストプレイで問題を発見して いくしかありませんでした。 もちろん OOM をしたところで最終的な問題はテストプレイをしなければ なりません。 しかし、 OOM によって問題を分析することにより、機能面での欠落や 処理方法の不統一性の問題というのはかなり回避しやすくなるものと思います。
ただ、 OOM の問題点として、「どうやれば良いのかが分からない」 というかそのやりかたの定式化がなされていない、あるいはできない というところでしょう。 記法は UML として定式化されているんですけどね... ですから、正直に言うと、OOMの勉強やRPGシステムの分析などをやりながら ここまで書くのに4ヶ月ほどかかってしまいました。
で、この試論を読んでいただいた方も、OOMのやりかたなどは 各自で勉強してもらうしかないのですが、 とりあえず例としてこの試論があるわけですから、 私がやったよりはずっと速く RPG システムの OOM と設計の概略が 理解できるものと思います。 もちろん、この試論が良いものであるか (あるいは良いものになりうるか)、 それともバカ丸出しなのかは今の私には判断できないのですが...
ぜひ、皆さんも RPG システムの OOM に基づく作成を考えてみてください。
そう、 OO と言えば、昔どこだったかが「オブジェクト指向で Fuzzy な システム」というのを謳い文句にした A.I. というシステムを発売するはず でした。でもその会社が潰れてそれっきりだし。 また今年の夏くらいに、メソッド・ベースドという、 OO を連想させる システムもある会社から発売予定でした (Nebula Games の ROPE)。 ところが CCG のほうがもうかるということで (本当か? )、 その 優先順位は下げられてしまい、これまたいつ出るのか分からなくなって しまいました。
それらが出ていれば、私がこんな不完全なものを書いたり 公開する必要も無かったのに。
あぁ、もっとちゃんと OOM しなくちゃ。 そうすれば、この文章ももっと整理して書けるようになるのですが。
とりあえず現時点ではここまでです。 疲れたし... いずれまたこの文章を読み直したり、考察を進めたり、 テストプレイをしてみたりということに基づいて改訂をします。 [an error occurred while processing this directive]
では、最後にここまでに考えたことをルールブック的にまとめておきましょう。 [an error occurred while processing this directive]
PCは、能力と技能という数値を持ちます。 能力とはPCの持つ肉体的な一般的な能力を表現するものであり、 技能とはPCの持つ特定の行為についての能力や知識を表現するものです。
能力は次の6つがあります。
これらに、12ポイントから割り振って能力値を決定します。 ただし、いずれの能力値もキャラクター・メイキング時には1以上4以下で なければなりません。
また技能には、次の21個があります。
これらに、20ポイントから割り振って技能を取ってください。 なお、キャラクター・メイキング時には技能値は0以上6以下でなければ なりません。
このほかダメージ・ポイントという数値が有ります。 これはPCの受けたダメージを表現するもので、 その上限は10+力強さとします。 この値を越えるダメージを受けた場合には、PCは死亡してしまいます。 また、以下に示すようにダメージ・ポイントによって判定に修正が付きます。
判定は大きく4つの種類があります。
ここで、「PCが道具を使わずに自分だけで結果を得られる行為」が 処理の基本となります。 この処理は、行為を行なうのに使う技能値と能力値の和に等しい数の 6面ダイスを振り、1個でも1の目が出れば成功とします。 1の目だけが成功であり、他の目は関係有りません。 また、1の目が出たダイスの数を達成値と呼びます。
この際、行為の難易などにより、GMの判断で、振るダイスの数を上下させても 構いません。
次に「PCが道具を使い自分だけで結果を得られる行為」の場合です。 基本的には上の「PCが道具を使わずに自分だけで結果を得られる行為」と 同じですが、判定に際して使う道具ごとに設定されている 判定における修正値を追加します。 つまり、その修正値の分だけ振るダイスが増減することになります。 また、道具によっては達成値に対する修正値も設定されます。 これは判定の結果の達成値に、修正値を加えたものを最終的な達成値とします。
3つめの「PCが道具を使わずに、他者に影響を与える行為」ですが、 基本的には「PCが道具を使わずに自分だけで結果を得られる行為」の判定を PCとその対象が行なうことになります。
ただし、行為の対象となる物は判定においてPCの達成値の1/2 (切り捨て)を 負の修正値として追加します。
この結果、PCの達成値と対象の達成値が得られます。 ここでPCの達成値 - 対象の達成値という計算を行ない、 結果が1以上であればPCの行為の成功と考えます。
4つめの「PCが道具を使い、他者に影響を与える行為」ですが、 これは2つめと3つめの合わせたものになります。 ただし、道具による結果に対する修正は、PCの達成値 - 相手の達成値の 結果に対して処理されるものとします。
本当は「走る」などの評価についてもここで書いておくべきでしょうが、 とりあえず今回は書きません。 [an error occurred while processing this directive]
戦闘は基本的に上記の「PCが道具を使わずに、他者に影響を与える行為」 もしくは「PCが道具を使い、他者に影響を与える行為」となります。
ただし、達成値を相手のダメージ・ポイントに追加していきます。 この結果、ダメージ・ポイントが上限を越えた場合、そのPCやNPCは 死亡してしまいます。 [an error occurred while processing this directive]
うーん、疲れた。とりあえずここまでにします。