文章正式开始之前，按惯例，还是先挖个坟：

《单挑篮球》开发过程文章发布当月，产品就在手Q小游戏平台获得了多次头部推荐，1年时间内累计玩家3000w+，同时也获得过抖音平台推荐位和入围首批微信小游戏优选计划，应该说成绩还不错，后续也推出了PVP真人对战，反响强烈，即便是在停更后很长一段时间，玩家群里依然热情不减，这也让我们对上线APP这件事增强了信心。

从小游戏到APP，绝不仅仅是移植这么简单，在小游戏平台上，优秀产品相对较少，中心化平台提供推荐位导流，好的产品很快便能脱颖而出，到了APP上，如何在竞争激烈的市场中杀出一条血路，是摆在团队面前一道难题。

为了让游戏有更强的可玩性和更好的视觉效果，项目组由原来的4个人，陆续扩充到数十人。经过一年多的打磨，《单挑篮球》在 AppStore 取得了体育榜第一的成绩。这中间的过程并不轻松。

公众号：Basketball_Duel

好了，广告发了，NB也吹完了，下面开始写干货了，我会围绕着：“在APP平台上，我们都有哪些设计上的改进”来写:

曾经我们认为在小游戏上做真人对战是个伪命题，吃力不讨好，但当游戏发展到4个2000人群的时候，真人对战的呼声越来越高，让我们重新审视PVP这个命题：

由于单挑篮球使用ECS结构开发，天然支持帧同步，所以我们确立了帧同步的方案，论坛有一篇大佬的科普文章，借花献佛：

帧同步游戏在技术层面的实现细节

在小游戏平台上，我们使用了腾讯云的联机对战平台（就是Creator工程模板里集成的那个MGOBE对战平台）。《单挑篮球》是 MGOBE 早期合作伙伴，早在2019年底 MGOBE 尚未正式发布时，《单挑篮球》就已经在配合腾讯云测试。我来说说使用感受吧：

瑕不掩瑜，作为专职开发小游戏十年的中老年程序员，我认为MGOBE确实是小游戏平台上的不二之选，可惜的是 MGOBE 要停止服务了。我们也会接入自己的对战平台。

开始APP开发后，我们用Go参照MGOBE写了一套联机对战平台，API命名一致，客户端无须做太大改动即可调通，我们平台的主要优点在于：

由于帧同步完全依赖客户端计算，就要求在游戏过程中两个客户端的演算结果完全一致，不然就会出现画面不同步的情况。

在小游戏版的单挑篮球中，由于我也是第一次做帧同步，经验不足，初上线的对战版本出现大量不同步的情况，经过排查，大致为以下几种原因：

由于帧同步依赖客户端演算，玩家是否出现不同步，服务器是没法知道的，所以不同步的排查只能依靠客户端日志来分析，我的做法是：

每隔一秒，双方各自将本端的战场关键数据组合后加密为md5发送给对方检验，如果出现不相等，则各自将自己的日志上报给日志服务器，服务器收到两个日志文件后，会生成一个文本比对页面（类似于beyond compare），并将链接发送给公司IM机器人，通过比对日志条目，来判断不同步的问题在哪里。

重连分为两种情况：

当客户端收到帧消息后，会将当前帧编号存下来，断线后，由于服务器并不会停止下发帧广播，所以重连后，中间会断帧，此时游戏逻辑不能继续，SDK必须发送请求补帧接口，将缺失的帧消息取回后插入帧队列，再转发至逻辑层驱动游戏进行，补帧的这一方在画面上会落后另一方，此时需要进行追帧操作，在逻辑层加速演算，将帧队列处理干净，画面自然就追上来了，追帧时，可以在1个dt内全部处理完，也可以每dt处理几秒的数据，让CPU喘口气，画面上能达到快进的效果。

游戏重启追帧与中途追帧流程基本相同，差别在于要恢复战场，且从第一帧追起，对于单挑篮球单局1~2分钟的时间来讲，从头追帧也并无太大压力。

APP版与小游戏的AI开发保持一致，仍然是BehaviorTree3。

冒着被毕业的风险，我贴一张高清的行为树图片出现讲解，以经典的11分玩法为例，我们先拆解一下行为树结构：

总体来说，行为树的设计类似流程图，把所有的分支设计好就行。

在小游戏中，以经典的11分玩法为例，10种难度级别我创建了10个行为树，每个行为树之间的差异极小，主要差别在于AI对行为的处理延迟和进入概率。

在APP上，策划要求对难度有更细腻的控制。假如有 100级难度，按原来的方法得创建100个行为树…这样显然不现实。解决方案是，在AI的每个具体行为的入口上设卡，结合配置表来控制行为的的概率和延迟。

在小游戏平台上，我们参考了Creator例子中的换装实现，即：用一个spine的slot上的attachment去替换另一spine上的slot上的attachment。

我们的用法稍有区别，所有的角色及初始皮肤还有套装皮肤都在同一个spine文件里，使用时，我先读取当前spine的getRuntimeData()，获得对应套装skin的实时数据，再取套装slot中的attachment替换当前角色skin相同slot下的attachment，太啰嗦了，贴段代码吧

随着角色越来越多，spine变得越来越难以维护，50个角色+20个套装在一个spine里，导出接近需要10分钟，输出的贴图也非常大，而且需要分页。

我想到将50个角色拆成50个spine，这又带来另一个问题：spine里有动画，50个spine就需要把动画copy50次，每新增一个动画就得同步到所有的spine，美术表示要吐血… …

绞尽脑汁后，我想到用组合新皮肤的方式来实现：

贴一段代码片段演示：

大家可能注意到这里 native 的 api 跟 js 的不一样，是因为 native 里有些方法和属性没有导出，比如 new sp.spine.Skin 在 native 上是会报错的，所以我们改了 spine c++ 下的 spine 运行库，如果大家能把我推到第一的位置，我就把修改的部分发出来（我太想要iWatch啦啦啦）。

好了，暂时写到这里了，再写下去，真得毕业了（其实是C姐催稿了），后续若有时间精力，会再补充一些开发经验分享上去。