ギリギリゲームエンジンを考える

夢はでっかく"21世紀のDOOM"ということで、究極ポータブルな3Dゲーム構成法を考えている。つまり、ゲーム1本を可能な限り多くのゲームエンジンに移植できればギャグとして面白いはず論。
というわけで、Irrilichtのような軽量エンジンからUnrealやCryEngineのような完全なソリューションまで調査して、それらで共通する機能だけを抽出したギリギリゲームエンジンを設計する。

面白さ

エンジン間でポータブルなゲームを作ることは、エンジンのもつ様々なレンダリングテクニックを一つのゲームで比較して並べられることに有る。よって、ギリギリエンジンでもマテリアルやパーティクル、エフェクトの抽象化は必須と言える。
逆に、AI(経路選択など)は抽象化を行わず、全てスクリプトで実現する。これは、AIへの入力の一部となるステージデータを抽象化することがどうしても難しいのと、そもそもAIのロジックが異なると別のゲームになってしまうという問題が有る。
要するに、これは一つのゲームをゲームエンジンの機能をフル活用して移植しようという性質のものではなくて、あくまで、同じゲームを別々のレンダリングエンジン/レンダリングハードウェアで実現したときの違いに着目している。

機能の取捨選択

もちろん、個々のゲームエンジンにはユニークな機能もかなり存在するので、抽象化対象とする機能はどうしてもゲームを実現するのに必要な最低限のものになる。

COLLADA 1.4.x アニメーションをアセットフォーマットとして使用する

殆どのゲームエンジンはアセットパイプラインとしてCOLLADAのインポートをサポートしている。
汎用のメッシュ表示 / アニメーションシステムはエンジンによっては存在しない。このため、生成的なメッシュを使用できないことになり、ゲームの表現力をかなり制約する。
また、エンジンを超えて共用できるラージメッシュフォーマットは無いため、エンジン付属の"ワールドエディタ"の類は役に立たない。このため、ゲームフィールドも通常のオブジェクトとして描画する必要がある。これもゲームデザインに対する影響が大きい。

オーディオは扱わない

ゲームエンジンのオーディオを抽象化するのは単純に困難なのでこのポイントは諦める。別立てでオーディオエンジンの抽象化を検討することにする。
多くのゲームエンジンはfmodとかWwiseのような外部のミドルウェアとの連携を最初から想定している。

ゲーム本体はスクリプトで記述する

単純なC/C++記述では、Unityのような.netプラットフォームに対して使い回しが効かないという問題が有るため、今回の企画のために新たにインタプリタを設計している。(将来nmoshにすることも視野には入れている)
モーションの管理や敵キャラクタのAIのような純粋なゲームロジックから、視錐台カリングのような演算までをコレで記述する。

実現される"仮想ゲーム機"

こうして個々のゲームエンジンの共通部分を抽象化すると、架空のゲーム機スペックを想定しているような状態になる。つまり、ギリギリゲームエンジンはスプライトベースのゲーム機のスプライトがCOLLADAモデルに置き換わったものといえる。
コアになる機能は非常に単純明快で:

カメラの設定 - 位置、角度、レンダリング先テクスチャ/画面
3Dモデルの表示 - 位置、角度、アニメーションフレーム、テクスチャ、マテリアル
HUD(2D面)の表示

の3種類しかない。ただ、これらのAPIの詳細を決めるのがなかなか難しい。今回は、一番機能制約の大きいIrrlichtでゲーム全体を作ってから他所に移植する形で共通APIを準備していくことにした。

次の一手

nmosh用の行列演算パッケージの作成 ...は多分一瞬で終わると思うのでどうでも良いとして、モデラとアニメーションエディタを制作する。率直に言って一番自作してはいけないプログラムの一つ(次点はゲームエンジン)だが、いずれにせよステージエディタを作る必要が有るため、ある程度のモデラはどこかの時点で作ることになる。。
今回の企画のために専用品が必要なのは、スケーラブルなモデルの量産が求められているため。ゲームエンジン組み込みのマテリアルをフル活用することが目的なので、in-gameエディタであることが必要条件であり、ゲームエンジン毎に最適化したメッシュ/テクスチャを作るためには手作業ではどうしようもない。