鹅厂游戏开发的引擎中台都涵盖了哪些内容？

2020-12-16

2020年12月8日，由腾讯游戏学院举办的第四届腾讯游戏开发者大会（Tencent Game Developers Conference，简称TGDC）进入了第二天的议程。来自腾讯互动娱乐研发效能部的引擎核心技术组负责人魏楠先生，分享了建设引擎中台过程中，核心渲染、内容工具和开发效率等方面的实践经验。以下是分享视频和文字实录：

今天主要分享，在过去一段时间，我们作为技术中台，和腾讯游戏内部很多项目合作、协助3A手游开发时积累的一些技术经验。

随着手游市场不断变化，玩家对手游的品质要求也越来越高。什么是一个3A高品质手游呢？其实可以借鉴传统的主机游戏作为参考。如下图，都是获得玩家高度认可的3A主机游戏。

通过我们的观察和分析，以下几点非常重要：

渲染效果。如果大家比较关注游戏技术发展的话，渲染一直是其中非常重要的一环。画面的质量对于游戏的体验是至关重要的一个环节。
海量内容。随着给玩家提供的内容越来越多，玩家所能探索的东西也会越来越多，可以极大丰富玩家体验。
丰富玩法。如果可以提供丰富的玩法，玩家就可以获得不同的乐趣。

综合上述，如果能够实现这些，就可以给玩家顶级体验。而作为技术中台，我们因为资源、人力等各方面的限制，不可能所有东西都做，所以我们只能聚焦于几个最核心的能力：

核心渲染。我们希望能通过核心渲染技术上的一些突破，帮助项目组在移动平台上真正实现质的提升、飞跃；
内容工具。因为要生产更多、更高质量、不同样式的内容，我们肯定需要在工具侧也做一些突破。通过这些工具帮助整个项目组，或者制作人员实现这些内容的生产；
开发效率。随着内容增多、玩法丰富，团队的开发效率也会遇到瓶颈。提高开发效率就成了至关重要的一环，这会对最终的游戏品质有非常关键的影响。

基于这些考虑，我们做了以下具体措施来发挥中台优势：

核心渲染

首先是移动端渲染管线开发。我们跟很多项目组合作，他们对动态、光照和阴影的诉求越来越强烈。目前来看，光照是整体渲染效果最核心的一个环节。

基于这方面考虑，首先我们会把所有资源投入在移动端延迟管线的开发上，在移动端实现一套延迟管线，来提升整体游戏画面。

在开发过程中，我们划定了三个非常重要的目标：

第一，性能提升。我们希望能在移动平台硬件性能有限的情况下，真正支持到百盏动态光源。效率、性能能够同时满足具体游戏项目的要求；

第二，带宽、功耗优化。在手机上，不管是发热还是电池消耗，都会影响玩家体验；

第三，兼容性。鉴于手机硬件非常丰富，各厂商之间不管是特性还是Driver层面，都有很大的差异，所以做好兼容性也非常重要。我们希望在低端、中端、高端，不同硬件厂商上，都能有非常好的覆盖。

基于这三点，我们在整体开发过程中总结出了以下经验：

第一部分，通过对光源比较彻底的优化，预期可以提升20%-25%的效率；

第二部分，在带宽层面针对不同的GPU，比如ARM的Mali、高通的Adreno，充分利用这些硬件的特性，我们可以达到25%-30%的带宽节省。有了这样的节省，我们在一些手机上的测试结果，有2℃-4℃的降温，极大提升了玩家体验；

另外在内部测试和实际落地项目中，从一些项目测试的数据反馈来看，不管是在低端、中端、高端上，使用这一套移动端延迟管线，在性能上都可以和当前主流的前向管线保持一致，甚至超越前向管线。

当然最后还是有些问题，因为本身前面提到诸多复杂性。所以如果要解决，需要有一套非常复杂的方案，这会进而极大提升整体实现的复杂度。所以就会带来整体引擎侧的维护成本、复杂度提升，这是大家需要非常注意的；

第三部分，需要在整体实现过程中考虑硬件、API，甚至一些Driver方面的问题和限制。这样才能有针对性地解决问题。针对于硬件和API限制，这里列举了一些我们的经验。

比如在Vulkan方面，因为Vulkan本身会提供一些非常有价值的新特性和扩展，在实现上会简单一点，而且对性能和功耗优化都非常明显。

但是有一个最大的问题，当前市场上能够支持的硬件非常有限，同时Driver层面的支持也非常薄弱。因为厂商多年精力都放在OpenGLES上，Vulkan只是在近一两年，才逐渐转换成一个重点，所以这部分应该非常留意。

