ゲームの設計手法
文章:syun
日付:2005/4/24

目次
1.はじめに
2.トークンの抽出
3.相互作用表の作成
4.有限状態マシン図の作成
5.解答






1.はじめに
今回はゲームの設計手法について解説します

(参考:ゲームクリエーターズバイブル

コレを使うのは「ゲームデザイン」完成した後の「基本設計〜詳細設計」あたりになると思います。

なぜこのようなものが必要であるのかというと、
細かいところをあまり考えずに作り始めると、
ある程度できたところで、
「ああぁ〜〜、この処理じゃ動かないよーー!!」
という事態が必ず発生します。

その場合に、急いで仕様を追加しようとすると、
色々な部分に手を入れる必要がでてきます。

そうやって修正をしているうちに、
「あれ??動かなくなっちゃった…」
ということになってしまうことがよくあります。
(このことを業界用語で「手戻り」「デグレ」「エンバグ」などといいます)

※ちなみに既存の部分に手を入れる場合には、
どの部分を修正するのか?(修正範囲)
どの部分に影響があるのか?(影響範囲)
をじっくり検討することで、「手戻り」を防ぐことは可能です。

とは言うものの、修正をしないでガーっと作れてしまった方が楽ですよね。

そのためにしっかりと設計を行うわけです。

手順としては、
  1. トークンの抽出
  2. トークン同士の相互作用表の作成
  3. トークンの有限状態マシン図の作成
という順番で行います。



2.トークンの抽出
設計の最初に行うこととして、「トークンの抽出」があります。

トークンとは、そのゲームを構成する最小単位のことです。

例えば、「ブロック崩し」を考えてみます。
がトークンになります

この抽出のコツは、
とりあえず、

「これがトークンかな、、?」

と思うものを書き出しておいて、

「これがなかったらゲームにならない!」

というものでふるいをかけます。

で、最後まで残ったものがトークンとなります。


では、1つ問題を解いてみましょう。
問1 ゲーム「パックマン」のトークンを抽出せよ。
問2 「ブロック崩し」で抽出したトークンだけでは、実は設計上あまり好ましくありません。
   何が不足しているかを考えなさい。
   (ヒント:設計上好ましくないというのは、このままでは個別のトークンがメッセージのやり取りを直接行ってしまう、ということです)




3.相互作用表の作成
トークンの抽出が完了したところで、
「トークンの相互作用表」を作成します

トークンは独立して存在しているわけではありません。
別のトークンと「相互に作用」しています。

例えば、ボールがブロックに衝突した場合ブロックが壊れる、とか、
ボールがパドルに衝突した場合ボールが跳ね返る、とか
ボールが穴に落ちた場合ゲームオーバーとなる、とかです。

実際の表は以下のようになります。
相互作用表

ただしこれは「衝突」という状況を想定した表となります。

読み方は、
行と列の考査する点に処理を書いていきます。
例えば、行の「ボール」と列の「パドル」が交差する点で「ボールが跳ね返る」となっていますね。

バッテンは何も起きません。


問3:ゲーム「パックマン」の相互作用表を記述せよ。



4.有限状態マシン図の作成
相互作用表でも、設計は行うことはできますが、
トークンが複雑に状態遷移する場合には、
有限状態マシン図(以下、FSM図[Finite State Machine])を
利用した方がよいです。

確かに相互作用図は、「全てのトークン」の作用の一覧を確認することができます。(全体)
しかし、「1つのトークン」がどのような作用をするのかを
細かく書きたい場合があります。(個別)

それがFSM図です。

例えば、「スーパーマリオ」の「マリオ」トークンを中心にしたFSM図がこの図です。
FSM図

矩形が「トークンの状態」を表します。
丸が「発生するイベント」です。


見方としては、例えば、キノコ取得イベントが発生します。

そのイベントは「赤の線」でトークンの状態とつながれていますので、
さらに赤の線をたどります。

つまり、その先のスーパーマリオ状態になるわけです。

その状態で、クリボーに衝突すると、青の線をたどりチビマリオになりますよね。

これを相互作用図で書こうとすると、項目が多くなりすぎたり、
イベントの処理の記述量が増えてしまい可読性が落ちてしまいます。

それでは、仕様を確認するのが大変ですよね。

という感じで、あるトークンが複雑に状態遷移する場合、

このようにトークンの状態遷移を視覚的に確認できるのがFSM図の利点です。


問4:
ゲーム「パックマン」において、パックマンを中心としたFSM図を記述せよ。



最後に…。

今回紹介した手法は、設計の唯一のアプローチではなく、
たくさんの他の手法を知っていた方が、より柔軟にアプローチが行えると思います。

例えば、UMLのようなモデリング手法を使うのも良い場合がありますし、
フローを書く場合には、PAD図を使う方法もあります。
(フローチャート図は、設計者により図が変化してしまうため、設計図としてあまりオススメできません(´ー`;

以上、syunでした。




5.解答
解答1:
例えば、以下のようになります。
解答2:
トークン同士が直接メッセージをやり取りすると、
トークンの追加や変更が発生した場合に修正が困難になります。
そのためメッセージをやり取りする場合は、
「ゲーム管理トークン」の存在が不可欠となります。

解答3:
例えば、以下のようになります。
パックマン相互作用表

解答4: 例えば、以下のようになります。
パックマンFSM図