我和一个小团队的程序员正在研究一个带有大方形世界地图的MMO浏览器游戏,其中每个索引(x,y)指的是地图上的一个图块.每个图块都有一对值来存储地形类型ID和随机生成的种子,这些种子将用于程序生成.此地图将在1500×1500到500×500平方米的范围内.
我们需要一种有效的方法将此表存储在服务器上,最好是在sql数据库中,以便可以访问较小的方块地图并将其发送给播放器以供其浏览器呈现.
关于访问地图数据,以下条件始终如一.
>存储在数据库中后,地图数据将永远不会更新
>永远不会立即访问完整的地图
>在任何给定的查询中只能访问地图的小矩形部分部分,范围从单个图块到表格中最大50×50的正方形
鉴于这些条件,我们可以选择将数据存储在MySQL数据库中,以便无论数据在表中的位置如何,对数据矩形部分的访问速度都很快,最好是相同的速度?
我们的一个团队成员为sql表提出了这种布局方法,其中每一行都是地图中的一个图块:
|------------------------------------------------------------|
| table: map |
|------------------------------------------------------------|
| coord | tile | attrs | seed |
|------------------|----------------|-------|----------------|
|mediumint unsigned|tinyint unsigned| text |tinyint unsigned|
| unique index | | | |
|------------------|----------------|-------|----------------|
> coord:世界地图上瓷砖的X和Y坐标的组合.通过X(Y << 11)计算1500x1500图.
(注意,对于50×50测试图,使用X(Y << <6))
> tile:tile的terrain类型的数字ID
> attrs:我们需要存储的任何属性来修改磁贴,
> seed:随机生成的tile种子
我们的团队成员都不具备sql表设计的经验,所以我们无法知道这是一个好的方法,还是瓶颈不足或减速
我们正在寻找一个答案,介绍我们在桌子或桌子设计中的选择,以及选择每个选项的优缺点.此外,如果你真的很好,从数据库中拉出一个矩形块的例子(如从(0,0)到(5,5))会很好.
编辑如果有一个除了MysqL以外的选项会更快,例如将它存储在服务器上的本地文件中也是一个有效的答案,但是我想要一些解释为什么在这些条件下它会更快
我意识到这不是一个简单的问题,并且会感谢你能给予的任何帮助
解决方法:
就个人而言,我会这样表达出来.
地图瓷砖
id - primary key
mapId - indexed
xCoord - indexed
yCoord - indexed
tileId
地图
id - primary key
tileSetId
活动
id - primary key
mapId - indexed
xCoord - indexed
yCoord - indexed
proceeduralInstructions
重要的是查找速度的索引.我在Map Tiles表中添加了mapId,以便您可以在此表中存储多个地图. Map表将保存地图特定信息,例如您用于绘制地图的tileset(图像).事件可以在渲染时添加到地图中.您可能会想出一个简写程序指令直接放入DB,可以由引擎解释.您可能还会为精灵添加另一个表,并可能为Map Tile表添加另一个列,用于绘制拼贴的图层(某些内容将出现在角色前面,而其他内容则出现在后面).您甚至可能需要两个前景图层和两个背景图层,以便您可以将具有部分透明度的图像叠加在一起,以获得更丰富的贴图.