プログラマからみたゲームプログラミングの本質的複雑さ(2)
- 前：プログラマからみたゲームプログラミングの本質的複雑さ(1)
今後広く使われるであろう有力なミドルウェアとして、PhysXやHavokなどの物理演算ミドルウェアがある。このような物理計算のミドルウェアは、本質的な複雑さがさほど大きくはない。基本的にこのミドルウェアがやる仕事は、世界の中に球や箱・平面などを置いて、タイムステップごとにそれらの位置を再計算するだけだ。この程度の処理内容であれば十分に高度な抽象化が可能で、やりたいことをほぼすべて実現できるようにしつつ、扱いやすくて美しいインターフェースを持ったライブラリを構築する難易度は、それほど高くはないだろう。
十分によくできた物理ミドルウェアであればコリジョン判定のアルゴリズムの詳細や、めり込み・振動などを防ぐための工夫などは外部から見えない場所に隠蔽され、プログラマは「物理計算を使ってやりたいこと」だけをライブラリを通して記述するだけでいい*1。そして、そのようなプログラマがミドルウェアの外側に記述した部分こそが、「アプリケーションの本質」になるのだろう。
また、FPSというジャンルのゲームは、本質的な複雑さがとても低い。
たとえば、初代DOOMを例に取ると、
- BSPで構築されて当たり判定を持った世界の中に、プレイヤー・敵などのゲームオブジェクトが存在する。
- すべてのゲームオブジェクトは時間のステップごとに位置や内部パラメータを更新し、銃弾や直接打撃などを介して他のオブジェクトに干渉する。
- プレイヤーの体力パラメータが０になればゲームオーバーとなる。
- 指定の当たり範囲内にプレイヤーが入ることで、次のエリアに移動できる。
- 最終エリアの出口に到達することで、ゲームは終了する。
初代DOOMは基本的にこれだけの要素で構築されている。MarathonやHalf-Lifeなどのゲームがここにいくらかの要素を付け加えはしたものの、このような観点から見ると、世の中にあるほぼすべてのFPSは初代DOOMと本質的には大差がない。
MarathonやHalf-Lifeは、「敵」ではないがそれと同程度の複雑さを持つオブジェクトを利用することで、その世界の中でリアルタイムに会話や演出が行われていると錯覚できるようなしくみを実現したし、映像や技術面に関してはこの頃から比べれば格段の進歩は遂げたものの、根本的な部分だけみればやはり上記の要素から逸脱するものではない。
「Unreal Engine」のようなゲームエンジンは、このような単純な仕組みのゲームを効率よく作るために存在する。FPSの最低限の基本ルールは既にライブラリ内に実装されているため、あとはそのゲーム固有の「アプリケーションの本質」部分を個別にそのライブラリを使って実現するだけで、簡単に新しいゲームを作ることができる。そうやって、海外では雨後の筍のようにちょっとづつルールの違うFPSのクローンが量産されてきた。
また、このような本質部分の同一性はFPSに限った話ではなく、マリオ64やゼルダ、メトロイドプライムのようなゲームであっても、３Ｄのアクションであればやはりこの枠内に分類することができるし、２Ｄのゲームはそこから次元を一つ削るだけなのでやはり本質的には同じ、ということもできるだろう。基本的にどんなゲームであっても、必要になる根本的な部分は変わらずシンプルであって、同じミドルウェアの上で実現できるものなのかもしれない。
ここまでの話をまとめると、
- ミドルウェアの外に書いたものがアプリケーションの本質
- ミドルウェアはアプリケーションでできることの幅を限定し、高度なミドルウェアに依存することは、アプリケーションの幅を確実に狭める
- しかし、世の中のほとんどのゲームはFPSのと本質的には変わらない要素を持つため、このようなミドルウェアを使うことによってゲームの幅を狭めることなく、効率的な開発が可能になる（少なくともミドルウェア信奉者はそう信じている？）
ということになるだろうか。
続：プログラマからみたゲームプログラミングの本質的複雑さ(3)
https://nao-u.hatenablog.com/entry/2006/06/01/000000
*1：多分、実際の製品に使うときにはそんなに甘くはないのだろうけど･･･。
