我正在为每个 x、y、z 坐标考虑类似 3x3 的矩阵。但这会浪费内存,因为很多块空间都是空的。另一种解决方案是使用哈希图 ((x,y,z) -> BlockObject),但这似乎也不太有效。
当我说高效时,我并不是指最优。它只是意味着它足以在您的现代计算机上顺利运行。请记住,由我的世界生成的世界非常庞大,无论如何效率都很重要。还有大量的元数据需要存储。
我正在为每个 x、y、z 坐标考虑类似 3x3 的矩阵。但这会浪费内存,因为很多块空间都是空的。另一种解决方案是使用哈希图 ((x,y,z) -> BlockObject),但这似乎也不太有效。
当我说高效时,我并不是指最优。它只是意味着它足以在您的现代计算机上顺利运行。请记住,由我的世界生成的世界非常庞大,无论如何效率都很重要。还有大量的元数据需要存储。
正如我在评论中所指出的,我不知道 MineCraft 是如何做到这一点的,但表示此类数据的一种常见有效方式是八叉树;http://en.wikipedia.org/wiki/Octree。一般的想法是它就像一棵二叉树,但在三个空间中。您递归地划分每个维度中的每个空间块以获得八个较小的块,每个块包含指向较小块的指针和指向其父块的指针。
这使您可以有效地存储相同材料的大块(例如,“空白空间”),因为您可以在到达由所有相同事物组成的块时终止递归,即使您没有' t 递归到单个“立方体”单元的级别。
此外,这意味着您可以有效地找到给定区域中的所有立方体,方法是获取当前块并沿着树向上走足够远以到达包含所有您可以看到的块 - 这样,您可以非常轻松地忽略其他地方的所有立方体。
如果您有兴趣探索表示 Minecraft 世界(块)数据的替代方法,您还可以研究位串的想法。每个“块”由一个 16*16*128 的体积组成,而 16*16 可以用一个单字节字符充分表示,并且可以合并成一个二进制字符串。
由于这种方法高度特定于交易客户端计算与高度优化的存储和传输时间的特定目标,试图解释所有细节似乎是不谨慎的,但我已经为此目的创建了一个规范,如果你有兴趣.
使用这种方法,计算存储成本与当前的 1byte-per-block 截然不同,而是“可变比特率”:((1bit-per-block,四舍五入为 8 的倍数) * (number of块类型出现在块中的唯一层)+ 2字节)
然后对(该块中的唯一数量的块类型)求和。
几乎只有在刻意的边缘情况下,这可能比正常结构的块更昂贵,超过 99% 的 Minecraft 块是自然生成的,并且会以 8:1 或更多的比例受益于这种可变位表示。我的测试。
最好的办法是反编译 Minecraft 并查看源代码。 Modifying Minecraft: The Source Code是关于如何做到这一点的一个很好的演练。
Minecraft 远非高效。它只存储“块”数据。
查看Minecraft Wiki开发资源中的“地图格式”。AFAIK,内部表示完全相同。