另一方面是OpenGLES的优势。第一，厂商硬件支持非常广泛，大部分都有对应特性支持，Driver上面也比较成熟。最大的问题是各个厂商往往提供了一些扩展，它们各方面有非常多差异。比如我们核心的，针对功耗方面的优化，在ARM、Mali和高通的Adreno GPU上就需要使用到不同的扩展。这样就会明显提升整体实现的复杂度和维护成本。

最后在Metal这边也有OpenGLES的优势。目前支持各方面还是比较好的，主要是因为有厂商来做这个，所以相对来说是最容易支持的一套API。

内容工具

第二部分给大家介绍一下，针对海量内容生产开发的一套工具——基于Houdini的PCG工具。

目前看来，特别是针对开放大世界、MMO这种品类的游戏，因为本身场景非常巨大，内容资源量也非常大，就需要借助一些程序化生成的方式来提升团队制作效率。往往大家都会围绕Houdini来开发一套PCG生产流程。而对于我们团队来说，开发这套工具最关键、最核心的是关注整体流程。

从经验来看，不同的项目对不同的效果、资源一般都有不同的需求，所以在效果侧最好还是由项目组自己解决。而对我们来说，能做的就是提供一套工具，让项目组灵活、快速，并且复用性地开发自己的流程，这是最关键的一点。同时也能帮助他们，把这套流程合理而有机地和整体引擎集成在一起，这是我们工作最关键的部分。

基于这些思考，我们开发了一套基于Houdini的PCG流程工具。这里第一个最核心的概念就是基于一个叫Node Graph PCG Flow的流程工具。这套工具最核心的想法，其实就是可以通过节点图的形式灵活定义自己的整体PCG流程。

在这个Flow图里，我们有不同类型的节点，包括输入、输出、处理节点。靠整体数据流把这些所有的节点串联起来，通过输入和输出节点和引擎进行数据交换，并来完成定义整体程序化生成的流程。

在这些处理节点里，我们可以把不同的Houdini处理节点封装在里面，甚至一些我们自己完全独立开发的程序化生成算法也可以放到这个节点图里，然后把这些处理流程串联起来。

接着给大家展示一下，我们针对这套Flow流程工具开发的一些数据输入工具：

第一个工具是曲线工具，因为曲线作为河流、道路生产最重要的输入数据，是非常重要的。我们想给大家开发一套工具，能够非常灵活地定义、修改曲线。右边是我们开发的Mask工具，它对于在整体引擎里标注整体区域、在区域里面进行程序化生成，是非常重要的一个源数据。所以我们也开发了一套Mask工具，帮大家灵活地定义这个类型的数据。

同时我们也提供了一套完整的Houdini HDA Library给项目组使用，可以让项目组基于我们已经开发的一些Houdini HDA，根据项目本身的一些需求，在整体这些HDA基础上进行一些扩展、定制或者修改，快速搭建自己的流程。

包括地形、植被、道路、河流、岩石、建筑等等，这些HDA会提供一些最基础的功能。目前我们这套工具在腾讯游戏内部已经有几个项目在使用，我们看到，项目组可以非常快速地利用我们这些工具来灵活搭建流程、快速实现一些Prototype工作，也能验证自己整体流程上的一些想法。

接着给大家介绍一个叫做Superman的面部表情动画工具。这套工具主要针对表情动画和捏脸的需求，它支持任意3D角色的面部定制，支持自动绑定、快速捏脸、表情系统，以及口音等数字资产制作，同时可以结合专业的面部数据对接。甚至简单一点，iPhone上的AR Kit也可以与它对接。

这套工具最主要的优势有三点：

第一是功能全面，支持谷歌框架和Blendshape数据的自动双向转换；

第二是通用性较强，从具体项目组来看，这套工具可以支持不同风格，包括写实、Q版角色等。它的操作非常简单，不管是安装还是功能，整体都对美术侧非常友好，只需要简单两步就可以让美术使用起来；

第三是开发效率明显提升，这也是最关键的一点。关于效率，这边有一些具体数据。

比如自动绑定，传统做法一般需要一周时间做好一个绑定。但如果使用这套工具，就可以在一小时的级别完成；

捏脸系统方面，有些项目可能需要一周左右才能初步搭建。但如果使用这套工具，大概两天就可以完成；

在表情制作方面，通常项目大概需要1.5周左右。如果使用这套工具，大概两天左右就可以完成；

最后，情绪、口型资产生成，借助自动化生成，可以从以前的1.5周时间变成马上生成，基本可以忽略不计。

开发效率

