腾讯WeTest/专栏文章/为什么越受重视的游戏项目越难开发好(05期)-结局篇/

为什么越受重视的游戏项目越难开发好(05期)-结局篇

开发测试干货
项目开发 13949

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

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

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

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

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

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

程序员有一个骄傲的心,对于别人的代码,都认为是垃圾。维护遗留代码,是很痛苦的事情,痛苦的程度,可以和继续吃狗没吃完的饭相提并论。软件开发行业流传Eating Dog Food[i]

的传说,一般指自己开发的东西,先在内部使用,这样可以更好的发现问题。而维护遗留代码会比Eating Dog Food更惨,往往吃的不是Dog Food,是Dog Shit

 “你见过乱成粥状的代码吗?by某游戏主程序)

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

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

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

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

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

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

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

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

 这些情况在各个团队中或多或少都有,生产效率一般随着项目折腾指数[ii],直线下降。

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

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

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

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

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

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

l   美术开发者工资低

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

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

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

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

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

策划也很委屈。

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

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

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

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

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

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

 

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

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

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

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

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

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

尾声:

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

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

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

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

好多人问,提了这么多问题,解决方案呢?

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

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

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

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

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

如果还有人刨根问题,一定想知道如何做出成功的项目,我会在长考后,给出人生、宇宙和万物的终极答案:42 [v]

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

(全文终)


[i] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
吃狗食,指自己先在平时工作时使用自己的产品,以便更好的发现问题。

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

 [iii] https://en.wikipedia.org/wiki/Braveheart 《勇敢的心》,纪念那些为自由奋斗过的农民"

 [iv] http://zhidao.baidu.com/question/555693022.html 热寂是一个项目管理名词。根据项目管理学第二定律(熵定律),项目的熵只能随时间而增加。当系统演化到终结时,对应于熵的最大值。"

 [v]https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#The_number_42 The ultimate answer to life the universe and everything. 42是万物的终极答案。出自《银河系漫游指南》,一本正经的胡说八道,说了等于没有说,却又处处透露出哲学智慧,和本文思路一脉相承,值得深入研究。

热度排行榜

购买
客服
反馈