MASATOの開発日記

2002/12/28

ただいま、実家に帰っております。実家は開発環境が無いので、 だらだらと駄文を書いて過ごすのみです。

ゲームのアーキテクチャ失敗例その1

今まで、私は何度かゲームのアーキテクチャを設計したが、 今現在、それらが良いアーキテクチャだったとはちょっと思えません。
そこで、SVGの練習を兼ね、今までどんなアーキテクチャで、どんな点が失敗だと思ったのか 説明して行きます。

まず最初に、結構昔使っていたアーキテクチャとその問題点を説明します。例としてRPGを使います。
UMLのクラス図で書くと、こんなクラス構成となっておりました。 なお、これは抽象的な図であり、正確に書いたものでは有りません。

ざっと説明しますと、Stateパターンが中核となっています。 ユーザの入力等により、Gameクラスの状態が、Title,Field,Battleのどれかを取ります。
Titleはゲームの状態がタイトル、すなわちタイトル画面制御用のクラスで、 Fieldは、フィールド画面制御用のクラスで、Battleは戦闘画面制御用のクラスです。 フィールド画面をうろついていると、突然戦闘画面に切り替わるようなゲームだったと思って下さい。
Title,Field,Battleはそれぞれ複数のGameObjectを持っていて、これらが画面上のキャラクタやマップやテキスト等を表します。 Title,Field,Battleは、自身が所有しているGameObjectを全て行動させたり、表示させたりすることによりゲームを進めます。 ある特定のGameObjectが、ある特定の状態になったら、Gameのstateが他のものに切り替わります。例えば、こんなときです。

• カーソルオブジェクトのy座標が1の時にスペースキーが押されたとき
• 全ての敵のHPが0以下になったとき
• プレイヤーのHPが0以下になったとき
• マップオブジェクトが、敵出現を検出したとき

しかし、この構成には、次のような問題点がありました。

• 各GameStateの派生クラス間でデータを共有するのが困難。
  FieldとBattle間で共有したいデータ（例えば、プレイヤーのHP）は意外と多いのですが、 共有するための仕組みが無く、実装が結構大変でした。
• 各GameStateの派生クラス間の遷移の制御が困難。
  戦闘終了後、Gameクラスのstateがどれになるのかは、Battleクラスが決定していました。 例えば、プレイヤーのHPが0以下になったときは、タイトル画面に移り、 全ての敵のHPが0以下になったときは、フィールド画面に移っていました。 しかし、イベント中に戦闘に突入したときはプレイヤーのHPが0になっても フィールド画面に戻って欲しいと思ったとき、それを簡単に制御する方法がありませんでした。
  ゲームの状態遷移は、gotoのように行ったら戻ってこないものではなく、callのように、元の状態に 戻ってくるとした方が適切なのかもしれないと思いました。
• セーブ／ロードが困難。
  現在の状態をセーブするとき、 例えば、Characterクラスのインスタンスは、キャラクターの顔の画像とHPを保持しています。 顔の画像は保存しなくても良いのですが、HPは保存する必要があります。 このように、保存する情報と保存しない情報を選別する必要がありました。
  ロードするときも、保存されている情報は選別されてますので、 その情報から、GameObjectを元の状態に復元しなければなりません。 これが結構面倒でした。

これらの問題は、結局無理やり実装して解決しました。 グローバル変数のようなものを一つ二つ追加すれば、大概の問題は片がつきます。 その後の保守／修正が面倒になるだけです。

ゲームの開発では、途中で仕様変更はぼこぼこ入りますし、 ソースコードの使いまわしというのもなかなか難しいものです。 よってゲームの全体的な設計を行うときに目指すものは、再利用性ではなく、 実装量を減らせるような設計ではないかと思います。
具体的には、

• 仕様変更に伴う実装変更が少なくて済む設計
• 各オブジェクト間の連携を暗黙的に行ってくれるような設計

ということになるのではないかと思います。

(2002/12/29) 細かい点を何点か変更しました。

(2003/01/05) 強調する部分に色を付けました。