游戏工程管理

作者：admin
/
时间：2022年11月01日
/
浏览：1849 次
/
分类：厚积薄发

成为主程，得以主导一款新游戏的技术，所关注的也会从具体的技术点转到工程的协调。技术是单一的具体方法，工程是综合的系统协调，区别于小型游戏的单枪匹马作战，中大型游戏开发是一项系统性工程，因此，除了需要高超的技术水平，还要掌握工程实施的方法。

随着游戏项目规模增长，模块间相互关联，开发成本将成指数增长，工程管理方法就是要抑制成本增长的曲线，让团队能够按时按质完成整款游戏项目的开发。

在工程管理领域，虽说有着传统《软件工程》、敏捷开发和PMP（项目管理认证）的一些实践，不过它们更适用于传统软件开发，游戏项目有着很独特的部分。版本分支怎么管理、代码规范怎么定、如何让多人合作变得顺畅、如何保障开发的质量，这是游戏主程必须面对的问题。然而市面上相关资料并不多，更缺乏体系化的归纳，于是决定抛砖引玉，试图编写《游戏工程管理》。

《游戏工程管理》是作者于2019年9月建立文档，历经三年修改整理完成的文稿，也是作者个人经验的一次总结，适合从事游戏开发的技术人员，希望成为主程的开发者以及希望理解程序工作流程的项目经理。

作者罗培羽任职于广州四三九九公司技术研发中心，多年实践沉淀总结，出产《Unity3D网络游戏实战(第2版)》以及《百万在线：大型游戏服务端开发》等技术经验值成长加速道具书，所著图书被部分高校的软件工程专业选为教材。

本次历时三年完成的《游戏工程管理》已首发于UWA学堂，欢迎关注。

推荐语

现在游戏大环境都在提倡“降本增效”，而如何能够提升整体研发的工作效率就是目前一个摆在各大游戏团队面前的难题。

《游戏工程管理》这本书的出现非常符合现有行业的需求和趋势，如何系统地对项目研发进行科学管理，是游戏项目中每位Leader和资深开发人员都需要了解和掌握的技能。

虽然市面上也有其他工程管理的相关书籍，但是游戏行业相较于这方面较为缺失，一方面是由于之前游戏行业的“短平快”思想，并不需要太过于系统化的研发管理，另一方面则是由于游戏项目的自身特点，相较于传统制造行业和软件行业，创意在游戏项目中的比重要大很多。所以，虽然中国游戏有着二十年的发展历史，但是真正在游戏项目中进行系统工程管理的团队却非常少。该书的出现也正好填补了游戏行业在这方面的空白。

书中提到的多个重点，我读到时都深有感触，“如何规划里程碑节点”、“团队建设与分工”、“性能和资源规划”等等，都是现在很多团队在工程管理中的缺失点，有些团队因为前期没有规划或者规划过于草率，导致中后期各种工作返工；有些团队在研发过程中过于倚重和照搬团队内个别“大神”的过往经验，导致整个团队的研发流程和节奏失衡；有些团队则前期不关注性能和资源规划，导致后期测试玩家“骂声一片”，运营无法上线等等。

诸如上述的问题，本质上都是研发流程管理出了问题。所以，非常建议游戏行业的资深开发者或项目管理者有空静下心来翻翻这本书，希望该书中的经验可以帮助到正在进行游戏创作的你。

---侑虎科技 CEO 张鑫

不知你发现没有，当我们面对未知产生恐惧时，大部分情况下都是因为对事情了解的不够全面，当你了解了事情的来龙去脉后，你会发现在面对它的时候变得从容、自如，这能够很有效的发挥出你的潜力。《游戏工程管理》就是这样一个课程，能很好的帮助我们了解游戏项目从0到1的演进过程，包括技术架构的演进、工业化生成的规范、组织架构、项目规划、人力成本等等等。它能够帮助你从容的面对游戏项目，更有效的发挥你当下拥有的能力和资源。

---《Unity3D高级编程：主程手记》作者 - 陆泽西

