MASATOの開発日記


前の開発日記 次の開発日記 一覧

2002/12/29

「オブジェクト指向における再利用のためのデザインパターン 改訂版」という本を最近読んでいます。 これがまた素晴らしい。論理展開が明確で、読んでいて非常に分かりやすいのです。 本に記述されているある方法を見て、この方法はこういう利点があるけれどこういう欠点もあるのじゃないかなーと 思いつつ読み進めていくと、その欠点がずばり書いてある。ついでに欠点の回避策まで書いてあって なかなかためになります。オブジェクト指向は多少は詳しいつもりだけど、どのように実践するものかなーというあたりで 悩んでいる人にはお勧めの本です。

私もいつかこの本の筆者のように、分かりやすく物事を説明できるようになりたいです。 この駄文はまだまだ分かりにくいと自分でも感じています。

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

前回の続きです。もちろん今回も失敗例です。誰か成功例を知っていたら教えて下さい。

前回の設計の欠点である各GameStateの派生クラス間でデータのやり取りをするのが困難セーブ/ロードが困難という問題を解決し、 さらにはネットワーク対戦にも対応できるよう、次のような設計としました。

各GameObjectの派生クラスのデータ部をDataクラスに保持させて分離した形となっています。
セーブ時に保存するような情報や、ネットワーク対戦時にホスト間で共有したい情報は 全てDataクラス以下に持たせるようにしました。
セーブする必要も無く、ネットワーク対戦時にホスト間で共有もしない情報、例えば キャラクタの画像のBITMAPハンドルなどは、CharacterDataではなくCharacterが保持します。
また、Characterクラスのインスタンスを生成するときは、 まずCharacterDataクラスのインスタンスを生成し、 それをCharacterクラスのコンストラクタに与えれば良いようにしました。

各GameObjectの派生クラスで、画像データを共有するため、BitmapManagerクラスを新設しました。 Bitmapのファイル名をBitmapManagerに与えると、Bitmapハンドルを返してくれます。 BitmapManagerは、そのBitmapが既にロードされていたら既存のハンドルを返し、 まだロードされていなかったらBitmapをファイルから読み込んでハンドルを返します。

これらの設計変更により、次のような効果がありました。

細かい問題は色々とあっても、大きな問題は無いと思っていたのですが、残念ながら見つかってしまいました。

ネットワーク対戦対応が困難。理由は次の通りです。

こうした状況で、変更された部分だけを送信する、という機能を実装するためには、 巨大な情報の中から適切に変更された情報だけを見つけだし、それを送信するという実装を丹念に行い、 Dataクラス以下が変更されるたびにその部分を再実装しなければならず、非常に困難でした。

また、ネットワーク対戦対応以外にも以下のような細かい問題がありました。

なお、今回の設計は、前回の設計で生じた全ての問題を解決しているわけではありませんので 注意して下さい。

さて、私は上記のネットワーク対戦の問題を解決するため、Commandパターンを導入することにしました。 詳しくはまたそのうち・・・

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

(2003/01/05) Stateパターンは崩れていないので、その旨を書いた一文を削除しました。

前の開発日記 次の開発日記 一覧