库洛游戏CTO林晨晨
9月6日,2024腾讯全球数字生态大会游戏专场在深圳国际会展中心举办。
会上,库洛游戏CTO林晨晨分享了《鸣潮》上线前后,项目组在服务器承压、性能优化、全球同步发行、兼容适配方面的研发经验。
林晨晨表示,《鸣潮》项目初期,他们就定下了500万PCU(最高同时在线玩家人数)的框架目标,最终花了一年时间才给游戏塞入了「500万个机器人」,用比较暴力的方式完成了服务器承压的测试目标。
以下为林晨晨分享原文,为照顾阅读体验,部分内容有所删改:
大家好,我是来自库洛游戏的林晨晨,《鸣潮》是我们的第三个项目,它在研发和运营过程中有两个比较大的挑战:一是全球全平台同版本上线怎么做;二是怎么处理开放世界游戏本身的研发复杂度。
首先全球、全平台同版本是我们立项之初决定的发行策略。
该策略首要面临的问题,是如何处理网络延迟,让全球玩家在合理的延迟内进行流畅的体验。
《鸣潮》是一款主打高速战斗的动作游戏,玩家需要流畅地做出极限闪避、弹刀、协奏等操作,因此我们把游戏网络延迟目标设置为120ms以内,这对于游戏服务器之间的物理距离要求较强;
但同时,《鸣潮》为了后续全球同步上线和更新,其服务器是一个全球大单服的结构,不能无限制地在全球部署,需要平衡延迟和单服务器覆盖范围。
我们根据玩家分布情况、物理距离等因素,选择了中国上海、中国香港、新加坡、日本东京、德国法兰克福、美国弗吉尼亚六座城市部署服务器,让全球玩家的网络质量得到保证。
其次是全平台开发。我们认为全平台适配和互通,是对玩家最友好的游戏方式。玩家在不同环境下,都能找到最适合的体验方式,比如在客厅里选择主机、电视端,在沙发和床上选择平板,外出时选择手机。
因此,我们就需要一个相对规范的工程文件,可以打windows、iOS、Mac等全平台的安装包。UE引擎在这方面提供了不错的支持,它本身支持多平台安装包体的输出;其次,我们在各大平台的结构层制作了一个抽象接口,保证我们做的逻辑和设计,可以在全平台通用,适配不同的管线。
最后是全球同版本。相信做过多支管理的朋友都知道,这是一个非常细碎、很容易出错的工作。
比如我们在多支管理工作期间,发现玩家不仅会对游戏的更新策略产生争议,还容易因游戏版本更新相对更慢,而失去新鲜感——如果更新时间相差半年,就会导致更新慢的用户,已经在其他各种媒体渠道看过相关内容了,进而对新版本失去新鲜感和兴趣。
如果能做到全球同版本,不仅能解决上述内容新鲜感丢失的问题,也能让项目组减少维护多版本的压力,保持一致的目标,聚焦解决问题,获得及时、统一的玩家反馈,刺激我们做出更高要求的内容满足全球玩家。
当然全球同版本也有不少痛点,包括技术层面的语言语音适配切换、界面适配、本地化的流程管线;用户层面的文化差异、玩法/剧情体验的需求等等……我们尽量取全球用户诉求的交集,做受众面更大的内容。
第二块要讲的,是《鸣潮》作为开放世界游戏的研发复杂度,这个话题很宽泛,我具体分享两个案例:500万同时在线的抗压测试、做得不够好的客户端性能适配。
如果关注我们上一款产品《战双帕弥什》的朋友,可能也知道它在上线时。遇到了比较大的服务器崩溃问题,因此我们在《鸣潮》项目上非常慎重地对待服务器承压问题,在项目初期就定下了要支持500万人同时在线的目标——从后来的上线情况来看,确实需要做到这个量级。
我们的解决方案首先是依托腾讯云的基础资源支持,包括六个城市的服务器部署、各种问题的及时响应;
其次是提升集群横向扩容能力。这一方面指数据库的横向扩容:我们利用MongoDB,以分片集群的方式,让读写压力合理地分散在每个分片上;另一方面是逻辑服的横向扩容:我们做到了整个集群没有任何单点,所有业务都可以横向扩容算力,解决单点瓶颈。
做好扩容准备后,我们在2023年春节期间,开始推进500万PCU的压测目标。
首先我们发现光优化扩容还不行,压测还需要更高效的发压工具,能快速制造500万个机器人,在这方面WeTest的发压框架,给了我们比较大的支持,只需要填充压测规则就可以,不用额外关注发压本身的细节内容。
其次,我们需要模拟真实的玩家行为。让服务器能最大限度地承载500万玩家的各种操作行为和体验场景,因此我们录制一整套真实游戏的过程,再结合过往CBT测试玩家真实场景来混合测试,模拟游戏开服状态——从结果来看,《鸣潮》开服的承压状态跟测试结果基本一致。
我们在压测过程中,也发现了很多问题。比如MONGO Bson增量更新不如全量覆盖、入库逻辑需要流速控制主动保护DB、我们服务端用的托管内存语言的问题比较多,需要做大量的内存优化工作、对象复用……最终我们完成500万同时在线压测目标,是在2023年12月14日,基本上用了一年时间,而且还是用比较暴力的方式冲到了这个数值。
另一个案例性能适配我们做得不够好。
首先在全平台发行的需求下,《鸣潮》需要适配设备既有2017年上市、距今7年的骁龙835芯片的手机,例如小米 6;也有最新的、安装了4090显卡的电脑,他们之间的性能差距远超过100倍,如何让不同设备的用户,都能有匹配当前设备的游戏体验,对我们的技术工作提出了比较高的要求。
后面《鸣潮》测试和上线时,我们听到非常多的移动端负面反馈,掉帧、发热、闪退、画面不清晰等等,我们深入反思下来有两方面原因:缺乏有效的发现和量化问题的工具方法,更多依赖于客服反馈;测试环境过于理想,不能代表玩家对游戏帧率设置、游戏操作、体验场景等真实情况。
好的量化问题方法,是我们解决问题的关键。在观测和量化线上性能数据方面,Perfsight可以获取每一个玩家真实玩游戏的过程,能从机型、CPU、GPU 、 发热、功耗、卡顿、内存等维度分析,找准当前问题的关键点在哪里,精力投入在哪里最有效,减少个别反馈的干扰。
在找准瓶颈后,我们采取了快速迭代、小量验证的灰度验证策略。在修复完问题后,通过客户端热更新的方式,按各种维度的比例推送给用户,小量观察验证效果后再逐步放量,以达到快速迭代、稳定落地的目的。
在具体实践中,我们也做了不少性能优化工具。
比如时间预算管理系统,我们《鸣潮》的性能需求划到60帧,一帧可用的时间是固定的16.6ms,我们会严格遵照这个时间开销,优先展现对玩家体验影响最大的内容,一些算不完的内容往后顺延,保证每16.6ms都能刷新,给玩家平滑顺畅的游戏体验。
再比如超分辨率算法的应用,它可以降低渲染分辨率,有效减少计算量、降低设备发热情况,然后通过算法把降低的分辨率,重新解析成高分辨率,通过持续调优,最终在画面和性能上达到玩家可以接受的「甜点值」。
做了一系列事情后,突然有一天,我们发现《鸣潮》的性能优化话题,上了B站热搜,我自己是比较意外的,但我相信,只要我们持续去做优化工作,量变总能引发质变,玩家感受到项目组的努力只是时间问题。
最后,《鸣潮》的研发过程整体比较曲折,我觉得多做减法、保持聚焦、直面问题、拆解节点、量化进度、定时复盘,是我们能把这个项目做出来的关键。
今天的分享大概到这里,谢谢大家!