Noel Llopisの内からのゲームのブログは、最近「リモートゲーム編集」の投稿でこれについて触れています。冒頭の段落：
私は長い間、最小限のゲームランタイムのファンでした。オフラインまたは別のツールで実行できるものはすべて、ランタイムの外で実行する必要があります。これにより、ゲームのアーキテクチャとコードは非常に無駄のないシンプルなものになります。
（この記事は、100％同意してもしなくても、ほとんどのNoelのものと同様に、強くお勧めする記事です。）
ここでの鍵は、複雑さをエンジンの外に保つことだと思います。それでも柔軟性はありますが、コンテンツパイプラインでは柔軟性があります。また、データの変換や移動に時間を費やすことなく、パフォーマンスが向上します。
エンジン内の編集機能の一部が失われているにもかかわらず、パフォーマンスが向上すると、不思議なことに反復時間が短くなる可能性があります。1秒でゲームをロードできれば、何かを試すのが簡単です。
「UNIXの哲学」の原則の一部を採用すると、ツールチェーンを柔軟に保つのに役立ちます：小さなモジュラーパイプライン。
私の個人的な哲学：焼くことができ、オフラインな限りデータの多くとしてではなく、いつでも新しい焼かれたデータを受信するためにエンジンのサポートを提供しています。（この新しいデータは、「リフレッシュ」ボタンが押され、次のレベルが開始され、新しい領域に移行するなど、都合のよい時点までは、必ずしも必要ではありません。重要なのは、最小化するスイートスポットを見つけることです。コードの複雑さとコーディングの労力を最小限に抑えた反復時間）
弊社では、アーティスト/デザイナー向けのツールのほとんどは、UIの問題に焦点を合わせています。単一のアセットやそのバッチの操作のしやすさなどです。Photoshopや3DS Maxなどのサードパーティツールにすぎない場合もあります。これらのツールは、中間形式（多くの場合、ソースバイナリデータを参照するxmlですが、常にではない）にエクスポートします。中間フォーマットは、バックエンドの「データ作成」ツールによってピックアップされ、ターゲットプラットフォームにとって有用で迅速なロードを可能にします。
移植性は、追加のバックエンドデータ作成ツールを追加するか、既存のバックエンドデータ作成ツールを拡張することによって実現されます。これには、コンテンツ作成者から見えないという追加の利点があります。
これで、適切なインクリメンタルデータの作成により、ベイク形式の変更を数秒で行うことができます。エンジンがスパイダーできるか、ツールがスパイダーできると、リソースシステムに表示され、都合の良いときにリロードできるようになります。
ツール（特にバックエンドデータ作成ツール）は、エンジンコードよりもスロッピーでバグが多いことがよくあります。これは、リファクタリング/書き換え、拡張、およびテストが容易であるため、問題ありません。それらの動作の仕様があり、一部のエンジンコードと比較して、それらを単体テストするのはかなり簡単です。
あなたの質問に対する私の意見：
エンジンはさまざまな画像フォーマットをロードできますか？TGAのみのローダーは、コードを渡すのがかなり簡単です。
（脇に：エンジンでTGAデコーダーを使用する場合でも、ハンドコードしないでください。問題を求めているだけです。ほとんどの画像形式には多くの微妙な点があり、準拠していないツールがたくさんあります。おそらく十分に指定されていないフォーマットに正確に対応します。画像処理用の十分にテストされた既存のライブラリコードを見つけるのが最善です。
ここで、TGAから内部のテクスチャ形式であるメタデータに変換するツールを用意します。
オーディオ形式はどうですか？wavファイルのロードのみをサポートすることは可能ですか？巨大なことが多いアンビエント音楽ファイルはどうですか？
ここでは3つの形式を使用します。追跡された音楽（.xm）、ADPCM（.wav）、およびSpeex（.spx）です。これは主にハンドヘルドを使用しているためであり、これらの形式はデコードするのに非常に軽量です。
エンジンは、動的TTF解析とアトラス生成が可能である必要がありますか？テクスチャパッキング。
アトラスは難しい問題です。最近の質問の回答を参照してください。ほとんどの場合、オフラインで行う価値があります。
さらに、文字ごとのメタデータを、ロードコードがほぼゼロのベイク構造体にすることができます。
最後に、MODコミュニティのために、このパイプラインをクリーンアップしてゲームとパッケージ化できます。いつでもソース形式を追加できます。また、特定の場合にコンテンツ作成ツールとエンジンの間のギャップを埋めることを妨げるものは何もありません。うまくいけば、データベイキングコードとスパイダー/転送コードをライブラリにリファクタリングして、場合によってはコンテンツ作成ツールで直接使用できるようにすることができます。しかし、私は必ずしも最初の目標を設定しません。それは最終的な目標であることを認識し、それがデザインに少し影響を与えるようにします。
更新として、テクスチャにKTXファイル形式を使用することを検討してください。それは、structほとんどのGLユースケースでほとんど「読み書きできる」という利点があります（そして、コメントからはGLをターゲットにしているように聞こえます）一方で、柔軟性があり、明確に定義されています。
ターゲットによっては、完全に焼き付けられたデータのKTXヘッダーオーバーヘッドが少し高くなる場合があります。また、ユースケースによっては、エンディアンスワップのサポートを省略したい場合もありますが、設計上の考慮事項として、少なくとも価値があることは間違いありません。