8

主に、これはゲームで使用される手法のようで、すべてのサウンドを 1 つのファイルに、テクスチャを別のファイルに格納します。これらのファイルは一般的に GB サイズに達します。

小さなファイルとしてサブディレクトリにすべてを維持することよりも、これを行う理由は何ですか?多くの小さなゲームがこれを使用し、モノリシックシステムが大企業に好まれていますか?

小さなファイルがたくさんあるファイル システムのオーバーヘッドはありますか? 彼らは自分たちの財産を守ろうとしていますか? ほとんどは新しい拡張子を持つ圧縮ファイルのように見えますが?

4

5 に答える 5

7

私が働いている場所（ゲーム開発会社）で、このような「アーカイブ」システムを使用する理由は次のとおりです。

  • 検索速度: ディレクトリ内のファイルを反復処理する必要はほとんどありません。名前で直接検索することの方がはるかに多いのです。本質的に単なる一連のカスタム「ファイル割り当てテーブル」を使用することで、ファイルを非常に迅速にhash( normalized_filename ) -> [ offset, size ]検索できます。このインデックスを RAM に保持して、他のインデックス テーブルなどとインターリーブすることもできます。
  • (繰り返しが必要な場合は、 内のすべてのファイルを簡単に繰り返し処理するか.arc、ファイル名のリスト、ファイル名のハッシュのリスト、または [ オフセット, サイズ ] ペアのリストをどこかに保存できます - - おそらくアーカイブ内のファイルとして. これは通常、FS でのディレクトリトラバーサルよりも高速です.)
  • metadata : 必要なファイル メタデータを簡単に挿入できます。たとえば、「サイズ」フィールドの 1 ビットは、ファイルが圧縮されているかどうかを示します (圧縮されている場合は、圧縮解除方法に関する詳細を含むヘッダーがあります)。事前にファイルの構造を十分に把握していれば、ファイルの断片ごとに圧縮を変えることもできます (スプライト アーカイブに対してはこれを行います)。
  • size : 私たちが使用するデバイスの 1 つには、「ファイル サイズは X の倍数でなければならない」という要件があります。ここで、X は一部のファイルに比べて大きくなります。たとえば、一部の lua スクリプトは、コンパイル時にわずか数百バイトになります。.luc ファイルごとに余分なオーバーヘッドがかかると、すぐに加算されます。
  • アライメント: 一方、スペースを無駄にしたい場合もあります。ファイルシステムからのより高速なストリーミング (バックグラウンド DMA など) を利用するために、一部のファイルは特定の配置/サイズ要件に従う必要があります。ツールでそれを正しく処理できます。また、対象となる位置合わせ/サイズは、基礎となる FS と必ずしも一致する必要はなく、必要な場所にのみスペースを無駄にすることができます。

しかし、それらはありふれた理由です。もっと楽しいもの：

それぞれ.arcがリストに登録し、弧を見て知っているファイルを開こうとします。最初に RAM 内にあるアーカイブを検索し、次にデバイス FS 上のアーカイブを検索し、次に実際のデバイス FS を検索します。これにより、柔軟性が大幅に向上します。

  • ファイルシステムへの動的な追加: いつでも新しいファイルまたはアーカイブを問題のマシンに (ネットワークなどを介して) ストリーミングし、「論理」ファイルシステムの一部として表示させることができます。これは、実際の FS が ROM または CD に存在する場合に優れており、他の方法よりもはるかに迅速に反復処理を行うことができます。
  • (Doom の.wadシステムは上記の一種の例であり、モッダーはゲームに組み込まれたアセットやスクリプトをより簡単にオーバーライドできます。)
  • 基礎となる fs がない可能性bin2obj: リンク時にアーク全体を実行可能ファイル ( ) に直接埋め込むために使用でき.rodataます。この時点で、デバイス FS を見る必要はありません -- 特定の小規模なデモ ビルドに対してこれを行います。など。この方法で、ネットワークまたは savegame-sneakernet を介してレベルを送信することもできます。=)
  • 編成とロード/アンロード: ファイルシステムの仮想「断片」をいつでもロード、アンロード、オーバーライドできるため、FS 内のファイル数を常に非常に少なくすることで、いくつかのパフォーマンストリックを実行できます。さらに、アーカイブ全体をメモリ、インデックス テーブル、およびデータにロードするように指定できます。このファイル ロード コードは、ファイルが既にメモリ内にある場合、ポインターを移動する以外にファイルを読み取るために何もする必要がないことを認識できるほどスマートです。高レベルのコードの一部は、ファイルが RAM にあることを実際に検出し、構造体のように見えるおそらく構造体ポインターを直接要求することができます。
  • 移植性: 使用する新しいデバイスごとにいくつかのファイルを取得する方法を理解する必要があるだけで、残りの FS コードはほぼ同じです。=) ツールの出力を時折 (配置上の理由から) 少し変更しますが、ほとんどの処理は同じままです。
  • 重複排除: スプライト アーカイブなどのよりスマートなアーカイブを使用して、データの重複排除を行うことができます。「ジャンプ」アニメーションの 5 番目のフレームと「キック」の 3 番目のフレームが同じ場合、ファイルを分割して、そのフレームのコピーを 1 つだけ保存できます。ファイル全体に対して同じことができます。

