ゲームシステムデザインのモデリング：「FF13」のオプティマシステムその３

ゲームシステムのデザインのモデリングをやってみよう企画の第五回目。

前回の続きとして、今回も、FF13のオプティマシステムを対象にモデリングしてみる。

モデリングの概要

具体的なモデリングに入る前に、どういうモデリングなのかが少し分かってきたのでまとめてみる。

何を表現するためのモデルか？：このモデルは、ゲームシステム上の仕様を細かな決定要素からなる構造に分解して表現する。
- 決定要素とは、たとえば「アビリティがある」「カウンター（というアビリティ）がある」「カウンターは5%の確率で発生する」といったもの。

何のためのモデルか？：このモデルは、個々の決定要素をプレイヤーの不満の観点から検討・評価・再決定するために利用できる。
- たとえばプレイヤーは「カウンターの発生率が低すぎて役に立たない」というような不満を持つかもしれない。これは「カウンターは5%の確率で発生する」という決定に対する不満である。したがって、この決定を変更する必要があるかもしれない。

また、これまでのモデリング実験で判明したことは次のようなこと。

何かの種類に関する決定が存在する。たとえば「職業の種類」など。
- 種類の数を決定要素として明示的にモデル化すると良い。「職業数は5つである」
何かの値に関する決定が存在する。たとえば「カウンターは5%の確率で発生する」
- どんな種類の決定かで起こりうるプレイヤーの不満を予測できる。たとえば、「職業数が少ない」
モデルの表現方法を工夫する必要がある。表現する要素が多くなると分かりにくくなる。

オプティマシステムの概要

以下は、オプティマシステムがどのようなものなのか知っている方は読み飛ばしてもらってもかまわない。

今週のファミ通情報によると、FF13のバトルの中心的な位置づけとなるオプティマシステムというのは、各キャラクターにロールを付与して、それにより戦略等に幅を持たせるようなもの。ロールの組み合わせをオプティマと呼ぶ。たとえば、「ディフェンダー」「アタッカー」「ブラスター」というロールで構成されるオプティマは「ラッシュアサルト」と呼ばれる。バトル中に、あらかじめセットしておいたオプティマを選択することで、状況に合わせて戦略を変更できる。

で、今作では、プレイヤーが操作しているキャラクター以外のメンバーは、AIにより行動する。どういう行動をとるかは、どんなロールが割り当てられているかによって決まる。たとえば、ロールが「ヒーラー」だと基本的には回復の行動しかとらなくなる。回復が必要になったら「ヒーラー」のロールがいるようなオプティマに変更すれば、回復行動を行ってくれる。そういう意味で、オプティマを変えることは、メンバーの行動の作戦を変更するようなものだと考えられる。

イメージはこの動画がちょっと参考になるかも。

で、さらに、オプティマシステムについてファミ通情報から分かっていることを書いてみる。

オプティマはバトル中に何度でも変更できる
バトル中にL1ボタンを押すとセットしたオプティマの一覧が表示される
セットできるオプティマのスロット数には制限があるが、増やしたりもできる。
ロールには、「アタッカー」「ブラスター」「ディフェンダー」「ヒーラー」「エンハンサー」が今のところ判明しているある。未知のロールがある可能性もある。
ロールにより、ボーナス効果が付与される。たとえば、「アタッカー」だと自身と仲間の攻撃力を上げる効果が付く。
ロールごとに、使えるアビリティが決まっている。
ロールにはレベルがある
ロールのレベルが上がる過程で、新しいアビリティを覚える
キャラクターごとに覚えられるアビリティと覚えられないアビリティがある
キャラクターごとに得意なロールと苦手なロールがある。得意なロールには物語の最初から変更できても、苦手なロールには物語が進まないと変更できない。

モデリング

前回は、次のモデルを作ったところで中断した。

今回は前回やり残した以下の事柄についてモデリングしたい。

キャラクターごとに覚えられるアビリティと覚えられないアビリティがある
キャラクターごとに得意なロールと苦手なロールがある。得意なロールには物語の最初から変更できても、苦手なロールには物語が進まないと変更できない。

まずは「キャラクターごとに覚えられるアビリティと覚えられないアビリティがある」ということに関係する決定要素を図に追加してみよう。以下の5つを追加した。

「キャラクターごとに覚えられるアビリティと覚えられないアビリティがある」
「ライトニング」
「ヴァニラ」
「ライトニングはアビリティXXXを覚える」
「ヴァニラはアビリティXXXを覚えない」

実際に追加したのが下記の図になる。図を見やすくするため、オプティマに関わる左半分は省略した。

なお、「ライトニング」と「ヴァニラ」の二つについては、これまでの図では単に追加していなかっただけで、「キャラクターごとに覚えられるアビリティと覚えられないアビリティがある」が存在するかどうかに関わらず存在していると見なせる要素である。

「キャラクターごとに覚えられるアビリティと覚えられないアビリティがある」という要素は「キャラクターが存在する」と「アビリティがある」という要素の存在を前提とする要素である。

どのキャラクターがどのアビリティを覚える/覚えられないのかは分からないため、仮として「ライトニングはアビリティXXXを覚える」と「ヴァニラはアビリティXXXを覚えない」にした。

ここで少し迷ったのは、「あるキャラクターがあるアビリティを覚える」という決定が行われていなければ、それは「そのキャラクターがアビリティを覚えない」ということを意味するのではないか、したがって、「覚える」に関わる決定だけを書いて、「覚えない」という決定は省略してもいいのではないか、ということがあった。最終的には、省略せずに書くことした。理由は、省略されてしまうと、「決定し忘れなのか」と「覚えないのか」の違いが分からなくなるためである。したがって、原則としては決定事項は省略せずに書くと良いと思われる。

ただし、仕様書として書く場合は、次のように省略して書いても問題ないかもしれない。

アビリティ名	覚えるキャラクター
アビリティXXX	ライトニング
アビリティYYY	ヴァニラ
アビリティZZZ	ライトニング, ヴァニラ

さて、一つ考察できるのは、覚える/覚えないといった2値（真理値）的な決定を要求する決定と、実際の決定が存在すると言うことである。

2値的な決定を要求する決定：「キャラクターごとに覚えられるアビリティと覚えられないアビリティがある」
実際の2値的な決定：「ライトニングはアビリティXXXを覚える」「ヴァニラはアビリティXXXを覚えない」

ただし、この考察は単に理論的な意味であり、実践的は意味はないかもしれない。

続いて、以下の仕様をモデリングしてみよう。

キャラクターごとに得意なロールと苦手なロールがある。得意なロールには物語の最初から変更できても、苦手なロールには物語が進まないと変更できない。

次の要素を追加した。

「キャラクターごとにストーリーの進捗に応じて変更できるロールが決まる」
「ストーリーがある」
「イベントAがある」
「イベントBがある」
「ライトニングがイベントAの終了時点で変更できるロールがある」
「エンハンサーに変更できる」
「ヒーラーに変更できる」

ここで「キャラクターごとに得意なロールと苦手なロールがある」というのは、抽象的な表現であると解釈して、それの意味するところは「キャラクターごとにストーリーの進捗に応じて変更できるロールが決まる」であるとした。また、ストーリーはイベントの集合からなると考えて、「イベントAがある」「イベントBがある」のような仮の要素を追加した。こうすることで、「ライトニングがイベントAの終了時点で変更できるロールがある」といった決定要素を表すことができる。

以上で、FF13のオプティマシステムのモデリングを終わりたいと思う。最終的なモデリング結果は次の図になる。

次回

次回は、この作成したモデルをもとに、このオプティマシステムの狙いについて少し考えてみることにしたい。