这本书是罗老师历时三年的心血。
对于从业多年的游戏同行们，各位基于过往的经历，也许有各种不同的观点与看法。我觉得这是很正常的。如果各位再把己见一并抛出，一起交流思辨，相信就比你单纯看完这本书更有价值。这也是罗老师所希望的“抛砖引玉”。
而对于有志踏入游戏行业的新人，这本书更是难得的分享盛宴。罗老师像一位知心大哥哥，将他从业多年的所遇所想，向你娓娓道来。希望这些内容能让你少一分迷惘、多一份笃定。

---广州四三九九虚幻引擎组 - 陆俊壕

本书根据作者主程成长之路，全面阐释了从游戏项目的技术人员转变为技术管理多面手的思考模式和体系化归纳总结，并在此提出了“游戏工程管理”的概念。将整个体系划分为：软件工程+项目管理两大阶段。
除了给出诸多案例来诠释作者对游戏工程管理的方法和实践之外，本书还通过案例全面展现游戏的业务研发和人员管理，总结了对游戏产品的深入思考。
本书提出的一整套方法体系已在多个项目中推广和落地。

---广州四三九九客户端主程 - 张永明

一、开篇思路

有朋友升职加薪，成为主程，得以主导一款新游戏的技术。我们之间探讨的话题也从“如何做线程调度”、“怎样做渲染”转变为“版本分支怎么管理”、“怎么定代码规范”。如何让多人合作变得顺畅？如何保障开发的质量？这是游戏主程必须面对的问题。然而市面上相关资料并不多，更缺乏体系化的归纳，于是决定抛砖引玉，试图编写《游戏工程管理》。

技术之上是工程

技术（technology）是单一的具体方法，工程（engineering）是综合的系统协调。区别于小型游戏的单枪匹马作战，中大型游戏开发是一项系统性工程，因此作为主程，除了需要高超的技术水平，还要掌握工程实施的方法。

项目开发并不是各功能模块的简单叠加，这就像一位新人，可以开发100款“乒乓球”、“俄罗斯方块”小游戏，但难以完成一款策略游戏。

由于模块相互关联，因此随着项目规模增长，开发成本将成指数级增长（下图左），而工程管理方法就是要抑制成本增长曲线（下图右），让团队能够按时按质完成整款游戏项目的开发。

不过实际项目要面临的情况不尽相同，有的不知道自己想要什么，有的不切实际想投入两三个人对标《王者荣耀》，有的项目缺技术，有的缺人手，有的缺时间，管理项目的方法自然也不同，没有放之四海而皆准的方法。因此我们做出一些简化，将游戏工程管理的范畴限定为：

给定一定时间、较稳定的项目成员、较稳定的项目需求、美术同事合作顺畅的前提下，按时按质完成整款游戏开发工作的方法。

这是很理想的情形，不过只有能把理想情形给处理好，才有可能进阶去面对更复杂的真实处境。就算不能保证项目成功，但至少让技术团队不拖后腿。

现代管理的视角

在工程管理领域，虽说有着《软件工程》和PMP（项目管理认证）的一些理论，不过游戏项目有着很独特的部分。每款游戏有它创意的部分，也有它严谨的部分，而相比于其他工程（如开发APP或造一座桥），游戏的创意部分占据更高比重，工程开发需要适应更多变化。

传统管理学并不能适用游戏项目。传统管理学诞生于机械时代，它适合于工厂生产，通过规范生产流程，使得有什么样的投入就有什么样的产出，而游戏开发有着更多的不确定性。

例如，每个模块的开发时间呈正态分布（下图左），而传统管理学常常使用严格的进度规划（下图右）。两者存在矛盾，若时间定的太紧，如右图中将签到系统的截止时间定在周二，意味着超过一半可能性无法按时完成，致使开发人员只能以加班弥补或为了赶进度而牺牲品质；如果时间定的宽松，开发人员又可能很清闲。