最近、FS アクセスが非常に遅いシステムに PC ゲームを移植しました。データ形式は変更していませんが、ロー デバイス FS のディレクトリを反復処理して 100 個の小さな XML ファイルをロードすると、ロード時間が完全に無駄になることがわかりました。私たちが使用した解決策は、各ディレクトリを取得し、それを独自の に作成し、圧縮subdir.arcされたマスターに貼り付けることでした。game.arcdir が必要になったとき (opendir のようなものが呼び出されたとき)、subdir.arc 全体を RAM に解凍し、ファイルシステムに追加してから、超高速で反復しました。

このようなものを数時間でまとめることができ、システム間での移植の苦痛を軽減できることが、このようなものを価値のあるものにしています。

于 2010-05-22T22:27:48.607 に答える
1

ファイル システムにはオーバーヘッドがあります。通常、ファイルは 2 のべき乗 (4 KB など) に切り上げられたディスク領域を使用するため、小さなファイルが多数あると領域が無駄になります。一部の最新のファイル システムはそれを軽減しようとしていますが、まだ普及していません。さらに、複数のファイルにアクセスする場合、ファイル システムは非常に遅くなることがよくあります。たとえば、通常、100 KB のファイルを 4000 個コピーするよりも、400 MB のファイルを 1 個コピーする方がはるかに高速です。

ファイル システムは、ファイル サイズの変更を簡単な自家製のソリューションよりもはるかにうまく処理できるため、ファイルを変更する必要がある場合に便利です。ただし、一定のゲーム データの場合はそうではありません。

于 2010-05-22T20:26:45.733 に答える
0

Apple システムでは、最も一般的な方法は、お勧めのようにディレクトリを使用することです。それらはバンドルと呼ばれ、Finder では 1 つのファイルとして表されますが、さらに調べてみると、実際にはディレクトリです。これにより、このバンドルから個々のアイテムをロードする際のコードの記述とメモリの節約が非常に簡単になります。:-) また、これにより、巨大なデータベースの増分バックアップが簡単になります。たとえば、iPhoto データベースは単なるバンドルなので、変更されたファイルと新しいファイルをバックアップするだけです。

ただし、Windows では、これを行うのははるかに難しいと思います。「何があっても」ディレクトリのように見えます (賢い人は、Explorer に特定のディレクトリを単一のファイルとして表示させるソリューションを見つけたと確信していますが、それは一般的ではありません）。

ゲーム開発者の観点からは、非常に小さなファイルを扱っていないため、ディスク容量のオーバーヘッドが非常に懸念されているわけではないため、@ doublep の提案には疑問があります。ユーザーがゲーム全体をどこかにコピーする場合、単一のファイルを使用するとはるかに簡単になり、セット全体が正しいかどうかを簡単に確認できます。

そしてもちろん、アクセスできない人にとっては読みにくくなります。しかし、修正するのも難しくなります。つまり、パッチを当てるのも難しく、拡張機能を書くのも難しくなります。拡張機能をよく使う人は、ディレクトリ構造を好みます: The Sims.

私がゲーム開発者だったら、個別のファイルを使いたいと思っています。また、Mac 用に書いているように、バンドルを使用していました ;-)

乾杯

ニック

于 2010-05-22T20:32:18.810 に答える
0

複数の理由が考えられます。

doublep が示唆するように、ファイルはディスク上で必要以上のスペースを占有します。したがって、アーカイブはスペースを節約します。10,000 個のファイル (任意のサイズ) をアーカイブに圧縮すると、20MB 節約できます。今日では正確に大量のスペースではありませんが、それでも.

私が考えることができる他の理由は、ディスクの断片化です。断片化されたスペースで何千もの個別のファイルにアクセスすると、断片化が激しいディスクのパフォーマンスが低下するのではないかと思います。しかし、私はこの分野の専門家ではないので、経験豊富な誰かがこれを検証してくれれば幸いです.

最後に、これは別のゲーム ファイルへのアクセスを制限することとも関係があると思います。大量の Lua スクリプトを公開して、いじって何かを壊すことができます。または、アウトロのシネマティック/サウンド/テキスト/何でも公開して、それにアクセスすることで台無しになる可能性があります. マルチパス XOR キーを使用して画像を暗号化し、テキスト ファイルと構成変数をモノリシック ファイル (セキュリティ強化のために圧縮) にパックし、自由にアクセスできる音楽のみを残します。このようにして、ゲームの秘密はもう少しの間発見されないままになります:)。

または、私が考えたことのない別の理由があるかもしれません:D.

于 2010-05-22T21:10:44.613 に答える
0

ご存じのように、特に大企業のゲームは、できる限りパフォーマンスを絞り込もうとします。1 つの手法は、すべてのデータを 1 つの大きなファイルに格納し、それをメモリに DMA することです (CD から RAM への memcpy と考えてください)。すべてのファイルが 1 つの大きなファイルにまとめられているため、ディスク シークは発生せず、多数のファイル (大量のシークが発生する可能性があります) をすべてこの手法により迅速にロードできます。

于 2010-05-22T21:18:19.383 に答える