時には、グラフィックスやサウンドファイルなどを使用するのではなく、人々がそれを推奨するのを見るでしょう。このような...
// Game code
Image myImage = new Image("path/to/image.png");
... 代わりにマニフェストファイルを間接参照のレベルとして使用する必要があります。
// Manifest file
MY_IMAGE: path/to/image.png
// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");
このようなアプローチを取る理由は何ですか？コンパイルされた言語を使用していない場合でも、これを行う理由はありますか？
回答:
ほとんどの場合、マニフェストファイルは、なんらかのアーカイブファイル形式に関連付けられています。たとえば、JavaのJARファイルは、zipファイル内のアセットとそれらの場所をリストするマニフェストファイルを持つ単なるzipファイルです。その場合、「path / to / image.png」は実際のファイルシステムパスではなく、圧縮アーカイブ内でオブジェクトを見つける方法に関する情報です。圧縮のディスクスペースの利点に加えて、ファイルアーカイブを使用するとパフォーマンスが向上します。これは、ウィンドウが少数のディレクトリ内の数万の個別ファイルを処理するのが非常に困難なためです。
この種のマニフェストファイルを使用することで、特定のデータチャンクの送信元を完全に抽象化できます。多分あなたのファイルはDVDにあるか、インターネットからストリーミングされるか、またはzipファイルの中にあります。これらのケースに対処するために追加のコードを記述する必要がありますが、マニフェストファイルを使用することで、ゲームロジックは何かがどこから読み込まれるかをまったく気にする必要がありません。
ここで、コンパイルされていない言語を使用している場合、このマニフェストファイルはC＃ソースファイルになる可能性がありますが、レジストリ設定などに基づいて、クライアントの実行時に使用しているマニフェストファイルを簡単に変更できると便利です。たとえば、実行中にハードドライブ上のキャッシュが存在するかどうか、またはDVDのみが利用可能かどうかを確認できます。次に、使用可能なセットアップに応じて、使用するマニフェストを切り替えることができます。
1つの理由：データ駆動型プログラミング。
コードは、「LightWood」テクスチャが必要であることだけを知り、リソースマネージャーがこのキーを使用してファイルへの正しいパスを見つけられるようにする必要がある場合があります。さらに、スクリプトでは、ファイルパスを覚えておく必要はありません。それらは乱雑で、正しくない場合があります。マニフェストにファイルの場所を調べさせ、ファイル名ではなく、その名前で必要な資料を人間に見つけさせます。
<material name="wood">
<diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
<normals>environment.zip/wood_normals.jpg</normals>
<shader>environment.zip/wood.fx</shader>
<specular color="1,1,1,1" power="0.5" flat="yes" />
</material>
一般的なデザインパターンとして、マニフェストは、さまざまなオブジェクトのセットに関するすべての情報を1つの場所に収集する場合に役立ちます。元の参照を再コンパイル/更新せずに物事を移動できるようにするために、アーカイブ/パックされたファイルについて、または間接についてである必要はありません。実際、後者は解決するよりも多くの問題を引き起こす可能性があるので、特定のニーズを解決した場合にのみそれを実行します。
マニフェストの大きな利点は、1つのコンパクトな場所で大量のデータのインデックスとして機能することです。そのため、特に複数のオブジェクトを反復処理する必要がある場合に、マニフェスト全体をディスクからロードしてメモリに保持できるため、パフォーマンスが向上しますが、それらのオブジェクトが何であるかが事前にわかりません。オブジェクトがディスク上にある場合、特にオブジェクトが複数の場所にある場合は、ファイルを反復処理するたびにファイルシステムを操作する必要があります。ディスクベースのファイルシステムの場合、ファイルシステムにアクセスするために必要な時間は法外なため、ディレクトリ内のファイルを反復処理することは莫大なコストになります。ビルド時にファイルのマニフェストを事前にビルドすることにより（注：コンパイル時ではありません）、そのコストをメモリ使用量と交換します。
アーカイブの目次は本質的にマニフェストそのものなので、アーカイブファイルではマニフェストを使用する必要があるため、動作は無料です。また、1つの場所でアセットのマニフェストを使用する必要がある場合は、すべてのアセットがマニフェストを通じて参照されるように主張する方が簡単です。コード内のアセットへの参照からアセットの実際の保存場所/メカニズムを抽象化することができます。これにより、コードに単一のアセット参照タイプを含めることができ、ファイルパス、アーカイブファイルパス+オフセット、またはサブアセットを区別する必要がなくなります。
マニフェストファイルは、リソース名とその場所の間の間接層を提供します。多くの場合、間接参照の余分な層は、設計が過剰であることを示しています。ただし、その余分なレイヤーが、エレガントで効率的なソリューションを構築するために必要なものだけの場合もあります。
リソース名/場所の分離が私を助けた簡単な具体的な例を次に示します。開発中、私のアートアセットはソースコードでリビジョン管理されています。これは非常に便利で、すばやく繰り返すことができます。通常、リソース名はその場所を反映しています。開発マニフェストは非常に単純です。
アセットが散らばってゲームを配布したくありません。配布する準備ができたら、アセットをリソースファイルに簡単に圧縮して、新しいマニフェストを作成できます。
また、テクスチャアトラスは、グラフィックシステムのパフォーマンスをもう少し引き出すための優れた方法です。アトラスは高速ですが、アートがまだ開発中である間、アトラスは扱いにくいものです。私の解決策は、ゲームを最適化しているときにのみアトラスを作成することです。私はマニフェストを使用しているので、アトラスの場所を指すようにマニフェストを更新するだけで、ゲームはストレートファイルではなくアトラスを使用するようになります。