导语:游戏的研发需要经历多个环节,从代码拉取、构建、部署分发到故障定位等;这其中,每个环节都有着不同的效率卡点,特别是当研发团队和游戏客户端包体大到一定规模后,问题尤为突出。
探究游戏研发效率卡点背后的原因,这里面既有因为海量资源,在代码仓库、构建层面带来的效率问题,也有因为人员过多、团队分散办公所引发的流程上的效率问题;
面对各种损耗夹杂在一起,对游戏迭代效率的影响,在今年三月于美国旧金山举行的GDC2023会议上,腾讯游戏CROS高级SRE经理RuiSu分享了腾讯游戏提升游戏研发效率的想法与思路,并介绍了行云产品如何成为腾讯游戏研效提升的催化剂。
在行云诞生之初,腾讯游戏CROS分两步来探索游戏研发提效的具体路径。
首先,针对初期为解决不同环节的效率问题,分别由团队内不同的部门,分别开发了多个不同的研效工具,意在有效解决某个垂直领域的效率问题,但是这也带来了三个方面新的问题,即:
2、为完成一件事情可能需要使用多个工具,需要在多个工具之间频繁切换,使用成本高;
3、工具未能发挥最佳性能,软件端和硬件端的同学未能实现有效协同,无法通过软硬协同方式提升效率;
因此,在第二步,团队进一步建设能力,以场景化的方式来提供更便捷的提效能力,形成了统一的产品——行云。
相比传统的思路,行云的提效解决方案优势在于通过cloudflow提供的流程引擎,打通了不同工具间的权限以及数据,并且可根据不同研发角色的用户场景编排成为常用工作流,通过不同的入口提供给终端用户;同时,提供给用户使用的方式包含UE插件,聊天机器人,web端工具、API等多种方式。
通过一年时间的发展,行云已积累了几十个可以在studio间通用的工作流。而对于新出现工具的使用方式,也能快速使用平台能力开发成新的工具集提供给用户。
在游戏精品化趋势下,一个特性的实现可能会涉及到美术、策划、运营、服务器开发、客户端开发、PM、测试和运维等近多个角色之间的信息流转,其中的每一个改动都会对其他人产生影响。
与此同时,当前研发功能的演进主要依赖日构建,一个bug的发现到修复至少需要两次日构建迭代甚至更长的周期,在这种情况下,依赖日构建版本的传统验证工作流程,显然已经无法满足各角色敏捷验证的诉求。
所以,针对各个角色,尤其是没有开发背景的创意类岗位,更加敏捷的行云验证工作流就是打通提效卡点的有力手段。
以策划数值表的编辑验证为例,经过持续优化,行云打通并新开发了包括引擎插件、转表工具、打包工具、资源包分发、测试环境管理、客户端任务下发(执行)、客户端自动装包、资源包自动加载、信息流机器人等10多个内部系统,实现了一键下发资源文件到服务器和指定客户端的功能。
此外,针对研发人员众多,版本互相影响的情况,行云还基于K8S容器技术构建了一套测试环境管理系统,研发人员可以随时申请一套专属验证环境。
经过以上优化,利用行云,策划人员可以一键实时发布更新到专属的测试环境和客户端,也确保了代码在集成之前进行充分的功能验证,有力地提升了研发效率和研发质量。
目前,这套工作流已经支持了包括引擎插件、web页面、IDE工作台等多个操作入口,为所有的研发角色提供了快速发布测试环境及游戏客户端的功能。
而关于整个dailybuild流程提高研发效率,缩短周期的情形,以腾讯某大型游戏的dailybuild流程为例,这个产品开发人员的规模约有数百名;
日常工作中,Perforce代码仓库有几亿个文件,数十TB的空间占用,每天进行几千次以上的代码拉取,平均每天卡顿2次;游戏包体接近10G,客户端全量构建需要将近几个小时;同时由于开发人员多,构建失败率居高不下;
对于这个团队,提升研效首先要做的是效能度量,将研发所有环节的耗时进行细粒度的拆解。
以构建环节为例,将构建按照UE引擎的执行步骤,拆解为了预处理、代码编译、cook、打包等多个环节;每次的构建的子步骤都可以获取到耗时详情,方便当构建耗时异常发生时能知道是哪个环节出了问题;并且每个环节还可以进行同比、环比、任意日期的比较等,能够通过趋势寻找到问题的所在;加速配置告警功能,用户可设置自定义的阈值来主动获取到发生异常的构建实例,例如可配置cook耗时超过45分钟告警等。
展示代码拉取的趋势,获取代码拉取每日的最高频的时间段;
获取到高频时间段具体执行的详细内容;可针对性的进行分析,看看是否有部分操作可以通过预分发的机制来减少拉取次数
方便回溯:我们将任何时刻点的P4执行详情都存入了数据库,我们可回溯任何一个时刻点的P4同时在运行的连接详情;
告警支持:可支持连接数、单用户连接过长、磁盘IO、CPU等多个条件配置告警;
通过这个系统,为行云有的放矢的进行策略优化提供了很好的帮助。并基于以上建设的分析能力,主要采取了以下几个解决卡顿的提效措施:
将P4的权限管理能力和公司内部的审核系统进行了打通,用户可使用行云系统自行申请或修改权限,PM可通过行云或者企业微信审核,这样比直接使用p4admin方便很多;极大解决了超大项目PM管理权限的难题,可以更加方便的进行细粒度的权限管控;
大文件分析,每日在backup服务器自动运行文件分析,并将分析的结果存入DB并在web页面进行展示,这样既避免了直接在对服务器的性能影响,也能更加直观的展示数亿文件中占用磁盘空间最大的top部分,不仅支持展示,而且还可以通过页面直接设置文件保留的版本个数,PM可直接页面操作;这样我们减少了很多非必要的大文件存放,且web的形式也方便了PM的管理门槛;
预分发,在开发者PC上安装了我们的定时分发程序,开发可以配置定时从P4拉取构建成功的引擎,一般配置的自动拉取时间在夜里,这样很大程度上可以减少日间的拉取压力;
硬件升级和EDGE proxy,在办公区域搭建了若干台PROXY服务器,可以缓存最常用的几个版本,使用户可以实现更近距离的文件拉取而极大提升拉取速度;同时对P4的服务器也进行了云盘磁盘性能的升级,提升了IO的吞吐能力,且由于云盘的三副本容灾能力,也不用担心机器故障数据的损失。
对于构建时间长的问题,则通过软硬协同的方案来提升构建效率,从硬件角度,针对UE和Unity分别定制了不同的机型,最终选取了通过成本、性能、持续供给等多方面综合进行选型;而软件方面,则给出了以下改进:
代码编译环节,在多个离团队距离近的地方,部署云上蓝鲸tbs分布式编译的集群,通过共享的硬件资源为开发团队提高编译速度,单业务最高调用的云端算力达1w核以上;
用度量找短板,通过前面提到的度量环节,也对预处理等一些环节的耗时异常进行了一些优化;
不容忽视的是,除了构建时长的问题,开发团队往往还会遇到了构建成功率过低的问题;比如在示例项目中,由于开发人员多,日构建有很高的编译失败率。
经过分析,可以发现,少部分开发人员没有在开发机本地进行编译正确性验证,就将代码提交到了代码仓库,影响了构建成功率。
事实上,对于例如10人以下较小规模的团队,可以通过一些流程或者政策要求,强制通过流程的形式让开发人员进行编译成功后再提交;但是对于大于50人以上的团队,流程通常不能解决所有的问题,必须通过技术的手段避免遗漏。
为此,行云cloudflow开发了内部称为Pre CI的pre-build的功能,让每位开发在提交代码仓库的时候,能够自动触发将自己的代码差量同步到远端的preci编译检查服务器。
面对数百G工程文件和众多开发人员,preci功能在设计上是存储和计算分离的,当分配preci编译机的时候,会根据用户的不同自动挂载不同的云盘,这样能将preci的服务器数量降低到开发人员的15%左右;通过preCI的机制我们就能保障每位开发提交到仓库的代码都是通过了编译检查的。
最终,这个方案将构建失败率降低了30%,且目前还在进一步优化中。
最后,当构建完成,版本、引擎的分发也是一个耗时过程。
一般情况下,开发人员,每日早晨都要拉取前一日构建成功的安装包或者游戏引擎,进行每日的开发或者功能测试;由于游戏包体特别大,每天这个过程都要耗费将近半个小时;
所以,行云开发了制品预分发的能力;用户可以在行云的后台配置灵活的分发策略,具有来看:
支持多版本包分发:可以将不同的设备划分为不同的设备组,用于接受不同构建流水线的产物,这样就可以将功能包安装到功能测试手机,性能测试的包安装到性能测试的手机上;
可配置自动执行的时间段,例如配置22:00-次日8点执行;
支持多种类型制品的分发,例如手机端的apk/ipa包,PC端的安装包,开发机上的引擎等等;
目前,该示例项目已经完成了数万次的预分发,对于游戏开发效率提升起到了显著的作用。
值得注意的是,随着未来越来越多的游戏在海外研发制作,行云研效能力支持也能够覆盖到海外的研发团队;
我们将蓝盾BK-CI的构建流水线与海外工作室的云上构建机及office构建机打通,通过Center/Edge的模式解决全球研发的问题,Center模块负责pipeline的核心逻辑,Edge模块贴近用户的构建机,负责编译加速、制品下载、就近访问等大流量模块;
作为腾讯游戏CROS的技术中台团队,行云在帮助开发团队提高开发效率的过程中,积累了大量的技术产品,取得了很好的效果,目前,还涉及到较多数字内容制作(DCC)和引擎优化(例如遮挡剔除、全局光照)等方面的能力,以贯通游戏开发全流程的视角,意在帮助越来越多的游戏开发者步入行云流水般的高效轨道。
评论区
共 9 条评论热门最新