网上看一篇关于目前几个流行flash mmorpg地图实现的分析，这里也想说说自己的一些看法。

常见的三种方式：
1、整图
2、Tile元素拼装
3、栅格化切片

整图

整图加载很好理解直接加载一张背景图。这种方式比较适合小场景（面积不要超过两屏），例如可以用来做悦来客栈、家里的菜园子或者王员外的内院。

整图的表现最大的优点就是可以让美工随意发挥，画面可以做得很细致。当然缺点也比较明显无法做得太大，否则加载将是个漫长的过程，即使玩家有耐心去 等待加载，但是会浪费客户端的很多内存容量。一个10屏*10屏的地图，客户端显示每次只能显示一屏，有99屏的东西是暂时用不到的。

Tile元素拼装

Tile就是斜视角地图中的一个标准菱形，这在许多的Tile Game里面最常见（红警、帝国时代）。这种方式会实现准备好各种地形，比如草地、沙漠、水面、雪地。理论上这种方式可以满足任何地图需求。

Tile元素拼装的优点是素材包小，因为他是提取了大量的可重复利用的素材在重复使用。素材包小可以节省素材加载时间。

不过Tile元素拼装的方式也不是谁都可以玩得好的，主要问题其实在于这些可重复利用的素材必须是2方连续的。要想让地图表现力好，Tile的制作 比较关键。这并不像整图那样，美工可以大笔一挥画出几种色彩层次。如果Tile素材制作的不好，地图看起来会非常死板。同时Tile元素的制作也必须处理 好各种地形的接壤问题。

比如你有4种地形：草地、水面、沙地、雪地，那么你就必须创建草地和水面交界的效果，水面和沙地，沙地和雪地。。。。然后草地和水面的交界你还需要 考虑草地的上面有水、下面有水、左边有水、右边有水、左上角。。。。。总之就是，你希望你的地图看起来舒服就必须穷举各种情况，然后还要一遍一遍调整。但 是一旦我们做好了这一切，那么将会非常受益。如果你的开发人员有空还可以帮你设计非常好的随机生成算法。（像帝国时代的编辑器）

栅格化切片

栅格化切片他的背景绘制其实还是以整图的方式完成的，只是按照一定的大小把它切成了一些固定大小的小图，比如250*250或者300*300，然 后给每张图定好编号，通常是map_行_列。地图加载的时候，我们根据场景的坐标加载需要显示的切片。当然加载的数量通常会比你看到的要多一点，事先预加 载一些。

栅格化切片的方式事实上我们在电子地图上见得很多，当然电子地图是可以进行缩放的，所以他所做的切片通常还会配合缩放倍数做不同倍数下面的分割。

使用栅格化切片表现力上跟整图一样，在制作的时候可以让美工任意发挥。同时也能解决一部分内存浪费的问题。这看起来是个非常完美的方案，甚至可以让我们做无缝地图。可是事实并非如此的，尽管我们有着无穷的想象力，但是我们还是会在制作大地图上遇到问题。

第一个问题——地图的设计
我曾经一厢情愿的规划了一张9000px*7500px的地图让美工去做设计，结果问题来了。这样一张大地图在ps里面打开都是一个漫长的过程，每次做一次存盘都可以去喝杯茶了。尽管效果可以很好，但是等待的过程几乎让人吐血。

第二个问题——地图编辑
我们的地图是在自己开发的air编辑器，尽管这时候的地图已经是ps合层好的了，但是在编辑器中操作仍然是个恶梦。

关于障碍数组
其实对于障碍数组也是地图设计中一个需要考虑的问题的因为这会关系到你的路径算法和物体遮挡，最常见的作法就是建立一个2维数组对应到 地图中，然后使用A*来实现。当然你也可以不这样记录，直接记录地图上物体底面积形成的多边形。寻径的时候采用两点连线然后绕过障碍定点，遮挡关系也利用 这些多边形顶点做计算。甚至你也可以不用2维数组改用object的方式只记录那些被占用了的底面积。。。

但是无论采用什么方式，你的地图大必然参与到引擎中的物体就会多，存储的内容就多。假设你也像我们一样通过2维数组记录障碍，那么数组同样也是限制你实现大地图的一个问题（尽管不是那么明显）。因为你同样会需要浪费到很多内存存大量的暂时用不到的信息。

上面提到了对背景做切割，2维数组如果你愿意也可以做切割来实现随需加载，对于地图上的建筑同样如此。不过我是感觉这样做没有多大意义。从玩家的角度看，真正在乎你的大地图制作的有多少，难道因为你做了个大地图玩家就一定会买账么？

个人建议

实际的开发其实我认为并不一定那种方式更好，取决于公司的开发资源和场景的实际情况，你对客户方的考虑。上面的三种方式我们可以相互结合。

我们可以用Tile拼装的方式结合简单的表随机算法做个平铺工具给美工来快速建立一些地图的局部，让他们直接另存出图片，导入photoshop制作整图。当然如果没时间的话随便找个编辑器也行，反正比photoshop的复制会快很多。

另外，我们可以在设计引擎的时候将整图和栅格化切图的方式一起考虑，对于小场景使用整图加载，对于大场景使用切片加载。

评论 (0) All

登陆 还没注册？