ゲームオブジェクトを一般化して管理しないことの妥当性について

なぜわざわざゲームオブジェクトクラスなんてつくって下方へ特殊化するクラスヒエラルキーをつくるんだろう。オブジェクト同士の連絡では、オブジェクトリストを持つ方は信号を伝達するだけで、ダウンキャストなりの特殊化はオブジェクト群のそれぞれの内側で行われるような運用をされる。か、もっと無茶をやる。なんでそういうことをやるのか。自然言語的にそうだから？慣習？リストを保持する方はゲームオブジェクトに新たなタイプが追加されても依存がないので編集する必要がない？こうすることでオブジェクト群から上をそっくり挿げ替えることも依存がないために可能になる？

しかし実際はオブジェクト生成部分が特殊化されたクラスに依存するし、群を走査する部分だけを挿げ替えるなんてありえない。そっちの反論はどうでもいいとして、ゲームルールはゲームオブジェクト同士の交互のやりとりを全体として眺めた状態を完全に規定する。プラグイン系のようなゆるい統合ではやっていけない。完全な記述が求められる。新たな種類のゲームオブジェクトが追加されるとしたら、全ての既存のゲームオブジェクトに対する反応が完全に新たにおこされてなくてはならない。ひとつのピースが残りの全部のピースとの接合部をもっている多次元ジグソーパズルだ。無機的な構造物と比べてここが全く異なっている。

ということで、オブジェクトリストを持つ層は一般化されたゲームオブジェクトのリストを一本持つのではなく、もっと特殊化したものを複数もっているべきだと主張する。例えばプレイヤー、敵キャラ、マップ上のトリガー、特殊なボス。という具合で。こうするとマップ上のトリガーが受け取ったオブジェクトなりIDを自分の内側でダウンキャストをしてプレイヤーじゃなかったら無視する、だのといった処理をしなくて済む。リストを持っている層がトリガーだけが持つ特殊なインターフェイスを使ってプレイヤーだけをトリガーへ渡して評価させればいい。「プレイヤーだけがマップ上のトリガを起動できる」というようなルールの断片がゲームオブジェクト内に分散されず、上層の走査部分にまとまることになる。

大規模アプリケーションプログラムの設計手法に毒されてこんなことにも気付かないでいたんですよ。まったくしようもない。こんなに長々考えぬかないと気がつかなかったようですよ。