从小游戏到APP，登顶iOS排行榜，这款PVP竞技篮球手游都做了些什么？-CSDN博客

本文链接：https://blog.csdn.net/weixin_44053279/article/details/129563264

2019年，在市场上大部分篮球小游戏都只是「纯投篮」玩法时，一款主打 PVP 实时 1V1 对抗的休闲竞技小游戏《单挑篮球》让玩家眼前一亮，上线微信、QQ、头条等平台后的1年间累积玩家达到 3000W+。

小游戏版的优秀表现坚定了研发团队上线 APP 的信心。经过近一年的打磨，手游版《单挑篮球》日趋成熟、厚积薄发，在近期登上了 AppStore 游戏体育榜第一名。

不管是小游戏版还是原生版，《单挑篮球》都使用了 Cocos Creator 进行开发。原生版和小游戏版有什么不同？都做了哪些改变或优化？本次，《单挑篮球》主程、来自武汉心驰神往（SAGI GAMES）的「蟹老板」，将和我们分享游戏从小游戏到 APP 的「进化」经验与心得。

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

着手开发原生版后，为了让游戏有更强的可玩性和更好的视觉效果，项目组由原来的4个人陆续扩充到数十人。技术层面上，我们从 PVP 对战实现与优化、AI 行为树的设计和难度配置、Spine 换装系统的改进及进阶技巧等方面对游戏进行了全面的优化，让手游版《单挑篮球》在原生平台上拥有更高品质表现。

PVP 对战

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

传统 io 类小游戏，由于一局参与人数多，成局困难，即玩即走，没有数值成长，用户粘性低，做 PVP 确实不划算；
《单挑篮球》主打 1v1 战斗，玩家可以通过分享卡片约战，成局率高，角色有数值成长，有养成要素，做 PVP 完全可行。

由于《单挑篮球》使用 ECS 结构开发，天然支持帧同步，所以我们很快确立了帧同步的方案，具体可参考社区大佬的这篇科普文章：《腾讯高级工程师宝爷：帧同步游戏在技术层面的实现细节》。

在小游戏平台上，我们使用了腾讯云联机对战平台（MGOBE）。《单挑篮球》是 MGOBE 早期合作伙伴，早在2019年底 MGOBE 尚未正式发布时，《单挑篮球》就已经在配合腾讯云测试。作为专职开发小游戏十年的中老年程序员，我认为 MGOBE 瑕不掩瑜，确实是小游戏平台上的不二之选，可惜的是 MGOBE 要停止服务了，我们也会接入自己的对战平台。

开始 APP 开发后，我们用 Go 参照 MGOBE 写了一套联机对战平台，API 命名一致，客户端无须做太大改动即可调通。在编写平台时，我们重点关注了以下几个方面：

分布式加自动弹性部署：当峰值突然陡增的时候，会自动部署新服务器以适应变化，峰值降低后会自动回收降低服务器成本。
协议压缩：将角色的操作指令用一个字节表示，同时对其他协议也尽可能精简。
同时支持 tcp 和 udp：由于 udp 有冗余指令，当网络不好时，消息包会积压，对低端手机不太友好，所以针对低端手机连接对战服，仍然使用 tcp 方式。
详细的日志及监控工具。

对战不同步的问题

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

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

浮点数的问题：0.3+0.4=0.7，可0.7-0.4!==0.3，尽管做了取整或保留2位小数的操作，但也总有遗漏。
入参不一致的问题：为了实现双方角色都以左视角进行游戏，我在对战初始化时，对角色数据作了翻转，对战指令也作了翻转，导致运算中两端的入参其实是不一致的，运算时要取反处理，导致大量浮点数问题。
战场复位的问题：前一场战斗结束后有些数据未清除干净带入下一场导致不同步。
运算顺序不一致的问题：谁先碰到球？

解决办法如下：

逻辑上房主永远在左侧、房客在右侧，但房客端将 UI 进行翻转，以达到视觉上在左侧的要求。
优化战前及战后的数据清理逻辑。
检查逻辑上的 bug。

这里还有一个很重要的问题：如何在线上运行的过程中发现玩家出现不同步的情况？

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

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

重连与追帧处理

重连分为两种情况：

游戏过程中断线重连。
游戏异常退出后重连（需恢复战场）。

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

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

PVP 其他经验

FPS 帧数：由于网络消息处理也在引擎主循环里排队处理，如果游戏本身性能优化不够好，FPS 过低，会影响到对战质量，建议 FPS 至少>55。
AI 介入：游戏中玩家经常会碰到一方因大比分落后而弃赛的情况，就需要 AI 介入，保障玩家体验。因帧同步服务器服务端没有逻辑只做转发，所以 AI 介入目前是由客户端自己实现的。当我端检查到对方掉线后，我端会给对手赋上 AI 行为，AI 的所有操作会以「对方的身份」向服务器发送行动指令，这样能保证对方重连后追帧正常。

