javascript高仿热血传奇游戏

（本文更新中，当前版本更新于18.2.23）

前言

游戏的第一个版本开发于14年，浏览器端使用html+css+js，服务端使用asp+php，通讯采用ajax，数据存储使用access+mySql。不过由于一些问题（当时还不会用node，用asp写复杂的逻辑真的会写吐；当时对canvas写的也少，dom渲染很容易达到性能瓶颈），已经废弃。后来用canvas重制了一版。本文写于18年。

资料汇总

• 项目使用数据驱动的轻量canvas渲染库Easycanvas：https://github.com/chenzhuo1992/easycanvas

• Easycanvas的Chrome调试插件：https://github.com/HuJiaoHJ/ec-devtools

• 热血传奇客户端文件解析：https://github.com/jootnet/mir2.core）

• 项目demo还有几处没有完成，完成后放出

1.开发前的准备

为什么要用Javascript来实现一款比较复杂的PC端游戏

1.js实现PC端网游是可行的。随着PC、手机硬件配置的升级和浏览器的更新换代，以及H5各种库的发展，js实现一款网游的难度越来越低。这里的难度主要是两方面：浏览器的性能；js代码是否足够易于扩展，以满足于一款逻辑极其复杂的游戏的迭代。

2.现阶段的js游戏里，很少有规模较大的可供参考。涉及到多人联机、服务端数据存储、复杂交互的游戏，大多数（几乎全部）都是用flash开发的。但是flash毕竟在衰落，而js发展迅速，并且只要有浏览器就可以运行。

为什么选择了一款2001年的热血传奇游戏

第一个原因是对老游戏的情怀； 当然更重要的另一个原因是，别的游戏要么我不会玩、要么我会玩但没有素材（图片、音效等）。花很大精力去收集一个游戏的地图、人物怪物模型、物品和装备图，然后去处理、解析一遍再用于js开发，我觉得是浪费时间。

由于我以前搜集了一些传奇游戏的素材，并且幸运地找到了提取热血传奇客户端资源文件的方法，所以可以直接开始写码，省去了一些准备时间。

可能的困难

1.浏览器的运行性能：这个应该是最困难的一点。假如游戏要保持40帧，那么每帧只有25ms的时间留给js计算。并且由于渲染通常比计算耗性能，实际上留给js的时间只有10毫秒左右。

2.防作弊：如何避免用户直接调用接口或者篡改网络请求数据？由于目标是用js实现比较复杂的游戏，并且任何网络游戏都需要考虑这一点，一定会有相对成熟的方案。此处不是本文重点。

2.整体设计

浏览器端

1. 画面渲染使用canvas。

   相比dom(div)+css，canvas可以处理比较复杂的场景渲染和事件管理，例如下面这个场景，涉及了四张图片：玩家、动物、地上的物品、最下层的地图图片。（实际还有地上的影子，鼠标指向人物、动物、物品时出现的相应名称，以及地面上的阴影。为了方便读懂，先不考虑这么多内容。）

   

   这时，如果希望实现“点击动物、攻击动物；点击物品、捡起物品”的效果，那么需要对动物和物品进行事件监听。如果采用dom的方式，那么会出现几点难于处理的问题：

   • 渲染的顺序和事件处理的顺序不同（有时候z-index小的需要先处理事件），需要额外处理。例如这个上面的例子里：点击怪物、点击物品的时候也容易点到人物，那么需要给人物做“点击事件穿透”的处理。而且事件处理的顺序不固定：假如我有一个技能（例如游戏里的治疗）需要点人物才可以释放，那么这时人物又需要有事件监听。所以一个元素是否需要处理事件、处理事件的先后，是随着游戏状态的不同而变化的，而dom的事件绑定已经不能满足需要。

   • 有关联的元素难以放在同一个dom节点中：例如玩家的模型、玩家的名字和玩家身上的技能画效，理想情况下是放在一个<div>或者<section>容器里，便于管理（这样几个元素的定位就可以继承父元素，不用分别处理位置了）。但是这样，z-index会很难处理。例如玩家A在玩家B的上面，那么A会被B遮挡，因此需要A的z-index小一些，但是又需要让玩家A的名字不会被B的名字或者影子遮挡，就无法实现。简单点说，dom结构的可维护性会牺牲画面展示的效果，反之亦然。

   • 性能问题。即使牺牲了效果，用dom渲染，势必出现很多嵌套关系，所有元素的style都在频繁变化，连续触发浏览器的repaint甚至reflow。

2. canvas渲染逻辑与项目逻辑分离

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

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

   

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

   style: {
       tw: 30, th: 30,
       tx: function () {
           return 40 + index % 8 * 36;
       },
       ty: function () {
           return 31 + Math.fl