プログラマからみたゲームプログラミングの本質的複雑さ(3)
前：プログラマからみたゲームプログラミングの本質的複雑さ(2)
https://nao-u.hatenablog.com/entry/2006/06/01/000000
じゃあ、ほとんどのゲームはそれくらい単純なものであるはずなのに、いつも作っているゲームのアプリケーション部分はなぜあんなにも複雑なコードやシステムが必要になってしまうのだろうか？その原因についていろいろ考えてはみたものの、今では「本質的にそれくらい複雑なものを作ろうとしているから」としか言いようがないのかもしれない、と思いはじめている。
今の世の中、市販されている大抵のゲームは初代DOOMと比べると明らかに複雑な作りになっている。そのようなルールを実装するには、どんなに優れたミドルウェアがあったとしても、アプリケーションごとに個別に実装するしかない。これから作ろうとしている新しいゲームのある要素を実現しようとしたときに、そのルールがUnreal Engineのようなミドルウェアやゲームエンジンが想定するFPS固有のルールや、そもそも一般的なゲームのルールとも根本的に食い違う部分が出てきたりすることもあるかもしれない。
FPSを作るのに特化したミドルウェアでFPSでないものを作ろうとするのはきっと大変だろう。ちょうど.Net FrameworkがWindowsのGUIプログラミングに特化しているのと同じように、そのミドルウェアがよくできていればいるほど、ライブラリやシステムの設計はFPSの根源的なルールに依存してしまう。
FPSでは必要だけど今作りたいゲームでは不要、とか、また逆にFPSを作ろうとすればいらないものなんだけど、今作ろうとしているゲームには絶対に必要、みたいな要素だってあるだろう。もしその整合性が上手くいかなければ、そのミドルウェアを使って仕事をするのは、アドベンチャーゲームツクールで無理矢理RPGを作るのと似たような余計な苦労を背負い込むことになってしまうかもしれない。
本当に自由にものを作ろうと思うのなら、そのために使える完璧なライブラリやミドルウェアなどはどこにも存在しない。また、ライブラリやミドルウェアはよくできていればいるほど、そしてその環境に使い手側が慣れれば慣れるほど、それを使う人の思考の幅を狭める。だからこそ、ミドルウェアを使うべきかどうかの判断基準は、そのようなことを踏まえたうえで「ミドルウェア部分を自力で作る労力」と「ミドルウェアによって制限される自由度」のトレードオフも考えておかなくてはならないのだろう。
このような自由度の縛りから解放されるには、そもそも「ミドルウェアの制限など知らない」人が、作るべき「アプリケーションの本質」の部分を考えるのが効果的だろう。しかし、結果としてそれでいいものができるとしても、ミドルウェアの枠外のものを無理矢理ミドルウェアの制限内に実装しようとするのは、場合によっては大変な負荷を伴う可能性もある。もともとは労力やコストを抑えてより良いものを作るためにミドルウェアを導入したはずだったのに、何故こんなことに？みたいなことにならないとも言い切れない。
だんだん何の話かわからなくなってきた。やっぱりうまくまとまらなかった･･･。
