游戏项目开发经验：如何在后续的评审中挽回领导的心

本帖最后由 小篱 于 2015-12-22 11:28 编辑


GameRes游资网授权发布 文 /顾煜

题图来自《阿甘正传》

上次说到经过了失败的评审，项目组的士气得到了重大的打击。如何在后续的评审中挽回领导的心，是摆在团队面前最大的问题。

回炉还是改进，永远是一个大问题。

如果项目组选择了回炉，也就选择了死亡（目测失败可能性大于90%）。推翻重做，和版本质量有提高，是没有任何因果关系的。推翻重做，带来了更长的开发周期，更猛的士气打击，更多的资金消耗。还是同样的团队，还是同样的人，把同样的错误，用不同的方式再犯一次。好游戏是打磨出来的，不是重做出来的。所以不看好这个方向。

还有团队会选择换方向。在一个成王败寇的时代，有成绩，可以解读为对过去壮士断腕，失败了，就会被解释成不够坚持。这个选择，不好说是非，只能说很贵，因为之前的工作大半白做了。

一般来说，团队会打磨版本，继续改进，来迎接后续的挑战。

让我们来盘点一下项目各个团队的状况。

先说程序团队，他们受到了重大打击，面临了和开始启动阶段完全不同的问题。最大的问题在于，前两年的开发，留下了大量的遗产。不是所有的遗产都是好的，比如代码，就不是一个你希望得到的遗产。

程序员有一个骄傲的心，对于别人的代码，都认为是垃圾。维护遗留代码，是很痛苦的事情，痛苦的程度，可以和继续吃狗没吃完的饭相提并论。软件开发行业流传Eating Dog Food【尾注1】的传说，一般指自己开发的东西，先在内部使用，这样可以更好的发现问题。而维护遗留代码会比Eating Dog Food更惨，往往吃的不是Dog Food，是Dog Shit。

“你见过乱成粥状的代码吗？”（by某游戏主程序）

一般项目早期，开发demo的程序员都比较资深，容易写出高质量的代码。即使他们上来为了快速看效果，做了很多hack代码，这些资深程序员也会更有职业操守，以及有更多的闲功夫——反正项目还没那么忙嘛，把不足的地方重构。

但是做到了2-3年以后，情况就很不相同了。

为了大规模开发项目，团队扩充的速度会比较快，一些比较junior的同学也会加入，他们对代码的控制能力就会弱很多。

时间紧任务急，各种临时拼凑代码没有时间重构，版本的代码质量就开始下降。还有很多人用不好的习惯修bug，各种hack，还不写注释。

人多了，版本规模大了，大家对程序的理解不一，会出现很多重造轮子现象，类似的程序功能买一送一，有人开发过了，后人不知道，再写一个类似但bug更多的版本。还没来得及整理，又冲上来一群新的程序员，基于这两个不同的实现branch出一堆的分支实现，代码依赖代码，函数依赖函数，胆敢贸然修改，必然牵一发动全身，还你一个灿烂辉煌的程序崩溃。

由于功能反复改，改的时候有些暂时没有用的代码，又不舍得删，怕某天会改回来。不删过期代码，慢慢导致代码膨胀，查找代码的时候花的时间越来越多，修改的地方越来越多。当然这个还是个人的开发习惯，养成好的习惯，有办法解决。

团队扩大，分工更细，工作的边界情况会更多。不是每个开发者都有能力和意愿去承担更多的边界工作。加上各种沟通交流不顺畅，每个人会倾向随手在自己的地盘做好保护，程序功能就在各人接口的部分开始堆积，形成了冗余功能的护城河，隔绝错误，降低效率，默默坑害项目。

AAA游戏可能会有多平台、多版本，一大堆宏定义也是一件让人崩溃的事情，阅读代码的成本会很高，特别是大段大段的宏，各种嵌套，复杂到IDE也不能特别精确的分辨出哪些是当前build里面有效的，哪些是无效的。很多工具试图精确分析宏的情况，要么有错误，要么暴慢无比，编程的快感丧失殆尽。

这些情况在各个团队中或多或少都有，生产效率一般随着项目折腾指数【尾注2】，直线下降。

能通过重构解决问题吗？不是那么容易的。代码充斥着bad smell，想要重构，又无力回天。领导追着进度，基础单元测试也不完整，重构带来风险，没有短期收益。而长期收益不那么明显，你怎么和一个加了几周班，天天做到半夜，心里想的就是哼哼拿完年终奖老子就不干了的程序谈长期收益？

而且不少团队借着重构的名义，开始实现各种取巧，指望重构来梳理，相当于变相延长了任务的开发周期。策划和美术会很嫉妒，为什么他们的专业领域里面，没有像重构这么听起来高大上，可以明显拖延进度却又在政治上光辉正确的专业术语，唯一有点接近的是“重做”，但是这个含义和“重构”相比，Low了不少，最起码重构常常是压力不大的时候做的，不用加班，重做经常是压力最大的时候，通宵睡公司也是家常便饭。

再来说说美术团队。美术相对独立，没有程序受到的冲击大。但美术资源有自己特殊的问题。

