回答:
eビジネスに同意します。サイズと編集方法によって異なります。
合理的にコンパクトな表現でマップのバイトサイズを見積もります。また、ゲームのプレイ中にマップのどの部分を変更できるかを決定します。変更されないパーツをロードして、保存する必要はありません。推定サイズが小さい場合は、すべてをメモリに格納します。データが必要以上に大きい場合を除いて、マップの一部をロードし、ロードしたものかどうかを追跡するという複雑さはそれほど価値がありません。
たとえば、Civilization IIを作成している場合、マップサイズは100x100タイルになる可能性があります。
Civ IIマップ+オブジェクトのコンパクトなバイナリ表現では30k未満なので、非常に大きい冗長形式を使用する場合でも、すべてをメモリに格納できます。上記の数値は、Civ IIマップ構造をリバースエンジニアリングした人から入手したものです。
Daggerfallは、途方もなく大きいマップを持っていると一部では考えられていますが、5000x2500で約25メガバイトのようですが、NPCも多数あります（750,000は私が読んだものですが、非常に高いようです）。今日のデスクトップ/ラップトップマシンではこれもメモリに収まる可能性がありますが、モバイルデバイスやブラウザでは少し大きすぎる可能性があります。ダガーフォールマップ形式を説明するwikiがあります。
冗長性を識別して除外することにより、サイズを削減できます。たとえば、100,000の同一のツリーまたは剣をそれぞれXML形式で保存する代わりに、1つのツリーと1つの剣、およびそれらへの100,000の参照を保存します。バイナリ形式では、その参照は1バイトまたは2バイトにすぎない場合があり、より詳細な形式では、参照は依然としてかなり小さい場合があります。
ゲームで機能する最も単純なことを行います。マップが小さい場合は、コンパクト形式と詳細形式のどちらを使用してもかまいません。コンパクトフォーマットがメモリに収まるが詳細なフォーマットは収まらない場合、バイナリフォーマットの追加作業がマップの一部のロードの追加作業より多いか少ないかを決定する必要があります。それはゲームに依存します。ターンをシミュレートするためにすべてのデータが必要なCivのようなゲームでは、バイナリ形式がおそらくより良い選択です。プレイヤーの近くにあるものを除いて領域をロードする必要がないダガーフォールのようなゲームでは、マップの一部をロードする方が適切です。地図がそうなら コンパクトフォーマットでもメモリに収まらない場合は、まず、それを処理するための追加の作業が本当に価値があるかどうかを自問し、そうである場合は、部分的にロードできるバイナリフォーマットを設計してください。
私の現在の（趣味）プロジェクトでは、マップとその上のすべてのオブジェクトは50 MBに収まるので、すべてをメモリに保持することで問題ありません。ただし、ブラウザーで実行したいのですが、50 MBはネットワーク経由で転送するよりも大きいので、サーバー上のすべてのメモリにそれらを保持し、クライアントの世界の一部のみをロードします。私のマップタイルは、タイルごとに1バイト、2048x2048タイル（4 MB）です。オブジェクト（木、椅子、オークなど）は、簡単にするためにJSONエンコードされています。クライアントでは、プレーヤーの近くにあるマップ領域（オブジェクトを含む）のみをロードします。
ロードする量は、少なくともマップの大きさに依存します。データがメモリに適切に収まる場合は、プログレッシブロードを行う必要はありません。
XMLが行う最も注目すべきことは、追加のストレージ/メモリ/ネットワークスペース/トラフィックを大量に消費することです。XMLの使用が楽しいと思う場合は、比較的少量のデータに対してのみ行ってください。
データ形式を設計するときは、このデータをどのように編集するかを念頭に置く必要があります。単純なテキストエディターを使用してデータをプレーンテキストファイルとして書き込むことも、これらのファイルを直接使用することも、バイナリ形式に変換してスペースを節約することもできます。画像エディタを使用してレベルをビットマップとして作成することもできますが、ここでも小さなファイルに変換することをお勧めします。
または、独自のエディターを作成することもできます。その場合、コンパクトなバイナリ形式を使用しない理由はほとんどありません。
これらの質問に対する答えはありません。これらはすべて本質的にあなた次第です。
好きなようにマップを保存して、いつでも表示/レンダリングできます。