MASATOの開発日記

2003/01/05

色々と設計をしていていつも思うこと。自分は本質を見失ってないだろうか。それ以前に自分は本質を理解しているのだろうか。自分がやっていることは何か意味があることなのだろうか。自分が悩んでいる部分は実はどうでも良い部分ではないだろうか。そんなことばっかりです。
つまり、あまり自分を信用できてないのです。
この開発日記を書くときも、いつもでたらめな事を書いてしまってないかと心配しています。いや本当にでたらめな事が書かれているかもしれません。お気をつけ下さい。

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

今回が最後の失敗例になります。前回のアーキテクチャのネットワーク対戦対応が困難という問題を解決するために、変更を施したものです。クラス図を以下に示します。

Battleクラスに、いくつかのクラスが関連付けられています。ゲームの仕様上、 Title,Fieldクラスはネットワーク対戦には関係無いので変更されていません。

新しく追加されたクラスを簡単に説明します。
本当は、ネットワーク対戦におけるサーバやクライアントの役割についても説明しなければならないのですが、一般的な役割しか割り振っていませんので、省略します。

Eventクラスは、戦闘中に発生する様々なイベントを表します。
例えば、魔法のエフェクトを表示する時、BattleクラスはMagicEventを生成します。上の図にはありませんが、MagicEventと同じ位置に、CommandEventや、TimeSpendEvent等、いくつか他のクラスがあります。 Battleクラスは、各GameObjectの状況を確認し、コマンド入力を行う必要がある時にはCommandEventを生成し、何も起こらず時間だけが過ぎるときはTimeSpendEventを生成します。
そして、Battleクラスは、Eventを、ネットワーク対戦時のサーバ（自分自身）及び全てクライアントに送信します。このEvent送信部分のクラスの構成がどうなっているかは、上のクラス図には書いてありません。
ServerExecutorFactoryクラスは、サーバ側の処理を実行するためのExecutorクラスを生成します。
ServerExecutorFactoryは、MagicEventに対し、ServerMagicExecutorクラスのインスタンスを生成します。 CommandEventやTimeSpendEventに対してはServerCommandExecutorやServerTimeSpendExecutorのインスタンスを生成します。
ClientExecutorFactoryクラスは、クライアント側の処理を実行するためのExecutorクラスを生成します。
サーバ側のプログラムと、クライアント側のクラスの構成は、両方とも同じものを使います。ただし、サーバ側は、Battleに関連付けられているのはServerExecutorFactoryであり、クライアント側は、ClientExecutorFactoryであるという違いがあります。
ServerMagicExecutorクラスは、サーバ側において、魔法エフェクトを表示するという処理を行います。
エフェクト表示だけではなく、各キャラクターのHPを減らしたりするのもこのクラスです。
ClientMagicExecutorクラスは、クライアント側において、魔法エフェクトを表示するという処理を行います。
ネットワークの先にあるServerMagicExecutorと通信を行います。といっても、クライアントにおいて、魔法エフェクト表示が全て完了したことを通知する程度です。

このように変更することにより、次のような効果がありました。

ネットワーク対戦が困難だった問題が解決。
もとからこの問題を解決するためだけに変更したので、解決できるのは順当です。しかし、現時点で実装が終わっていませんので、本当に解決したかどうかは不明です。

上記の構成は、Commandパターン（ExecutorがCommandクラスに相当します）やAbstractFactoryパターンを使用し、なんとなく格好良い構成だと一時は思っていたのですが、問題点はいっぱいあります。

一つのイベントXXXを追加するために、XXXEvent、ServerXXXExecutor、ClientXXXExecutorと3つもクラスを追加しなければならない。
クラス数がどんどん増えて行きます。しかも、イベントは最終的にはかなりの数になるはずです。必要なクラスならば仕方が無いですが、たぶんXXXEvent、ServerXXXExecutor、ClientXXXExecutorは1つに纏められるはずです。
Fieldクラスのネットワーク対応が困難。
ゲームの仕様上、Fieldクラスはネットワーク対応が必要無いはずですが、もし対応が必要なんてことになると、かなーり面倒なことになりそうです。 ServerFieldExecutorFactoryなんてクラスが必要になるんですかね・・・
複雑過ぎる。
上記のクラス図は、実際のクラス構成の概略を書いた図ですが、概略でさえ様々なクラスが出てきてやたらと複雑になっています。もうちょっと単純な構成にしないと、今後の機能追加やらなんやらがどんどん大変になって行きます。一回全部ぶち壊して、今まで出てきた問題が全て解決できる単純な構成を考えた方が良さそうです。

というわけで、色々付け足していった結果、わけのわからん構成になってしまったという失敗例でした。次からは、前向きに、どのような構成が良いのかを考えていってみたいと思います。