游戏地形数据库模型
我正在开发一款网络游戏。 本场比赛的地图至少为2000公里×2000公里。 我希望能够以某种粒度（例如 100m X 100m）对海拔和地形类型进行编码。
对于 2000 公里 x 2000 公里的地图，将此信息存储在 100m2 存储桶中意味着数据库中有 20000 x 20000 个元素或总共 400,000,000 条记录。
是否有其他方法来存储此类信息？
更多信息
地图本身永远不会完整显示。 单位将以回合制方式在地图上移动，玩家将获得有关它们所在位置以及当地区域情况的反馈。 地形将决定速度和移动限制。
我想我想说的是，地图将用于游戏，而不一定用于图形或显示目的。
I am developing a game for the web. The map of this game will be a minimum of 2000km by 2000km. I want to be able to encode elevation and terrain type at some level of granularity - 100m X 100m for example.
For a 2000km by 2000km map storing this information in 100m2 buckets would mean 20000 by 20000 elements or a total of 400,000,000 records in a database.
Is there some other way of storing this type of information?
MORE INFORMATION
The map itself will not ever be displayed in its entirety. Units will be moved on the map in a turn based fashion and the players will get feedback on where they are located and what the local area looks like. Terrain will dictate speed and prohibition of movement.
I guess I am trying to say that the map will be used for the game and not necessarily for a graphical or display purposes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于您想要如何生成地形。
例如，您可以按程序生成所有内容（使用低分辨率地形/高度图的插值 - 存储为两个“位图” - 使用从 xy 坐标播种的随机插值以确保地形不会变形），并使用最小的存储空间。
如果您想要完全定义的地形区域，您可以单独存储它们并在适当的情况下使用它们，随机生成其余部分。）
如果您想要完全定义的地形，那么您将需要研究某种压缩/流技术仅拉动您当前感兴趣的地形。
It depends on how you want to generate your terrain.
For example, you could procedurally generate it all (using interpolation of a low resolution terrain/height map - stored as two "bitmaps" - with random interpolation seeded from the xy coords to ensure that terrain didn't morph), and use minimal storage.
If you wanted areas of terrain that were completely defined, you could store these separately and use them where appropriate, randomly generating the rest.)
If you want completely defined terrain, then you're going to need to look into some kind of compression/streaming technique to only pull terrain you are currently interested in.
我会通过区分地形类型和海拔来以不同的方式对待它。
我认为，地形类型的变化不会像海拔一样快 - 可能存在相同类型地形的部分，其延伸范围比最低粒度级别长得多。 我会将这些扇区映射到数据库记录或某种哈希表中，具体取决于性能、内存和其他要求。
我认为海拔是半连续的，因为它大部分是逐渐变化的。 我会尝试将这些值映射到连续函数集（不连续的部分之间的不同集，如海拔的突然变化）。 对于任何一组地形具有相同高程或可以用简单函数描述的坐标，您只需定义该函数覆盖的范围即可。 这应该会大大减少描述地形中每个点的海拔所需记录的信息量。
因此，基本上我会将地图分解为由 (x,y) 范围组成的不同部分，一次用于地形类型，一次用于地形高程，并为每个部分构建一个哈希表，该哈希表可以根据需要返回适当的值。
I would treat it differently, by separating terrain type and elevation.
Terrain type, I assume, does not change as rapidly as elevation - there are probably sectors of the same type of terrain that stretch over much longer than the lowest level of granularity. I would map those sectors into database records or some kind of hash table, depending on performance, memory and other requirements.
Elevation I would assume is semi-contiuous, as it changes gradually for the most part. I would try to map the values into set of continuous functions (different sets between parts that are not continues, as in sudden change in elevation). For any set of coordinates for which the terrain is the same elevation or can be described by a simple function, you just need to define the range this function covers. This should reduce much the amount of information you need to record to describe the elevation at each point in the terrain.
So basically I would break down the map into different sectors which compose of (x,y) ranges, once for terrain type and once for terrain elevation, and build a hash table for each which can return the appropriate value as needed.
如果您想要您正在寻找的那种粒度，那么没有明显的方法可以做到这一点。
您可以尝试二维小波变换，但这非常复杂。 像傅立叶变换这样的东西就可以很好地发挥作用。 另外，您可能不会采用每块土地一条记录的方式存储地形； 拥有某种可以存储编码矩阵的数据库字段更有意义。
If you want the kind of granularity that you are looking for, then there is no obvious way of doing it.
You could try a 2-dimensional wavelet transform, but that's pretty complex. Something like a Fourier transform would do quite nicely. Plus, you probably wouldn't go about storing the terrain with a one-record-per-piece-of-land way; it makes more sense to have some sort of database field which can store an encoded matrix.
我认为通常的解决方案是将您的域分解为可管理大小的“图块”。 您必须添加一点逻辑才能在任何给定时间加载适当的图块，但也不算太糟糕。
您不需要立即访问所有这些信息——即使每个 100 平方米的桶占据屏幕上的一个像素，据我所知，没有屏幕可以同时显示 20k x 20k 像素。
另外，我不会使用数据库——研究高度映射——有效地使用黑色和白色。 其像素值代表高度的白色图像。
祝你好运！
I think the usual solution is to break your domain up into "tiles" of manageable sizes. You'll have to add a little bit of logic to load the appropriate tiles at any given time, but not too bad.
You shouldn't need to access all that info at once--even if each 100m2 bucket occupied a single pixel on the screen, no screen I know of could show 20k x 20k pixels at once.
Also, I wouldn't use a database--look into height mapping--effectively using a black & white image whose pixel values represent heights.
Good luck!
无论你从哪个角度来看，这都将是非常多的信息。 4 亿个网格单元将遭受损失。
我看到有两种解决这个问题的方法。 首先，由于它是一款基于网页的游戏，您可能可以购买一台具有适当大小硬盘的服务器，并像平常一样在其中存储 400M 的记录。 或者更有可能创建某种您自己的存储机制以提高效率。 然后，您只需设计一种有效访问数据的方法，这可以通过考虑您可能需要一次使用所有数据的事实来完成。 ;)
另一种方法是某种压缩。 不过你必须小心这一点。 大多数开箱即用的压缩算法不允许您解压缩流中的任意位置。 也许您的地形数据中有一些可以使用的模式？ 我怀疑这将是完全随机的。 我更有可能用相同的数据预测大片区域。 也许这些可以这样编码？
That will be awfully lot of information no matter which way you look at it. 400,000,000 grid cells will take their toll.
I see two ways of going around this. Firstly, since it is a web-based game, you might be able to get a server with a decently sized HDD and store the 400M records in it just as you would normally. Or more likely create some sort of your own storage mechanism for efficiency. Then you would only have to devise a way to access the data efficiently, which could be done by taking into account the fact that you doubtfully will need to use it all at once. ;)
The other way would be some kind of compression. You have to be careful with this though. Most out-of-the-box compression algorithms won't allow you to decompress an arbitrary location in the stream. Perhaps your terrain data has some patterns in it you can use? I doubt it will be completely random. More likely I predict large areas with the same data. Perhaps those can be encoded as such?