9月21日，由腾讯游戏学院举办的第三届腾讯游戏开发者大会（以下简称TGDC）召开。在技术分论坛上，腾讯互动娱乐 天美工作室群技术副总监郭智作了「腾讯郭智」主题演讲。
以下为演讲实录，内容有删减：
首先，我先介绍一下我们整个引擎公共能力建设。
“引擎”和“中台”这两个词是近两年来是一个比较热的词汇 ，今天我会以一个中台的视角去介绍一下我们在《使命召唤手游》里面所做的一些工作。
第一个部分，引擎公共能力的建设。
其实是天美的j3工作室引擎技术组整个搭建过程做一个简单的复盘，同时我们这个组成立了一年刚刚开始，今天只是抛砖引玉和大家一起探讨，一起进步。
2018年是可以说是手游3A化的元年，我们一起看看业界游戏技术有什么变化。
引擎技术移动化
1、大家都在使用线性空间光照及HDR管线。
2、大世界成为热潮，不断的在讨论多地貌的地形制作，地形渲染，
3、TOD日夜变化大肆流行，雾和大气也是标配，还有图形上都使用基于物理的渲染。
4、再次目前我们引擎组 可以再移动端实现一些拟合的动画光照GI效果。
我们大肆的在使用端游时代的技术
引擎与工具也在不断升级：
UE4普及
Unity也升级到了2019
Houdini与Substance为代表的 卓越的美术工具大肆被大家使用
硬件也在进步
高通的GPU已经到了855+苹果进入了a13，性能与几年前PC无限拉近
PC显卡已经 进化成光线追踪的RTX，各大引擎厂商都在更新自己的光追烘焙器
各种3A大作前沿技术被手游使用
Destiny的VisualEffect
Farcy5和幽灵行动的大世界技术
甚至于各个游戏公司也在各大技术峰会以及大作总吸取技术经验
综合起来，其实是端游技术在手游延伸，引擎工具的发展，硬件的发展，再加上整个业界技术的分享和传承，其实现在整个手游技术已经不断往AAA化发展。
技术深厚的公司出现了一大堆的高质量的手游，比如说像《天堂2》、pubg mobile这样一些高质量游戏在国内外都取得了不俗的成绩。在未来其实会有更多高质量的手游出现，技术竞争也会越来越激烈。
我们制作的COD手游会在今年海外进行上线，大家也可以看一下这款产品，我们在上面做了很多深度技术的改造。
来看看传统游戏开发团队的架构。
其实它组成很简单，按照岗位划分会出现一些美术团队、策划团队、服务器开发和客户端开发。同时，在技术团队中会有那么一小波同学会做一些引擎的开发工作，这些会成为现在所称为“引擎工程师”。他们在负责一些面向于项目需求的特性的开发，性能优化，解决一些技术的难题，去参与攻坚一些项目，这样子架构能够很好的服务团队，这一波人也能为项目解决各种各样的疑难问题。
两年前这样的运作模式出现了很多很多的爆款式，甚至于我们在腾讯内部很多很多产品也是由这种架构延伸出来成功的。但是，长远来看这样的架构还是会出现瓶颈。
在手游AAA化的今天，对于品质和创意要求越来越高的今天，技术已经成为胜败的关键。以前游戏开发团队往往会存在这样的问题，技术积累比较缓慢，技术管件需要升级，人才需要升级，我详细解释一下。
1、技术积累缓慢。
主要是因为一般游戏产品都是需求驱动，用人力解决问题。
由于技术眼界的原因，往往这个团队里面所出来的技术是为了满足当前需求的，所以积累的技术会比较慢。同时，也会因为关注单一产品的原因对一些前沿的方向的想法比较少，储备不足。
2、人才。
人才维度也会遇到的问题，整个业界盘一盘。国内做引擎或者做底层的开发者其实非常有限。我们当面对这些需要做一些引擎开发的时候，要做一些深度的开发很难找到这方面的人才，同时我们要有很好的一些培养和管理机制去做配套。
配套好之后我们还要在工作室里面每个项目做整个引擎技术的全覆盖，这样子项目组的研发人员能够和整个技术中台、引擎组的人能够做很好的协同工作。
3、开放和传承。
以前可以看到整个业界里面技术都是封闭的，现在其实开源协同已经变成了一个主题，大家不断在开发大会分享自己的技术，对于中台组织来说也要对外不断进行合作。合理的共建。
在整个《使命召唤》手游研发过程中我们联合了引擎厂商、芯片厂商、手机厂商。腾讯内部的一技术中台力量一起把这个游戏开发好，这样才能让一个高品质的游戏诞生。
最后，对这些已经沉淀出来的技术需要在各个项目里面不断做传承。
不仅仅是技术上的中间平台或中间件，而是一整套集创新组织架构，敏捷研发流程以及前沿游戏技术的综合生态
我们目标是：
组织维度：营造环境--支持项目快速创新、规模化创新；提供完整的持续交付工具链。
技术维度：赋能业务--根据技术前瞻提前组织资源，利用技术先发和可复用的优势，赋能业务真正做到多（同一时间支持多个项目），快（持续快速交付），好（品质保障），省（技术与人才充分复用）的逐个落地。
目前我们支撑多个UE4，unity项目。
我们也是在刚刚起步，欢迎也后面跟各位开发者共同探讨一下这些东西怎么做，也互相学习。
中台的架构。
这是我们的架构，我们只是刚刚开始，人才上也会是多维度的人才，覆盖这个游戏开发的各方面，比如：技术美术，做引擎技术的开发，维护workflow的工具链开发，做自动化测试的开发。
提供 引擎技术能力，开发制作管线，工作流工具建设，技术美术能力等全方位能力去支撑业务，同时也会从业务发展过程中发辅中台。
和业务非常紧密结合是这个团队最大的特别，我们不会一味做很多不落地的技术。我会根据工作室未来方向定义自己的Roadmap，比如未来会做大世界，会推PBR的管线，会做过程化的布局，我们70%的需求来源于业务，然后剩余30%来源于对业界趋势的一些思考。
同时中台支撑需要有很好的流程支撑，比如说需求管理、目标管理、代码管理、开发流程管理等方方面面。
这是我们所做的一些技术的全貌，囊括了整个引擎的方方面面，从底层是一些引擎的技术，基于引擎技术是一些工具链，一些workflow制作管线。然后再上层是一些开发框架和支撑我们现在的一些各种各样的手游的研发，所以说整个东西其实不是一门技术，还是支持整个项目研发的方方面面。我说完的前面的一些中台建设，我们来看一下其实我们在如何在中台里面以中台的思维去思考一下我们在使命召唤手游所做的一些引擎工作。
第一个方面，画面品质升级。
我们来看看CODM的一些引擎工作，画面品质升级。
要做画面升级，首先是画面呈现标准的建立，我以中台视角说说普PBR时代画面呈现的最佳实践与升级。
第一步对一个IP产品来说我们要定义他制作的主基调，一开始在做cod手游的时候是要考虑性能，因为当时的机器比较差，做性能是永远能服务于大盘用户的，经历过一段时间使用传统的phong光照模型做简单还原，一张diffuse,normal specular，静态烘焙。2018年我组建了工作室引擎组，对游戏画面做了重大翻新，使用PBR复刻主机画面，我们要挑战主机画面丰富度还原-满足IP高端玩家的主机情怀。
可以看到这张图。
左边是两年前的情况，右边是去年的我们做画面升级，可以看到整个品质其实提升的是非常多的。我们有了主基调之后，既然我们要做pbr，就需要统一制作管线和技术管线，对于制作管线来说美术资源需要在线性空间计算。技术管线来说，我们要为引擎定义并且统一渲染管线，我们渲染管线是根据硬件scaleable的HDR渲染管线。
有渲染管线之后，对于画面 呈现来说，我们要建立一致的画面标准。
比如这个角色，每个像素，我们定义他的material model lighting model shading model
对于真实感来说：标准建立了，我们其实是用同样的语言在说话。
他们都是具有物理意义的参数和真实物理定律(PBR)。
全场景是统一光照环境的。使用动态光影 + PBR + IBL
先看看我们的shading model是什么。我们构建了一整套完整的手机平台pbr光照方案
高中低配都采用了完整的PBR信息。
动态物体使用全实时计算+动态阴影
直接光使用的是GGX specular+lambert diffuse
间接光使用 IBL的 cubemap 和SH球谐光照
Occlusion来说，使用了Baked AO表示 Diffuse AO，再根据 bake AO，normal，Eye direction smoothness信息计算specular ao
如果是低配我们直接使用AO替代SO。
对于静态物体，出于性能考虑，我们低配简化了很多光照成分
有5级lod，有4级是对pbr做数学拟合的近似，1级是为最低端机器的兼容性考虑
光影使用全实时计算加上lightmap,shadowmask方案
直接光使用的是预先烘焙的直接光阴影shadowmask
间接光使用 IBL的 cubemap 和 烘焙的lightmap
Occlusion数据来说使用法线梯队产生小范围AO加上 lightmap ao
Specular AO的方式和动态物体类似
再聊下我们的material model :固有色贴图，一张，法线贴图加粗糙度存一张，金属度和AO存一张
lighting model，直接光为Directional light,间接光使用lightprobe和 refectionprobe
前面就是我们为使命召唤手游定义的PBR工作流，我们来做个小结。
█ 项目中所有物体统一使用 PBR 材质渲染，BRDF 均为 Lambert + GGX Cook-Torrance
█ 实时光阴影：Shadowmap 衍生技术 （实时 / 预烘焙）
█ 间接光：Convoluted Cubemap + SH ( Lightprobe ) + Lightmap
通用性：80% 的可见实体均使用这套 shading model的变种
其他20%（头发、皮肤、水体、植被）使用其他特殊方法
确定了shading model,materiel model, lighting model，画面标准就基本建立。下面我么要聊聊制作本身，对于COD这样一个AAA级手游的制作管线。
整个制作管线的核心因素有哪一些？我认为是有三个方面，一个来量产、一个是引擎、一个是性能。我们怎么构建这些因素的。
制作管线，需要使用流程与工具保证美术素材的正确和合理性。
原则有两个
原则一：美术素材输入PBR标准
原则二：生产规格与生产环境
如何达到PBR资源的量产化
可以验证，有详尽可以追述的文档和记载，并且科学性。
pbr的诞生本来就是工业化的产物，当你一味强调各种hack，每个美术用不同的做法制作之后，就不可能科学，不可能量产，最后整个团队就会乱掉，会把这个开发周期给拉长。
要成量产我们要有标准的场景，验证：我们需要在substance painter里面提供了一系列的标准光照环境给美术验证
这些场景需要满足三大要点：
图形技术保证：在同一个 IBL 光照环境下，Substance Painter 与 引擎内显示效果有95%以上的一致性。
制作环境约束：美术制作者Substance Painter 渲染环境必须是标准光照与标准着色器。
验收制度约束：任何人讨论素材本身的效果品质问题时，只能参考标准光照下的效果。
这是我们所有的标准场景环境，其实覆盖了整个游戏里面所出现的方方面面，有一个主场景和六个辅助场景，其实现在已经不止六个，主场景主要验证- 固有色明暗、色相
- 不同粗糙度表面的镜面反射情况
- 金属材质的镜面反射情况
辅助场景主要验证。
- 室内环境（弱点光源）- 暖色调环境下效果
- 强对比阴阳光照
- 典型室外光照下效果
- 固有色是否太黑
同时我们提供定义详细规则的文档白皮书
最后一个要点是正确性。我们接住了黑科技 去考查光照
我们借助的素材有屏幕校色，照度仪（重要），RiteChart 标准色卡
我们在各种环境下测量球谐参数SH以及Lightmap
在substance与unity里面都提供参考固有色 比色卡。
如此严格科学性的验证下才能得到目前3A级的CODM手游画面
所以对于中台组织来说，我们要推行的是管线和整个制作生产本身，而不是提供一门技术。说完整个画面承呈现和PBR的制作管线，我们来看一下我们做了哪一些技术沉淀，有了前面标准之后我们才能很好地做一些沉淀。
首先是我们日常的引擎迭代里面都需要有一个自动化兼容性测试的框架，我们能尽可能保证所交付的引擎是稳定的，这是我们一个目标。首先我们日常的引擎迭代里面需要有一个完善的自动化兼容性测试框架。能尽可能保证所交付的引擎是稳定的。
我们和腾讯Wetest质量平台合作，定义了一套devops自动测试框架，每日拉起TOP200的手机做测试
测试结果和基础机器的backbuffer做对比，可以发现各种渲染异常。也可以验证游戏graphic api的兼容情况。同时可以针对Top200机器做兼容性，性能测试。
同时支撑新渲染特性以及渲染管线的评估。
通过这个框架我们解决了不少的问题。
他有如下几个作用。
技术预研期，
移动设备发展趋势
技术方案选择
新技术成长过慢
研发期
引擎修改稳定性问题
自动化性能监控
要解决引擎测试缺少特定的性能信息，干扰多
要解决渲染管线耦合性较高，大量问题反复发作
同时测试案例集成及推广
对于运营期
自动化测试替代手工测试
Bug报不清，难以定位修复
项目组经验传承
同时，自动化兼容性测试已经在天美工作群分享共建，各个项目一起用，迭代各种各样有益的测试用例的框架。有了这个自动化监用性测试框架之后，我们就能很安心的做一些引擎开发和特性，然后跟上业界的一些技术趋势，把握一些技术趋势。
这是我们现在的第二个管线，大世界制作管线。对于地形系统来说我们做了很深度的改造，我们会使用一些VTF，比如说支持64种材质的变化，同地貌的折扣也会进行合并，支持十种的生态环境，支持地形的continuus distance dependent做lod变化。我们通过过程化的技术，大世界制作管线，生产出来比较高质量的、符合整个自然界规则的一些大场景，这个迭代也非常快。
以前我们生产一棵树，需要LD或者一些美术在场景里面手工摆，现在我们只需要通过程序化的方式生成地形，植被等信息。生产效率会更快，地图的质量也更高。
我们还对烘焙器做了很深度的定制，烘培器使用了GPU的烘焙，原来我们在PVP地图里面单次烘培需要4-6个小时时间，使用这个烘培机。只需要3-5分钟时间搞定了，整个效果也是有所提升，整个计算的正确性和参考也是非常科学。
我们还对管线做了更深度的拓展，使用自己拓展的烘焙器，我们还实现程序化生成lightprobe，让整体光影更加真实，迭代更加快速。
同样是pcg程序化生成，我们还融合到了植被制作之中。
借力于houdini，我们程序化生成法线和AO，让整个植被的生产周期由2周缩短为2天
最后我们提供了一系列workflow 保证 美术制作，引擎，性能工具一体化。
如图整体上不打算美术工作流，程序后续执行优化。
使用的技术有texture Atalas，Texturestreaming，以及各种级别的pbr shader lod策略
再下来可以看到一些常用技术的沿用，比如皮肤用了ssss，角色PBR制作，不同发型的制作，我们会补齐方方面面的引擎特性。维护整个生产管线和制作管线的本身。
看到我们在使命召唤手游所做的工作，可以看到其实我们提供的是一套引擎技术小中台的能力。
包括：引擎技术能力，创新赋能，梯队培养，工作流与技术管线，品质与性能保障，与资源与经验的重用。
而不只是技术的本身，我们也是刚刚起步，我们还有很多问题需要解决，技术上我们还属于在追赶，做不到引领，我们的组件一个会各种小问题，我们还是一个小小的 team在不断的成长，欢迎大家多多指教或者加入我们。
在实施引擎中台的过程中遇到过哪些困难，如何协调好项目组与引擎组的关系。
郭智：第一个问题可能在一些的中台里面会遇到，比如说一个公共组织引擎组可能会遇到问题，项目组和引擎组的关系。这个问题在我们这边比较好的解决是因为引擎的人组建的时候来源于项目组，这些引擎的同学也是跟着项目一起迭代，大家都奔着帮助这个产品成功来工作的。
同时，我刚才说到了我们70%的需求是服务好产品，30%是来源最前沿的思考，所以在跟项目组处理关系的时候，我们就要思考一下这个产品需要什么技术，这个产品的研发周期什么时候发版本，什么时候需要这个技术的提供，整个工作室层面未来会出现怎么样的一些产品，需要什么样的技术，这些盘点跟着项目组的节奏来，问题会迎刃而解。
引擎中台指是什么，和传统的游戏引擎有什么差别？
郭智：游戏引擎说的是技术。对于我们引擎组来说要解决的是技术管线、制作管线和整个技术如何很好的整合提供产品使用。
