最难啃的游戏「工业化」，这家北京大厂闯出来了？

紫龙对工业化的探索和理解，或许值得大部分厂商参考借鉴。

以下是手游那点事整理的演讲实录：

从PC时代到现在，我们的核心人员基本上保持着长期在一起合作的状态。在经历这么长时间之后，我们也积累了一些对工业化方面的摸索、实践和心得，今天就来和大家交流一下。

首先，我们团队有个「缺陷驱动性开发」的理念。就是当问题发生，出现了一个缺陷之后，我们会尝试去理解这个问题是如何产生的，然后思考如何去解决这个问题。那么引申到工业化，它到底是用来解决什么问题呢？

在我们的视角里面，工业化首先要解决的是工作结果交付一致性较差的问题。比如说做一个模型或者角色，不同美术人员产出的面数差异、或是贴图之中的材质差异，这些东西都代表着一致性比较差。

工业化的反面，其实就是「作坊化」。作坊化意味着工作过程的一致性较差，进而会导致产出效率降低，以及信息传递的缺失、低效和失真。

比如说策划给美术传递信息的时候，如果产生了一些失真、或者信息没有传递到，结果就一定会产生一些反复和迭代，浪费不必要的成本。在传统的作坊化工作底下，这种流程通常是很难保持高度一致性的。而不同工作人员之间工艺上的差别，也会导致最终成品的质量出现参差。

基于前面这些为基础，我们其实很难去定义开发过程当中某一个任务是否完成，以及完成的界定准则和参数到底是什么。所以会导致，我们无法描述这个任务应该在什么时候完成，以及完成之后还会不会迭代。那么开发过程的信息管理就会非常混乱，可控性也变得非常差，并最终造成时间成本失控，交付质量受到影响。

在我们的视角之下，游戏开发工业化应该由哪些方面构成？第一，要保证工作过程和结果的正确性和一致性；第二，在这个基础之上需要保证输出效率。

为了保证一致性，首先要注重开发过程中的管理规范，其次是针对游戏行业本身，我们在工艺流程方面也会存在一些具体的规范。

在有些规范的情况下，我们能够靠人力去保证一致性。但规范定得越细，检查越严格，工作效率整体也会下降。这时候就需要靠一些开发过程管理的数据化和工具链，以及制作工艺流程环境下的数据化和工具链，来使效率得到合理提升。

接下来我们分解一下开发工程管理规范。

第一，它是以通常意义的软件项目过程管理为基础，像我们以前去做传统软件，也会用到一些项目管理的软件，比如说微软的project。

第二，我们最开始要解决的一个基本问题是信息流和决策流管理。整个开发过程的管理，它的人员组织结构应该会形成一个树状结构。就像军队指挥打仗一样，如果没有一个很好的树状结构，信息流并非通过根节点才能流向叶节点的话，就会出现策划直接和执行层面的程序和美术进行沟通，来进行一些密切的迭代。

这就有可能导致你的leader，以及承接需求的leader都无法判断，这些信息是否和原有体系自洽。在他们不知道的情况下，后续流程可能也没办法正常开展。所以作为基础，我们需要把信息流和决策流的管理做好。

至于开发过程管理规范和工业化的关系，其实开发规范并不依赖工业化存在，在我们没有涉及到工业化概念的时候，其实就已经在用一些简单规范的调整。

第三，工业化一定会带来流水线的制作成本，那么针对这些新的流程建设，我们就需要对原有的开发规范，进行一些适配和调整。即使在有规划的情况下，随着项目发展、以及同一套工业化流水线在不同项目中的应用，具体开发规划同样需要作出调整。

这个地方特别要去避免，比如说开发规范的具体执行人都是PM团队，会经常出现一些任务导向倾向，把规范里面规定的几个流程做了，就算没责任、尽到自己义务了。但事实上我们需要向他们灌输，做一个规范或条例的目标是什么，为了实现怎样的目的。在具体环境当中，如果没有达成相应目的，就应该分析一下，到底是执行环节出了问题，还是规范本身有问题需要回答。

第四，开发过程管理需要数据化。数据化是工业化的基础，我们的工具里面给每一个任务打了很多标签，有功能范畴方面的，比如它是某某系统，是属于战斗还是属于技能；还有它在岗位上的标签，因为我们经常会为了某个功能范畴任务扭转很多个岗位，那么这个任务到底是属于哪个岗位，就是把整个开发过程原数据化去定义它。

那么，如何保障上面这些东西执行？我们会在开发规范上面去定义运营立项的各个阶段、每一个版本，它要达成的目标是什么、它要验证什么，在达成了某个目标之后，才能往下继续走。这其实是为了在前期尽量减少成本，解决一些未知问题。

