GameRes游资网

 找回密码
 立即注册
查看: 2167|回复: 1

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

[复制链接]
发表于 2015-12-22 11:24:06 | 显示全部楼层 |阅读模式
本帖最后由 小篱 于 2015-12-22 11:28 编辑

3a2af22d6679eb944636e67f454fa660_b.png

  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游戏的质量需求

发表于 2015-12-22 17:59:52 | 显示全部楼层
本帖最后由 lin21forever 于 2015-12-22 19:01 编辑

很准确,的确在很多个团队项目里待过
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|广告投放|信息发布|关于本站|手机版|GameRes游资网 ( 闽ICP备05005107-1 )

GMT+8, 2018-1-22 10:24

快速回复 返回顶部 返回列表