仕様分析1
さて、要求分析においては、ゲーム内のあらゆるものはENTITYであるとしました。また、それに付随する「程度」もまた書き出してあるはずです。
次に必要なのは、作りかたは好き好きとは言え、どんな形であれ「判定のメカニズム」です。「どんな形であれ」と書いたのは、そのメカニズムが存在しない場合も含めてです。しかし、そのメカニズムが存在しないとしても、たとえば「GMに一任」と書けば、システム上においてはそのような形で存在することになります。
そのために、システム全体としての基礎的なメカニズムを考えてみましょう。そこで、次の図1を見てください。これはおおまかにシステムを図示したものです。システムは必ずこの形として分析できるというわけではなく、この図はその一例です。また、この図はオブジェクト指向の考え方に基いています。
図1
この図の中で、 "Player" と "GM" は、ゲーム内世界の外に存在しています。また右下にある「判定器」は、これまで言及していませんでした。
この図を、矢印についた番号に沿って説明していきます。
1. 「行動宣言」
これは、PlayerがGMに対して、自分のPCの行動を宣言します。
2. 「処理条件」
宣言された行動に対して、どのように処理を行なうかを、 GM が Player に宣言します。
3. 「処理条件」
Player は、GM によって与えられた処理条件を、PC、あるいは特に GM と Player が等しい場合には NPC に与えます。
4. 「処理条件」
PC または NPC は、その処理条件を用いて「判定器」によって判定します。ただし、後程説明しますが、オプションとして "Item" が関係する場合があります。また、システムによっては、他の PC や NPC もここでの "Item" 扱いになるものがあります。
4.1.1. 「処理条件」
"Item" を使う場合、処理条件を "Item" に渡す必要があるかもしれません。なお、この "Item" は、アイテムや小道具に限りません。「魔法」などがある世界の場合、それらも含みます。
4.1.2. 「処理条件」
ここでは、 "Item" を経由した場合の判定を考えています。
4.1.3. 「結果」
"Item" を経由した場合の判定結果を "Item" に返します。
4.1.4. 「結果」
"Item" を経由した場合の判定結果を PC/NPC に返します。
5. 「結果」
"Item" を経由しなかった場合、「4. 処理条件」の結果が PC/NPC に返します。
5.1.1. 「PC/NPCの処理結果 = 処理条件」
PC/NPC が、他の PC/NPC に働きかける場合、PC/NPCの判定結果を他の PC/NPC などへの処理条件として与えます。これは、たとえば、判定結果を他のPC/NPCなどの判定の修正値とするような場合です。
5.1.2. 「処理条件」
与えられた処理条件を判定器に与え、判定します。
5.1.3. 「結果」
結果を他の PC/NPC などに返します。
5.1.4. 『結果」
他の PC/NPC などに対しての処理の結果を PC/NPC に返します。
6. 「結果」
最終的な判定の結果を Player に返します。
7. 「結果」
最終的な結果を、Player は GM に伝えます。
8. 「描写」
GM は、 Player から伝えられた結果に応じて、状況の描写や、 PC/NPC に適用するなにがしかを Player に伝えます。
9. 「結果適用」
Player は、GM からの指示に従い、 PC/NPC に結果を適用します。これは、たとえば HP の減少などが含まれます。
10. 「結果適用」
GM は、他の PC/NPC などが判定に関係していた場合、他の PC/NPC などに結果を適用します。あるいは、結果の適用を要請します。これは、たとえば HP の減少などが含まれます。
これは、あくまでシステムの仕様の一例ですが、どのようなTRPGであれ、判定に関してはだいたい同じような事柄が行なわれています。 "Item" や "他のPC/NPC、その他の物や事" の扱いは、システムによってこの図とは大きく異なるかもしれませんが、なんらかの形で判定処理に関わっています。
この図でわかる事には、判定には次の4種類があるということです。
- 「PC/NPC のみで処理が済む行為」
- 「PC/NPC に Item などが関与して処理を行なう行為」
- 「PC/NPC が他の PC/NPC などに関与する行為*」
- 「PC/NPC が Item などを用いて他の PC/NPC などに関与する行為*」
ただし、この図には示していませんが、「他の PC/NPC、その他の物や事」においても、すくなくとも "Item" が関与する場合があります。ですので、実際の処理の類型は、「*」を付けておいた 2つが実際には4つになり、計6種類になります。もっと細かく分けることもできますが、例としてのシステムの仕様分析としてはこれくらいで充分でしょう。
このような図を描くのは簡単ではないかもしれませんが、先に表計算に書いた内容から、どのようなものとのようなものが関係しているかを見れば、暫定的なものは描けるだろうと思います。もちろん、上に示した図と同じになるとは限りません。
あるいは、このような図を描くのは無駄だと思われるかもしれません。しかし、全体像を早い時期に掴んでおくことは無駄ではありません。図として描くかどうかはともかくとして、なんとなくではあっても、このようななにかを思い描くことは無駄ではありません。少なくとも、例外だらけのシステムにしたくないなら、ぜひ思い描き、できれば実際に描いてみましょう。補足するなら、例外だらけであることがウリのTRPGも存在します。それのよしあしや好き嫌いはともかくとして。
次回は、ENTITY (の一部) と、この仕様分析の図がどう関係するかを見てみます。