SYDEKICKとは 4

System Development Kit というものをTRPGにおいて作れるためには、まずTRPGのルールとは、すくなくともいくつかの部分に分けられるという前提が必要になるかと思います。次の2つの図を見てください:

私はTRPGをこのようなものと考えています。もちろん、ここで2つの図を挙げたように、状況や必要に応じてあれこれ変えたものを用います。2つの図に関連したものとしては、TRPGを作ろうを参照していただくといいかもしれません。

とりあえず、四角が大きなモジュールだとしてこの図を見てください。このモジュール群はそれぞれ独立していると言えるのでしょうか? これは、必要最大限の独立性を持ちうると言えます。完全に独立していたら、逆に各モジュールは存在する理由がなくなります。必要となるのはインターフェースです。

Software Development Kit の場合、そのインターフェースは引数と返り値、あるいは副作用としての状態変化も入れてもいいでしょう。ですが、このくらいに収まります。 Software Development Kit というわけではありませんが、ちょうど話題になっているので三角関数関係で話をしてみましょう。三角関数に与える角度の値は、度数法の度によっても、ラジアンによっても、グラードによっても与えることができます。少なくとも人間相手にはですが。しかし、コンピュータに計算させようとしたら、プログラムなりファイルなりの先頭などにおいてどれを使うかを宣言するか、三角関数の引数としてどれを使うのかを指定するか、言語やライブラリなどの仕様において規定するか、もしかしたら起動オプションやコンパイルオプションによって指定するかという選択肢があります。そのどれであってもかまわないのですが、少なくともその関数において、かつその時点においてはどれであるかが分かっていなければなりません。

もし、度数法の度、ラジアン、グラードが混乱したらどうなるでしょう? ある関数ではラジアンを引数に取るとしているにも関わらず、度数法の度を与えたとしたらどうなるでしょう? 言うまでもなく、いわゆるバグが生まれます。これは最低限、ある関数に与える引数を用意するという時点にまで遡って考える必要があります。別の関数が計算の結果として度数法の度を返り値としたとします。この返り値が度数法の度であり、ある関数はラジアンを引数として要求しているということがわかっていれば、その間に度数法による度からラジアンに変換する工程を入れることで繋げて使うこともあります。別の言い方をすれば、インターフェース規格がわかっていれば、いろいろなんとかなるともなります。ただし、様々な関数などがおのおの好き勝手にどれかを選んでいると、使う側としては面倒になります。ですので、少なくとも特定の環境下では、どれであるかを固定した方が便利となります。

SYDEKICK も似たようなものです。モジュールというよりも、サブモジュールや、サブサブモジュールあたりの話になりますが、それらの間でのインターフェースを想定しています。では、そのインターフェースとはなんでしょう? ここは2段階にして考えています:

• 1次インターフェース: 修正値と基本達成値

• 2次インターフェース: 技能レベル、Gift レベル、Flaw レベル

実のところ、2次インターフェースは1次インターフェースの修正値に含めていいものです。ただ、SYDEKICKとして上記のような名前を着けているため、ここでは2次インターフェースとして挙げています。

というわけで、入ってくるもの ―― 修正値 ―― と、出ていくもの ―― 基本達成値 ―― が決まっているわけです。また、それらが適切と思える範囲に収まるように、 "EQUIPMENTS" などにおいて例示してもいますし、 "BASIC　SIZE" においては計算方法を示しています。後者は、特定の範囲を超えなことを保証するものではありませんが。

また、そこがあるため、 "EXPANSION　JUDGEMENTS" では、サブモジュールごとに読み替えも発生することとなります。

サブモジュールやサブサブモジュールはインターフェースを介して値をやりとりすることで、なんらかのまとまりとしての処理を行ないます。SYDEKICK では1個のサブサブモジュールも module Complex と呼んで構いませんが、 module Complex という考え方はこのようなことを意識した時により強く活かせます。

SYDEKICK においてモジュールはインターフェースによって結びつく。これが SYDEKICK の考え方です。