观察 |一上就爆红，冲500万在线，这家广州公司下了多少

整理 | 二师兄下载 | 西泽步

9月6日，2024年腾讯全球数字生态大会游戏专场在深圳国际会展中心举办。

会上，库洛游戏CTO林晨晨分享了《鸣潮》上线前后的研发实践经验，以及他们在全球部署、全平台开发和同版本维护等方面的解决方案。

据林晨晨介绍，他们在项目初期就给《鸣潮》定下了500w PCU（最高同时在线人数）的目标，并且最后真实跑起来500万个机器人对服务器集群进行压力测试。

（库洛游戏CTO林晨晨）

以下为林晨晨演讲全文，为方便阅读，部分内容有所整理与删改：

大家好，我是来自库洛游戏的林晨晨，《鸣潮》是我负责的第三个项目。《鸣潮》是一款开放世界的动作游戏，战斗硬核、角色细腻、Boss战斗有特色，游戏整体体量比较大。

在《鸣潮》的研发和运营过程中，我们遇到了两个重大挑战：第一是实现全球全平台同版本上线；第二是开放世界游戏本身的研发复杂度。

接下来，第一个挑战我将从三方面与大家分享我们的做法。

先来说全球部署。《鸣潮》主打动作，极限闪避、弹刀和协奏反应等玩法都对操作手感和延迟非常敏感。我们的设计目标是让玩家在120毫秒延迟下也能流畅地游玩。

《鸣潮》采用了大单服的架构。简单来说，就是我们希望一个服务器集群能够覆盖尽可能广的范围。在进行全球部署时，我们需要重点考虑延迟对游戏体验的影响。

根据玩家的分布情况，我们选择了全球六个城市（中国上海、中国香港、新加坡、日本东京、德国法兰克福、美国弗尼吉亚）进行服务器部署，以确保物理距离能够满足低延迟的要求。从实践结果来看，这种部署方式保证了全球玩家的游戏网络质量。

接下来我想谈谈全平台开发。我们认为，全平台适配并实现互通互联是对玩家最友好的游戏接入方式。无论是在客厅的主机、沙发上的平板，还是外出时的手机，玩家都能找到最适合当前环境的游戏体验方式。

要实现一个工程打包全平台，就需要对工程进行一些规范化处理。得益于Unreal引擎的支持，我们可以抽象出各个平台差异化的接口，进而在业务层面保证游戏的设计和逻辑在全平台的通用性，适配不同的构建管线以产出对应平台的游戏包。

最后是全球同版本的问题。有过相关经验的同行都知道，版本管理的工作非常细碎且容易出错，而且不同版本对游戏也没有实质性的增益。如果玩家只能玩到半年前的内容，新鲜感肯定是不足的，因为内容会有一定的失效性和磨损。

但如果采用同版本策略，就可以让团队的目标更加一致，更聚焦于解决问题。同版本下，反馈是及时的，问题也是统一的，同时还能减少维护多版本的压力。但是，用同一个版本去服务海量用户，对游戏内容有着严格的要求。

我们在技术层面上就遇到了几个痛点，包括语言语音的适配切换、多语言界面的适配以及语言本地化的流程管线等等。在内容方面，我们需要考虑不同地区玩家的文化差异；在玩法、剧情、游戏体验等方面，我们又需要找到它们的交集，以创作出受众面更广的内容。

第二块要讲的内容是《鸣潮》在研发复杂度方面的话题，这部分的涉及面很广，我准备通过两个具体案例来进行分享。一个是我们做得相对顺利的500万同时在线，另一个则是做得不够好的客户端性能适配。

如果有了解库洛上一款产品《战双帕弥什》的朋友，就会知道它在上线初期遇到了比较严重的炸服问题。吸取这些经验教训后，在《鸣潮》项目初期，我们就定下了服务器要达到能够支持500万同时在线的标准，从上线情况来看，也确实需要做到这个量级。

要达成这个标准，我们首先是依托腾讯云基础资源的支撑，丰富的服务器资源让我们在遇到情况时都能及时响应。此外，我们还要解决集群本身的横向扩展能力，这是关键所在，而且无法依赖任何外力。让集群实现横向扩容主要有两个工作方向。