在我们的观点里面，工业化本质就是建设流水线。建设流水线会涉及到成本问题，所以说预算比较小的项目，就需要权衡自己值不值得发动大家去做这件事。除此之外，改动它的成本也非常高，注定了它会有某种局限性，只适应于为某个目标特别定制的流水线。

因此，流水线模式和游戏创新实际上存在天然矛盾，通常我们会用项目过程管理规范中，对每个版本的要求去缓解。

搭建流水线过程中有两个重要的版本：第一是核心游戏性验证法，一般很少有美术会参与，尽量采用白模和既有的美术资源进行核心游戏性和3C的验证。

接下来，我们会进入美术原型阶段，需要确定美术的风格，去为每一种工件制定标准、说明美术工件的复杂度。复杂度标志着它的生产成本，并衡量游戏当中对于这种复杂度资产需要的量是多少，这几件事情是进入Alpha0阶段的前提。

在Alpha0阶段当中，要解决的问题是为构成游戏的零件去制定最终规范以及定量，然后再为这些零件制定每个环节上的检查规范，以及哪个岗位的人来做这件事情。

这里我拿了内部工具的几张图给大家做例子。在UI系统制作上面，首先我们会去画一张流程图，来定义对于某一个美术，或者内容资产，我们要把它分解为哪些步骤。这个图上面其实已经包含了很多check步骤迭代，以及一些整合、调试的步骤。

另外一边就是我们和流程图配套的一些规范。这个规范是遵从于我们「缺陷驱动」的开发，当我们发现某个地方出现问题的时候，需要去为它拟定一套新规划，添加到原有体系当中。不断去做这个事情，就会使得你的规范越来越完善。

下一个是《钢岚》中机甲制作的一些规范。我们对很多工具都有进行二次开发，因此必须按照我们自己的规定安装使用，包括工具环境、机甲比例范围、面数都包含在规范里面。

开发过程管理的数字化和工具链，我们在项目管理当中使用的是Jira和Project。Jira，比较适合每个人只关注自己能看到的任务条目，Project比较适合让管理者能够看到任务和任务之间的依赖关系以及时间关系。

另外在经过反复调研之后，我们最终选定了Perforce。它最吸引我们的一个功能是和Swarm的联动，在迁入以后可以去自动做Review环节的联动。CI环节我们用的是Jenkins和一些自研资源检查工具。

还有一个就是我们自己开发的消息通知软件DevMeg。这个东西是为了解决项目当中的信息丢失。比如说我开了个分支，要求后面针对某个版本的切入，必须在另外一个分支上做，这个时候往往有美术说我不知道，你也没办法专门找人盯着他，向他确认。最好的方式就是做个软件，把这个Message Box以窗口的方式弹在他脸上，不点确认这个窗口永远不会消失。

如果把我们整个开发流程看作一个Excel表格，表格的内容就是版本的需求，然后各个组长再进行任务拆分，只拆分单个任务或者某个明确要分解成哪几个任务的条目，但在这个阶段先不安排时间也不安排人。

之后通过工具把这个表格导出成一个最初版本的Project干燥图，在干燥图上就能够非常清晰地看到这些任务在时间上的关系，当安排了人员和资源之后，哪个地方会成为长板，就把它调整一下，把多出来的调到其他任务上，使每个人员和资源的使用都非常清晰明了。

从b角度来看，整个任务的b型开发流程和初步开发流程都会非常清晰，然后再通过内部的扩展工具导入到前面的干燥图里面，这样就会在每个人身上形成对应的工作条例。每天完成工作之后，只需要把相应的工单设置为「已完成」，然后再同步回Project的干燥图。

再通过每天同步的自动报表，把所有类型任务的完成情况、完成比例以及拖延情况统计出来，同时把同步好了的干燥图发给公司领导，这样就有了一个了解当前项目进度的高效方式。

当然，我们在嵌入工单资源或者代码的时候是有一些强制性要求的，会规定在嵌入的时候必须提供哪些信息。其中一个非常重要的信息就是单工单报酬，这个东西一般来说开发人员是没有办法直接签的，这个图在使用的时候是不会看到有这一块的。

一般来说这个领域被调用之后，会触发一个自定义的CI流程，流程会根据工单的类型，涉及的资源，以及嵌入的资源在工程目录的路径里匹配规则，判断工单到底属于哪种资源然去做相应的检查，检查完了以后把这个检查结果贴到使用嵌入人员的工单下面，当组长去看的时候就可以直接看到自动检查的结果里有没有一些不合适或者是虽然不很合适，但可以接受的点。

