欢乐坦克大战：微信小游戏重度之作的开发挑战与架构解析

《欢乐坦克大战》是一款支持 3V3 实时对战的作品，也是最早上线的微信小游戏之一。由于这款游戏在微信小游戏中属于重度作品欢乐坦克，项目开发周期很短，因此游戏复杂度、开发难度、性能挑战也颇大；项目团队在一个月内就完成了单机和联网对战玩法的开发。

同时，由于客户端开发团队的核心成员都有多年的引擎开发经验，项目组决定使用 V1.6.1 版本的引擎进行开发。而对于微信小游戏平台使用的语言，开发团队基本都是从零开始，边学边做，这对他们来说是一个很大的挑战。

1. 架构

在网络通讯方面，项目采用协议进行通讯，通讯格式为JSON。为了迎合TDR的XML协议，项目组开发了TDR->JSON转换工具。

为了方便规划人员使用Excel表进行数据配置，项目组还开发了将Excel转换为JSON文件的工具，以便客户端读取配置文件。

对于地图，我们没有使用 Cocos 引擎提供的地图，而是自己实现了一个类的机制，规划人员可以在 Excel 中配置地图信息，然后使用工具将 Excel 转换成 JSON 格式的地图文件，供客户端加载。

由于开发工期紧张，我们需要同时开发单机和PVP两种玩法。所以我们封装了一个命令层（CMD层）来驱动战斗逻辑。比如使用摇杆控制坦克移动，展现层会把CMD命令发送给逻辑层处理。单机模式下，CMD会存放到客户端的本地列表中，然后命令管理器会读取本地的命令列表来驱动逻辑层处理。战斗模式下，CMD命令会发送到服务器，由服务器广播给所有玩家，由玩家客户端的命令管理器驱动逻辑层处理。引入命令层（CMD层）之后，战斗逻辑层抽象而独立，开发者不需要关心当前的玩法模式，而且可以轻松复用，降低开发成本。

我们的PVP实时战斗采用c/s模式的同步架构，客户端进行碰撞检测，并将碰撞检测结果通知服务器，服务器验证并计算伤害，然后广播给其他玩家。游戏支持断线重连和客户端崩溃重连机制，服务器拥有战斗中的所有状态数据，重连时将所有数据发送给客户端，客户端还原战斗场景。

玩家位置同步采用基于时间戳的位置点同步算法，该算法最初在《空战》的双打模式和对抗模式中使用，《空战》的实时战斗采用UDP通讯，在《欢乐坦克大战》的环境中也取得了不错的效果，算法原理如下：

挑战

在开发过程中，我们遇到了很多挑战，但我们都一一解决了，具体遇到的问题如下：

1.微信小游戏平台增加动态代码执行限制

微信小游戏平台对动态代码执行增加了限制，如：eval('.log(1)')、new('.log(1)')、('.log(1)')等调用方法无法调用，但在 .6.1 源码中被大量使用。为了解决这个问题，我们与 cocos 引擎开发者沟通，并参考 cocos 1.7 版本（当时还未发布）中的改动，修改了部分源码，解决了这个问题。

2.微信小游戏不得超过4M

正如标题所示，微信小程序对尺寸的要求非常严格。为了解决这个问题，我们想出了很多解决方案。

措施一：定制引擎，去掉不必要的模块，减小引擎体积，这可以通过设置引擎模块来实现。

步骤2：图像压缩

使用PNG图像压缩工具可以有效减少PNG图像的文件大小（通常约减少60%-70%）。

即使采用以上两种措施，资源仍然会超出限制，所以只能采用动态资源下载的解决办法。

措施三：资源动态下载

我们给游戏添加了资源更新场景，游戏启动时，场景更新资源时不会创建游戏业务模块，而是在游戏场景中创建并初始化业务模块，然后再进行场景切换，具体方案如下：

1.首先下载一个资源更新配置文件，里面包含了需要下载的资源列表以及资源验证MD5信息。

2、根据资源下载列表，将验证MD5与本地文件进行对比，相同则不下载，不同则下载。

