【发布时间】：2018-07-25 13:27:05
【问题描述】：
背景：
我正在研究 2d 无限世界生成。它是基于瓷砖的，这意味着我的地形完全由正方形组成。你可以把它想象成 2d Minecraft（从上方看地形）。
我实现了标准块系统，其中地形被分割成小的 8x8 瓷砖区域，随着玩家在世界各地移动，这些区域会被加载和删除。到目前为止，这可以非常顺利地工作，没有任何打嗝或滞后。我正在使用 Lua 和 Corona SDK。
问题：
由于玩家将能够修改地形，我需要一个快速高效的系统来在玩家加载新区块后将区块保存在内存中，以及从内存中加载这些区块的系统如果它们之前已加载。
这就是问题发生的地方。它需要经常读取和保存到文件（内存），这会导致明显的延迟。使块更大不是一种选择。
我尝试过但都导致延迟的解决方案：
a) 我实施的第一个也是显而易见的解决方案是只为每个块创建一个文本文件，并将图块名称作为字符串。它看起来像这样：x12y10.txt 在文件中，我只是转储了所有磁贴名称，以便它们需要放置在屏幕上："Grass Grass Water Sand Sand Sand Grass Grass..."。这行得通，但加载字符串很慢，所以我尝试了另一种解决方案：将切片另存为索引。
b) 将图块保存为它们的索引。我将每个图块与一个数字配对。由于数字更短，它们占用的内存更少，加载速度更快。我给了每个图块它自己的索引：Grass -> id 1、Water -> id 2、Sand -> id 3 等等。这样我只需要保存 1 或 2 个字符而不是每个图块的完整字符串。我的 txt 文件现在看起来像这样："1 1 2 3 3 3 1 1..."。这效果更好，但仍然导致延迟。
c) 我做的下一个改进是块在内存中的组织方式。我没有将所有块都转储到一个文件夹中，而是为每个 x 坐标创建了一个文件夹并将所有具有该 x 值的块放入其中。
所以不要这样：
- 包含所有块的文件夹：
x0y0.txt、x0y1.txt、x0y2.txt、x1y0.txt、x1y1.txt、x1y2.txt
包含所有块的文件夹内我有这个：
文件夹 x0：
x0y0.txt、x0y1.txt、x0y2.txt文件夹 x1：
x1y0.txt、x1y1.txt、x1y2.txt
我不确定这对少量块有多大帮助，但我很确定对于数千块，改进是有的。
可能的解决方案？
我有一些改进的想法，但我想听听您对解决方案的意见。
a) 将地形保存为二进制文件？
b) 我已经阅读了有关 Minecraft 区域格式的信息，我真的很想了解它是如何工作的，但由于关于它的信息很少，所以没有得到它。因此，如果有人知道并可以向我解释他们的系统，我将不胜感激。
c) 另一种更快的文件格式？
d) 制作/访问许多文件夹很慢吗？有更好的选择吗？
【问题讨论】：
-
为什么要将数据保存在文件中？使用位于内存中的单个 Lua 表：
{['x12y10']='1 1 2 3 3 3 1 1', ['x0y0']='2 1 2 1 2 1 2 1', ...} -
地形可以无限生成。将表中的每一块都倾倒是一个非常糟糕的主意。如果有变化，地形也需要保存。离开游戏后，该 lua 表将被销毁，地形变化也会随之删除。
-
人类无法进行如此多的更改以溢出 Lua VM 内存。在一个表中存储一百万个修改过的单元格对于 Lua 来说是可以的。一百万次鼠标点击是人类点击的 11 天 :-) 是的，表格必须在退出时保存并在进入时加载。
标签： memory optimization lua coronasdk procedural-generation