游戏葡萄 09-23
库洛CTO:《鸣潮》上线前,我们曾把它做到500万在线
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_keji1.html

 

库洛游戏 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 站热搜,我自己是比较意外的,但我相信,只要我们持续去做优化工作,量变总能引发质变,玩家感受到项目组的努力只是时间问题。

最后,《鸣潮》的研发过程整体比较曲折,我觉得多做减法、保持聚焦、直面问题、拆解节点、量化进度、定时复盘,是我们能把这个项目做出来的关键。

今天的分享大概到这里,谢谢大家!

宙世代

宙世代

ZAKER旗下Web3.0元宇宙平台

逗玩.AI

逗玩.AI

ZAKER旗下AI智能创作平台

相关标签

cto 林晨 物理 美国 腾讯
相关文章
评论
没有更多评论了
取消

登录后才可以发布评论哦

打开小程序可以发布评论哦

12 我来说两句…
打开 ZAKER 参与讨论