如果将canvas的各种渲染操作（如 drawImage 、 fillText 等）与项目代码放在一起，那么势必导致项目后期无法维护。翻了一下几款现有的canvas库，结合vue的数据绑定+调试工具的方式，搞了一个全新的canvas库Easycanvas（ ），并且像vue一样支持通过一个插件来调试canvas中的元素。

这样，整个游戏的渲染部分就容易很多，只需要管理游戏当前的状态、并且根据服务端从socket传回来的数据去更新数据就可以。 “数据的变化引起视图的变化”这个环节由Easycanvas负责 。例如下图的玩家包裹物品的实现，我们只需要给出包裹容器的位置、背包里每个元素的排布规则，然后将每个包裹的物品绑定到一个array上，然后去管理这个array即可（数据映射到画面的过程由Easycanvas负责）。

例如，5行8列共计40个物品的样式可以通过如下的形式传递给Easycanvas（index为物品索引，物品x方向间距36，y方向间距32）。而这个逻辑是一成不变的，无论物品的数组怎样变化、包裹被拖拽到什么位置，每个物品的相对位置都是固定的。至于canvas上的渲染则完全不需要项目本身来考虑，所以可维护性较好。

canvas分层渲染

假设：游戏需要保持40帧，浏览器宽800高600，面积48万（后面称48万为1个屏幕面积）。

如果用同一个canvas来呈现，那么这个canvas的帧数40，每秒至少需要绘制40个屏幕面积。但是同一个坐标点很可能出现多个元素重叠的情况，例如底部的UI、血条、按钮就是重叠放置，他们又共同遮挡了场景地图。所以这些加在一起，每秒浏览器的绘制量很容易达到100个屏幕面积以上。

这个绘制是很难优化的，因为整个canvas画布的任何一处都在进行视图的更新：可能是玩家和动物的移动、可能是按钮的特效、可能是某个技能效果的变化。这样的话，即使玩家不动，由于衣服“随风飘飘”的效果（其实是精灵动画播放到下一张图），或者是地面上出现了一瓶药水，都要引起整个canvas的重绘。因为 游戏中几乎不可能出现某一帧的画面与上一帧毫无区别的情况，即使是游戏画面的一个局部，也很难保持不变 。整个游戏的画面永远在更新。

因为 游戏中几乎不可能出现某一帧的画面与上一帧毫无区别的情况 ，画面永远在更新。

因此，这次我采用了3个canvas重叠排布的方式。由于Easycanvas的事件处理支持传递，因此即使点到了最上面的canvas，如果没有任何元素结束了某一次点击，后面的canvas也可以接到这次事件。3个canvas分别负责UI、地面（地图）、精灵（人物、动物、技能特效等）：

这样分层的好处是，每层最大帧数可以根据需要来调整：

例如UI层，因为很多UI平时是不动的，即使动也不会需要太精密的绘制，所以可以适当降低帧数，例如降低到20。这样假如玩家的体力从100降低到20，那么可以在50ms内更新视图，而50ms的切换是玩家感觉不出来的。因为像体力这种 UI层数据的变化很难在很短的时间内连续变化多次，而50ms的延迟是人很难感知的，所以不需要频繁的绘制 。假如我们每秒节约了20帧，那么很可能可以节约10个屏幕面积的绘制。

再如地面，只有玩家移动的时候，地图才会变化。这样，如果玩家不动，那么每帧可以省去1个屏幕面积。由于需要保证玩家移动时的流畅感，地面的最大帧数不宜太低。假如地面为30帧，那么玩家不动时，每秒就可以节约30个屏幕面积的绘制（这个项目中，地图是几乎绘满屏幕的）。而且其它玩家、动物的移动不会改变地面，也不需要重绘地面这一层。

精灵层最大帧数不能降低，这层会展示游戏的人物动作等核心部分，所以最大帧数设置为40.

这样，每秒绘制的面积，玩家移动时可能是80～100个屏幕面积，而玩家不移动时可能只有50个屏幕面积。游戏中，玩家停下来打怪、打字、整理物品、释放技能都是站立不动的，因此 大量的时间里都不会触发地面的绘制，对性能的节约很大 。

