x、y、z 座標ごとに 3x3 マトリックスのようなものを考えています。しかし、多くのブロック スペースが空であるため、これはメモリの無駄遣いになります。別の解決策は、ハッシュマップ ((x,y,z) -> BlockObject) を使用することですが、それもあまり効率的ではないようです。
効率的と言うとき、最適という意味ではありません。それは単に、現代のコンピューターでスムーズに実行するのに十分であることを意味します. Minecraft によって生成される世界は非常に巨大であることを覚えておいてください。とにかく効率が重要です。保存する必要があるメタデータも大量にあります。
私のコメントで述べたように、MineCraftがこれをどのように行うかはわかりませんが、この種のデータを表す一般的な効率的な方法はOctreeです。http://en.wikipedia.org/wiki/Octree。一般的な考え方は、それは二分木のようなものですが、3つのスペースにあるということです。各次元のスペースの各ブロックを再帰的に分割して、8つの小さなブロックを取得します。各ブロックには、小さなブロックへのポインターとその親ブロックへのポインターが含まれています。
これにより、同じマテリアルの大きなブロック（「空のスペース」など）を効率的に格納できます。これは、同じもので構成されているブロックに到達するたびに、再帰を終了できるためです。 tは、個々の「キューブ」ユニットのレベルまで再帰しました。
また、これは、現在のブロックを取得し、表示されるすべてのものを含むブロックに到達するのに十分な距離までツリーを上ることで、特定の領域内のすべてのキューブを効率的に見つけることができることを意味します-そうすれば、非常に簡単にできます他の場所にあるすべてのキューブを無視します。
Minecraft の世界 (チャンク) データを表現するための代替手段に関心がある場合は、ビット文字列のアイデアを調べることもできます。各「チャンク」はボリューム 16*16*128 で構成されますが、16*16 は 1 バイト文字で適切に表現でき、バイナリ文字列に統合できます。
このアプローチは、クライアントの計算と高度に最適化されたストレージおよび転送時間の取引という特定の目標に非常に固有であるため、すべての詳細を説明しようとするのは賢明ではないようですが、興味がある場合は、この目的のためだけに仕様を作成しました。 .
この方法を使用すると、ストレージ コストの計算は現在の 1 ブロックあたり 1 バイトとは大幅に異なりますが、代わりに「可変ビット レート」です: ((1 ブロックあたり 1 ビット、8 の倍数に切り上げ) * (数ブロックタイプがチャンクに現れる一意のレイヤー) + 2bytes)
これは、（そのチャンク内のブロックタイプの一意の数）に対して合計されます。
意図的なエッジケースでのみ、これは通常の構造化されたチャンクよりも高価になる可能性があります.私のテスト。
最善の策は、Minecraft を逆コンパイルしてソースを確認することです。 Modify Minecraft: The Source Codeは、それを行う方法についての優れたウォークスルーです。
マインクラフトは効率的とはほど遠い。データの「チャンク」を格納するだけです。
Minecraft Wikiの開発リソースで「マップ形式」を確認してください。私の知る限り、内部表現はまったく同じです。