ゲーム開発に内在する癌

ゲーム開発以外のプログラム開発では、商用ライブラリやオープンソースライブラリを利用することが多い一方で、ゲーム開発チームの多くはツールを内製し、一般的な機能をスクラッチする。近年のゲーム業界に、Unityの出現というパラダイムシフトがあったことは言うまでもないが、そのパラダイムシフトはモバイルゲーム開発など、ごく一部であると認識している。そして、ライブラリが存在するとしても、社内にとどまっているのが現状である。

しかし、コスト意識を持って開発に取り組んでいる方なら想像がつくと思われるが、ツールの内製や機能のスクラッチがもたらす工数の増加は馬鹿にならず、これがゲーム業界の慢性的な超過業務や、経済的な不振、業界としての発展の停滞につながっている可能性は否定できないのでは、と筆者は考える。

それでは、今後この体質の変化は見込めるのか？筆者の考えではNOで、その理由はおおきくわけて２つある。

ゲームプログラムは、ハードウェアの性能（CPU、メモリ、VRAM）をフルに使い切るようなアプローチをとる。格闘ゲームではフレーム落ちは許されず、60フレームを死守という言い方がされる。そうした中でコードサイズさえも制限され、例えば（C++での開発という前提で）STLやテンプレートの機能がプロジェクトの方針という形でカットされる。

こういった背景がある中で、例えば、一般的な2Dスプライトツールがあったとしても、プロジェクトで必要の無い機能が乗っていて、それによって出力データが大きくなってしまうとなれば、自然と選択肢は、これまで脈々とチーム内で受け継がれてきた内製ツールをメンテナンスする流れに進む。また、汎用ライブラリがあったとしても、頑張ればスクラッチできる範囲であれば、自分でスクラッチした方が、インポートに必要な読み込み時間が省かれるし、最低限の機能にとどめればコードサイズも抑えられる。

といっても、そこまで神経質にならずに、管理が簡便化と設計をスマートにすることを優先して、組み込みライブラリを使用する例は一般的である。スクリプト言語を用いたシーケンス管理やsqliteによるパラメータ管理などである。といっても、プロジェクトによってもシーケンス管理の方法がまちまちであることは、いうまでもなく、方法が統一され、ライブラリ化されたものがあらゆるゲーム開発で採用される、という形が理想のはずである。

ここまでが１つめの理由である。２つめの理由は、ゲームタイトルがエンターテイメント作品であり、“個性”というものがもてはやされるためである。
あらゆるプロジェクトで同じグラフィックライブラリが採用されて、同じような画が出ることを開発陣は危惧している。それによって、ユーザーがこれまで感じていた、ゲームタイトルごとの差異にもとづく新鮮みを感じられなくなるためだ。結果的に彼らは、多くのプロジェクトで作成されるグラフィックシステムやモーションシステムをスクラッチする。

また、こういったコアの部分をライブラリを採用してしまうと、システムをスクラッチするという経験が蓄積されず、技術者が育たないことを開発チームは危惧する。一度技術を失えば取り返しが付かないと考えている。
さらに、ゲームタイトルはエンターテイメント作品であるとともに、高い品質が求められる。ライブラリの都合で読み込み時間が発生することは許されず、そのライブラリがスクラッチしたものであれば、自分たちでなんとかできるという安心感が保証されるのだ。

ゲーム開発には、ライブラリの利用がもてはやされない背景があり、これによって工数の増幅や技術発展の停滞を生んでしまっている。今後、高いハードウェア性能をもったプラットフォームが出現したとしても、より高い品質のタイトルが求められることになり、この体質の改善にはつながらない。これまで述べた理由には尤もなものもあるかとは思うが、現状のままで良いはずはなく、何か早急な対策が必要であることは言うまでも無い。現場の開発者が積極的な運動をおこさない限り、永続的に続くものであり、この体質が続く限りゲーム開発に未来はない。