私はウェブ用のゲームを開発しています。このゲームのマップは最小で 2000km × 2000km になります。あるレベルの粒度で標高と地形タイプをエンコードできるようにしたいと考えています。たとえば、100m X 100m です。
2000km x 2000km のマップの場合、この情報を 100m 2のバケットに格納すると、20000 x 20000 要素、つまりデータベース内の合計 4 億レコードになります。
この種の情報を保存する他の方法はありますか?
詳しくは
マップ自体が完全に表示されることはありません。ユニットはターン制でマップ上を移動し、プレイヤーはユニットの位置や地域の様子についてフィードバックを受けます。地形によって、速度と移動の禁止が決まります。
マップはゲームに使用され、必ずしもグラフィックや表示の目的で使用されるわけではないと言いたいのだと思います。
地形をどのように生成するかによって異なります。たとえば、手続き的にすべてを生成し (2 つの「ビットマップ」として保存された低解像度の地形/高さマップの補間を使用し、xy 座標からシードされたランダムな補間を使用して地形が変形しないようにする)、最小限のストレージを使用することができます。 . 完全に定義された地形の領域が必要な場合は、これらを個別に保存し、適切な場所で使用して、残りをランダムに生成できます)。
完全に定義された地形が必要な場合は、現在関心のある地形のみをプルするために、ある種の圧縮/ストリーミング技術を検討する必要があります.
地形の種類と標高を分けて、別の方法で扱います。
地形タイプは、標高ほど急速には変化しないと思います。おそらく、最低レベルの粒度よりもはるかに長く伸びる同じタイプの地形のセクターがあるでしょう。パフォーマンス、メモリ、その他の要件に応じて、これらのセクターをデータベース レコードまたはある種のハッシュ テーブルにマップします。
標高はほとんどの部分で徐々に変化するため、半連続であると思います。値を一連の連続関数にマップしようとします (標高の突然の変化のように、連続していない部分間の異なるセット)。地形が同じ標高であるか、単純な関数で記述できる座標のセットについては、関数がカバーする範囲を定義するだけで済みます。これにより、地形の各ポイントの標高を記述するために記録する必要がある情報の量が大幅に削減されます。
したがって、基本的には、マップを (x,y) 範囲で構成されるさまざまなセクターに分割します。1 つは地形タイプ用、もう 1 つは地形標高用であり、必要に応じて適切な値を返すことができるそれぞれのハッシュ テーブルを作成します。
通常の解決策は、ドメインを扱いやすいサイズの「タイル」に分割することだと思います。適切なタイルをいつでも読み込むには、少しロジックを追加する必要がありますが、それほど悪くはありません。
一度にすべての情報にアクセスする必要はありません。たとえ 100 平方メートルのバケツが画面上の 1 ピクセルを占めていたとしても、20k x 20k ピクセルを一度に表示できる画面はありません。
また、データベースを使用しません-高さマッピングを調べます-ピクセル値が高さを表す白黒画像を効果的に使用します。
幸運を！
どう見ても情報量がすごい。400,000,000 のグリッド セルが犠牲になります。
これを回避するには2つの方法があります。まず、これは Web ベースのゲームであるため、適切なサイズの HDD を備えたサーバーを入手して、通常どおり 400M のレコードをそこに保存できる可能性があります。または、効率化のために何らかの独自のストレージ メカニズムを作成する可能性が高くなります。次に、データに効率的にアクセスする方法を考案するだけで済みます。これは、一度にすべてを使用する必要があるとは思えないという事実を考慮して行うことができます。;)
もう1つの方法は、ある種の圧縮です。ただし、これには注意が必要です。すぐに使える圧縮アルゴリズムのほとんどでは、ストリーム内の任意の場所を解凍することはできません。地形データには、使用できるパターンが含まれているのではないでしょうか? 完全にランダムになるとは思えません。おそらく、同じデータで広い領域を予測します。おそらくそれらはそのようにエンコードできますか？
探している種類の粒度が必要な場合、それを行う明白な方法はありません。
2 次元ウェーブレット変換を試すこともできますが、それはかなり複雑です。フーリエ変換のようなものは、非常にうまく機能します。さらに、おそらく、土地ごとに 1 つのレコードという方法で地形を保存しようとは思わないでしょう。エンコードされた行列を格納できる何らかのデータベース フィールドを持つ方が理にかなっています。