アセットパイプライン
ゲームコンストラクション環境ではアセットパイプラインが非常に重要視される。アセットパイプラインとは「システム外で作成されたものを、システムのアセットにするための流れ」のようなもので、
など色んなやり方がある。このアセットをアプリケーションの中で使う方法も様々で、命名規則から使用するアセットを自動決定するもの、ハードコードで指定するものから、間に一枚かます方法までえっとある。アセット管理用サーバーやアセットパイプラインミドルウェアやロードランタイムが商品として売っとって、商売になっとるくらいじゃけん。
ゲーム開発環境でアセットパイプラインが重視される理由に、
- アセットの数が膨大なので、管理者を介在させてコントロールする方式が採用できん
- データの追加、更新、変更に対して、エンジニアがいちいち動きよったら仕事にならん
- そもそも、エンジニアがおらんでも、デザイナ（環境のエンドユーザー）レベルでゲームを変更してテストプレーできる環境を目指しとる
などが挙げられると思うが、どこの業界も似たようなもんじゃろう。XOOPS Cube コア v1.0 では主に最後の理由で、アセットパイプラインとアセットの利用メカニクスを導入しようと考えとって、テーマとテンプレートに関しては概ね完成した。こういったパイプラインはエンジニア主体の開発からみるとお袈裟な仕組みに見えるかもしれん。けど、わしは、ウェブの世界も（だいたいの世界は）例外なくデザイナー&プランナー主体の開発に移っていくと思うし、そもそも XOOPS はそういうシステムじゃけー、アセット体系の強化は必須じゃと思っとる。
XOOPS のアセット周りは、テンプレートを例題にとるんが分かりやすい。内部のモジュールは、ソースアセット（データ資源）じゃのうて、アセット自体*1を取得して使用することになる。
例えば、自分が描画に利用するアセットをキーを使って請求する。他の連携するシステムがそのキーに応じたアセット（テンプレートオブジェクト）を返す。このソースアセットがデータベースなのか、ファイルなのかは、インポータを変更することでユーザレベルでの変更が可能になる。また、あるキーに対してどのアセットを使用するかという応対もユーザーレベルでコントロールできなくてはいけない。このあたりをある規則に基づいて決定することで、開発を迅速に行うフレームワークがあるとすれば、設計コンセプト的に真っ向からぶつかる。ただしそのようなパイプラインは現在ゲーム開発においては事実上絶滅した。メリットも多かったけど、最終的にはアセットパイプラインをちゃんと作るという方向へ来たということじゃと思う。*2
前述のゲーム環境では、ゾンビのインスタンスをコピーして、メッシュのアセットをロボットに変更するということが、マウスだけで簡単にできる。そういった操作を積み重ねて別物になったインスタンスをエクスポートして、プレハブとして他のユーザー渡すことも簡単。カスタマイズとクリエイトの区別がないと言っていいかもしれません。
XOOPS では長らくインポート後のアセットの直接改編と、オーバーライドという例外処理で、ユーザーレベルのクリエーション*3ができるようにしとった。じゃけど、ファイル資源とデータベース資源の抽象化は、パイプラインと一体化したレンダリング用サブシステム委ねられとった。そのへんがユーザーと、複雑なメカニクスを了承しなければならない開発者の妥協点だったんかなぁと思う。
コアやベースに近いシステムがアセット制御のコンセプトとランタイムコードを提供することで、開発者の負荷を最小限に抑えながら、ゲームコンストラクションツール水準に達する程度のアセット周りの機能を提供できんかのうと思っとります。
