ゲームオブジェクト設計の変遷（つづき）

システムにはキャラクタが上に乗ると別の場所へ移動するポータルが存在した。この位置や転送先はこれまではマップのデータに静的に書き込まれたものを展開していただけだったが、サーバからネットーワークを介して届く情報に基づいてその属性を決定する必要がでてきたため、Ghostのツリーに組み込み、一つのGhostPacketDrivenとして扱うことにした。（変遷期の図参照）

これはもちろん問題なく機能するのだが、当然一つのGhostとして扱われているため、HPやセリフを話すことを前提としたルーチンやパケットに基づいて座標を移動するなどの無駄な機能をもってしまっている。その上このままでは今後も人型ではない何かをGhostPuppetのようにネットワーク越しに制御したいときには、人用の型を組み合わせて構築しなければならない。ちょうど熱を出して頭がぼんやりしていたついで、Ghostの中から基礎の基礎になる単純な構造をとりだして、Ghostの一段上から始まる継承ツリーを設計しなおすことにした。

これまでのGhostは、

• エンティティ管理クラスに対してトップレベルのインターフェイスの提供(例えばTickとかOnMoveとかDrowとかそういう類の）
• 各具象クラスに対してエンティティの状態情報のデータ構造そのものを提供（いわゆるコンテキスト。例えばHPとか座標とか）
• 全ての人型エンティティが共有できるルーチン（例えば移動時の座標の補間やジャンプ、攻撃を受けたときの攻撃情報の評価、HPが0になったら死亡状態になる等の抽象的なレベルでの状態遷移の管理）

の3つを担っていた。（決してお前ら具象クラスは全部まとめて霊魂クラスだぜ俺ってオブジェクト指向してるぜカッコイイぜ俺と悦に入るためではない）この3つについて、それぞれのうちから基礎の基礎になりうるものを選り分けて基底クラスを作り上げるつもりなのだが、このGhostを直に継承しているGhostInteractiveを始めとする3種類の機能を司る抽象クラスは、その機能自体がGhostの構造に大きく依存していることを理由にGhostを継承しているのであった。ここが困ったところで、つまりもしも依存しているGhostが内部的に分割されてしまうならば、自分たちもその依存している部位に応じて分割されなくてはならないということになるのだ。

つづく