所以我用C ++设计一个带有大量数据的2D游戏 - 基本上，它具有随机生成的，块状地形（以非常大的字节数组的形式），很像Terraria的风格，也会需要为怪物（以及其他各种游戏对象）保存状态。当玩家四处奔波时，游戏世界的某些部分将被加载/保存到磁盘上，从而形成一个无限扩展的游戏世界（类似于Minecraft）。
将所有内容保存到磁盘的最佳选择是什么？我主要关心的是效率（因此用户永远不必等待内容加载），但易用性和可维护性紧随其后。我非常熟悉Minecraft的保存方法，每个“Chunk”都有一个单独的文件，但我想知道 - 我应该指定我自己的文件，如Minecraft，还是使用数据库？还有哪些其他可能性？如果我使用一个文件，我会通过询问操作系统的原始访问和自己处理（很像数据库那样）来获得显着的性能提升吗？
此外，我希望能够将项目从PC移植到Mac和控制台 - 各个平台的替代方案都很好，我只需要根据平台交换方法。
谢谢！
答案 0 :(得分：3)
数据库的目的是加速复杂的搜索。你没有任何搜索;你有一块数据需要进入内存。对于此任务，数据库绝对没有任何价值。
您的需求实际取决于您所谈论的数据量以及您希望的平台特定程度。你似乎在谈论2D游戏，所以大块不能 大。常规C或C ++文件IO函数可能已经足够好了。最糟糕的情况是，您可能必须将它们粘贴在异步文件IO和处理的线程中。
真的，只是开始做明显的事情。如果它成为一个问题，尝试使它与简单的线程结构异步。你可能不需要走得太远。
答案 1 :(得分：1)
根据我的经验，这实际上取决于很多因素。我的小组有一个将数百甚至数千个文件保存到数据库的系统，并且性能得到了提高。这些文件很小，因此与等待磁盘驱动器启动的延迟相比，或者操作系统将文件系统导航到每个单独的文件时，读取和写入都很短。
如果您有数千个小于4 kB页面的文件，我会使用数据库。如果文件大于那个，那么请使用文件。数据库无法帮助您提高吞吐量 - 只有您的延迟。
答案 2 :(得分：1)
单个文件将更加清晰，并且可能比依赖文件系统进行组织所需的物理磁盘空间更少。只需在文件开头维护一个偏移表即可链接到每个块。
就压缩而言，应用行程长度编码肯定会缩小文件大小，如果它像Minecraft那样，你将会有很多相同的块。作为奖励，它将在使用平板驱动器的计算机上加载更快，因为几个字节可以等同于数千个块，而不必为每个块读取一个字节。以下是有效运行长度编码的快速提示：使用命令字节，比如0x00。所有其他字节与块相关联，但命令字节表示非块的信息位。传统的运行长度编码如下所示：
Source: AAAABBBBBBBCDDDEFA
Destination: 0x0441074201430344014501460161
Plaintext: .A.B.C.D.E.F.A
使用命令字节，省略会增加大小的序列：
Source: AAAABBBBBBBCDDDEFA
Destination: 0x00044100074243444444454641.
Plaintext: ..A..BCDDDEFA
这在“大理石”数据部分中具有明显的优势。
另一件事，我建议您使用系统存储类似于midi格式的数字，尽管采用小端格式。为了节省谷歌搜索，所有它真正意味着你牺牲一点用于存储数字的每个字节。如果第8位置位，则表示该数字中有另一个字节，并且它会级联。例如：
Storing: 65
Stored as: 0x41 (01000001) //The eighth bit is not set, so this number only occupies 7 bits.
Storing: 192
Stored as: 0xC081 (11000000 10000001) //The eighth bit of the first byte is set, so the following byte is part of the number. The second byte doesn't have the eighth bit set, so the number ends there.
Storing: 612453
Stored as: 0x72D825 (11100101 1011000 00100101) //The eighth bit of the first two bytes are set, and the third is not, so this number occupies 3 bytes.
我希望我帮助提供一些见解。