在这个地方和代码编译过程一样，也有S/L这样的机制，就在开发前期的某些版本可能会允许模拟版本的存在方便往后迭代，但在比较正式的版本分支就会确定CI就已经签进去，然后主管看完以后就会决定要打回去重做、修整或者是接受嵌入。

通过这种方式，能够最大程度上保证每一个环节提交的东西都是符合标准的，而且提供整个制作工艺流程、美术生产过程的数据。当然这些东西都是有特殊性和通用性的，每个项目的美术规格都有差异，风格也不一样，有写实的，有卡通的，跨平台的预算分配也不一样，这些东西都要和项目组沟通以后，反复测试才能定下来一个符合当前项目的标准。

而且很多项目也存在一些自定义的媒体资源，特别是一些预制件，在别的游戏当中不存在，在它这里存在，这些预制件就有自己的一些规范，这就是特殊性。如果要单独为每个项目开发一整套供应链和流水线，这样的话成本太高了，所以通用性上面，我们一般是把整个功能和要落地的过程，分阶段和层次去实现。

首先我们会有一个跨项目的数据规则框架和工具链的框架，然后在落实到具体项目当中，会把数据规则框架进行配置，就是数据驱动的规则模板，比如说每个项目都会去检查某个资产的面数，面数就由项目组自己去制定。然后还有工具的组件化和部署，整个工具链必须是要考虑好组件化的，不能说只能搞个全家桶，得允许项目组去选择某些组件来部署。

在这个地方我们其实也做了一些部署框架什么之类，然后我们在有些环境下面是直接用的收藏处理，就是把部署好的环境一股脑全迁到应用环境里面，这样更新的时候也很方便。

后面我举两个例子来说明美术方面的一些数据化和供应链，一个是美术资源从源头导入，另一个是材质一致性的验证。

首先是美术资产的源头导入，这些资产在生产完了以后，第一件事是要导出，在导出的时候我们就会利用一些二次开发工具来检查这个资产的命名规则和层级结构，还有顶点数据有没有把一些废数据也一同导出来了，或者是一些面参数上面有没有符合我们的要求，就诸如此类的一些东西。

裸资源出来以后，第二步就是导入。这些资源进入了系统之后，比如说场景里面的这些资源放上去以后，我们会通过一些Python工具做一些初步验证，看这些东西组合在一起是否符合要求，这些工具后面我们会再详细介绍。

当在引擎中的生产过程完成之后，上传时就要做CIA检测，以及保证进入市场资源的合法性。前面已经说过了，然后这里要谈的是材质一致性的问题。以前我们经常会遇到在一个游戏当中两个不同的场景，这两种不同场景：一个是晴天，一个是阴天。

哪怕是同一个美术，有时候也会犯这样的错误。因为他为了达成最后美术画面的呈现效果，有些地方是要去调台的，比如说建筑物上的材质和颜色，有的地方是靠调光来拉长，跟其他地方一比就非常的不一致。

当做一些全局后期处理的时候，这件事情的重要性立马就凸显出来了，不做动态的报告可能这个问题还不会暴露，但是当问题暴露的时候再去反复去找问题源头，成本就变得很高。

所以在处理这种问题的时候，一个首要前提就是要搞清楚最后画面每个像素的颜色贡献，在光照在着色渲染上面它到底分哪几个步骤，每个步骤的贡献到底是什么，然后再针对每个步骤进行计算机制的对齐和最终贡献结果的对齐。

比如说PBR的渲染，我们首先要确定的是物理着色器模型，然后再确认光照环境。比如说要验证模型必须有一个标准场景，那我们如何来保证这个「标准」是正确的呢？我们首先把它推进去炫一下，看看它在缺陷环境下看起来是什么样子的，然后再用我们自己运行期的渲染方式。这两个结果一对比就不需要比较每一个部分的颜色差异是否在一个可接受程度内了。

基于标准光大环境的话，就可以把一些后续增加的材质放进来。因为在标准观察环境中会有一些能够先放的标准或者资产，例如一排石头或者木桶之类的，这时候把新生产出来的材质放到里面去做比较，看看在维度上面是否处于一个正确的位置，那就能确定你的东西是不是对的了。

在换一个项目之后其实也是同样的过程，只不过风格不一样就需要确定风格化的逻辑模型，然后再确定光照环境，角色光、虚拟光的分配。

这个东西是我们刚才说的开发过程当中会涉及到的一些检测手段，第一排第一张是我们渲染过程中把每一个渲染层级，或者在渲染管线上每一层的贡献都能够单独拿出来检查，这样整个效率会更高。

