为什么越受重视的游戏项目越难开发好(三)
为什么越受重视的游戏项目越难开发好(一)?
为什么越受重视的 游戏项目越难开发好(二)?
声明1:本文不影射任何行业产品,请勿对号入座,保留删除评论权利。
声明2:本文不代表我个人的经历,吐槽不代表我加入的公司、领导和团队有类似问题。
声明3:由于今天有人质疑声明2,于是再声明一遍,现在工作挺好的,团队给力项目靠谱机遇难得,没有相关问题。再有人质疑就只能断更了...
上回说到领导关心,书接前文。领导喂过你胡萝接下来要抡起棒子砸你了:你这游戏啥时候能上线啊?
对于deadline设置,有很多不同的手段,下面是几种常见的:
- 预留安全期限:告诉你是时间点A上线,其实还留了buffer的时间,两周后才是真正的截止时间。
- 压榨潜力:给出一个很紧的期限,意图压榨开发团队。这个手段其实大家或多或少都在用,压榨程度视乎老板良心不等。
- 随意拖延:对于一些管理比较宽松的企业,回答领导的上线时间的问题,是可以用一个霸气的回答:when it is done的。这样deadline其实是不用当真的...
- 更互联网一些,小步快跑快速迭代,早期打磨好核心玩法,在内容不够的情况下就先上,然后不停根据市场反馈改进游戏。
预留安全期限其实是一个不错的管理技巧,所有的项目一般都会偏乐观,低估工作量,特别是没有经验的团队。而且游戏项目有一个特点,就是只要你想polish,永远可以找到能打磨的地方,也就是说,永远不可能被全部完成。在这个情况下,每个项目到了deadline的时候总会有很多事情没做完,怎么取舍也是很考验制作人的事情。之前一些大项目在最后冲刺版本的时候,宁愿攒下一堆容易修复的小问题不去修复,来降低风险,但是对某些有很大修改风险的问题,由于会比较重要,制作人也会可能有强行要求大家要搞定。在这样残酷的行业现实下,如果大家很沮丧的发现下周的截止日期来不及赶上了,要准备天天在公司打地铺,然后PM摸出制作人留的锦囊,上面写着One more week,作为开发者,想到终于可以额外再多加一个星期的班,你是不是会为了制作人的高瞻远瞩而感动?但这个方案的缺陷是,骗过大家几次,同学们很快就会知道,下一次又是狼来了,大家会默默把真正的deadline想象成官方日期后面一周,万一老板这一次良心发现,告诉大家的是真正的deadline,就会很欢乐了。
至于压榨潜力式的deadline,其实多数项目都在用,除了那些不差钱的公司和团队。核心理念就是设置一个不太可能做到的期限,为了动员大家的士气,也会设点虚拟的假想敌,然后充分利用加班不用付加班费的行业潜规则,进行惨无人道的加班开发甚至封闭开发。游戏行业加班之凶残也是罕见,不多吐槽了,看帖到这里的同学心里都懂的。加班的缺点也被大家讨论了很多,只简单说两个:
- 过度加班影响个人成长:我之前一直坚持每天学习,加了一阵子班,就丧失了对技术和世界的好奇心,回家什么也不想看了,只想睡觉。
- 长期加班提高个人演技:当加班成为常态了以后,聪明的开发组员就会成为演技派,开始均匀把8小时能做完的事情分布到12小时里面来做完,同时细心琢磨怎么能演得更逼真,上班表演出欲仙欲死的忙碌,下班表演出领导你先走我来断后的豪迈。
![](http://gameweb-img.qq.com/gad/20151010/phpG7ibTL.1444442728.jpg)
至于偶尔加几天班,冲一下版本节点,我觉得还是可以有的。定期总结每个版本的成败,大家有休息回血的时间,每个版本成败也能促进大家思考学习下次怎么提高,而且由于加班时间比较短,大家也来不及磨练演技,基本还可以坦诚相待。
当然这个行业加班也不可避免,上面说的优缺点,其实老板们也心里有数,作为开发者,既然进了这个行业,如果热爱游戏开发,也只能对得起自己的职业操守,尽力做好手头的工作,演技这东西尽量还是不要去修炼,开发圈子很小,自己的口碑还是很重要的。
When it is done是一种态度。好多when it is done的项目,其实最后都没怎么done,业界有好多案例,拖着拖着就烂尾了。游戏技术是有保质期的,拖上几年,技术脱节理念过时,再上线也就是给行业添一个反面案例。而且很多游戏质量之低,口碑之差,连作为案例也不够资格。
这个模式,对于milestone是不尊重的,会引起较多的拖延,拖延本身也会影响团队的士气。为了便于管理,制作人是会设置一个所谓的deadline,到时候没做完,就往后顺延。想象一下长跑的情况,好不容易在deadline之前百米冲刺,终点快到了,突然有人跳出来说,其实前面还有1000m要跑,对心灵的冲击,会造成critical attack。
小步快跑快速迭代的另一个说法是996,或者997,是更加强版的压榨潜力。因为正常情况下几个月开发期间做出的内容,玩家只要几周就消耗完了。如果希望上线后不停敏捷调整,同时要满足玩家消耗内容的速度,工作强度可想而知。当然在一个好的团队,这样做对产品的改进的针对性会更好,也有助于做出更好的游戏。
上述手段其实是可以一起用的,Combo连击才更有效,更能对团队造成巨大的杀伤力。
再换一个角度,从milestone的性质来看,可以分成hard milestone和soft milestone,这是我自己生造的说法。
- hard milestone指那些无法被延后的milestone,比如和电影同期上线的强IP游戏;
- soft milestone指那些不那么严格的milestone,比如上面说的when it is done式的milestone。
- 还有很多类型的milestone排在两者之间,比如公司财报有压力,有些游戏必须要改在财年上线,比如要赶圣诞档期,比如要和竞品竞争,赶时间踩死对方丫的。它们有点硬,又不太硬,坚硬程度由开发团队的良心、制作人的向上沟通能力、竞品争气不争气、开发顺利不顺利等因素决定。
硬性的Milestone伤身,加班是必备,如果领导良心一点,允许砍特性,上下齐心,其利断金,还是可以顺利做出来的。如果唧唧歪歪,没拿出快刀斩乱麻的决心,这也要那也要,结果就是什么也要不到,每个特性都没打磨好,时间到了就上线。整个milestone就退化成when it is due了... 曾经参与过一个主机游戏开发,三个月从wii移植到xbox,并且一次送审就通过,质量把控很好,加班程度也可控,就是砍了所有不重要的特性,一路只把关键路径任务全部走通。
软性的Milestone伤心,一次次拖延会消磨团队耐心,时间一长团队互相就开始指责,彼此都开始不信任,团队开始撕逼内耗。一个特性策划写完案子程序说你想好没,别做完又改;实现完策划说程序你睡醒没,那么多bug;双方一通乱掐发现势均力敌,于是合力去掐躺着也中枪的美术;美术委屈,就蹂躏外包;最后项目拖延,大家一起谴责制作人。对于软性milestone,唯一的想法,就是别拖太久,尽量在制作人层面把它当成硬性milestone来做。夜长梦多,多做无益,速战速决才是王道。
上述关于milestone的讨论,放到AAA项目,就会被混合使用。AAA项目原则上都是when it is done类型的,质量不能差,否则公司丢不起那人。实际操作中会受到公司情况影响,需要有一个不太硬的milestone放在那里,比如财年内发布。到制作人层面,如果是做过项目的制作人,会设置一次次迭代细化版本,其实每一个小迭代版本也可以认为在压榨大家潜力。但AAA项目要成功达成milestone是比较难的,因为milestone不仅仅意味着feature implemented,还包括了一个质量上的要求,对于AAA项目,质量上会有很高的要求,我们在下一篇里面再讨论。
未完待续。。。