3.下载完成后进行MD5校验，如果校验不通过，则删除本地文件，重新开始下载流程。这里的MD5校验不仅可以验证资源下载是否正确，还可以防止资源被恶意修改，资源防作弊。

4、修改cocos引擎源码，在load-中将资源读取替换为读取本地下载的文件。

由于游戏运行过程中可能会出现 Bug，需要发布客户端补丁。资源更新配置文件可能会被多次修改，CDN 更新可能会有延迟，导致部分玩家下载旧版本的配置文件。另外部分中小运营商出于成本考虑，会缓存旧文件。在以往的项目中，出现这种情况时，一般都是联系玩家定位问题，如果发现是运营商问题，就会上报给运维人员，网络部的同事再去催促运营商进行修改，效率不高。为了降低这种情况发生的可能，我们使用了双 CDN 策略。

具体做法是，对同名文件增加版本号机制，更新文件时将文件内部存储版本号加1，在两个不同的CDN上更新文件，客户端下载时会下载两份文件，取版本号较大的那个。这样，更新配置文件时，只需要同步两个不同CDN中的其中一个，可以减少CDN更新延迟和运营商缓存出现问题的概率。

3. 性能优化

不同于一般游戏，微信小游戏平台本身的 js 脚本执行效率就比较弱。目前采用的 iOS 环境小游戏引擎，默认没有开启 jit 优化，js 执行速度会比手机慢一些，从简单的测试结果来看，速度会慢一倍左右。从 js 脚本执行时间来看，会占到 80% 左右。因此减少脚本计算量也是性能优化的重要方面。

小米6

游戏

微信浏览器

57.55

53

58

iOS小游戏

IOS微信浏览器

iOS

20

四十八

50

帧率测试对比

为了解决这些问题，项目组做了以下优化

渲染批次合并和大部分游戏项目类似，需要对同级使用的图片资源的图集、拼图的使用进行合理的规划。

可分为地图背景层、地表、地图物体、坦克、子弹、特效、UI等谜题。尽量保证同一层级的游戏物体使用同一张图集，相邻的精灵使用相同的材​​质。

面具

游戏中玩家的头像显示为圆形，而微信平台下载的头像为矩形，原有的头像显示采用 Cocos 的 mask 组件进行渲染，效率较低。我们自己实现了一个基于 mesh 的控件，将圆形划分为 n 个三角形，并给这些三角形的顶点分配相应的 UV，从而绘制出圆形的头像，减少了渲染头像时的 batch 开销。

影响检查

Cocos 自带的碰撞系统效率不高，没有做空间划分，不适合大量单位的碰撞检测。另外碰撞体的碰撞盒需要每帧更新。我们的游戏地图中存在大量静态物体（例如地图中的砖块、主基地、钢板等），当玩家在场景中移动时，通过移动摄像机，地图视图会发生变化，因此地图上大量静态物体的世界坐标不变，它们的碰撞盒只需要计算一次。

为了解决这个问题，我们给 Cocos 节点增加了一个属性，使得节点的计算结果可以被缓存，避免重复计算。

对象池

游戏中的坦克、子弹、砖块等都使用了对象池，在进入战斗场景时会预先加载足够数量的对象，并在战斗过程中重复使用，以避免实时创建和销毁对象。

避免场景和节点更新

分析源码发现，当一个节点出现的时候，会触发递归遍历的场景，开销非常大。

为了避免这种开销，游戏中物体死亡时，不是将其从场景中移除或禁用，而是通过将坐标移到较远的地方设置为死亡状态，代码中不执行相应的逻辑处理。尽量保持帧率稳定，避免性能曲线出现毛刺

裁剪

当物体超出主角的视野范围，且不是持续的特效或声音时，可以将其切断。

模型适配

美术资源分为高、中、低三个等级，策划在资源表中配置不同等级的资源名称，游戏过程中根据机器型号和实际表现选择显示某个等级。

图中横轴为时间（单位为秒），纵轴为FPS，可以看出FPS得到了明显的提升，通过一系列的优化措施，最终保证了低端机也能基本满足游戏的需求。

以上就是微信游戏《欢乐坦克大战》的开发总结，感兴趣的小伙伴可以过来一起交流一下~