什么是游戏开发流水线？以及我们为什么需要他？

          其实在平时的游戏开发中，大家很少有人聊到过 ”流水线“ 这个名词，似乎他和游戏开发相去甚远。但实际上，他就像饭菜里的盐一样：平时不见踪迹，但缺少了他，难免疲乏少力，进退失据、少了那么一些味道。

        鉴于大部分开发人员都对游戏开发流水线缺乏了解，这里我专门花一个章节来讲讲，什么是开发流水线及其作用。

1、什么是开发流水线？

        游戏开发流水线，即从构思到成品的一系列过程。

        相信有的朋友已经迷惑了：哪个项目不是从构思到成品呢？

        诚然，所有项目都是从构思到产品。但关键在于 “一系列过程” 。你经历过的项目，他们的这个过程是相同的吗？有通用的步骤吗？每做完一个项目，能让我下一个项目进行地更快吗？也许，有的项目是先写好策划案，美术和程序再依照制作；有的项目是一边做功能，一边补案子；有的项目做了编辑工具；有的项目有原型流程图……

        然而，如果不能将游戏的开发步骤形成规范，且既能从项目中抽象出来，也能适配到项目中去；复用、解耦、组合……那开发一个项目留下的沉淀就只有个人技术成长本身。如果不能将开发流程整理出来，在项目进行到中后期将便非常乏力：任何改动都牵涉巨大，旧的东西不敢动，新的东西加不进去、项目里总是能发现很多长时间没人维护的资产……凡此种种，都是游戏开发流水线缺位导致的恶果。

        在项目中，我认为程序应该主动承担设计、管理开发流水线的工作。将以往开发的各个流程整理出来、规范化，形成一套标准和操作手册。越是大型的项目，越是需要这样的规范，从而避免项目管理混乱造成的项目崩溃。

        下面，我将介绍几个实际的例子，为大家更方便地理解流水线。

2、示例1：单独的美术工程

        一般来讲，大家开发都是在同一个工程开发：无论美术、策划还是程序都是在同一个工程里制作内容。在项目初期，这种模式能很方便地推进，但是在项目中后期，这样的模式的弊端就非常显著：

• 项目里有很多冗余资源，大家都知道有冗余资源，但没人敢动手去清理；即便专门清理，也很难保证能清理干净，也不能保证不会再有冗余资源。
• 美术上传的资源格式、命名不符合要求，但直到上限了才发现；
• 项目中存在许多编辑工具、早期的Demo、废案等。
• 某资源使用时需要同步配置一些数据、辅助资源，而老是有人忘记……

        这种在传统项目中几乎是无解的，即便是使用了分支管理，但对于策划和美术来说也过于复杂。我们开发流水线的目的，就是将大量程序性的工作嵌入到开发环节中，尽可能解放生产力。这里我将项目进行了重新整理：

        如图所示，我将工程拆成了4个：

• 正式工程：表示游戏开发的最终工程，用于打包和功能开发；
• 美术工程：或者叫资源工程，存放各种美术素材、音效等；
• 设计工程：用于前期验证功能做Demo的工程，临时配置、测试用；
• 同步工程：辅助工程，用于帮助几个工程数据同步用。

        平时美术制作的资源，就上传到美术工程里，并不直接导入到正式资源。当需要时，则通过特定工具进行导出（我将这个导出工具做成了一键式）：

        那么，在美术工程进行导出时，我就可以做以下一些工作：

• 检查所有资源合法性，例如不能重名、贴图规范等；
• 将需要烘培的资源进行烘培；
• 检查配置表和资源，检索缺失资源。
• 将资源按照一定规则整理好，并放到对应文件夹中。

        而且，因为正式工程的资源都是从美术工程拉过去的，所以正式工程的资源每一次导出都可以全部删掉。每次导出时，都是根据配置表决定需要哪些资源，所以从机制上就避免了冗余、重复、资源缺失。

        虽然在开始阶段，大家对这个流程有一些不适应，但随着项目进行，也都认可了其带来的好处。例如，有一次发版本前夕，工具反馈有资源缺失导致导出失败，相关人员立即就进行了处理；从而避免在版本发布后再发现丢失资源的情况。

3、示例2：白模与工作协同

        如果在游戏里要做一个场景，且要针对这个场景设计一些玩法，一般情况下大家会怎么做呢？相信很多项目都是这么一个流程：

        策划也许会讲一下概念设计，但后面美术再去做对应的岛屿/关卡，然后策划再看着这个完成的场景配置玩法、程序开发对应功能。看起来没啥问题，但实际过程中却进退失据：

• 程序和策划需要等美术完成之后才能开始；
• 美术后期根本不敢动场景设计，因为已经配置了很多点位、玩法在现有地形上了；
• 一旦设计上有不合理的地方，同样难以迭代，牵一发而动全身。
• 一旦有结构上的问题（例如场景做小了），只能全部推翻重做。
• 铺量=堆人，一旦要批量制作关卡只能无限地增加人手；

        为了项目后期不崩溃，我设计了一套基于白模的开发流程（具体流程后面会提，这里就不详细介绍了）。简单地说，就是用白模把各个部门隔离开：策划设计白模、程序基于白模制作功能、美术基于白模制作场景。

        这样，就将以前的串行流程变成了并行流程，极大地加快了开发效率。同时一些不合理的设计，在白模时期就能暴露，节约了返工成本。

        白模流程由于一开始就确定了一个交互原型，给美术设计划定了安全区和边界，美术迭代起来也减少了顾虑：不必担心多摆放了几块石头就造成了逻辑错误。

4、各项目通用库

        有时候我们在开发时做了很多通用的工具，例如将场景转换成预制体的工具、将预制体转换成数据结构的工具、一些通用的数学库等等。写得好的工具，或者叫插件，各个项目都可以无缝接入，立即使用。

        这里我们就用了 UPM 的解决方案，可以参考这个：

【Unity】UPM解决方案：苍耳_unity upm-CSDN博客文章浏览阅读2.1k次。在进行Unity游戏开发的时候，一直有一个痛点，那便是相同功能的代码在不同项目之间如何共同使用？苍耳提供了一个解决方案。_unity upmhttps://blog.csdn.net/cyf649669121/article/details/127751098        通过这个方案，我们可以一边开发项目，一边收集公用的库，然后提供给其他项目使用，从而加快开发效率。像这种边际成本为 0 的工作，我的建议就是多做。

5、写在最后

        开发流水钱，小到一个工具，大到整个项目的开发管理，都可以囊括进来。他其实是工程化思想在游戏行业的体现，是将游戏开发从手工业升级为工业的必备步骤。

        如此美妙的东西，推行起来却充满困难。因为大家都习惯了旧的开发方式，不愿意走出自己的舒适圈。持续学习，无论对于谁都是一个痛苦的过程。之前随意的开发流程，对于单个人员来说确实方便，但规范了流水线之后，便不能随心所欲……

        即便我们看到了流水线带了很多优势：资源错误检查、并行开发、加快其他项目的开发速度……，但真正要想用好还是要强而有力地项目管理。可惜，大部分程序也不愿意走出自己的舒适圈，主动承担项目流程的责任，毕竟对于程序来讲，本职工作只需要编写好自己的程序就可以了。然而，如果不关注程序外的事情，总会遇到程序解决不了的难题。

        无路是什么流水线，最终都要落地到具体的人。再好的开发流水线，执行的人不行，那还是不行。从设计程序本身，到设计项目工程，这也是程序员的重要一步。祝愿大家都能早日找到自己的 “银弹” 。