返回到前面提到的光照本身，它是渲染最核心的效果，即使有像延迟管线这样的技术，对于动态光源、光照，我们能有非常好的支持，但是像间接光照这种，我们依然需要借助一些预计算的方式才能比较好的支持到。

目前来看，主流引擎里的光照烘焙会是一个计算量非常大、非常耗时的过程。有些具体项目里，比如前面提到的开放大世界项目一个像5K*5K的地图，烘焙一整套图往往需要一整天时间。这样就极大限制了开发效率。

所以基于这些问题，我们利用GPU开发了一套GPU加速的光照烘焙系统。这里开发其实有几点需要注意：

第一，虽然开发了一套新的系统，但肯定还是要保证它和以前的旧系统在整体烘焙的效果、质量上完全对齐，甚至在个别点上做到超越；

第二，我们的初衷是要大幅提升整体烘焙效率。从实际情况来看，我们确实可以将效率提升一个数量级的；

第三，这套系统应该是一个比较好、完备的、可以进行功能扩展的系统。我们在后期开发一些功能时已经验证了这一点，比如我们在光照烘焙系统上又增加了一些新的烘焙特性，来支持一些新的需求。

这里是一个简单的效果对比图，基于CPU光照烘焙系统和GPU烘焙系统的截图。

从图里标注出来的地方可以非常明显地看到，CPU光照烘焙系统的漏光还是比较严重的，而GPU烘焙就完全避免了这些问题。要实现这些效果，最主要还是在算法、实现方式上对CPU这边的一些改进和差异所提升的效果。

另外，这里也有关于烘焙效率的一个对比。这是我们在半年前的测试数据，里面基本上是有三组数据，第一组，像蓝色标出来的是这套CPU光照烘焙系统大概需要多长时间。中间这部分数据，我们测试的时候是一块2080 Ti的显卡。右侧数据是我们自己搭建的GPU服务器，一台有八块Quadro RTX 6000的显卡。

通过这个数据对比我们看到，在单块GPU上我们一般性能提升会有3-7倍。如果是针对一台服务器做对比，我们一台服务器大概会有15-30倍的提升。

这里的数据差异，主要是因为在不同场景里，因为烘焙时任务有一定差别，所以有些任务效率提升会高一些，有些会低一些。但是整体上如果和服务器对比，我们认为基本上会是一个比较大的数量级差别。所以就像前面我提到的，像5K*5K的地图，一般CPU需要一天，我们这边可能一个小时，甚至一个小时之内就可以完成烘焙。

最后介绍一下我们开发的一套分布式构建系统，主要目的是利用分布式系统提升整体游戏构建效率。目前来看，引擎本身编译、资源场景、构建、打包等等流程，都是非常耗时的。因为有一些实际项目可能会出不同的版本，整体上有些是几个小时，甚至确实以天数计。这样的时间会严重制约项目开发进度、迭代效率。

其实不管用多么强劲、单一的一台构建服务器，也没有办法完全解决这个问题。最好的方式，是把一个耗时的处理流程放到分布式环境里，利用分布式环境大量的计算能力、可扩展能力，来更好地解决问题。

另外目前来看，像我们这样一个中台部门其实有很多的计算资源，这些资源平时也会空闲下来，如果能够在平时集中式地利用，对资源利用率也会有一个非常好的提升。

基于这些想法，我们开发了这样一套分布式构建系统。开发同时，我们最开始可能只会盯着一两个任务来做，但是在做的过程中我们感觉到，构建流程当中任务种类非常多、非常复杂。这就要求我们最好是开发一套开放式的作业框架，在这套框架中随着开发进程不断改进，让不同形式的任务都能完全纳入到这套框架里，让这套框架能不断提升本身能力。

同时，系统还提供了一些相应的Cache机制。因为本身在一个团队里，有可能一个用户的构建结果对另一个用户也一样，如果我们有一套比较好的Cache机制，就能够保证这些处理完结果的复用。这样会更进一步地提升整体系统效率和利用率。基于这些，这套系统能非常显著地提升整体程序、美术的工作效率。

这里面其实还有一个比较重要的一个部分，就是这套构建系统需要对于不同平台的支持。因为目前来看，我们不单单需要让这套系统跑在Windows上，同时还要能跑在MacOS、Linux上。不仅仅能构建出来PC版本、安卓版本，同时也要能构建出iOS版本。

所以在开发这套系统时，我们就需要充分考虑跨平台问题，选择比较好的实现方式。这边有一些目前这套系统的实际运行数据，我们测试时大概是使用像32核64线程这样CPU的一台服务器进行构建引擎，大概需要半个小时左右。如果使用我们的分布式构建系统，我们使用四台服务器构建，整体时间可以缩减到大概8-10分钟。