Is an Object-Oriented Game Engine necessary? (2)

では、理想的なオブジェクト指向言語における理想的なゲームオブジェクト設計とは何だろう？　私は、良いゲームオブジェクト設計は、前時代に完成されたと考える。ビデオゲームプログラミングは、当時からオブジェクト指向設計の要素を実装してきた。

当時のビデオゲームプログラマがオブジェクト指向のプログラミングを実現することを望まなかったことは、重要である。彼らは、生産的な開発とエキサイティングなゲームを追求してきた。そこに我々が学ぶべきである何かがある。

現在、私達は、十分な仕様のオブジェクト指向プログラミング言語を用いることができる。私は、前のエントリで、それが私達のゲームオブジェクト設計を狂わせる原因であると書いた。しかし、当時のビデオゲームプログラマは、 C++ (Cも!) を使えなかった。従って、彼らは、マシン語を用いた。私が最初に加わったプロジェクトは、アセンブリで書かれていた。そのような条件下で、プログラマは、オブジェクト指向の設計を追求することはできない。従って、その設計は、自然とゲームのために良いバランスになる。

見てみよう。私達が使った技術は、タスクシステムである。もちろん、ビデオゲームプログラマは、 C++ と共に今この手法を使っている。しかし、当時のプログラマは、アセンブリでタスクシステムを書いた。従って、現在の手法と当時の手法には違いがある。

タスクシステムは、ポピュラーなビデオゲーム開発方法のうちの 1 つである。それは、データ格納とジャンプアドレス群から成る原始的なメモリブロックである。振る舞いを変更するには、ジャンプアドレスを書き直す。コールバックされたコードは、オフセットアクセスによってメンバーデータにアクセスすることができる。既にポリモーフィズムは実現していた。そこには「型」がない。しかし、それは、 C/C++ のコンパイルされた結果と類似している。現在、私達は、 C++ でこれを書く。C++ は、 vtable という概念を持っている。従って、もっとうまくポリモーフィズムを実現することができる。

一方、私達のプロジェクトは、タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることを禁じた。つまり、私達は、ゲームオブジェクトの間のメッセージ通信を禁じた。

タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることは、安全ではない、なぜなら、 型がないからだ。C++ は、もう少しうまくそれを扱うことができる。なぜなら、私達は、 C++ でダウンキャストを比較的安全に書くことができるからだ。しかし、それは、同じくデバッグしにくい。私達がそれを禁じた別の理由は、私達はそのような方法からメリットを発見できなかったからである。

子供タスクは、自身のものをコントロールする。しかし、これらのタスクが他のタスクと仕事をする必要がある場合は、子供のマネージャ役である親タスクにまとめて仕事をさせた。私は、この方法が私達への最適解であるかどうかを知らない。しかし、それは、デバッグ、調整、調節に易く、そして、変更のために柔軟であった。

当時、私達の周りには「オブジェクト指向」という言葉がなかったので、私達は、それを追求しなかった。プログラマの自己満足が、ゲームオブジェクト設計の秩序を乱すこともなかった。