十万在线webgame的设计思路（二）--地图模块设计思路

因为要把这么多访问量分担到不同的服务器里，原先的数据库表设计肯定不会合适。初步的想法是根据游戏的逻辑模块，将不同模块的数据库表拆分到各个服务器里，如果按照上面的服务器预估得到的结论是4~6组服务器，实际上这个方案还是可行的。但如果是20组服务器的话，除非是一台服务器一张数据库表，但这的设计会造成数据表太分散，在处理事务的时候，会跨多个数据库

策略类webgame一般的主要模块为：建筑物和资源、军事、英雄、物品、帮会、交易、地图。

地图模块：

地图在传统策略类webgame里都是以平面的方式展示和存储的。地图的移动都是在这个平面上实现。但一般来说，平面地图的设计容量都会有一个上限，一般来地图多为400*400，他的人数上限就是16w，实际上服务器容纳3~5w人后，整张地图就会显得很拥挤了。如果要想容纳几百万人在线，平面地图的尺寸就需要扩容得相当大了，这样玩家从地图中间移动到边缘的时间会相当恐怖，因此平面地图在这里不是很合适。因此，地图不能用平面来构造，必须是立体的方法构造。在这里我设计了两组方案：

立体平面空间：

如上图所描述的，立体平面空间，就是把多块地图一层层叠加在一起，形成一个立体的空间。这样如果用户不够，再增加一个新的平面就行。游戏的背景可以根据需要做调整（例如整个世界是被大海隔开的5片大陆组成，在这5片大陆之外，还有其它的超位面空间，这些空间自身是互不相连的，但是可以通过传送阵进行位面传送）。这样做的好处是，用户容易理解，以往用户的操作习惯不用改变，毕竟都是在平面地图上战斗。只不过要做跨位面的战斗的移动计算上会存在问题（逻辑上的问题：是否允许跨大陆的远征军）

用户坐标的表示方法：地图层次、x坐标、y坐标

数据库设计方案：

采用了层次结构，只需要增加一个地图层次的字段，这个地图表就能沿用。（参考字段：ID、地图层次、X坐标、y坐标、地图类型、玩家ID、城池ID）

虽然说，加入了一个地图层次的字段能解决地图的表示问题，不过，因为整个游戏世界是单一世界的服务器，当所用地图信息存储到一张表的时候，这数据量就不容小视。在这之前做webgame项目的时候，整张地图是预先生成好数据库记录的，当有玩家加入游戏的时候，就去修改表里的玩家ID和城池ID。同时因为地图大小只有400*400，整张表也就16w条记录。但如果是要做一个承载500w人的服务器，那地图的尺寸最好是要800*800，并且地图的层次为15~20层，就算最小的15层，按照原先的设计思路，至少需要预先插入960w条记录。

数据量看上去比较夸张，不过对于SqlServer来说也不是处理不了，并且我们还将计划把地图表单独用一台服务器来处理，其压力远小很多。不过也不能不考虑当发生性能瓶颈时的优化处理。优化的方法有两个：

1． 拆分：按照地图层次，把这张表拆分成15~20张表，或者拆分到15~20个数据库里

2． 用疏矩阵存储：地图不预先生成用户的地图信息，而是有玩家加入时才插入数据。这个方案在服务器早期人数比较少时会得到良好的性能效果，但当用户人数达到一定量时，还是避免不了因为记录函数过多而导致而外的开销。

全立体空间：

全立体空间就是取消了平面的坐标显示，用户都是在一个三维的立体地图里战斗。好处是地图不用那么分散，在移动计算让很好处理，存在的问题就是游戏在显示的时候，如何表现地图的三维效果会比较困难。

用户坐标的表示方式：x坐标 y坐标 z坐标

数据库存储方案：

三维空间的数据库表设计结构可以和上面的表一样，而且也只能采用疏矩阵的方式存储，因为做成三维空间后，可表示的位置的记录数更多了。

可移动基地在全立体空间的设想：

早在两年前，看过《超时空要塞F》的时候，就产生了一个想法http://www.cnblogs.com/yahle/archive/2008/05/27/1208355.html，就是玩家的基地是可以移动的。玩家的母舰在游戏的过程中，已一定的速度在整个世界里移动。也就是说，游戏里，不再是一个玩家占领一个格子战斗，而是多为玩家可以同时待在一个格子里。也就是说，存储玩家坐标将不再是用整数，而是浮点型。当然，因为玩家的母舰是可以移动的，在计算攻击距离和攻击事件的时候，计算公式不能按照固定格子来计算了。甚至，玩家都不能在常规地图上看到其他玩家的位置。一切攻击都只能针对一个局部地区（母舰雷达能扫描到的区域）。如果超过雷达范围，只能用过设定坐标和对应玩家ID来进行引导，如果用户舰队赶到目标位置而没对方母舰已离开目标区域，则视为攻击失败。