ゲームシステムデザインのモデリング：「FF13」のオプティマシステム
ゲームシステムのデザインのモデリングをやってみよう企画の第三回目。
今回は、FF13のオプティマシステムを対象にモデリングしてみます。
今週のファミ通情報によると、FF13のバトルの中心的な位置づけとなるオプティマシステムというのは、各キャラクターにロールを付与して、それにより戦略等に幅を持たせるようなもの。ロールの組み合わせをオプティマと呼ぶ。たとえば、「ディフェンダー」「アタッカー」「ブラスター」というロールで構成されるオプティマは「ラッシュアサルト」と呼ばれる。バトル中に、あらかじめセットしておいたオプティマを選択することで、状況に合わせて戦略を変更できる。
で、今作では、プレイヤーが操作しているキャラクター以外のメンバーは、AIにより行動する。どういう行動をとるかは、どんなロールが割り当てられているかによって決まる。たとえば、ロールが「ヒーラー」だと基本的には回復の行動しかとらなくなる。回復が必要になったら「ヒーラー」のロールがいるようなオプティマに変更すれば、回復行動を行ってくれる。そういう意味で、オプティマを変えることは、メンバーの行動の作戦を変更するようなものだと考えられる。
イメージはこの動画がちょっと参考になるかも。
で、さらに、オプティマシステムについてファミ通情報から分かっていることを書いてみる。
- オプティマはバトル中に何度でも変更できる
- バトル中にL1ボタンを押すとセットしたオプティマの一覧が表示される
- セットできるオプティマのスロット数には制限があるが、増やしたりもできる。
- ロールにより、ボーナス効果が付与される。たとえば、「アタッカー」だと自身と仲間の攻撃力を上げる効果が付く。
- ロールには、「アタッカー」「ブラスター」「ディフェンダー」「ヒーラー」「エンハンサー」が今のところ判明しているある。未知のロールがある可能性もある。
- ロールにより、使えるアビリティが変化する。
- ロールにはレベルがある
- ロールのレベルが上がる過程で、新しいアビリティを覚える
- キャラクターごとによって覚えられるアビリティと覚えられないアビリティがある
- キャラクターごとに得意なロールと苦手なロールがある。得意なロールには物語の最初から変更できても、苦手なロールには物語が進まないと変更できない。
さて、ここまでオプティマシステムについて分かっていることをざっくりと説明してきた。でも、このように文章で書かれると、このオプティマシステムを構成する個々の細かな要素がどう関係し合っているのかが把握しにくいんではないだろうか？ ということでモデリングしてみよう。ちなみに、このモデリングの話は段階的に、その場的に、書きながら悩みなどを書いていくので、奇麗な話の流れにはなっていないので注意。
オプティマシステムというのは、ゲームデザイナー（企画者orディレクターorプランナー）が決めたことである。いってしまえば、仕様である。ここでは、仕様をゲームデザイナーが「決めたこと」の集合だとして捉えて、それをゲームシステムデザインと呼んでいる。
前回までと同じく、今回のモデリングも、「決めたこと」と「それらの間の関係」の観点から行う。ここでいう関係とは、「これを決めるにはまずこれが決められていないといけない」と言う関係である。前回までで少し問題にしたように、この関係付けには多少無理がある点もあるけれど、初期の試みだと我慢して、とりあえずは突き進んでみよう。
まずは、オプティマシステムというのは、そもそも「バトルがある」ということを前提をしなければ存在できない。なので、以下の図は「バトルがある」という決定に「オプティマシステムがある」という決定は依存していることを示している。
前回も書いたように、このモデリングの仕方はちょっと違和感があるかもしれない。というのもオプティマシステムというのは、最初にこのシステムの説明をしたことからなる総称であると考えられるためである。同様にバトルというのも抽象的な表現である。とはいえ、特に気にせずモデリングをすすめたい。
次に、オプティマシステムの主要な構成要素である「ロール」と「オプティマ」をこの図に追加する。まずは、「ロール」から。
この図では次の二つの要素を追加した。
- ロールがある
- 各キャラクターはバトル中に特定のロールを持つ
モデリング上悩んだのは、「ロールがある」という決定は何か他の決定と独立して決定できるものであるかという点である。つまり、次のような図は何を意味するのかである。
ロールと言う概念は、現実的な意味からいうと、何かに対して付与されるものである。その何かを決めずに決めることができるのか。ある意味では、次のように書く方がいいのかもしれない。
つまり、ロールはキャラクターに付与されるものなので「キャラクターが存在する」という決定が行われていれば、「ロールがある」という決定も行えるという見方である。ただしそれだけでは、仕様としての詳細度に欠ける。たとえば、次のような疑問がでる。
- キャラクターは常に特定のロールを固定的に持つのか。
つまり、デザイナーはさらに詳細な決定を行っていることになる。
ここでは「各キャラクターはバトル中に特定のロールを持つ」と書くことでより詳細な決定を表した。実際は、さらなる詳細化が必要かもしれない。
ここでの疑問は、どこまで詳細化したモデルを作るのか？ ということかもしれない。一つ今回のモデリングが対象としていないのは、モデリングの結果は仕様書ではないということである。仕様書として使えるかもしれないが、目的は異なると思っている。このモデリングの一つの活用は、モデル結果をプレイヤーがどう評価するかもしれないかに使うことである。僕の調査では、プレイヤーはゲームプレイを通じて、デザイナーの個々の決定に対して満足・不満を持つ。したがって、一つ一つの決定あるいは決定間の関係が潜在的に、特にどんな不満を生み出す可能性があるのかを考えることが重要になる。モデル結果は、デザイナーが行った決定と、決定間の関係を表す。ある決定が不適切であると評価したなら、その決定を変更する必要になる。そのとき、その決定が他の決定とどう関係しているのか、この決定を変えることで他のどんな決定を変える必要があるのかを把握する必要がある。このモデリングは、そのような目的のために使うことを意図している。
続いて、オプティマをモデルに追加してみよう。
ここでは、「ロールの組み合わせによってオプティマが決まる」という決定要素を追加した。この決定は「ロールがある」という決定がなければ存在できない。たとえば「ロールがある」から「ロールがない」という決定に変わったら、オプティマという概念は存在できない。このように、この決定が変わったら他のどの決定が変わるか、いう観点で考えてみることで、その決定がどの決定に依存しているのかを確認できる。
次に、オプティマに関わる決定されたことを追加してみよう。オプティマは、プレイヤーが事前にセットしたものの中からバトル中に自由に選択できる。また、選択は何度でも行える。
ここでは、まず「バトル中にオプティマを選択できる」という大きな決定があって、その決定が存在するとして細かな決定「事前にセットしたオプティマが選択できる」「何度でも選択できる」が行われるとして表している。
このあたりから、個々の決定に対する評価が行えるようになる。たとえば「バトル中にオプティマを選択できる」ではなく「オプティマはバトル前にあらかじめ設定されたものが使われる」という決定、別の言い方をすれば「バトル中にオプティマを選択できない」であるという決定であれば、どうなのか？ バトルの面白さにどう影響を与えるのか？というようなことを考えることができる。
別の例では、「事前にセットしたオプティマが選択できる」ではなく「どんなオプティマでも選択できる」という決定だとしたらどうだろう？ さらに別の例では、「何度でも選択できる」ではなく「あらかじめ決められた回数で選択できる」であるとしたら？ 後者は、一見、プレイヤーに対してより戦略的な考えを要求することになるかもしれない。あるいは、「あらかじめ決められた回数で選択できる」という決定を行ったときに、プレイヤーからは不満としてそのまま「あらかじめ決められた回数で選択できる」ということが挙げられるかもしれない。
次に、「事前にセットしたオプティマが選択できる」というのはさらに決定を行う必要がある。というのも、いくつセットできるかをこの決定は言っていないからである。
ここではファミ通からは具体的な仕様を読み取れなかったので「事前にセット可能なオプティマ数は？個である」としている。この決定に関しても、いくつかプレイヤーの不満が予測できる。たとえば「事前にセット可能なオプティマ数が少ない」などである。
続いて追加する決定は、これまでのものとは毛色が少し違ってインタフェースに関する決定である。「L1ボタンを押すとオプティマの一覧が表示される」というのを追加する。
この決定はさらに詳細化でるかもしれないが、ここではこの粒度にしておく。
次に、さらに毛色の違う要素を追加する。先ほどの決定である「L1ボタンを押すとオプティマの一覧が表示される」は、「L1ボタンが存在する」ということを前提としている。さらにいえば「L1ボタンが存在する」は「コントローラが存在する」ということが必要である。これらを表してみよう。
これら二つの決定は、デザイナーからみればコントロールできない環境的な決定である。モデリング上の疑問は恐らく、これら環境的な決定要素をモデルに追加する意味は何か？ ということだと考えられる。一つは、別の開発環境への移植を考えた場合、このような環境的な要素との依存関係を明確にしておくと、役立つかもしれないということである。
ここまででかなり長くなってしまったのでオプティマシステムの残りは、後半でさらにモデリングすることにする。今回、（僕も含めて）学べたことは次のことである。
- このモデルでは、ゲームシステム上の仕様を細かな決定要素からなる構造に分解して表現する。
- このモデルは、個々の決定要素をプレイヤーの不満の観点から検討・評価・再決定するために利用できる。
- このモデルでは、環境的な決定要素もモデリングする。
続きはこちら。