AI 行为树

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

设计思路

角色在场上有三种状态：进攻/防守/均未持球。行为树设计即围绕这三种状态展开：

进攻时，要做什么？

判断所能做的操作？发技能/上篮/扣篮/突破/投篮（角色使用了有限状态机）。
判断与篮球的距离（不同的距离出手概率不一样）。
起跳到什么阶段出手？

防守时，要做什么？

逼近对手。
是否抢球。
对手起跳了，我要不要跟随起跳盖帽？

无球时，要做什么？

球在空中么？在的话是否争球？
球在地上么？赶紧去捡吧！

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

难度控制

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

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

Spine 换装系统

多角色多套装的换装思路

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

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

changeCloth (skinName: string, slotName: string): any {
    let spine: sp.Skeleton = this.node.spine
    let skeletonData = spine.skeletonData.getRuntimeData()
    let skin = skeletonData.findSkin(skinName)
    const slot = spine.findSlot(slotName)
    const slotIndex = skeletonData.findSlotIndex(slotName)
    const attachment = skin.getAttachment(slotIndex, slotName)
    slot.setAttachment(attachment)
  }

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

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

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

将 spine 拆分为三个，base.spine / skin.spine / suit.spine，作用分别是：

base.spine 里有动画定义和基础三色皮肤（黑皮肤/白皮肤/黄皮肤）的四肢，但不带脸部贴图；
skin.spine 里配有角色的脸部和基础外观；
suit.spine 里是套装定义。

new sp.spine.Skin 一个 skin 出来，先 copy base.spine 里的肤色皮肤，再从 skin.spine 里取出角色皮肤叠加到 newSkin 中，最后再从 suit.spine 里取出套装部位的 attachment 再一次叠加到 newSkin 中，最终形成一个新的 skin，添加到场上角色的 skins 中，再 setSkin(newSkin)，即可产生新的外观。
注意一个前提，三个 spine 的 slot 结构要完全相同，顺序相同，这样覆盖时才不会出现 bug。

贴一段代码片段演示：

export default class SpineUtil {
  static async setSkin (spine: sp.Skeleton, heroId, skinId, collocation = {}) { // posType 1头饰 2上衣 3裤子 4鞋子 5手部 6腿部
    const skeletonData = spine.skeletonData.getRuntimeData()
    const baseClothesData = await AssetLoader.loadResAsync(`spine/clothes/c_${heroId}/c_${heroId}`, sp.SkeletonData)
    const baseClothesDataRuntimeData = baseClothesData.getRuntimeData()
    const baseClothesSkin = baseClothesDataRuntimeData.findSkin('c_' + skinId)
    if (!baseClothesSkin) return

    let newSkinName = 'newSkin' + heroId + skinId
    for (let pos in collocation) {
      newSkinName += '_' + collocation[pos]
    }
    const newSkin = new sp.spine.Skin(newSkinName)
    const { SkinColor } = app.db.actor.GetActorById(heroId)
    const findSkin = skeletonData.findSkin(['white', 'yellow', 'black'][SkinColor - 1])
    newSkin.copySkin(findSkin)

    // 使用默认外观
    for (const skinEntry of baseClothesSkin.getAttachments()) {
      const slot = !cc.sys.isNative ? skinEntry.slotIndex : baseClothesSkin.getEntrySlot(skinEntry)
      const name = !cc.sys.isNative ? skinEntry.name : baseClothesSkin.getEntryName(skinEntry)
      const attachment = !cc.sys.isNative ? skinEntry.attachment : skinEntry

      this.addAttachment(SKIN_PART, newSkin, slot, name, attachment)
      this.addAttachment(ARM_PART, newSkin, slot, name, attachment)
    }
    
    ... 省略部分代码
    
    if (skeletonData.skins[skeletonData.skins.length - 1].name === newSkin.name) {
      skeletonData.skins[skeletonData.skins.length - 1] = newSkin
    } else {
      !cc.sys.isNative ? skeletonData.skins.push(newSkin) : skeletonData.addSkin(newSkin)
    }

    spine.setSkin(newSkinName)
    }
}

大家可能注意到这里 native 的 api 跟 js 的不一样，是因为 native 里有些方法和属性没有导出，比如 new sp.spine.Skin 在 native 上是会报错的，所以我们又修改了一下 spine c++ 下的 spine 运行库。

Spine 的一些其他技巧