GFXエンジンの設計 (下調べ編)

teslawire

グラフィックスエンジンの設計はさらに難しい。企画上の特殊な要求もいくつか有るが、そもそもゲームエンジンにはなかなか共通点が存在しないというごく当然な問題に直面している。

調査(予定)エンジン

とりあえずゼロ円かつ個人契約で実際のコードを書くところまで行けることが基本。予算の都合でゲームエンジンはあまり購入できない。今回スクリプトエンジンの非C系API対応を見送った関係でUnity等非ネイティブエンジンを外している。
これらのエンジン全てについて開発することは(スケジュールの都合で)予定していない。多分Irrlichtと何か1つFOSS/商用、自前GLESの計3エンジンの実装となる。

IrrlichtはFOSSのゲームエンジンで、非常に簡潔なコードでとりあえず絵が出るのが最大の特徴。著名な採用にはOctodad( http://octodadgame.com/ )が有る。
teslawireではデザイン基準にこのエンジンを選んでいる(このエンジンにはソフトウェアレンダリングを行うBurnings Videoバックエンドが有るため)。

OSGはFOSSのグラフィックスエンジンで、ゲームを構成するためにはDelta3D( http://delta3d.org/ )のような追加のライブラリが期待される。
良く構成されたAPIとスケーラビリティをウリにしており、マルチGPUサポートやOpenGL ESレンダリングなどの興味深い機能もある。

OGREはFOSSのグラフィックスエンジンで、独自のシェーダ/パーティクルスクリプト等を持つ。FOSSなエンジンの中では比較的完成度が高く、DirectX/OpenGL両対応でNaCl等への移植も進んでいる。NeoAxisは.netバインディングとゲーム向けの数多くの拡張を提供し、エディタも持つ。NeoAxisは無料版も有るがソースコードはライセンスの購入が必要。
同人ゲームのほむらコンバットがこのエンジンで書かれている( http://www.neoaxis.com/showcase/products/homura_combat )。

Cryengineは非商用利用のために無料のSDKを提供している。開発ホストにDX10以降が必須。
ゲームエンジンとしては珍しくCOLLADAをワークフローの中核に置いている(他にはSCEのPhyreEngineが有る)。Sandboxと呼ばれるゲームエディタはカットシーンの編集など多くの高度機能を集約している。

UnrealEngineはUDKと呼ばれるUnrealScriptベースの開発環境を提供している。UDKはUE3ベース。
ライセンスのサブスクリプションによりUE4をそのまま使用できる。が、サブスクリプションなので止めどきが難しい。。

Valveはmodコミュニティ向けSDKをGitHub経由で公開している。率直に言って、このSourceのSDKはmod以外の目的には適切でない。(トータルコンバーションmodとしてゲームを作ることになる。)
本来のSource SDKはHavokベースの物理エンジンやMilesオーディオの統合を含んでいる。こちらの金額等はNDA。

千鳥はプロプライエタリなエンジンだが、個人でもSDKを請求することができる。(まだ未請求)
珍しい国産エンジン。他にはヘキサエンジン(と、それを元にしたOROCHI)くらいしか無い。

グラフィックスエンジンの機能

今回はゲームエンジンに備わっている機能のごく一部しか使用しない。例えば、多くの商用エンジンはマルチプレイヤやAI、アニメーションのための良い考察を持っているが、teslawireでは企画上必要としていない。
(ゲームエンジン一般の構造についてはGame Engine Architectureのような良い書籍がある: http://www.gameenginebook.com/ teslawireは特殊なプロジェクトなので通常のエンジン考察を採らない部分が多く、そういう意味では一般的なゲームエンジンの捉えかたからはかなりズレている。)

  • シーングラフ

(3D)ゲームエンジンを名乗るライブラリはほぼ例外無くシーングラフ機能を持っている。シーングラフは、描画可能なオブジェクトやレンダリングパラメタを格納したカメラ等ノードの木構造で構成され、これに対するオブジェクトの加除がゲームエンジンに対する基本的なAPIとなる。また、シーングラフに追加できるノードの機能がゲームエンジンの機能そのものとなる。多くのエンジンでは、C++のオブジェクト指向的側面を使用して、ノードをユーザコードで拡張できるようにデザインしている。
木構造を採用することで、ゲームオブジェクトを"相対的"に配置するチャンスが有る(ある親ノードを移動すると、子となっているノードも同時に移動する等)。

  • エフェクト(FX)、マテリアル

エフェクトはさまざまな内容に用いられるが、平たくいえば 1) 抽象化されたシェーダ 2) パーティクルなど量的なゲームオブジェクト を扱うシステムであることが多い。これらはゲームによるカスタマイズ要求が高い割には高速に動作する必要もあるため、専用の言語(OGRE)やXML表現(ColladaFX、OSG)、専用のエディタ(多くの商用エンジン/ミドルウェア)を提供している。これらの処理系は、ターゲットAPIのためのシェーダ(HLSL、GLSL)やネイティブコードのためのC++を生成する。
エフェクトのエンジン間交換には基本的に良い考察が無い。nVidiaのCgFXは業界的に良く用いられたが、現状はサポートされていない。
teslawireではこの部分は共通化を諦め、エンジン毎に固有の実装を持つことにしている。ゲーム性に関わる重要な問題としては影の生成がある。影の生成は多くのエンジンでサポートされてはいるが、その生成される影がゲーム表現として期待されるものかどうかは難しい問題となる。

  • 描画ステートの管理

描画ステートの管理は重要な問題だが、グラフィックスエンジンごとの考察はまちまちなものになっている。
特に重要なのは半透明オブジェクトの描画で、これをサポートするために必要な方法がエンジン毎にかなり異なる。例えば、OSGでは描画ステージが"render bin"として抽象化されていて、半透明部分を含むオブジェクトはそれをサポートしたrender binに所属させないと正しく描画されない。
半透明オブジェクトが問題になるのは、GPUに対する描画順の問題が有るため。GPUは既に描画されたオブジェクトよりも奥に書かれたオブジェクトの描画は自動的に無視させることができる(Z test)が、半透明オブジェクトの向う側にあるオブジェクトはこの省略を適用できない。
この部分の共通化はなかなか良い考察がない。