第一个是数据库的横向扩容能力。我们使用MongoDB作为数据库，所有的库表都采用分片集群的方式。通过合理设计分片键，我们可以将读写压力分散到各个分片上。

第二个方向是逻辑服务器的横向扩容。我们努力做到整个集群无单点，所有的业务都可以通过横向扩容来增加算力。这就需要从每个具体的业务逻辑入手，解决单点瓶颈问题。

在2023年第一季度春节前，500万同时在线就被定为服务端优先级最高的目标。

我们通过压测结果中的PCU数据来量化这个目标。压测工作除了服务端，还需要高性能的客户端发压工具。在这方面，WeTest的发压框架给了我们很大的支持，只需要填充压测逻辑就可以了。

如何模拟玩家真实的游戏过程是另一个难点，单纯靠构造协议的比例来模拟是不够真实的。因此，我们做了一套录制真实游戏过程的方法。

以“录包回放”的方式，我们可以直观地看到视频效果，从而结合CBT线上测试玩家的真实游戏情景占比做推论。通过按照比例混合不同情景的录包来模拟开服状态，这种方式得出的结论与上线的真实情况是比较接近的。

在压测过程中，我们也发现了很多问题。

简单列举几个，比如MongoDB的BSON增量更新不如全量覆盖、入库逻辑需要流速控制来主动保护数据库、服务端使用的托管内存语言导致GC问题比较多、需要做大量的内存优化工作（如对象复用）等等。

我们第一次完成压测的用时接近一年。

接下来，我想分享一个我们做得不够好的案例，也就是客户端的性能适配。

在全平台发行的需求下，我们需要适配各种设备，其中既有2017年上市、距今已有7年历史的骁龙835手机（如小米6），也有最新的RTX 4090 PC，而这些设备之间的性能差距超过百倍。

如何让不同设备的用户都能获得与其设备相匹配的游戏体验，这对技术工作提出了很高的要求。

《鸣潮》上线初期我们收到了非常多的手机端负面反馈，掉帧、发热、闪退、画面不清晰......经过深入反思，我们发现问题出在两个方面：

一是缺乏有效的发现和量化问题的工具和方法；二是测试环境过于理想，无法代表玩家的真实情况。拥有好的量化问题的方法是我们解决问题的关键。

在观测和量化线上性能数据方面，PerfSight是一个成熟的工具。

它可以获取每一个玩家真实的游戏过程，从机型、CPU、GPU、发热、功耗、卡顿、内存等多个维度进行分析，准确找出当前问题的关键点在哪里，以及将精力投入到哪里是最有效的。这样就可以减少个别反馈的干扰。

在找准瓶颈后，我们采取的方法是快速迭代、小量验证。

我们有一套灰度外放的策略，在修复完问题后，通过客户端热更新的方式，按照各种维度的比例进行外放。我们会在小范围内观察并验证效果，然后再逐步放量。这样可以达到快速迭代、稳定落地的目的。

在客户端性能适配工作中，有两个收益比较大的例子。

第一个是时间预算管理。对于60帧的游戏来说，每一帧可用的时间是固定的，大约是16.6毫秒。在这个有限的时间内，我们需要一个调度系统来管理，找出什么逻辑在其中运行能够达到最佳的性价比。

第二个例子是超分辨率技术的应用。通过降低渲染分辨率，我们可以有效减少计算量，从而降低发热，但这会带来画面糊的问题。采用超分辨率算法，则可以将低分辨率的输出结果转换为更高分辨率的画面。

在不同平台上对应采用不同的方法，通过持续调优，最终在画面质量和性能之间达到一个合理的甜点值。

我们做了一系列优化之后，突然有一天《鸣潮》的性能优化话题登上了微博热搜，还是挺感慨的。这也是持续的量变引发质变的结果：我们所做的所有工作，玩家都是能够看得见的。

最后，站在今天回头看《鸣潮》的研发过程，整体还是比较曲折的。我觉得多做减法、保持聚焦、直面问题、拆解节点、量化进度、定时复盘，是我们能够成功做出这个项目的关键。

今天的分享大概到这里，谢谢大家！