用于存储巨大平铺地图的选项

Posted 2023-04-18

【中文标题】用于存储巨大平铺地图的选项

【英文标题】：Options for storing huge tile map

【发布时间】：2017-03-22 08:08:37

【问题描述】：

我正在创建一个基于伪回合的在线策略浏览器游戏，许多人在同一个世界中长时间（数月）玩。为此，我想要一张 64000x64000 瓦 = 40 亿瓦的地图。每个图块我需要大约 6-10 字节的数据，总共需要大约 30GB 的数据来存储地图。

每个图块应具有类型（水、草、沙漠、山）、资源（木头、牛、金）和 playerBuilt（道路、建筑）等属性

客户只需要同时访问大约 100x100 个图块。

我已经在客户端控制了地图。我面临的问题是如何在服务器端存储、检索和修改此地图中的信息。

所需功能：

创建、存储和修改 64000x64000 平铺地图。 向客户端显示地图的 100x100 部分。 在地图上进行修改，例如道路、建筑物和耗尽的资源。

到目前为止我所考虑的：

程序生成：程序生成动态需要的地图的任何部分。确保给定相同的种子，它总是生成相同的地图。我对此的主要问题是在游戏期间会对地图进行修改。注意：只有不到 1% 的图块会在游戏期间被修改，并且可以将修改与坐标存储在外部数组中。在程序生成之上加载它们。 数据库：在游戏开始时生成地图并将其存储在数据库中。一位朋友建议我不要为这么大的瓦片地图这样做，并告诉我我可能希望将其存储在内存中。 将其全部保存在服务器端的内存中：将其保存在内存中的数据结构中。如果地图更小，但要保存在内存中的 40 亿个图块，这似乎是一个不错的方法。

我打算为这个项目使用 java+mysql 作为后端。我仍处于早期阶段，如果需要，我愿意改变技术。

我的问题是：以上三种方法中哪一种看起来可行和/或还有其他我没有考虑过的方法？

【问题讨论】：

欢迎来到 SO！对于这个问题，您可能会得到一些有用的答案，但总的来说，对于这个网站来说，它真的太宽泛了。正确的答案将是“这取决于”关于如何设计游戏的许多因素。如果您可以更具体地了解您在每个解决方案中看到的问题并询问如何解决它们，那么您可能会获得更好的信息。如果这对您来说过于宽泛，请不要感到惊讶。

每个图块大约有多少数据？每块 8 位的解决方案与每块 1 mb 的解决方案有很大不同...

Sprinter - 感谢您的欢迎，以后我会尽量保持简洁。 Pikalek - 每个图块大约 16 字节的数据。

这16个字节的数据到底是什么？通过仅存储对常见值组合的引用，完全有可能使图块消耗更少的内存。例如。奶牛不生活在水中，因此类型和资源可能会以一种有用的方式结合起来。

有趣的想法，Markus Benko。谢谢。我在想的是：我需要一些位（2 字节？）来确定类型（草）和资源类型（牛、金）。然后我需要几个更大的整数（每个 4 字节）来确定剩余资源量和对潜在 playerBuiltObject 的 ID 引用。这构成了大约 10 个字节的上限，除非我需要存储任何其他信息。平均约为 6 字节，因为只有不到 1% 的图块会有 playerBuiltObjects。

【参考方案1】：

取决于：

您（或玩家/用户）获得了多少 RAM 大部分瓦片地图是空的（稀疏的）吗？对面是密集的。 是否有默认地形（如空地或水？）

如果稀疏，请使用哈希图而不是二维数组。

如果密集，则更具挑战性，您可能需要使用数据库或一些特殊的数据结构 + 缓存。 您可以检测热区并将它们保存在内存中一段时间​​，死区（那里没有玩家，没有活动......）可以存储在数据库中并按需读取。 您还可以在多个通道中加载数据：首先只是地形，然后是其他对象……每一层都可以以不同的方式存储。例如，地形可能是 perlin 噪声生成 + 另一个可以修改的图层。