回答:
理論的には無限の量のデータに単一のフラットファイルを使用しないことをお勧めします。
理論的に無限の量のデータがある場合は、ランダムアクセス、つまり複数のファイルまたはデータベース、またはファイルシステムまたはデータベースによって既に解決されているインデックスの問題を解決する必要があるインデックス付きフラットファイル形式が必要です。
チャンクを複数のファイルに分散している場合、チャンクを（-110、5000）に取得するには、「％APPDATA％/ game / map / -110 / 5000.dat」（または、それらの圧縮を開始します）。データベースにはクエリが必要です。チャンクにデータがない場合は、何も格納できません。単一のフラットファイルは、ランダムアクセスの速度と利便性をすぐには提供しません。
任意のサイズの単一ファイルで、高速ランダムアクセスの場合、データのチャンクの位置を保証する必要があります。つまり、インデックスを使用する必要があります（データチャンクを介した生のバイナリ検索はパフォーマンスを低下させ、グリッドを作成するため） 「空白」のスポットを含むファイルは、Byte56の問題を引き起こします）。インデックスシステムを開発し、効率を上げてAPIを作成したら、ファイルシステムやデータベースなどを再作成できます。あなたが実際にそれから何かを得るのでなければ、それはおそらく投資する価値がありません。たとえば、SteamはGCF / NCFファイル形式から大きなメリットを得ています。
保存のセキュリティが必要な場合でも、それを行うことが可能です。たとえば、個々のチャンクを暗号化できます。それらが削除されるのを防ぐために、既存の保存されたデータに基づく中央のハッシュを持つことができます。保存されたデータがハッシュと一致しない場合（およびプログラムが変更を引き起こさなかった場合）、チャンクは削除されます。
最も頻繁に使用される解決策は、多くのファイルに分割することですが、あなたの質問は単一のファイルのみを意味しています。これに対する唯一の賢明なオプション（私の意見では）は、その単一のファイル内で非常に単純なファイルシステムをエミュレートすることです。実際、それほど難しくはありませんが、可能であれば、複数のファイルを使用することを検討してください。
1つのファイルに固執する必要がある場合は、ext2 fsから実装のインスピレーションを得られる可能性があります。http://en.wikipedia.org/wiki/Ext2ゲームにシンプルなFSを実装する必要があったときに、いくつかの良い決断を下すのに役立ちました。
しかし、実際には、拡大するマップについては、通常、「アクセスされた」チャンクごとにファイルを使用する方が適切です。
無限の世界をいじっていたときに、ゲームにチャンキングシステムを実装しました（それらを保持するかどうかはわかりません）。単一のファイルで使用するために、最初にチャンクのワールド位置を使用して、ファイルへのバイトオフセットを計算しました。これは、静的なチャンクサイズ、または少なくとも静的な最大値を想定しています。ただし、ユーザーがしばらく一方向に向かう場合、まだ生成されていない土地の広い領域があり、ファイルに空白スペースがあったため、このファイルはそのサイズに対してかなりまばらになります。
2つのファイルシステムも試しました。1つのファイルは、「チャンク位置」と「チャンクファイルオフセット」のペアのマップを保持します。2番目はすべてのチャンクを保持します。新しいチャンクが生成されると、それは単にチャンクファイルの最後に置かれ、そのオフセットは位置->オフセットファイルに保存されます。これは、大量のチャンクがあり、position-> offsetファイルでオフセットを見つけるのに少し時間がかかった場合の問題でした。実行可能であることがわかった場合は、位置->オフセットデータをロード時にハッシュマップにロードして、すばやくアクセスできます。
ここでは2番目のオプションを使用していますが、パフォーマンスが不足していることが判明した場合は、別のオプションに切り替える可能性があります。この情報があれば、自分に合ったものを作成できるでしょう。幸運を！