「実証済みの問題でない限り、心配する必要はありません」という意見には同意しますが、早い段階で検討する価値はあると思います。そして、はい、「近くの」タイルを更新することだけが彼らの行く方法です。ただし、パフォーマンス上の理由から、ゲームの世界でアイテムを効率的に格納およびアドレス指定できることは非常に重要です。
ここで実際に考えているのは、スパースデータセットです。潜在的なインデックスは大きい（または無制限）が、実際に使用される割合はわずかなものです。重要な点は、どの比率を使用するかが正確にわからないことです。
スパースデータセットの問題に対する標準的な解決策は、インデックス/アドレス可能度を実際のデータストレージから分離することです。そのため、タイルオブジェクトが高価な場合は、コンパクトな形式（フラット配列など）で保存します。ただし、より安価なオブジェクトを介してインデックス付けできるようにします。最も単純な形式では、これは座標で簡単にインデックス付けできる2D（または3D）マトリックスにすることができますが、マトリックス内の各アイテムは単なるインデックスです。次に、そのインデックスを使用して、実際のタイルの内容を別のコンパクトな配列で検索します。タイルのコンテンツがまだ存在しない場合は、それらを配列の最後に追加し、3Dマトリックスにインデックスを格納します。
コンテンツの削除をサポートする場合（コンテンツ配列の断片化につながるため）、タイルコンテンツが安価な場合、インデックスの追加の重み（32ビットまたは64ビットのインデックス）の場合、ソリューションはより複雑になります。可能性のあるすべてのタイルを保存しないことによる節約をおそらく圧倒します。これは追加のルックアップでもあり、キャッシュのパフォーマンスを低下させます。
インダイレクションの追加レイヤーを導入することで、ストレージ効率をさらに高めることができます。タイルをチャンクに編成し、チャンクの粒度が64x64x64であるとします。タイルが125、1、132の場合、チャンク（1,0,2）に属していることがわかります。したがって、コンパクトなチャンク配列とチャンクインデックスのマトリックス（チャンクが存在しない場合は-1）で構成されるワールドがあります。各チャンクのコンテンツ（存在する場合）は、タイルインデックスの64x64x64マトリックス（タイルがまだ存在しない場合は-1）と使用されるタイルのコンパクトな配列です。このようにして、使用されていないチャンクに対して大量のタイルインデックスを焼き付けることはありません。このようなアプローチに従い、チャンクの粒度に適切な数値を選択することで、ユニバースを大幅にスケールアップし、メモリ使用量を制御することができます。実際、チャンクを32x32x32にすると、
チャンクの高次ビットまたはタイルインデックスを使用して特別な何かを意味するような、卑劣なトリックを行うこともできます。したがって、タイルマトリックスのエントリに上位ビットが設定されている場合、下位31ビットはタイルインデックスを意味するのではなく、「ワープインデックス」または類似のものを意味します。これは、個別に維持されるリストで調べることができます。それが導く座標を見つけるために。