《最强魔斗士》是由腾讯光子游戏工作室采用 Cocos Creator 3D 开发的一款画风精湛、玩法有趣的 3D 小游戏，近日腾讯光子开发团队接受了 Cocos 的专访，从策划、运营和技术多个角度，大方分享了游戏的开发经验，包括关卡设计、动画效果、角色换装、碰撞检测、资源管理和加载、性能优化等，相信能给大家带来新的思考和启发。
游戏亮点
游戏设计《最强魔斗士》沿用了当前非常火的弓箭类操作设计，移动虚拟摇杆即可控制角色移动躲避，停下来的时候会自动对敌人进行攻击。角色会发射子弹自动攻击怪物，省去了选择攻击目标、选择技能、进行攻击的步骤。这种允许玩家单手操作的方式，更适合广泛的休闲用户，同时又赋予了玩家一种 「Play to Win」的乐趣。 在玩家成就反馈上，用相对慢速但可永久保存积累的装备+秘籍系统，搭配每局战斗中临时获得的局内等级+技能，让玩家在局内大概 2 秒杀一怪、30 秒清一关、60 秒升一级、10～15 分钟通一关，能在游戏过程中体验到飞速成长的即时满足感。
游戏采用了 2D 场景 + 2D 弹幕 + 3D 怪物和角色的做法：
-
2D 场景的设计大幅降低了同屏的顶点数，一方面降低运行在 iOS 小游戏平台的性能压力，另一方面也留出足够的性能空间来丰富场景美术。所以我们可以看到和其他弓箭类游戏不同的是，《最强魔斗士》场景细节极其丰富，各种建筑、农田、树木都做得非常细腻。
-
2D 弹幕则是弓箭类的标准做法，这可以大幅降低碰撞逻辑运算的压力，使得游戏可以承载像「3 连发连弩 + 正向箭 + 斜向箭 + 左右箭 + 子弹折返 + 弹射」这样同屏存在七八十个子弹的轨迹和碰撞计算。
-
3D 角色和怪物，则方便做各种技能和换装，特别是换装及其背后的经济系统，这个毋庸多说。
专访实录
由于本次技术专访内容太过专访硬核，为保证阅读体验，我们将按照技术和策划分为 2 期来推荐哦，本期为技术向干货分享，下期策划向专访内容也在整理中，敬请期待。 游戏中丰富的关卡设计是如何提高制作效率的呢？ 我们有专门的小组开发关卡编辑器，除了实现传统的刷子等地表编辑功能外，还有一个更上层的抽象-岛屿，通过表格配置以及一定的随机规则，可在工具层自动拼接岛屿生成完整的关卡，这是支撑目前数百上千个关卡制作的重要能力。 游戏中丰富的动画和效果是如何制作的呢？ 这部分得益于 Cocos Creator 3D 本身强大的动画系统，我们所有动画都是美术在 Creator 里制作的，粒子系统和时间轴动画系统能满足所有需求，应用到程序里也非常方便。 角色换装是如何制作的呢？ 目前产品里的角色是由武器决定外观的，所以换装系统并不复杂，武器决定了主角使用的整个模型和贴图，不过同动作的人物形象是复用骨骼和动画的，这能节省不少资源量。 能否分享下我们在碰撞检测上做了哪些优化策略呢？ 复杂情况下有七八十个子弹和 10 个左右同屏的怪物，这个量其实不算很大，不过因为渲染已经消耗了一半的时间，再加上 iOS 下 JavaScript 解释执行的效率有限，所以还是遇到了一定挑战。 碰撞检测我们没有用物理引擎，为了简化运算，整个游戏里仅支持圆形和矩形碰撞体。障碍物首先对相邻的矩形进行合并减少碰撞体数量，然后用四叉树做空间规划，对每个子弹来说，每次参与运算的障碍物只有 0-2 个，所以这个消耗控制得很低。 更主要的消耗在于子弹和怪物的碰撞，这方面除了碰撞算法本身要简化到极致外，更重要的是从上层根据实际业务需求来复用子弹的运行路径和碰撞测试结果，从而达到大量减少运算的效果。 如何缓解同屏子弹和怪物数量较多时的渲染性能压力？ 怪物是 3D 模型，引擎的渲染性能已经很不错了，另外我们扩展支持了 GPU Instancing，某些情况下能有一定性能提升，目前在低端 iOS 上怪物渲染占了不到一半的帧时间，算是比较可接受的范围内。 子弹大多数为 2D 精灵，同屏精灵数量最复杂的情况下有数百个之多，在合理安排层级控制 drawcall 在 40 以下之后，引擎本身的渲染效率已经不错。
-
很大部分矩阵运算可以简化为坐标求和；
-
实现轻量的 active 功能以优化大量频繁的节点增删；
-
用定制的仅支持 Simple 模式的 sprite 渲染减少动态合批的运算量；
-
用静态合批优化不动的精灵渲染；
-
用懒渲染模式减少序列帧动画的消耗等。
Cocos 团队：v1.1 已经自带 GPU Instancing 支持，不仅支持静态模型，还支持蒙皮模型的 Instancing 合批。
游戏整体非常流畅，可以为我们分享些小技巧吗？ 资源管理和加载方面我们做了深度的定制，在不改动引擎原生实现的情况下，我们进入新手关卡需要下载超过 300 个文件，总体积在 9M 以上。而定制了文件组织形式和下载流程之后，进入新手关卡只需要下载约 15 个文件，总体积不到 2M。 资源定制的主要思路是把大量零散的小 json 合并成大 json，然后根据 prefab 的依赖关系把多个文件压缩成一个 zip 包，运行时下载这些 zip 包解压使用。 另外在关卡内战斗的时候，我们会利用空闲时间去下载下一关的 zip 包，从而达到更快的切换速度。 对 Cocos Creator 3D 的表现是否满意呢？ 目前来看对 Cocos Creator 3D 的性能表现是比较满意的，beta 版本缺乏的一些对性能特别重要的组件也已经陆续支持了，据了解 1.1 版本还会支持 GPU 粒子系统，把性能上留下的一块短板补上，这个是我们特别期待的。 至于性能优化方面，对于大型的复杂游戏来说，即使引擎的通用功能性能再好，都避免不了要定制化部分实现，从这个角度来说，希望 Cocos 引擎后续在用户定制与扩展方面提供更好的支持，这样能降低用户直接修改引擎源码的需求和维护成本，变得更加友好。Cocos 团队：v1.1 的粒子系统开始支持利用 GPU 运算能力进行模拟，大幅度提升运行性能，特别是在不支持 JIT 的 iOS 设备上，可以愉快地增加特效的使用啦。 最终为什么选择 Cocos Creator 3D 来制作呢？ 由于微信小游戏平台上的复杂 3D 游戏案例并不多，所以技术选型是我们特别慎重的事情。 项目在选型阶段花了接近一个月时间，预研了多个现今市场上支持 3D 渲染的H5引擎，并且分别用 Cocos Creator 2.5D 版本，Cocos Creator 3D beta 以及 LayaBox 2.0 引擎实现了原始 Demo，做了详细性能测试。 对比了开发流程、技术支持和运行性能的各方面因素，发现 Cocos Creator 3D 在前两者有明显优势，性能上也基本持平，所以成为了我们的首选。 是否有计划发布到原生平台呢？ 目前我们也构建了安卓 App 版本，运行性能高非常多，不过暂时没有发布计划，从能力上来看 Cocos Creator 3D 是能满足跨平台需要的。 Cocos 团队：原生性能一直是我们非常重视的关键指标，开发者们可以尝试把自己的游戏发布到原生平台，可能会有惊喜哦。 对于各个岗位上手 Cocos Creator 3D 是否有什么建议呢？ 在 Cocos Creator 3D beta 版本阶段，引擎和工具在稳定性以及易用性上面有较多不足，不过随着版本迭代，我们能感受到引擎的进化非常快，对 bug 的响应及修复都非常敏捷。 目前到了正式版阶段，我们开发团队认为问题不多了，引擎运行层面比较稳定，主要是编辑器方面的稳定性希望进一步加强。 Cocos Creator 3D 和 2D 在工作流体验上是否有差异呢？ 非常接近，涉及 3D 的部分需要看一下文档，其它方面可以无缝切换。 如何评价 Cocos Creator 3D 的整体使用体验呢？ 功能丰富性能强大、使用上很简单符合过往经验，IDE 集成度高，对团队协作支持得很好，代码开源对性能分析和优化很友好。建议方面还是集中在编辑器，希望有更高的稳定性和扩展能力，进一步提升开发效率。 
