最近和很多人讨论如何优化他们现在的开发管线。在这里也做一些笔记。费了好大劲写的，点赞收藏再看吧。一、定义与作用游戏管线，或者游戏开发管线，指的是一种“工作流程”。每个游戏项目因为其选择的核心玩法、渲染风格、叙事方式或者纯粹的体量要求，都会导致管线的特异性。这个所谓的“管线”在一个项目中，不是一个，而是会有许多个。这些管线交织在一起，形成针对不同资产、不同阶段的游戏内容生产轨道。它们彼此关联，互相影响。好的游戏开发管线有两个最显著的作用：提高质量下限、优化整体效率。也做出一些足够出彩的细节来吸引玩家是必须的，但是这和工业化与提效不冲突以一些常见的情况来举例：有多少团队会在“结版本出包”这件事上让整个团队停下来几天，甚至数周？有多少团队会出现游戏资产的质量参差不齐，有的很精致，有的很拉跨？有多少团队会经常出现”开发瓶颈“——大家在经常要等某几个人，这几个人的进度决定了整体的进度？而这些问题之所以存在，正是因为”电子游戏“是一种”拥有商业属性的高技术浓度装置艺术“。这种产品与传统互联网产品完全不同，反倒是和汽车工业等有点像。一个优秀的产品往往具备设计壁垒、技术壁垒、工作量壁垒中的至少一个（常见的大多具备两个以上）。而前两个壁垒在小型独立游戏领域问题可能不大，但是一旦项目成一定规模，就必须建设可靠的开发管线，以保证壁垒的持续和坚挺。而所谓的”游戏工业化“就是游戏开发管线的设计、搭建、维护和优化的过程。二、管线设计大概知道开发管线是怎么回事之后，我们来聊“管线设计”。众所周知，工业化的基础是标准化。而标准的制定，却是整个环节设计的”第3步。第1步，是做Demo和立项 —— 大家先说清楚我们做的是啥。很多时候立项只是因为有个“点子”。这本身没有问题，但是实际上这个点子是否成立是需要实际论证甚至验证的。因为不是所有人都具备足够的“演绎法”能力，为了不让以后出大麻烦，开发团队需要在一开始就锚定整个项目的目标，并用Demo将这个目标讲清楚。在这个Demo的开发过程中，整个初始团队要进行疯狂的磨合，一方面了解团队和目标的关系，一方面探索流程的合理性。又可能你脑子里想的内容不多，但是为了让Demo成立，会衍生出一堆东西来在这个阶段中，我们还需要确定几件事：美术资源品质要达到什么程度。标准形态下的核心玩法需要做到什么程度。达到这个程度，当下最合理的工作流是什么样的。为了展示上述内容，我们有什么资源是必须新做？用尽可能少的“新资源”来制作Demo，说明标准和目的是一种能力第2步，制定里程碑 —— 别一下子把摊子铺太大，大家一起向一个方向用力。在这个阶段，大家需要圈定好项目的边界和范围。然后根据团队的能力和预算，分好开发阶段。尽可能不要在实际开发走起来之后，发现做每一件事都需要打补丁和产生不可预估的前置任务。在这个阶段中，我们需要确定几件事：项目一共有多少内容量。说清楚有多少功能、多少玩法、多少系统。根据我们的产能，制定多个可以量化内容的阶段。每个阶段不能超过三个月。（团队必须能用文字清晰的描述每个阶段——里程碑 的验收内容和每个内容的保准。如果可以的话，用形象的语言描述此时如果是玩家能看到什么、体验什么。）详细的拆解每个里程碑的开发内容，排清楚开发顺序。之前我们自研的一个项管系统的某个版本第3步，现在，我们就可以面向目标定标准了。这里的标准主要包含两部分：流程的标准 —— 大流程包括了谁先谁后，前置环节做到什么程度才能启动后置环节，每个不同类型的需求由谁发起，谁跟进，每个环节的负责人如何指定，最终结果谁负责。资产的标准 —— 除了各类美术资产，也包括策划资产、技术资产，甚至会议记录的内容。而管线的设计也就由此开始：简单的游戏资产管线设计：明确的规范游戏开发的每个环节，包括资产的生产，人员的协作，并作的验收，多个成果的组合。这个是飞书项目你必须可以明确的描述游戏开发流程中每个资产从无到有的各个环节的负责人，以及每个开发任务的前后置关系。不同事项的依赖关系和优先级定义：有些需求虽然看似明确，但却依赖于其他的需求的结果；有些需求虽然看似关键，却是个无法确定耗时的“研究”；有些非常耗时的研究和探索，可能会导致后续工作流的变化；有些工作项是尝试性的，可能其成果不一定会真的有用。这些工作项可能彼此依赖，或在冷静的讨论下被调整优先级。因为团队的规模有限，需要在项目开始的时候决定好，每个人在每个阶段的工作重心是什么。尤其是每个领域的核心角色。第4步：管线的维护和优化管线优化的主要目的是提高效率，那么就会有如下几个方向的思考：优化单个环节工活儿的时间人员的适配在这个环节是最有感觉的。优秀的项管人员能将合适的人放在合适的活儿上。很多工具、插件也是在这个部分发力的。此时，管线的设计者需要明确的判断这些工具的价值和影响：这个工具的对象是雕花还是铺量，提高质量还是提高速度，代价是什么？这个工具的引入带来的影响是一个人的还是一条线的还是一个面的，对整个团队来说整体的结果是不是利大于弊？尤其是在AI时代逐步来临之后，越来越多的工具在这个环节努力将已经标准化的流程从工业化推向智能化。但是这往往带来工作流程和团队结构的改变。需要有额外的管理成本和人员培训成本。比如我们为之前公司设计开发的剧情动画工具↑，它是个服务，由插件和引擎关联我们可以很清晰的描述它的定位就是铺量，能够保证整家公司剧情表演动画的下限。它的利弊：但是它无法负责雕花。它能将剧情动画的铺量工作从数周一条变成一分钟一条，而且可以让剧情策划直接操作。在策划完成这部分工作后，让剧情动画组或者PV组的美术同学在此基础上做选择并优化结果。它产生的开发管线影响：它需要项目开发团队的工作流程和资产准备的顺序产生影响，需要团队更早的规划每个角色的动作库。释放剧情动画人员的人力需求和时间需求，大幅度降低这个环节前置步骤的开发成本。衡量下来整体是增利大于弊的，而且利弊对比悬殊。这个工具也因此成为了在全公司在全国各类团队中都非常受欢迎的自研提效工具之一。当发现因为“标准不明确”导致的返工时，要格外注意。有些时候，“你之前没说清楚”或者“我怎么知道你以后要这么做”是一个很容易被忽略的管理问题。作为管线的维护人员，我们绝不能把这种话看作是“甩锅”。绝大部分的人，都不存在能力问题。但是大部分人都是不想“为沟通浪费时间”。那么如何让单次的沟通更有效率，更准确，是要时刻去关注的。这也是帮助团队中一个管线下的各个环节形成默契的手段之一。“你为什么不看文档”和“你开会的时候怎么没说”。也是在规则之上要针对“人”去做处理的。当然，如果某些可以量化的标准是普遍要遵守的，也可以做一些工具出来：我们曾经为美术开发过资产检查工具，检查不通过是不能上传到库里的优化整体时间这里其实更多的是和很多“一直以来都是这么做的”去较劲的，冲破历史和习惯的枷锁。时刻关注耗时的高峰，将削峰作为使命。游戏开发的过程中，经常会出现一些计划外但又无法预估耗时的事情。比如每次“打包”“打版本”前的混乱。包括了冲突、配置错误、因为性能不合规导致的资源修改和不合适的渲染方案优化。其实所有有点经验的开发者都知道这件事应该前置。但是本来每个人的开发工作量几乎就是排满的，而且屎山上的屎也不全是自己的。种种原因就会导致谁也不愿意提早进行这部分工作，就算想，这件事的优先级也提不起来。所以，削峰就成为了一个要去“设计”的事情。比如说，使用UWA等工具在游戏第一次成功出包之后，就进行全自动的每日打包，配一个自动安装启动的脚本。这个脚本每天后半夜运行。指派一个人，早上来了看一眼，如果失败了，就立刻找人解决一下。让问题不堆积。在此基础上，我们完全可以做一个简单的性能监控脚本，这个脚本就是打开游戏里一些主要的功能玩法，和美术、程序最担心性能问题的地方。每周一次，周末自动运行，只要包打的出来，就去这些地方跑一下，把性能记下来。周一上午让主程主美引擎TA一起看一下，如果发现又隐患，立刻插个小单下去，争取周三之前就消化掉。我们在前司的部分项目中搭建了这套流程，有一套自动化的SaaS守护着这些项目，他们也从来没位这种问题担心过。日常监控设备墙减少瓶颈环节的存在感这里主要针对“科研”类任务。这些任务往往拥有很高的必要性和不可预估的耗时。所以，这些事必须做，但必须“单独处理” —— 不把这件事放在里程碑的常规规划里，而是作为一件单独的时间线进行管理。所有它的后置任务先不排。能不能流出人力Buffer看团队的实际情况而定。但是反正不能让别人等它。注意，瓶颈工作项是一定会存在的，但是如果你想打造一个健康的工业化管线，就要努力让瓶颈工作项的影响范围更小。合理的利用工具进行职权转移每个岗位都有他自己的“垃圾时间”。比如，我会认为界面最上层的逻辑和某些关卡元素的搭建对于前端来说，就是垃圾时间。因为这些事对于策划和UX来说可能是需要频繁调整的事情，而这些事对于这两个工种来说是非常必要且持续的，对前端来说就是细碎且没有营养的。于是我会非常推荐使用一些图形化编程工具，让非技术人员可以先把Demo和效果调到满意，再让真·程序员去把最后一公里走完。这件即节省了程序的开发时间，也节省了程序与策划和UX的沟通时间。当这些非技术人员培养出来后，关卡玩法、社区功能、UI制作、表演控制都可以由他们来完成了。（从某个角度来说，这也是省钱的方法，毕竟程序的时薪比别的工种都贵啊）我们甚至为这件事开发了一个专门给策划用的逻辑编辑器持续提高环节通过率这是每一个管线维护人员都要去因地制宜去思考的。尤其是一条新管线在刚跑起来的时候，一定要持续跟进一段时间。观察环节和环节的交互是否顺畅。有些时候，规矩是好的，但反人性，也需要规则的设计者进行换位思考。而且在早期不要害怕尝试，也不要怕挨骂。举个例子：我曾经有连续两三个月对一个大型项目的五十多个管线进行大规模的删减。最有趣的是，大部分时候，我删掉了一些环节，整个团队毫无感觉 —— 这些环节规则上存在，但是因为反人性，所以大部分团队成员是不愿意遵守的，甚至已经故意无视它们了。而在这个时候，你要意识到：因为这些环节的被忽略，一定有风险和隐患出现了，我们需要去检查之前的产出物，看是否有问题。沟通方式优化、文档内容减少废话、规范和标准的清晰、不墨守陈规的尝试新的工具都是要去做的事。尤其是努力尝试将垃圾时间释放掉。比如我们会意识到大部分项目的美术资源规范是程序制定的。但是当美术不遵守规范时，程序很难主动张嘴去维护这个规范 —— 一来是觉得还有更重要的事儿，二来毕竟早晚是要做优化的。从削峰的角度来看，这件事就需要去解决。所以我们在请程序为每个项目主要的DCC开发了资源检查插件 —— 这个插件的目的除了给美术增加约束外，还必须具备让美术舒服的功能：美术可以通过插件直接上传资产到库里。通过插件上传的资产可以自动关联工单，美术同学再也不用去网页上去改任务状态了。自动生成复合规范的命名主体，美术同学只用根据规范写这个东西最后一部分的名字就好。在上传前，插件会自动检查资产规范，如果不复合要求就不让上传。配合一个复合网盘直觉的前端设计，这个产品就很让美术同学感到舒服了总结游戏开发管线必须建立在一个明确的目标的基础上，这个目标包括了核心玩法、美术目标、发行策略等。游戏开发管线的重点在于让游戏能够稳定、高效的生产出来，而并不能解决游戏是否出彩、是否好玩、是否赚钱的问题。它更多的是保证下限。很难说有没有一种范式可以适配所有游戏的开发。因为运作顺畅的管线和这个团队里的每个人都有关系。当年做发行的时候，发现80%的项目都是做不完的。而所谓“做完了”的项目也有80%最终没能走到上线那一步。我自己也曾在做制作人的时候遭遇项目中道崩殂的情况。虽然大环境一定是有锅要背的，但是我们身在其中却也只能继续前行。