美术资源可能规格过高或过低，需要梳理、转换。这块工作量还可以，有大量工具可以辅助，也可以外包。但是在接近成品的游戏里面，美术资源量很大，全部梳理一遍也是很感人的一件事。

“NND，程序员又开发出新渲染特性去向老板邀功啦”，由于美术资产依附于引擎，是一个不稳定因素。引擎轻轻一改，上层美术建筑轰然倒塌，需要重现翻新。程序做完功能，爽完技术，得了赞扬。由于能量总是守恒的，程序正能量多了，就需要苦逼的美术来点负能量，中和一下。彼之欣喜，必是我之劫难。各种特性都要美术在关卡里面调好，没做好的，老板也不会责怪程序，都是找美术同学。最可气的是，程序老是实现些不完美的技术，有各种各样的瑕疵，有可能是不负责，也可能是技术的确有局限，老板只看见好的地方，至于那些瑕疵，程序轻描淡写说一句，美术做的时候小心点绕开问题...

由于改动美术资源相对成本比较低，美术会有不同的悲催。这个和美术从业人员以及项目管理都有关系，我们展开说说：

美术开发者工资低

美术是一个长期在竞争激烈行业进化的生物，美术开发者耐X能力普遍更强美术职位往往不像程序需要彼此合作，程序每个人做的内容都不一样，在项目开发中形成了更大的合力。而美术往往是平行可扩展规模的，比如做关卡，放5个人做5个关卡，彼此依赖不多。这造成了美术人员相对容易被替换。一根筷子容易掰断，一把筷子就不容易了，道理是一样的。

项目管理上，总是希望大家时时有事做的。程序这里，特别是渲染和引擎，由于太底层，处在根节点，改动会向策划玩法、工具链、美术等等众多环节传递，所以项目中后期肯定是希望收敛一点的。但是美术则不然，他是一个叶子节点，每个项目不顺利了，都找美术改个UI玩玩，给领导造成我们一直在努力工作的假象。而且UI又是一个人人可以指手画脚的领域，大家审美各异，所以多数项目从头到底都在做UI，永远不用担心UI无法改进了，大不了把UI推翻重做嘛。前公司做的N个大作，UI都是做了3-4版的。光子工作室分享过全民突击的开发，Jerry有一句话真的说到了心坎里，他说没有一个项目是因为UI成功的，所以他们的UI不去乱改。真心希望大家都能引以为戒。

所以，每次改版本的开始阶段，美术都是最忙的，就算没有工作，领导也会创造工作让你上。但到了版本后期，多数美术就会稍微空一点了，可以聊天打屁、嘲讽挑衅策划和程序，也是人生一大快事。

最后谈谈游戏灵魂的工程师：策划团队。策划在早期意气风发，指点江山。现在就该勇敢的跳出来背锅了。

“所有的问题，都是策划的问题，连闪退也是”，(By不明真相的玩家)

策划也很委屈

努力的策划会说：说好的功能，程序一直做不出来，上线前才做完，我哪有时间细调玩法啊？

不努力的策划会偷偷藏起需求，在最后一刻告诉程序，把球踢给程序，然后像努力的策划一样抱怨。有人的地方，就能拖延，通过制度性的官僚体制，来系统的拖延任务进展，回避责任，这是一门科学。不露痕迹，不留把柄，才是最高境界。凡事多请示，自己不背锅，一切以减少工作量为前提，游戏好不好玩关我屁事，没在我的环节出问题就好了。

策划团队面临了要不要大改玩法的困境，改了，也不一定好玩，不改，也不一定不能调好。但是你只能选一条路，那条没选的路是留给领导用的：当你改失败了，领导就会说，你当时为什么不选另一条路呢？可见，战略永远不会错，错的都是执行。

策划的另一个大挑战在于反馈的滞后性。一切工作，如果能有快速的反馈，做起来也有趣，能力也容易提高。比如渲染，比如引擎效率优化，都是相对容易树立标准，好坏一目了然，反馈很快就有。但是策划的玩法设计，真的很难验证，需要更长的时间讨论，需要求程序大爷实现出来，做出来以后要改一点，程序美术都老大不愿意：”你想清楚没有？不行就别瞎指挥，立个字据，最后一次改了”。改完调完，还要找人体验，这一轮优化，时间短不下来。一切都建立在各个团队有信任感的基础上，如果大家互相不信任了，那程序和美术大爷们不一定愿意接客，策划就更难做了。评审失败后策划往往会受到最大的质疑，就会陷入信任危机，导致工作更难开展。

每个项目团队都很不一样，出问题的环节都不同，无法一概而论。哪个环节最弱，就觉得哪个环节有最多的问题。如果策划是短板，就会觉得这个项目有个好策划就一切顺利了。等你真找到好策划了，就发现程序又成了短板。这里的核心问题在于游戏质量要求无限高，不管做到什么程度都可以有提高空间。策划、程序和美术，只好拼命往前跑，不求领先，只求不是三个团队里面跑得最慢那个。

可惜，人不是机器，机械都会疲劳，人更会掉链子。一次次的挫折，会帮助团队重新思考人生： 是不是还要继续做？制作人行不行啊？这个团队不给力啊？拿完年终奖跳槽？