敏捷开发也常在游戏项目中滥用。敏捷开发的主要推动者大多有着外包或技术咨询公司的从业经历，他们的观念必然与从业经历有关联。如果把视角定位在技术团队，把策划当成客户，传统敏捷思路可能比较贴切，如果视角定位在整个开发团队，把玩家当客户，那就要做些适应性调整。我们不能将乱改需求等同于敏捷开发。

《软件工程》中以建筑施工比喻软件开发，两者的确相似，不过却也不同。建筑施工成本高昂，拆除重建更是难以接受，而设计成本可以忽略不计。据网上数据，设计费一般占工程总承包额的2%左右，因此建筑施工会倾向于尽善尽美的做设计。而游戏设计的成本占比较高，反复修改策划案的成本不可忽略，例如在某游戏团队中，策划、程序和美术的成员占比为1：1：2，设计（策划）成本占据25%。有时详细写策划案的时间比写代码时间还要多，致使开发过程中不可避免地出现口头提需求、需求不明确的情形。

有人认为既然开发人员会为了赶进度而牺牲品质，那只要制定详细的验收标准，是否能够保证质量呢？答案是不太可行。出于成本限制，策划案难以做到详尽描述（或者如果很详细，开发人员的理解成本便不可忽略），必然存在模棱两可，不少细节需要依赖开发人员自身经验，标准便无从谈起。

例如，对于“两军相遇，兵力多的军队形成围攻之势”会有多种不同解释（如下图）。尽管这是个很差劲的策划描述，却是某个商业项目中真实存在的。笔者还见过有个SLG项目的策划案写着“两军相遇，士兵像花一样散开”，而这短短一句需求就让程序花了两周时间。

总而言之，传统管理学理论可以作为参考，但不能照搬。

在互联网时代，我们需要用概率视角来看待管理问题。如下图所示，某同学能否按时按质完成开发任务会呈现一定的概率分布。新手缺乏经验，因此有大概率无法完成，老手经验丰富，大概率能够让人放心。

开发流程之构建

开发流程的实施（人们常说的构建现代化开发流水线）就是调整概率分布的过程。如下图所示，某项目组使用“程序开发→策划验收→测试”的开发流程，在经历每个环节后，开发质量满足期望的概率越来越高。

天下没有免费的午餐，流程化中的每一个环节即增加了保障，也意味着成本。按照《人月神话》的说法，完善产品的成本是程序开发的9倍。

有些团队为了严谨，会设置更多环节。如下图所示，先开个“需求沟通会”明确需要做的内容；在想好程序思路后，与技术专家开个“评审会”验证思路是否可行；在开发完成后，再由同事复查代码（code review）。

历经这么多的流程，付出如此多的成本，开发质量得以保障。

随着游戏市场竞争白热化，玩家对游戏品质要求越来越高，区别于高风险的短平快模式，大型游戏公司越来越愿意付出成本以保障品质。就像能量守恒定律一样，稳定的品质不可能凭空而来，在不增加成本的情况下（项目组成员开发水平不变），需要在效率与保障之间做权衡。

开发流程的设计上，可以依据概率分布的思路，评估各个环节的成本和价值。对于新手，安排更多流程以取得保障，对于老手减少流程以降低成本，整个设计过程像拼图一般。

整款游戏的品质受限于各模块的品质。所谓水至清则无鱼，有时候不得不妥协勉强合格的内容以保障进度。若能保持60%的模块与预期相符、20%超出预期、20%勉强通过，则项目可以达到较高的整体水平。

二、第1步：规划里程碑节点

要开发一整款游戏，必先做好规划，把它分解成多个开发阶段，每个阶段有侧重点，整体才能井然有序。

然而“学习怎样做规划”是个悖论，因为做规划很依赖实践经验，单纯的理论只能了解一些皮毛。若没有实际参与过多个项目的开发，很难做出契合实际的规划；而如果经验丰富，那便不需要学。笔者读过不少做规划的资料，但总感觉要不就是大而空的讲一些原理，要不就是介绍怎样制作甘特图之类的细节。若非亲历多个项目，或只能通过大量阅读，借鉴他人的项目开发历程，以便归纳总结。

