目次
1.はじめに
今回はゲームの設計手法について解説します（参考：ゲームクリエーターズバイブル）
これを使うのは「ゲームデザイン」完成した後の「基本設計～詳細設計」あたりになると思います。
なぜこのようなものが必要であるのかというと、細かいところをあまり考えずに作り始めると、ある程度できたところで実は面白くなかった、という事態が必ず発生します。
その場合に、急いで仕様を追加しようとすると、色々な部分に手を入れる必要がでてきます。そうやって修正をしているうちに、「あれ？？動かなくなっちゃった…」ということになってしまうことがよくあります。
※ちなみに既存の部分に手を入れる場合には、
- どの部分を修正するのか？（修正範囲）
- どの部分に影響があるのか？（影響範囲）
をじっくり検討することで、「手戻り」を防ぐことは可能です。とは言うものの、修正をしないでガーっと作れてしまった方が楽ですよね。そのためにしっかりと設計を行うわけです。
手順としては、
- トークンの抽出
- トークン同士の相互作用表の作成
- トークンの有限状態マシン図の作成
という順番で行います。
2.トークンの抽出
設計の最初に行うこととして、「トークンの抽出」があります。
トークンとは、そのゲームを構成する最小単位のことです。
例えば、「ブロック崩し」を考えてみます。
- ブロック
- ボール
- パドル
- 壁
- 穴
- スコア
がトークンになります。
この抽出のコツは、とりあえず、「これがトークンかな、、?」と思うものを書き出しておいて、「これがなかったらゲームにならない！」というものでふるいをかけます。で、最後まで残ったものが本当に必要なトークンとなります。
3.相互作用表の作成
トークンの抽出が完了したところで、「トークンの相互作用表」を作成します。トークンは独立して存在しているわけではありません。別のトークンと「相互に作用」しています。
例えば、ボールがブロックに衝突した場合ブロックが壊れる、とか、ボールがパドルに衝突した場合ボールが跳ね返る、とか、ボールが穴に落ちた場合ゲームオーバーとなる、とかです。
実際の表は以下のようになります。
| → → → | パドル | ボール | 壁 | ブロック | 穴 |
|---|---|---|---|---|---|
| パドル | – | – | – | – | – |
| ボール | ボールが跳ね返る | – | – | – | – |
| 壁 | パドルが止まる | ボールが跳ね返る | – | – | – |
| ブロック | – | ブロックが壊れる | – | – | – |
| 穴 | – | ゲームオーバー | – | – | – |
ただしこれは「衝突」という状況を想定した表となります。読み方としては、行と列の考査する点に処理を書いていきます。例えば、行の「ボール」と列の「パドル」が交差する点で「ボールが跳ね返る」となっていますね。（”-“は何も起きません）
4.有限状態マシン図の作成
相互作用表でも、設計は行うことはできますが、トークンが複雑に状態遷移する場合には、有限状態マシン図（以下、FSM図[Finite State Machine]）を利用した方がよいです。
確かに相互作用図は、「全てのトークン」の作用の一覧を確認することができます。（全体）
しかし、「１つのトークン」がどのような作用をするのかを細かく書きたい場合があります。（個別）
それがFSM図です。
例えば、「スーパーマリオ」の「マリオ」トークンを中心にしたFSM図がこの図です。
矩形が「トークンの状態」を表します。丸が「発生するイベント」です。
見方としては、例えば、キノコ取得イベントが発生します。そのイベントは「赤の線」でトークンの状態とつながれていますので、さらに赤の線をたどります。つまり、その先のスーパーマリオ状態になるわけです。その状態で、クリボーに衝突すると、青の線をたどりチビマリオになりますよね。これを相互作用図で書こうとすると、項目が多くなりすぎたり、イベントの処理の記述量が増えてしまい可読性が落ちてしまいます。
それでは、仕様を確認するのが大変ですよね。という感じで、あるトークンが複雑に状態遷移する場合、このようにトークンの状態遷移を視覚的に確認できるのがFSM図の利点です。今回紹介した手法は、設計の唯一のアプローチではなく、たくさんの他の手法を知っていた方が、より柔軟にアプローチが行えると思います。
例えば、UMLのようなモデリング手法を使うのも良い場合がありますし、フローを書く場合には、PAD図を使う方法もあります。
