2.4ゲームロジック
ようにそのレジストリに登録し、他のサブシステムは必要に応じてイベントを送る。このイベントは事前に登録したサブシステムにだけ送られる。
第10章ではこのシステムについてさらに掘り下げ、その仕組みを詳しく解説する。
2.4.4プロセスマネージャ
ゲーム世界のシミュレーションは、通常、非常に単純な個別のコードから構成される。例えば、オブジェクトを直線経路に沿って動かす、Luaのスクリプトの構文解釈をする、といったコードだ。こうした小さなコードを結合して1つのオブジェクトに作用させることで、こうした状態変化を結合させることができる。こうしたコードをクラスにまとめれば、どのゲームオジェクトに対してもインスタンス化することができる。「この経路に沿って動かす」クラスと「Luaスクリプトを実行する」クラスを作り、これらのクラスを1つのオブジェクトに対してインスタンス化すれば、2つの単純なコードから複雑で面白い相互作用を得ることができる。
これはゲームのもう1つの重要なサブシステムの中枢部ともいえるプロセスマネージャである。プロセスマネージャはプロセスのリストを管理する部分で、ゲームループごとに1つのプロセスを呼び出し、小さなCPU時間を与える。この好例が、経路探索プロセスだ。このプロセスはオブジェクトをある場所から別の場所に動かすためのプロセスで、目的地に達したら操作を終了してそのオブジェクトへの作用をやめる。
『ウルティマVI』から得た貴重な教訓
実話
ウルティマVIの完成後、プログラマたちはオリジンシステムズの中庭に集結し、『ウルティマ』の技術を『ウルティマVに向けて再設計するための計画を練ることになった。最高の天気。ホワイトポードもあるし、さらにいいシステムという目標を目指して皆の気持ちも1つになった。このブレーンストーミングで生まれたのが、1つのオブジェクトあるいはオブジェクト群を一定時間操作するコードを協調プロセスにカプセル化し、ライフタイムも各自で管理させるというアイデアだった。そして作業を終えたコードは自滅させる。このアイデアの最も優れた点は、稼働中のプロセスのリストを持っているただ1つのクラスによって、すべてが管理できるという点だった。この技術は最終的には、複雑だが便利な、ちよっとしたOSレベルにまで進化し、協調プロセスとリアルタイムプロセスの両方をこのシステムで管理できるようになった。
ウルティマ』では、プロセス間に依存性を持たせたのがよかった。つまり、あるプロセスが動作しているとき、他のプロセスはその動作が終わるのを待って動作を始めるということだ。火炎瓶を考えてみよう。1つのプロセスが火炎瓶の放物線運動を追跡し、それが何かと衝突したら、別のプロセスがそれを爆発させる、といった具合だ。ゲーム内でこうしたプロセスを繋ぎ合わせると、驚くほどクールな効果を生み出すことができる。
このシステムについては第6章でさらに詳しく説明する。