ゲーム開発に内在する癌
ゲーム開発以外のプログラム開発では、商用ライブラリやオープンソースライブラリを利用することが多い一方で、ゲーム開発チームの多くはツールを内製し、一般的な機能をスクラッチする。近年のゲーム業界に、Unityの出現というパラダイムシフトがあったことは言うまでもないが、そのパラダイムシフトはモバイルゲーム開発など、ごく一部であると認識している。そして、ライブラリが存在するとしても、社内にとどまっているのが現状である。
しかし、コスト意識を持って開発に取り組んでいる方なら想像がつくと思われるが、ツールの内製や機能のスクラッチがもたらす工数の増加は馬鹿にならず、これがゲーム業界の慢性的な超過業務や、経済的な不振、業界としての発展の停滞につながっている可能性は否定できないのでは、と筆者は考える。
それでは、今後この体質の変化は見込めるのか？筆者の考えではNOで、その理由はおおきくわけて２つある。
ゲームプログラムは、ハードウェアの性能（CPU、メモリ、VRAM）をフルに使い切るようなアプローチをとる。格闘ゲームではフレーム落ちは許されず、60フレームを死守という言い方がされる。そうした中でコードサイズさえも制限され、例えば（C++での開発という前提で）STLやテンプレートの機能がプロジェクトの方針という形でカットされる。
こういった背景がある中で、例えば、一般的な2Dスプライトツールがあったとしても、プロジェクトで必要の無い機能が乗っていて、それによって出力データが大きくなってしまうとなれば、自然と選択肢は、これまで脈々とチーム内で受け継がれてきた内製ツールをメンテナンスする流れに進む。また、汎用ライブラリがあったとしても、頑張ればスクラッチできる範囲であれば、自分でスクラッチした方が、インポートに必要な読み込み時間が省かれるし、最低限の機能にとどめればコードサイズも抑えられる。
といっても、そこまで神経質にならずに、管理が簡便化と設計をスマートにすることを優先して、組み込みライブラリを使用する例は一般的である。スクリプト言語を用いたシーケンス管理やsqliteによるパラメータ管理などである。といっても、プロジェクトによってもシーケンス管理の方法がまちまちであることは、いうまでもなく、方法が統一され、ライブラリ化されたものがあらゆるゲーム開発で採用される、という形が理想のはずである。
ここまでが１つめの理由である。２つめの理由は、ゲームタイトルがエンターテイメント作品であり、“個性”というものがもてはやされるためである。
あらゆるプロジェクトで同じグラフィックライブラリが採用されて、同じような画が出ることを開発陣は危惧している。それによって、ユーザーがこれまで感じていた、ゲームタイトルごとの差異にもとづく新鮮みを感じられなくなるためだ。結果的に彼らは、多くのプロジェクトで作成されるグラフィックシステムやモーションシステムをスクラッチする。
また、こういったコアの部分をライブラリを採用してしまうと、システムをスクラッチするという経験が蓄積されず、技術者が育たないことを開発チームは危惧する。一度技術を失えば取り返しが付かないと考えている。
さらに、ゲームタイトルはエンターテイメント作品であるとともに、高い品質が求められる。ライブラリの都合で読み込み時間が発生することは許されず、そのライブラリがスクラッチしたものであれば、自分たちでなんとかできるという安心感が保証されるのだ。
ゲーム開発には、ライブラリの利用がもてはやされない背景があり、これによって工数の増幅や技術発展の停滞を生んでしまっている。今後、高いハードウェア性能をもったプラットフォームが出現したとしても、より高い品質のタイトルが求められることになり、この体質の改善にはつながらない。これまで述べた理由には尤もなものもあるかとは思うが、現状のままで良いはずはなく、何か早急な対策が必要であることは言うまでも無い。現場の開発者が積極的な運動をおこさない限り、永続的に続くものであり、この体質が続く限りゲーム開発に未来はない。
本棚を整理する意義
うちの本棚は、慢性的にあふれていて、日に日に酷くなって言っています。
並んでいる本は技術書が9割方で、捨てる量＜＜買う量という構図が原因です。
なぜ捨てられないかと言えば、
- 読みたいところだけ読んで、残りをいつか読もうと思って残している。
- 単純に買うだけ買って読んでいない。
- 内容が今後必要になると思って、残しておきたい。
などです。
たとえ、本棚を拡張したところで、空間としての物理的限界は来るわけで、
これによって、インプットが途絶えるというのは、知識欲の危機であると気づきました。
というわけで、必要な箇所だけメモをとったり、必要であればページをキャプチャして、
本自体は処分するという作業を、積極的に進めています。
Windows8対応PCを見にヨドバシカメラに行ってきました
Windows8アプリを作ってみたいと思いましたが、
それ以前にWindows8もタッチパネル対応PCも持っていないので、
かかる費用の確認を含め、ヨドバシカメラに行ってきました。
まず、自分の希望としては、
借りている部屋のスペースも考えて、小さめのラップトップPCで、
さらに、タッチパネル対応のもの、
贅沢を言えばUltrabookで、加速度検知などのセンサーがついたものでした。
本題の、実際に見てきた所感ですが、
Windows8といえば、タッチパネルによる操作をメインに据えたインタフェイスで知られていますが、
タッチパネル対応しているラップトップPCは、
店頭に並んでいるWindows8インストールされているものの半分程度でした。
ちなみに、デスクトップPCも見ましたが、
Windows7の頃からタッチ操作に対応しているタイプが、対応している程度でした。
また、タッチパネル対応のWindows8ラップトップPCの価格帯ですが、
安いものでも10万強といったところでした。
総括：
一般家庭にタッチパネルPCが普及するにはまだまだ時間がかかりそうですね。。。
また、Windows8アプリを作ったところで、
実際にタッチ操作や、その他センサーの機能を利用できるユーザーはごく少ないようです。
ゲームアプリケーションにおけるSQLiteを用いたデータ管理（１）
SHAMAN-Projectのデータ管理部分の対応として、SQLiteの導入を進めております。
これまで、アドベンチャーパートのメッセージデータが、ソース直書きでしたが、
これをSQLiteのデータベースから取得できるように変えました。
実際にどういったシステムが出来たのかというデモと、
プログラム的にどういった変更をおこなったのかという内部的な解説は、
次回のエントリで行いたいと思います。
今回のエントリでは、SQLiteに関する解説と、
ゲームアプリケーションのデータ管理に用いた際の利点について、掲載します。
SQLiteとは
データベースエンジンの一つです。
データベースエンジンは、一般にサーバーアプリケーションでよく用いられますが、
SQLiteは、組み込み用に実装サイズを抑えた設計がされたものです。
管理構造としては、
“データベース”が複数の“テーブル”を管理して、
“テーブル”が複数のデータを管理します。
そして、“データベース”単位で1つのデータファイルとなります。
ゲームアプリケーションへの応用
ゲームアプリケーションにとって、多くの項目を実装する必要がある中で、
昨今、グラフィック部分をUnityに、エフェクト制作を専用ツールを用いて、というように、
特定の要素をミドルウェアに任せる方法論が確立されつつあります。
そして、データ管理部分をSQLiteに任せるというのも、これと同じイメージになるかと思います。
ですので、一般に言われるようなミドルウェア導入に伴うメリット、デメリットも、
そのまま当てはまるかと思います。
具体的には、メリットとしては、データ管理部分を一からスクラッチする必要がない、などです。
デメリットとしては、バージョンアップに伴う仕様変更があった場合、
それに追従するためにソースを変更する必要がある、などです。
その他、SQLiteは多数の言語のバインディングに対応しておりますので、
ゲームアプリケーションのクロスプラットフォーム化にも対応可能です。
具体的には、ゲームアプリケーションの言語、OSが変わったとしても、
SQLiteのカバー出来る範囲であれば、同じデータを使い回せます。
また、メリットのひとつとして、データを動的に変更できることが挙げられます。
具体的には、メッセージのような静的なデータ以外にも、
現在所持しているアイテムのリスト、といった
ゲームの進行に合わせて変更が必要なデータにも対応することが出来ます。
さらに、別のメリットとして、ソートや特定データの抽出など、
データベース特有の機能を使えることが挙げられます。
例えば、現在所持しているアイテムのリストをSQLiteでデータ管理し、
ソートの機能を使えば、リストの整列を簡単に実現することが出来るでしょう。
その他、全ての商品アイテムをSQLiteでデータ管理し、
販売ショップカラムに特定のショップ名がついているものを抽出すれば、
あるショップの商品ラインナップを簡単に取得することが出来るでしょう。