服务器端

由于目标是js实现一款多人网游，所以服务端使用Node，使用socket与浏览器通讯。这样做还有一个好处，就是一些 公用的逻辑可以在两端复用 ，例如判断地图上某个坐标点是否存在障碍物。

Node端的玩家、场景等游戏相关数据全部存储与内存中，定期同步至文件。每次Node服务启动时，将数据从文件读取至内存。这样可以玩家较多时，文件读写的频率成指数级上升，从而引发的性能问题。（后来为了提高稳定，为文件读写增加了一个缓冲，“内存-文件-备份”的方式，以免读写过程中服务器重启导致的文件损坏）。

Node端分接口、数据、实例等多层。“接口”负责和浏览器端交互。“数据”是一些静态数据，例如某个药品的名称和效果、某个怪物的速度和体力，是游戏规则的一部分。“实例”是游戏中的当前状态，例如某个玩家身上的一个药品，就是“药品数据”的一个实例。再举个例子，“鹿的实例”拥有“当前血量”这个属性，鹿A可能是10，鹿B可能是14，而“鹿”本身只有“初始血量”。

3.场景地图的实现

地图场景

下面开始介绍地图场景部分，仍然是依赖 Easycanvas 进行渲染。

思考

由于玩家是始终固定在屏幕中心的，所以玩家的移动，实际上是地图的移动。例如玩家像左跑，地图就向右平移即可。刚才已经提到，玩家处于3个canvas中的中间一层，而地图属于底层，因此玩家一定遮挡地图。

这样看起来是合理的，但是假如地图中有一棵树，那么“玩家的层次始终高于树”就不对了。这时，有2种大的解决方案：

地图分层，“地面”与“地上”拆开。将玩家处于两层之间，例如下图，左侧是地上、右侧是地面，然后重叠绘制，把人物夹在中间：

这样看似解决了问题，其实引入了2个新的问题：第一个是，玩家有时可能会被“地上”的东西遮挡（例如一棵树），有时又需要能够遮挡“地上”的东西（例如站在这棵树的下方，头部会遮挡住树）。另一个问题是渲染的性能消耗会增加。由于玩家是时刻在变的，“地上”这一层需要频繁重绘。这样做也打破了最初的设计——尽量节约地面大地图的渲染，从而导致canvas的分层更加复杂。

地图不分层，“地面”与“地上”在一起绘制。当玩家处于树后的时候，将玩家的透明度设置为0.5，例如下图：

这样做只有一个坏处：玩家的身体要么都不透明、要么都半透明（怪物在地图上行走也会有这个效果），不会完全真实。因为理想的效果是存在玩家的身体被遮挡住一部分的场景的。但是这样做对性能友好，并且代码易于维护，目前我也采用了这个方案。

那么如何判断“地图”这张图片哪些地方是树呢？游戏通常会有一个大的地图描述文件（其实就是一个Array），通过0、1、2这样的数字来标识哪些地方可以通过、哪些地方存在障碍物、哪些地方是传送点等等。热血传奇中的这个“描述文件”就是48x32为最小单位进行描述的，所以玩家在传奇中的行动会有一种“棋盘”的感觉。单位越小越流畅，但是占用的体积越大、生成这个描述的过程也就越耗时。

下面开始正题。

实现

我找了一个朋友帮我导出热血传奇客户端中“比奇省”的地图，宽33600、高22400，是我电脑的几百倍大。为了避免电脑爆炸，需要拆分成多块加载。由于传奇的最小单元是48x32，我们以480x320将地图拆成了4900（70x70）个图片文件。

canvas的尺寸我们设定为800x600，这样玩家只需要加载3x3共计9张图片就可以铺满整个画布。800/480=1.67，那么为什么不是2x2？因为有可能玩家当前的位置正好导致有的图片只展示了一部分。如下图：

总结

以上所述是小编给大家介绍的javascript高仿热血传奇游戏实现代码。编程之家 jb51.cc 收集整理的教程希望能对你有所帮助，如果觉得编程之家不错，可分享给好友！感谢支持。