技术派第6期|重度小游戏《三国封魔传》技术实现方案
在 3 月 29 日结束的 Cocos 开发者沙龙北京站的现场，来自北京饭团网络科技有限公司的工程师凌风，以公司旗下卡牌策略重度小游戏《三国封魔传》为案例，从游戏产品架构设计、产品本身战斗机制、开发过程中遇到的技术难点及解决方案三个方面，向与会开发者分享了重度小游戏产品的技术实现方案，引起了在场开发者的热烈讨论。
今日，Cocos 将凌风的演讲内容整理成文，没有去到沙龙现场的开发者也可以了解技术干货啦！
一、游戏介绍
《三国封魔传》采用卡牌回合对战的玩法，三国题材写实画风，经典武将和装备养成系统，游戏内置丰富的剧情和资源副本，另外还有世界BOSS、爬塔、剿匪、工会战、跨服战等特色玩法，武将搭配，阵容布置，技能克制等重要技巧都是胜负的所在，十分考验玩家对游戏的理解和认知。
目前已在微信小游戏等平台上线，获得许多玩家喜爱。在当前版号难得的情况下，这款小游戏版号资质齐全，这也就意味着，游戏除了广告变现之外，还可以开启内购付费变现。
根据游戏制作人的介绍，目前游戏内自然增长渠道的付费用户 ARPU（ARPPU）截至目前已突破 70 元，且仍在不断攀升，用户付费渗透率较高，随着产品质量的不断打磨精进、后期运营的不断深入，上述数据有望再提升 3-5 倍。
二、技术实现方案
工程师：凌风
《三国封魔传》是一款基于 Cocos Creator 制作的卡牌回合制游戏，产品类型和市面上前两年流行的卡牌回合制游戏很相似。预计主要发行于各厂家的小游戏平台和各种快应用平台，目前在微信小游戏和头条小游戏可见。游戏的特点：融合了推本，爬塔，PVP，BOSS 战，剿匪以及众多的养成链。
传统的卡牌游戏，很多使用 CocosStudio + lua 开发，本产品则是使用 Cocos Creator+ts 制作。
这样完美实现跨平台，支撑运营方针对于各种平台及快应用都能得到推广。
产品在技术上的立意是：
（1）产品在技术上需要保证在微信小游戏平台上和 H5 平台上流畅运行；
（2）产品需要在技术上达到和手游相近的体验；
（3）产品需要有足够多的承载力，就要求产品功能做的足够多，对程序提成的支撑也更重要。
基于此，我们从以下几个几点进行分析：
- 架构设计
- 战斗机制
- 技术难点及解决方案
架构设计
本产品采用 MVC 模式，数据层逻辑层控制严格分离。相互之间以观察者模式进行消息通信。
这个架构的优缺点：
优点：耦合性低，重用性高，部署快，可维护性高，方便管理。提高开发效率，降低开发难度。
缺点：增加了系统结构和实现的复杂性，需要额外花费精力维护，不适合小型程序，易影响运行效率。
注意：如果是一个代码量有限的小型休闲游戏，不建议使用，直接回调+单例生写效率会更高。
在组件式的 Creator 中应用 MVC：
- 表现层（View）：游戏画面，UI
Creator 的表现层主要由各种 Scene 和 Prefab 组成。各节点可以挂在多个脚本，消息的监听挂载到各个组件的脚本上面。组件销毁的时候同时销毁监听的消息，组件上各种挂载的节点逻辑尽量分离，这样相对比较清晰。 - 逻辑层（Controller）：数据接口，操作控制，AI
- 数据层（Model）：数据保存，图片、声音等资源
基础类模块：
（1）网络层
长链接采用 websocket + protobuf，短链接采用 Http，具体自己封装就好。
（2）通信消息层
用于游戏内部各模块之间的通信。值得注意的是 Creator 组件式开发的特点，当组件销毁的时候，最好同时清除这个组件上监听的消息，以防止不必要的麻烦。
（3）UI 管理层
游戏内部的 UI 实太多，各个创建和销毁如果任由工程师去随意创建和销毁，那将是一场灾难，因为你不知道你的内存什么时候就爆掉了，所以这个管理很重要，处理的时机方式也很重要。
（4）模块工具包
包含各种基础的算法和工具方法以及一些基础的程序管理及加密、SDK 的嵌入方式等等。
战斗机制
回合制卡牌游戏的开发核心是战斗，这个处理起来还是很繁琐的。
这种游戏有几个共性，分别是：
（1）战斗场景，无论是玩家对玩家 或者是 玩家对 NPC 这些战斗场景都是一个载体。
（2）战斗单元，玩家对手玩家 NPC 都是一个战斗单元。
（3）战斗站位，不同的游戏有九宫站位、六宫站位等等。
（4）行动顺序，各战斗单元的出手顺序。
（5）战斗行为，普攻，奥义，还是其他的反击格挡等等以及单元受到攻击行为之后产生的被动行为。
（6）各种减益/增益状态的处理，中毒，燃烧，眩晕等等。
（7）行为结果判定，各种伤害数值的显示。
战斗机制的实现：
战斗机制分为两种 ：一种是服务器算好，客户端根据战斗流程去播放；一种是客户端根据一些数据自己编写战斗逻辑并上报服务器。
本产品从战斗的流畅度来考虑，选择战斗机制在客户端去实现，服务器参与数据的计算和验证存储等等。
回合制的流程控制机制:
包括轮询刷新和帧刷新两种机制，这两种方式的都是可以的，但需要注意帧刷新的控制，不要因为帧率过快影响战斗单元的出手。
轮询刷新相对而言是比较可控。
帧率刷新的时候需要对每个战斗单元进行刷新。
轮询刷新的时候可以根据自己的主流程控制去设定战斗单位的各种状态。
战斗的流程控制：
（1）回合制战斗流程首先要确定出手顺序，向策划索取，并能动态更改。
（2）每个战斗单位的出手需要选择相应的出手时机，出手技能，出手之后被攻击方的反应以及己方是够有协同等等。
（3）战斗单位表现形式，我们的产品并不是一张静态的卡片，而是一个骨骼动画。虽然占用的资源多一些，但是借助于 Creator 对于骨骼动画的支持和性能的优化，在微信小游戏上运行非常的良好。
骨骼动画和帧动画的区别相信大家大家都很清楚，而且卡牌游戏由一代向二代过度的时候也逐步的有静态的图片转向更为生动的骨骼动画。
骨骼动画氛围龙骨和 spine，我们一般都使用的 Spine，在这里不一一赘述。
（4）战斗技能的选取以及技能形象的表现，这个需要由配置表来配置，这样可以更加的灵活，不然后期就是一场灾难。另外技能的使用的释放不要频繁的是创建和销毁。会增加开销和发热量。这个地方一定要进行管理一下。
每个战斗单元和战斗的技能也不是绑定的，要达到任意一个技能都可以通过配置绑定到任何一个人物身上，这样如果发生变化通过配置表可以相当灵活的去调整。
（5）战斗技能的播放，同时指定的攻击对象要做出相应的回馈受击的动作，如果系统里面有协同性的动作还要考虑协同的动作。
（6）攻击之后就是各种动态数值的计算，这个和战斗实现的机制有关系，如果你是服务器计算好的，客户端负责按照固定的模式去播放，那么加上随机因子去播放就好；如果你是客户端根据相应的参数去计算，那就客户端自己控制，这个需要自己把控。
（7）各种伤害和效果的展示，以及加速和减速等特效的增强。
技术难点及解决方案
1.资源压缩
资源压缩是做 H5 游戏或者微信小游戏一件重要的事情。
在追求精品化的时代，保持产品精美话的同时又要保持资源的大小和流程度确实不是一件容易的事情。我们压缩主要采用 pngquant，而后采用 pngout 再次压缩。由于我们精细度很高，所以压缩比不是很失真。
我们的游戏压缩之前大概 150m 以上，在压缩之后我们成功降低到了 30+m，这样在微信小游戏要求 50m 缓存的情况下，已经比较完美了。
2.内存控制
在控制完资源大小之后，内存大小也是需要特别注意的地方，微信小游戏毕竟是内嵌的游戏。由于游戏做的很重，所以势必很吃内存，甚至可能在一些苹果机上打不开游戏的现象也是存在的。
所以在内存的优化处理上要特别注重，当前是我们处理的方式主要还是研发的时候加强控制和及时释放已经不用的资源，不要让一个东西长存太久。
3.加载控制
英雄骨骼动画和配置文件以及 UI 的加载。
配置文件是要提前加载到内存中的，这个是没有办法的，因为游戏里面随时要用。骨骼动画可以后加载，用到的时候再异步进行加载。
当场景切换的时候可以适当析构掉不用的资源。
另外延迟加载可以提高界面打开的效率，让玩家体验良好一些。
分帧加载可以让界面更加流畅，这些都是需要注重的。
4.微信小游戏支付
支付的钱一定要以微信存管账户为准，客户端只通知查询的时机,以防止外挂刷。
5.探讨技术点：首帧加速加载
小游戏在加载完成三个点的时候，进入首场景，有些平台要求这个过程要很快，所以地方处理起来并不是很容易，这也是我们研究的一个点。
5G 的发展和娱乐的多样化，为我们提供了更广阔的空间，希望我们能有更多的空间可以去开拓。在此感谢 Cocos 引擎团队的支持和厚爱，感谢我的团队所有伙伴。
欢迎各位开发者扫描下方二维码体验这款重度小游戏《三国封魔传》。
技术派，是 Cocos 全新推出的专栏，我们将不定期邀请知名的游戏制作者，为广大开发者分享来自真实项目的实用的开发技术和实战经验。欢迎大家推荐想要学习的游戏产品和想要了解的技术知识，也诚邀有技术分享意愿的开发者联系我们噢~
更多精彩
Cocos 技术派 | 实时竞技小游戏技术分享
Cocos 技术派 |《野蛮人大作战》从开发到上线
Cocos 技术派 | 推荐一款可查看节点树的插件 CC_inspector +
Cocos 技术派 | Cocos Creator 2.0 摄像机的灵活运用
Cocos 技术派 | Camera 摄像机详解
创意小游戏专访 | 《蛇它虫》
创意小游戏专访 | 《五子大作战》
创意小游戏专访 | 《甜蜜糖果屋》
文章被以下专栏收录
