仕様分析10
こんなふうに考えてきたところで、ちょっと振り返ってみましょう。注意する点は、先に書き出したエンティティが、その世界観を再現するのに充分かというところです。書き出されていたエンティティは、なにかしら特徴的なものだけだったかもしれません。ですが、それ以外のエンティティはどうでしょうか？
たとえば、「走る」というエンティティは書き出されているでしょうか？ もちろん、「走る」というエンティティが書き出されていなければならないというわけではありません。ですが、仮に判定器にかける必要があるなら、書き出しておきましょう。
ただし、エンティティによっては判定器が出す結果のうち、成功/失敗は無関係で、エフェクトの結果のみ使うという場合もありえます。「走る」であれば、多くの場合、「走る」ことは判定するまでもなくできるでしょう。ですが、どれくらい速く「走れる」かについては判定器のエフェクトの結果を採用したいという場合があるかもしれません。
そういうわけで、判定器はなにかできているとして、どういうものに判定器が必要かを考えながら、もう一度エンティティを見直し、必要なら書き加えましょう。
なお、これにより、 “Primary” と “Secondary” が、先に書き出したものとは変わってくるかもしれません。また、 “Primary” を元に、キャラクターを現わすなにかを作ったかもしれませんが、そこにも変更が加わるかもしれません。
かなりの手間ではありますが、手間を惜しまずにやってください。
ところで、「仕様分析1」の図1ですが、判定器を他とはそれなりに離れた、あるいは独立したものとして描いています。もしかしたら、「判定器とはそのように独立して存在できるものではない」と考える方もいるかと思います。
それなりに独立させるのと、独立させないのとどちらが良い/悪いということはありません。判定にも世界観を反映させたいという場合もあるでしょうし、そうは考えない場合もあるでしょう。
ただ、どちらにせよ、書き出したエンティティの処理ができるかどうかは重要です。カードなどの小道具を使って判定器に介入する方法もありますが、できるならそのような場合でも、判定は統一的にできるようにしておくことをお勧めします。これは、行為あるいはエンティティごとに判定のやり方が違うというような極端な場合、システムについての理解が面倒になるためです。
カードなどを使うにせよ使わないにせよ、フレームワークはきっちりしていた方が理解しやすくなるでしょう。単純な方法としては、エンティティの一部はカードにするというような方法です。とくにエフェクトが特殊だったり手間がかかる場合には、むしろカードなどにすることを検討してみてもいいかもしれません。
ただ、個人的な考えとしては、プレイヤーであればキャラクター・シートがあれば事が済むようにしておくのが好みではあります。そのためには、ルールはシンプルかつ統一されている必要があるでしょう。ですが、これも結局は好みであり、またどれくらいうまくルールやシステムに落し込めるかという話でもあります。
もうお気付きの方もいるかと思いますが、「判定器」をできるだけ独立させておくと、「汎用システム」寄りになります。また、そうする際には、特定の世界観を判定器に持ち込むのは避けた方がいいかもしれません。
汎用システムとは言っても、実はそう簡単な話ではありません。一般にこのような理解がされているわけではありませんが、すこし見てみましょう。よくあるだろうものは、判定器が同一であるものです。これを「Engine」と呼びましょう。これは、能力値にせよエンティティにせよ、できる上限の制限がそのまま判定器やエンティティに含まれているものです。それに対して「Shell」と呼ぶものを想定しましょう。これは「Engine」にある制限がないものです。ないというか、「利用者はそこから決めてね」というものです。そしてもう一つ「メタ・システム」があります。メタ・システムというは、システムを作るためのシステムというもので、「能力値の決め方はこうするかああするか、それとも別のこうする」などが書かれているものです。
この連載は、残念ながらメタ・システムではありません。というのも、肝心の判定器の決め方をなにも書いていないからです。メタ・システムであっても、なにがしかの「こうする」とうものがあるのですが、この連載は「前提なし」を前提としているため、判定器についても大したことは書けないからなのですが。
ともあれ、もう一度エンティティと判定器を見直してみましょう。
ここまでは一回の判定に関係するような話でした。次回は、セッションを通して機能するルールないしシステムについて考えてみます。たぶん、仕様分析は次回で終りです。そのあとは、バグ・フィックスの話になります。
