2 月 13 日，2022 年度中国游戏产业年会在广州召开。本次大会以“奋进十年路，再搏新征程”为主题，并围绕游戏出海、国风游戏、游戏工业化等话题，深入开展了 16 场分论坛探讨。
当天下午，在以“国内察看——游戏制作工业化降级趋势主题论坛”上，紫龙游戏上海研发核心首席技术官王琦，现场发表题为《咱们对工业化的摸索——抛砖引玉》的主题演讲。
以下是演讲实录：
王琦 ：咱们其实是一支十分强的团队，从 PC 时代始终开发到当初，核心成员始终在一起单干。这么长时间以来，咱们积攒下了一些本人对于工业化方面的摸索和实际。
首先，咱们团队的理念是缺点驱动——当产生了一个问题，咱们会尝试去了解这个问题如何产生的，而后再去思考如何解决这个问题。那么面向工业化：工业化到底是要解决什么问题呢？
在咱们的视角里，首先是工作后果的交付一致性较差。比方做一个角色模型，不同的美术工作人员产出的面数差别、或者是贴图材质差别，都代表了它的一致性比拟差。
另一方面，工业化的背面其实是作坊化，这会导致工作过程的一致性较差，从而带来产出效率较低，以及信息传递的缺失、低效和失真。比方策动向美术传递信息的时候，如果产生了一些失真，使得有些信息没有传递到，就会导致最初产出后果肯定会产生重复和迭代，这对于老本来说都是节约。
同时在传统作坊工作形式下，流程通常来说很难放弃十分高的一致性。不同工作人员工艺的不统一，肯定会导致最终出现的后果呈现差别，并带来品质方面的错落。
基于上述内容，咱们其实很难去定义，开发过程中某一个工作是否被实现，以及它被实现的界定准则和参数到底是什么。所以会导致咱们无奈形容这个工作应该在什么时候实现，以及实现后还会不会迭代。
因而，开发过程的治理信息会变得十分凌乱，同时导致开发过程的可控性变得极差，最终后果就是工夫、老本失控，交付品质不现实。
而咱们视角下的游戏开发工业化由哪些方面形成？第一，是要保障工作过程和后果的正确性和一致性；第二，在这个根底之上须要保障工作过程和后果输入的效率。
为了保障一致性，咱们有两个方面：第一是开发过程治理标准，相比传统的软件开发大家应该比拟相熟，毕竟传统开发会十分重视项目管理机制和规定。第二个是针对游戏行业自身，咱们会存在具体的工件制作工业流程的标准。在局部标准的状况下，咱们是可能靠人力去保障它的一致性。
通常来讲，标准定得越细，查看得越严格的话，工作效率整体会降落。这就须要靠一些开发过程治理的数据化和工具链，以及制作工艺流程环境下的数据化和工具，来使效率失去一个正当的晋升。
这里咱们合成一下开发过程治理标准。首先，它是以通常意义上的软件我的项目过程治理为根底。像咱们以前做传统软件，也会用到一些项目管理的软件，比如说微软的 Project 这些货色。
第二，最开始要解决的一个根本问题，是信息流和决策流的治理。整个开发过程的治理，它的人员组织构造应该是会造成一个树状构造，就像军队指挥打仗一样。
如果没有造成一个很好的树状构造，你的信息流不是在树下面通过根节点能力流向叶子节点的话，比方在执行环节，策动会间接和执行层面的程序和美术沟通。这个有可能会导致你的 Leader 不晓得，因而他们对于这些信息是否和原有体系自洽，并没有做出判断。而且在他们不晓得的状况下，后续 QA 流程必定也被断开的，这都是问题，所以咱们须要把信息流和决策流的治理做好。
第三，开发过程治理标准和工业化的关系，后面其实曾经提到了。开发标准其实并不依赖工业化存在，在咱们没有波及到工业化概念的时候，就曾经在用简略的标准在操作。同时，工业化肯定会带来一些流程线的制作老本，针对这些新的流程建设，咱们须要对原有的开发标准进行一些适配和调整。
再者，咱们即便在有布局的参加状况下，其实随着我的项目过程的倒退，以及同一套工业化流程线在不同我的项目中的利用，具体的开发标准其实还须要做调整。这里特地须要去防止：一般来说，咱们执行开发标准的具体执行人都是 PM 团队，但 PM 团队常常有时候会有一些工作导向的偏向。就是说标准里规定了我有 abc，下面流程做了那就算没责任了，尽到了本人任务。
但事实上，咱们其实须要互相灌输：做这个标准、做某一个条例的指标是什么？它是为了实现什么样的目标？那在具体的某个环境中，如果没有达成相应的目标，咱们是不是应该去剖析一下，到底是执行环境出了问题还是说标准有问题。
而后第四个，就是开发过程治理须要数据化。数据化其实是工业化的根底，如果咱们不能用数据化的形式去形容整个开发过程，就没有方法以数据化的形式去定义每个工作，以及每个工作的分类是什么。
在咱们的工具外面其实给每一个工作打了很多标签，它有性能领域方面的标签，比方是某某零碎的、是属于战斗还是属于技能的；还有一个就是它在岗位上的标签，因为咱们做某个性能领域的工作常常会流转很多岗位，而这个工作到底是属于哪个岗位，就须要把整个开发过程元数据化，去定义它。
最初一项，就是咱们如何保障下面这些来执行。其实咱们会在开发标准下来定义立项的各个阶段，每一个版本要达成的指标是什么、它要验证什么？在达成了某个指标后能力持续往下走。这其实是为了在后期尽量减少老本，解决一些未知问题，前面会更具体地去解释这个问题。
那工业化和流水线之间的关系，在咱们的观点外面，工业化的实质就是建设流水线，既然是建设流水线，就会波及到一个老本问题，一般来讲老本都是很高的。所以估算比拟小的我的项目，那就要须要问问本人值不值得动员它来做事。
既然它老本高，改变它的时候老本也高，那它就肯定会有某种局限性，即只适应于为了咱们这个指标特地定制的流水线。所以，流水线模式和游戏翻新实际上是存在人造矛盾的。能够通过咱们我的项目过程治理标准里对于每个版本的要求，去缓解这样一个矛盾。
这里谈到咱们搭建流水线的过程，提到了一个叫做 Alpha0 阶段。Alpha0 阶段其实是一个版本，这个版本之前有两个重要的版本阶段。
第一个版本阶段，是所谓的外围游戏验证阶段。在这个阶段中，咱们个别很少有美术来参加，基本上尽量采纳白模和既有的美术资源来进行外围游戏性和 3C 的验证。这个阶段过了当前，咱们认为达成了验证指标，就会进入第二个阶段。
第二个阶段，是美术的原型阶段，咱们须要确定美术格调，去给美术的每一种工件制订它的规范。基于规范，就会阐明这个美术工件的复杂度，标记着它的生产成本。可能掂量游戏中对于这种复杂度资产须要的量是多少，也就是美术内容格调的制订、定标和定量。这几件事是进入 Alpha0 阶段的前提。
那在 Alpha0 阶段中要解决的问题，第一是为形成游戏的每个“整机”制订最终要求和标准、以及定量，而后再为每个“整机”制订工序环节和每个环节上的查看标准，并制订是哪个岗位的人来做这个事件。这个问题，前面会再具体解释。
这里拿了几个咱们外部工件制作的图解，给大家奉献例子。
在 UI 零碎制作下面，首先咱们会画一张流程图，来定义对于制作某一个美术或内容的资产，咱们要把它合成为哪些步骤？其实这个步骤曾经合成得十分细了。蓝色方框的局部最终会体现在你的工单零碎里，会变成某一个人身上的一个 Task，会去定到人、定到工夫、定到时长。灰色的局部基本上属于一些非工作性的环节，比方某种沟通、或者某种会议。这个图上曾经蕴含了制作流程中很多 check 的步骤，以及一些迭代、整合、调试的步骤。
另一边和这个流程图配套的，就是咱们针对每一个环节的标准，这个标准也是听从于咱们缺点驱动的开发。当咱们发现某个中央呈现问题的时候，须要去为它拟定一条新标准，增加到原有的体系当中。当咱们一直地去做这种事件，就会使得你的标准越来越欠缺。比方 UI 规定了字体应该怎么用，你的按钮控件应用的一些规定是什么。
下一个就是机甲部件制作，要经验一个什么样的流程。咱们的标准其实还蕴含要应用哪些工具，因为咱们针对工具有做很多二次开发，因而不能胡乱地遵循你的爱好安顿工具装置，必须依照咱们本人规定的这些货色。包含工具环境要用什么，机甲的一些比例范畴，面数等，都是在这个标准外面。
这是场景相干的制作标准，这个只是形容纯正的美术方面场景，因为场景利用到游戏当中，还会变成其余的内容，这个标准在前面大家会看到。
这个是场景做完了后，把它利用到游戏当中的策动外部流转。蕴含关卡策动、文案策动，一些主策动验收，数值策动填充数值等过程的流转，以及他们一条条迭代演绎进去的一些步骤和规定。
而后是开发过程治理的数据化和工具链，咱们大略应用的项目管理是 Jira 或 Project。每个工具都有他本人的专长，比方，Jira 比拟适宜每个人只关注本人能看到的工作条目；Project 比拟适宜让整个我的项目的管理者可能看到工作和工作之间的依赖关系、工夫等。
版本治理咱们用的是 Perforce，也是在做过重复调研后，最终选定的 Perforce。它最吸引咱们的一个性能是和 Swarm 的联动，迁入当前能够主动做 review 环节的联动，等一会我会具体的介绍。
CI 环节，咱们用 Jenkins 和一些自研资源查看工具。还有一个就是咱们本人开发的音讯告诉软件，叫 DevMsg，这个货色是为了解决什么问题呢？就是咱们常常会遇到的在我的项目中信息失落。
比如说我开了个分支，要求前面针对某个版本的迁入必须在另外一分支上做，这个时候往往就有美术说“我不晓得”、“你没告诉我”，他也不看 QQ，你也没方法专门找人去盯着他、问他确认。最好的形式就做个软件，把这个 Messagebox 以模态窗口的形式弹在他脸上，他不点确认这个窗口永远不会隐没，彻底消除他们说任何“我不晓得”的状况。
** 这个是 Jira 和 Project 的互通。咱们整个开发流程的终点，是每个版本的一个 Excel。在这个 Excel 外面去定义了这个版本的 Featurelist，而后各个组长会在 Featurelist 上进行工作拆分。只拆分这个工作节、某个 Feature 要分解成哪几个工作条目，不安顿工夫、也不安顿人，而后这个 Excel 会被一个工具导成一个出最后版本的 Project 的杆状图。
**
在杆状图上，咱们可能非常明显地得悉一个工作在工夫上的关系。当咱们安顿了人之后，我发现哪个中央成为长板，须要把它调整一下，负责人就把工作调到其他人身上去，使得每一个资源的阶梯化应用十分清晰明了。从 Leader 的角度来看，咱们整个工作的 b 型开发流程和故事开发流程会十分的清晰。
**
做完这一步当前，咱们用本人做的 Jira 拓展工具导入到 Jira 里上，会造成每个人身上挂的一些工作条目。这些人每天实现工作之后，就把对应的 Jira 上的工单设置为已实现。咱们每天会再做一次同步回 Project，杆状图的实现状态也会跟着更新。
**
与此同时，咱们每天会在 Jira 上做一个主动报表，把所有类型的工作、每一个大的性能分类工作的实现状况和实现比例，以及迁延状况统计进去发给所有的 Leader，让公司领导也能很明确的理解。同时咱们也会把同步好了的杆状图收回来，可能以一个比拟有效率的形式去理解以后我的项目进度。**
这个是 Perforce 和 Swarm 的联动。当咱们在 Perforce 下来迁入一个资源或代码的时候，咱们有一些强制性的要求。就咱们通过二级开发 Perforce 去规定迁入的时候必须提供哪些信息，其中一个十分重要的信息就是：你针对的 Jira 工单的工单号是什么？一般来说，开发人员是没有方法间接去迁入的，他只能提交一个 review 的 request，会在 Swarm 下来丢给你的 Leader。
一般来说，这丢给 Swarm 之后会触发咱们一个制订的 CI 流程，它会依据你的工单的类型，这个就波及到咱们后面那个元素的作用了。咱们得晓得这个工单是为了什么目标、它到底会波及哪些资源、咱们要做哪些查看，以及依据你迁入的资源在咱们工程目录外面的匹配规定，它到底属于哪种资源。去做相应的查看后，咱们会把查看后果贴到那个 Swarm。
当你的 Leader 去看的时候，他首先看一下主动查看的后果，有没有一些不适合，或者尽管不太适合然而能够忍耐的局部。这个中央和咱们代码编译过程会有 warning 和 error 的局部一样，然而在某一个比拟正式的版本分支下面，这些就曾经迁不进去了，而后你的 Leader 看完当前会决定要打回或者是承受。通过这种形式，咱们可能最大水平上的去保障每一个工作环境上的人提交的货色是非法。
这个是 DevMsg 产品。
这是制作工艺流程中，基本上是美术生产过程的数据化和工具链，咱们要谈到它的特殊性和通用性。
特殊性，意味着每一个我的项目的美术规格都有差别，格调也不一样，有的写实、有的是卡通。游戏类型不同，跨平台的估算调配也不一样。咱们可能有的游戏须要在特效上多调配，它容许每一帧所耗费特效的 GPU 工夫会多一点，有的是整个场景的植被渲染要多一点。这个货色都是依据咱们中台在 Alpha0 阶段去做的一些掂量，和项目组做一些沟通后去重复测试，批下来的规范。很多我的项目也存在自定义的美术资源，特地是一些预制件。在别的游戏中不存在，只在他这里存在，也有本人的一些标准。
有特殊性，它也有通用性。通用性是为了保障，咱们不能独自为了一个我的项目开发一整套工具链和流水线，老本都太高了。在通用性上，咱们个别是通过把整个性能和要落地的过程切分很多档次。
首先，咱们会存在跨我的项目的数据规定框架和工具链框架，落实到具体我的项目中，咱们会把数据规定框架进行一些配置，就是数据驱动的规定模板。比方咱们每个我的项目都会去审查某个资产的面数，面数的值由项目组本人来治理。还有工具的组件化部署，你的整个工具链必须是要思考好组件化，不能间接来个“全家桶”，你得容许我的项目去抉择某些组建来部署。这个中央咱们也做了一些像腾讯的共事们做的那些部署框架之类的，有些环境上面是咱们把部署好的环境一股脑全迁到珍藏库外面，其余工作人员间接盖下来就是最新的，这样的话咱们更新的时候也很不便。
前面会举两个例子来阐明，美术方面的数据化和工具链。一个是美术资源解决流程，就是美术资源进口资源的导入；还有一个是材质的验证。
这个是美术资产的导入。首先，美术资产生产完了当前，第一件事是要导出。在导出的时候，就会利用咱们做的二次开发的一些工具，来查看这个资产。比方一些命名规定、层级构造，顶点数据有没有废数据，在一些变数参数下面有没有合乎咱们的要求……裸资源导出了当前，第二步就是导入。
在那个裸资源导入引擎的时候，咱们在引擎外面做的二次开发会对资源进行二次解决。比方贴图的跨平台压缩设置，针对不同的规格品质要求的包的贴图的设置。比方《钢岚》我的项目，他机器人咱们导进来的裸资源其实是一套的机甲部件，在满足肯定的那个命名规定的前提下，咱们会让程序那个主动去做一些预制件的生成。就间接把它组装成最初程序会调用的一些货色。
而后这些资源进入了零碎之后，比方咱们在场景外面把这些资源放上去了后，咱们会做一些 profiling 的工具来去做初步验证，这些货色组合在一起是否符合要求，这些 profiling 工具前面咱们会再具体介绍一下。
引擎当中的生产过程实现了之后，咱们上传的时候就会去做 CI 检测，以及保障进入 source control 资源的合法性，这个后面曾经说过了。
这里再谈材质一致性的问题。咱们以前会遇到的一个问题是什么呢？比方在一个游戏当中，两个不同的场景可能一个是晴天，一个是阴天，不同的美术、哪怕是同一个美术有时候也会犯这样的谬误：他为了达成最初美术画面的出现成果，有的中央是靠调建筑物的材质和色彩来达成，有的中央是靠调光的达成……就十分的不统一。当你想去做一些全局的前期解决时，这件事件就立马凸显呈现。而后你想返过来搞，老本又很高。
所以在解决这种问题的时候，一个前提是要去搞清楚最初画面像素的色彩，在光照着色渲染下面到底分哪几个步骤，每个步骤的奉献到底是什么？以此来针对每个步骤进行计算机制的对齐，以及最终奉献后果的对齐。
比方 PBR 的渲染，咱们首先要确定的是物理晚期模型。再就是光照环境的一个确认 HDRI 天光的拍摄和改正，物理光照和曝光，而后再是 GI 烘焙。还有一个 GroundTruth 是咱们本人定义的，他的作用是什么呢？比方你要验证材质模型，必须要有个规范场景，这个规范光照场景咱们如何保障正确呢？咱们首先把它渲一遍，而后咱们再用本人光栅化的渲染形式再把它渲一遍，再比拟每一个局部的色彩差别是否在可接受程度内。如果 ok，阐明咱们这个光栅化的货色曾经达到了指标要求，当然这个货色只适宜做 PBR 渲染。
而后基于这个规范光照环境，咱们能够把其余后续减少的材质放进来。因为策动会去定义，这个材质咱们想看这个时候没有那个时候润滑，这个时候会比那个时候也是深一点。那咱们在规范光的环境中，就会先放一些规范的资产，如一排石头、一排技术桶之类的。这样的话，你就会把新生产进去的材质放到外面去做比拟，看看在他的那个维度下面是否属于一个正确的地位，就能确定你的货色做对了。
这个是在咱们另外一个我的项目的非 PBR 渲染当中，是同样一个过程，只不过它的格调不一样。咱们须要确定风格化的着色器模型，每个角色要用一样。也是要去确定它的光照环境，角色光、虚构光照和 GI 烘培。
这个是咱们方才说的，profiling 过程中会波及到的一些检测伎俩。第一排第一张图是针对渲染过程，咱们把每一个渲染层级，或者他在渲染管线上的每一层级的奉献可能独自拿进去去查看，这样的话就是对于 TA、美术来说，效率会比拟高。
第二行这个是来检测咱们 MipMap 的应用，这个货色很多引擎都曾经提供了。最初一个货色比拟非凡，是咱们自研的一个货色，它是用来解决什么问题呢？制作人有时候看到某个场景，会说这个场景如同不太好，但美术问他具体哪里不好，他其实很难说进去的。非美术人员是很难去答复，他只感觉那个场景屏不够不够丰盛。那美术问他，是不是我多加点加点轮胎、或者加点什么小部件，你会感觉更好，有时候其实并不是。
那这个货色的作用是什么呢？你看它下面有几张小图，黑的一个柱状图，那是在统计这张图外面每一个像素的亮度散布。一般来说，亮度散布越集中，你的画面就会越突兀。它的比拟高的局部代表亮度高的那个像素，从高区往低区走的过程越平滑，阐明你光照的那个散布越平滑，那阐明细节越多。当然这个货色不是相对的，有一些风格化的游戏和摄影过程中，的确会用到十分强的明暗比照，而且明暗适度十分突兀，这是他的格调。
前面那个黑白的方框，是在统计每一个像素在色域上的散布，来让你去查看是否有撞色、补色。在这些反对的状况下，咱们显著发现：你如果感觉一个场景的细节度不够、光照很平的时候，第一张图就会呈现出一个局部曲线更平缓的状况；你感觉有些场景很好，就会发现第一张图它的散布会略微平滑一点。
最初一个话题是工业化团队建设问题。咱们认为再好的配备也须要人去操作，那什么是最重要的，人才是最重要的。
咱们是一个持续时间十分长的团队，在推动工业化的过程中，咱们其实有一些非凡的劣势，就是自上而下的推动。包含咱们很多工具链该如何做，咱们的对工具链的布局是什么样的、咱们要达成什么样指标、每一阶段要做什么？这些事基本上是我本人在做。
再谈到一点就是灰度推动，咱们没有方法等所有事件都 ready 当前再去推动，那个事件永远等不到。咱们只能在我的项目中，让这个我的项目用得少一点，那个我的项目用得更宽泛一点，然而咱们得保障一点：越往后走的我的项目利用范畴越宽泛。通过重复的迭代，咱们就会失去一个比拟好的后果。
再就是谈一下咱们中台做的事件。咱们中台实现了服务器框架、客户端框架以及渲染管线，还有开发和配置管理工具链的 support。当然，服务器框架和客户端框架基本上都是我写的，前面其他人保护的，起初咱们中台负责人来搞了渲染管线框架的局部。另外有一个团队专门去负责配置管理工具链的开发。
最初谈到的就是梯队建设的问题。当初游戏开发动辄上亿的估算，是非常复杂的信息管理体系，这些信息管理体系如果须要人去操作的话，须要保障这个团队的延续性，和一个继续的自我迭代。咱们有一个操作的办法，即在中台设立一个所谓的教导队。
这个教导队是干什么的呢？他会重度参加公司的某一个我的项目。在这个我的项目中去迭代咱们的框架代码、渲染代码，包含开发管理工具链的利用。同时，这个教导队的人员来自咱们每一年的校招，筛选的天花板比拟高，并且被公司挪用足够的人去做密集的造就。这些人将来也是公司成长的要害，他们会逐步成长为小的力量、大的力量，以及到公司的技术负责人。
这个造就过程谈判到价值观和方法论，咱们认为价值观是第一位的，方法论只是术，价值观才是道。我常常会跟大家说，开发过程中“勿以善小而不为，勿以恶小而为之”。
勿以善小而不为，因为开发的过程太庞杂了，有很多细节，你如果感觉某个批改很小懒得做，那就永远不会产生大的提高，必须从一点一滴去做起。而勿以恶小而为之，开发过程当中其实有很多“恶”，是一点点小的不标准。这些货色如果不去做管控，起初的人看到你放低对本人的要求，这个事件就会越来越大，始终滚到一个无奈拾掇的境地。
还有一个是积攒和传承。后面也说过，咱们曾经长达数十年去做实习生的造就，当初公司很多开发骨干和管理人员，都是过后新近造就进去一些人，这是公司外部自身就存在的需要。我感觉咱们公司存在的一个很重要的指标，就是让认同咱们价值观的人，可能有一个适合的工作环境。
咱们也会和一些大学单干，一开始从大二大三去建设兴趣小组，起初逐渐跟学校单干，建设实验室。实验室也会有美术专业和计算机专业的人加入，咱们去单干做我的项目，并且咱们还制订了一些课程，包含各种根底的内容、引擎的应用、编程设计方面等等。
这其实就像种一颗树，最好的时候是十年前，其次是当初。只有咱们一直去做这个事件，这个行业才会有倒退、薪火相传，可能做出更好的产品。