这里第一个是rp6，第三个是检测整个UV使用的分布均匀程度是否满足要求，第四个是检测金属度，看有没有一些异常设置导致它不work的情况，第五个是我们iou选的预览。

第二行这个是我们来检测我们mic的使用，这个东西倒是很多引擎都已经提供了，最后一个东西就比较特殊，那是我们自己做的一个小工具。

这个东西是解决什么问题的呢？

经常会有制作人看某个产品，会说这个产品画面好像不太好，但是要问他具体哪里不好又很难说出来。这个问题其实非美术人员是很难去回答的，但他能感觉出这个场景平，不够丰富，每次问他是不是多加点什么小物件以后感觉更好，答案都是：是。

所以很多时候并不是加的这个东西有什么具体作用，而是一般来讲在一张图里面，每个像素的亮度分布越集中，画面就会越突兀，从高区往低区走的过程越平滑，说明光照的分布越平滑，细节越多。

当然这个东西不是绝对的，因为有一些风格化的游戏和摄影过程中，确实会用到非常强的明暗对比，而且明暗过渡非常非常投入，这就是它独有的风格。

后面彩色的方框是什么呢？其实是在统计每一个像素在色域上的分布，来检查是否有撞色，有堵塞这些东西。有了这个工具支持之后可以明显地发现：当一个场景的细节度不够，光照很平的时候，它就会呈现出曲线很陡峭的情况；有些场景很好，它的分布会稍微平滑一点。

现在有很多时候还会谈到一个话题是工业化和城市建设的问题，但我们认为再好的工具也需要人去操作，人才是最重要的，对吧？在推进工业化的过程当中，我觉得我们是有一些特殊优势的。因为我们是自上而下推进工业化的原则。

包括很多供应链该如何做，需要一些什么样的供应链，对供应链的规划是什么样的，我们要达成什么目标，每一个阶段要做什么，这些事基本上是从上往下传达的。

还有灰度推进，这个我们只能在项目当中用得少一点，那个项目用得更广泛一点。但是得保证一点就是越往后面的项目，它应用的范围就越广泛，通过反复的迭代，一个项目一个项目地迭代，才会得到一个比较好的结果。

再谈一下我们中台做的事情，目前我们的中台完成了服务器框架、客户端框架以及宣管线，还有开发和配置管理工具链。这里其实还有梯队建设的问题，现在游戏开发动辄上亿的预算已经成为了一个非常复杂的信息管理体系，这些信息管理体系如果需要人去操作的话，首先就需要保证团队的延续性和持续的自我迭代。

这里我们也有一个操作的方法，就是会在中台设立一个所谓的「教导队」，这个教导队是干嘛的呢？其实他们会重度参与公司的某一个项目，在这个项目当中迭代我们的框架代码、渲染代码、甚至供应链的开发管理和应用，都会在这个项目中做迭代。

同时教导队里面的人员来源也是我们每年在校招里面挑选的，天花板比较高，并且公司也有足够的预算去做这样非常密集的培养。

因为这些人未来就是公司成长中的细胞，他们会逐渐成长为公司的技术负责人。培养过程其实就会谈到价值观和方法论，我经常会说在开发过程当中叫勿以善小而不为，勿以恶小而为之，为什么呢？

现在一个开发的过程太长太大了，有很多的细节。如果觉得某个修改很小就懒得改，那就永远不会产生大的进步，我们必须从一点一滴做起。那开发过程中的恶又是什么呢？

是哪怕只有一点的、小小的不规范、不一致，这些东西如果不去管控，时间长了就会「伤」，当后来的人看到连你都放弃了对自己的要求，那这个事情就越来越伤，越来越严重，最后发展到无法收拾的局面。

最后谈到的就是积累和传承，前面也提到过我们其实一直有在做实习生的培养，现在公司内也有很多开发骨干和管理人员是很早期公司内部培养出来的人才，公司内部本身就存在这样的需求。

其实我觉得我们公司存在一个很重要的目标，就是让认同我们价值观的人能够有一个合适的工作环境，让大家工作得愉快一点。

我们现在也会找一些大学去合作，从大二大三开始建立一些新小组，后来甚至建议跟学校合作建立实验室，实验室也会有美术专业和设计专业的人去参加合作，去做项目，而且我们还制定了一些一些课程规范，包括基础和细节的内容。

实际上就像种一棵树，最好的时候是10年前，其次是现在。只有不断去做这个事情，这个行业才会有阀门，然后薪火相传做出更好的产品。我的分享到这就结束了，谢谢大家。

—— 点击下方公众号名片，即刻关注我们 ——

———————  Ps  ———————