一些合适的材料如下：
《天涯明月刀幕后》（顾煜）
《剑侠情缘网络版开发回顾》（赵青）
《荒野行动Plus幕后》（周峰）

2.1 案例借鉴

我们以一款SLG手机游戏项目的节点规划为例，说明它的里程碑节点设计。规划方案必先要了解它面临的外部环境，在该公司中，项目立项后需在两个月内提交Demo演示给专家组评审，以评估是否继续开发。而市场竞争激烈，游戏需在8个月后上线，以免错过时机。好在项目组有一些积累，可以拿原先的MMORPG项目底层框架做修改。

团队将整个项目的开发过程分成6个阶段，每个阶段作为一个里程碑节点，如下图所示。

各个阶段的内容如下表所示。

团队在“核心模块可行性探究”和“Demo实现”阶段解决了大部分技术难题；在“前30分钟功能点开发”阶段制定了开发标准，而后按照标准快速“铺量”，完成大部分功能开发；最后两个阶段即作为完善阶段，也作为预留时间。该规划下的开发节奏很紧，不过各阶段时间的比例或有参考价值。（PS：以上内容主要参考@jiacat 大神的经验总结）。

在赵青《剑侠情缘网络版开发回顾》一文中，也总结了游戏开发四个里程碑阶段，如下表所示。剑侠情缘网络版于2000年9月开始筹备，到2003年9月公测，历时三年，虽年代较久远，但依然有参考价值，其整体思路与上述8个月版SLG游戏里程碑规划很相似。

游戏工程的整体开发节奏：先解决关键性技术难点，再验证玩法可行性，最后铺开外围功能模块。

2.2 分解任务

说起规划，必提SMART原则，指要把大目标分解成一个个具体的、可量化到的、有时效性的小任务。所以规划游戏工程，就要把项目拆解成一个个小任务，评估各个任务的开发时间。不过，笔者认为这种想法过于机械，因为它要求规划者拥有全局的视野，不然就做不到合理的量化和分解。

然而技术更迭之快速、市场变化之剧烈，我们更要适应“只掌握少部分信息”来做规划。例如，在周峰《荒野行动Plus幕后》一文中，就提及网易开发荒野行动Plus时，团队面临很多技术难题，前期直接以“开干”代替“计划”。从规划角度看，有时候只有开干了，才能获得更多信息。

如下图所示，一个团队的能力和经验总是有限的，只有少量的事情能够完全掌握，大量的事情是模糊和未知的。例如，让一个成功开发过多款MMORPG游戏的团队再做一款MMORPG，他们能够在一开始规划好各种开发事项，属于完全掌握；而要让这支团队去开发SLG游戏，他们是模糊的，有着“无缝大地图”、“大量实体渲染”等未知的技术难题要去解决；而如果让他们去造火箭，那便是未知领域。

传统的规划原则限定了我们能做事情的范围。在经验不足时，就不可能做到严谨的任务分解。就像让这支MMORPG团队去对标较强的竞品开发SLG游戏，如果要遵循SMART理论，那直接认输就得了。

“只掌握少部分信息做规划”才符合现在的激烈竞争局势，也才是常态。里程碑节点的设置就符合逐步降低信息熵的特点，优先解决不确定性高的问题，让项目越来越稳。如下图所示，随着工程进展，项目的不确定性也在逐步消除。

严密的规划更多“沟通问题”，可以让团队内各成员步调一致，但它不属于“规划问题”。顶级的规划往往是艺术的，靠着灵感乍现与厚积薄发。

顺带提一下，笔者认为职业发展规划的理论也存在同样的问题，所谓依据客观条件设立人生目标，其实大部分人并没有优越的条件，能规划的目标不过是庸碌平淡，这真的是想要的吗？那还不如躺平。关于目标规划，笔者曾写了一篇文章《从旅游攻略到目标规划》，欢迎一起探讨。

本文的试读到这里就结束啦，课程已上线UWA学堂，欢迎关注。