“人心散了，队伍就不好带了。”(By黎叔，《天下无贼》)

项目的结局会怎么样，反而不是最重要的了，大家纷纷准备着自己的前程。以前猎头打来电话都是直接挂掉的，现在或许会和他调调情，聊聊天，不小心就谈出了感情，换个地方，一样做项目。

再怎么打鸡血也没有用，累了，不会再爱了。积极的同学，被一次次冷水泼过，再也没有了热情。主动积极职业化的人还好，从哪里跌倒，从哪里站起来，努力学习充实自己，希望下一次做得更好；消极被动懒散化的人，从哪里跌倒，就从哪里躺下，老板你要我做什么，我就做什么，加班我是不做的，你要我加班，就算留下了我的肉体，也留不住我的心，BTW，我有苏格兰血统，装备了brave heart，就算你用考核威胁我，我也要高喊：Freedom！【尾注3】

再一次的评审，再一次的挫折，循环往复。往前看，项目的一切，都起源于一个喧嚣的点，往后看，项目的努力，都归于平静，宇宙热寂【尾注4】是万物无法逃脱的宿命。

起势如破竹，病来如山倒，墙倒众人推，树倒猢狲散，项目吞噬了你的青春和梦想，除了遗憾，什么也没有留下。

多年以后，没有人会记得，你们做过一个精彩绝伦的Demo。它曾是你的过去，却没成为你的未来。那个Demo视频，和你们汇报的PPT一起，躺在硬盘的角落，被遗忘。

尾声：

做得太久的项目会烂尾，技术会过时，团队会疲惫，市场会变迁。

写得太长的文章会烂尾，兴趣不在了，工作太忙了，灵感没有了。

这次，居然没有烂尾...给自己点个赞，也给读者点个赞，谢谢大家的支持。

我做过多个大型项目，有过2个4年左右规模的游戏（幸好都是后期加入），也有做过5年规模的游戏，好在这些项目都能成功上线，所以大家不用太怀疑我在吐槽自己的工作经历。但即使在成功的项目中，好多问题也都和失败项目有共性，不妨一起拿来戏说一番。

好多人问，提了这么多问题，解决方案呢？

我想，文章里并没有好的解决方案，软件工程是一个仍然在高速发展（发展了几十年还没有发展完）的科学（科学到不知道怎么能做出一个有质量的软件），游戏方面的软件工程又带有自己的复杂性，复杂到加班也不能解决所有的问题，请来各类高级顾问，也都是鸡同鸭讲，无法指导你们的工作，这里通篇的讨论，还考虑人的因素，考虑市场的因素，这更是不可控因素。

但是我觉得这系列文章，如果在恶搞过后，如果能带给大家一些思考，一些反省，它的意义也就够了。

因为成功的项目，有各种机遇，各种偶然，虽有各种狗血都都能在领导英明指挥下化险为夷，太多案例不具备可重复性，意气分发的分享者介绍的种种情况未必能直接套用在你们的项目中，分享中也许还夹杂着个人的私心，美化当时的决策和夸张当时遇到的困难。我们很难在成功项目中得到有价值的启示。

而研究失败的项目，是一个更有价值的思路。如何避免问题，能提前知道有些什么雷区，也好提前准备。总是有这么多的坑，即使知道它在那里，你还会掉进去。把注意力放在不要掉进坑里，会更容易一点。

至于怎么做才能让一个项目成功，我无法回答，追问的同学，我只想反问一个问题：我要知道怎么能100%做出成功项目，是不是早就应该拉人去创业了，哪有这闲功夫在这里写文章？理论上战略规划都是正确的，错的只是执行。我们要做的，不是高瞻远瞩，思考如何确保成功，而是脚踏实地，思考如何不掉坑里。在我们层次还不高的时候，I have a solution，会远远好于I have a dream。

如果还有人刨根问题，一定想知道如何做出成功的项目，我会在长考后，给出人生、宇宙和万物的终极答案：42 【尾注5】

请大家不要回来，马上走开，今后如果有机会，我们再来开一个严肃的系列：怎么提高自己，但那个，已经是很远很远的将来了。

Eating your own dog food

吃狗食，指自己先在平时工作时使用自己的产品，以便更好的发现问题。

[ii] 折腾指数由下列要素构成：代码规模，工具完备程度，多种语言混合编程，团队平均能力，团队人数，项目持续时间，方向变更、推翻次数，团队人际关系，团队组内对立情绪，公司待遇，业界竞争情况，加班程度，目前各个元素的构成权重暂时未知，有待研究。

[iii]Braveheart 《勇敢的心》，纪念那些为自由奋斗过的农民。

[iv]宇宙热寂是什么意思？宇宙最后有可能热寂死亡吗？ 热寂是一个项目管理名词。根据项目管理学第二定律（熵定律），项目的熵只能随时间而增加。当系统演化到终结时，对应于熵的最大值。

相关阅读：

诊断：为什么越受重视的游戏越难开发好？

越受重视的游戏项目越难开发好？ 试试deadline设置

越受重视的游戏项目越难开发好？探讨AAA游戏的质量需求