为什么越受重视的游戏项目越难开发好（三）
为什么越受重视的游戏项目越难开发好（一）？
为什么越受重视的 游戏项目越难开发好（二）？
声明1：本文不影射任何行业产品，请勿对号入座，保留删除评论权利。
声明2：本文不代表我个人的经历，吐槽不代表我加入的公司、领导和团队有类似问题。
声明3：由于今天有人质疑声明2，于是再声明一遍，现在工作挺好的，团队给力项目靠谱机遇难得，没有相关问题。再有人质疑就只能断更了...
上回说到领导关心，书接前文。领导喂过你胡萝接下来要抡起棒子砸你了：你这游戏啥时候能上线啊？
对于deadline设置，有很多不同的手段，下面是几种常见的：
- 预留安全期限：告诉你是时间点A上线，其实还留了buffer的时间，两周后才是真正的截止时间。
- 压榨潜力：给出一个很紧的期限，意图压榨开发团队。这个手段其实大家或多或少都在用，压榨程度视乎老板良心不等。
- 随意拖延：对于一些管理比较宽松的企业，回答领导的上线时间的问题，是可以用一个霸气的回答：when it is done的。这样deadline其实是不用当真的...
- 更互联网一些，小步快跑快速迭代，早期打磨好核心玩法，在内容不够的情况下就先上，然后不停根据市场反馈改进游戏。
预留安全期限其实是一个不错的管理技巧，所有的项目一般都会偏乐观，低估工作量，特别是没有经验的团队。而且游戏项目有一个特点，就是只要你想polish，永远可以找到能打磨的地方，也就是说，永远不可能被全部完成。在这个情况下，每个项目到了deadline的时候总会有很多事情没做完，怎么取舍也是很考验制作人的事情。之前一些大项目在最后冲刺版本的时候，宁愿攒下一堆容易修复的小问题不去修复，来降低风险，但是对某些有很大修改风险的问题，由于会比较重要，制作人也会可能有强行要求大家要搞定。在这样残酷的行业现实下，如果大家很沮丧的发现下周的截止日期来不及赶上了，要准备天天在公司打地铺，然后PM摸出制作人留的锦囊，上面写着One more week，作为开发者，想到终于可以额外再多加一个星期的班，你是不是会为了制作人的高瞻远瞩而感动？但这个方案的缺陷是，骗过大家几次，同学们很快就会知道，下一次又是狼来了，大家会默默把真正的deadline想象成官方日期后面一周，万一老板这一次良心发现，告诉大家的是真正的deadline，就会很欢乐了。
至于压榨潜力式的deadline，其实多数项目都在用，除了那些不差钱的公司和团队。核心理念就是设置一个不太可能做到的期限，为了动员大家的士气，也会设点虚拟的假想敌，然后充分利用加班不用付加班费的行业潜规则，进行惨无人道的加班开发甚至封闭开发。游戏行业加班之凶残也是罕见，不多吐槽了，看帖到这里的同学心里都懂的。加班的缺点也被大家讨论了很多，只简单说两个：
- 过度加班影响个人成长：我之前一直坚持每天学习，加了一阵子班，就丧失了对技术和世界的好奇心，回家什么也不想看了，只想睡觉。
- 长期加班提高个人演技：当加班成为常态了以后，聪明的开发组员就会成为演技派，开始均匀把8小时能做完的事情分布到12小时里面来做完，同时细心琢磨怎么能演得更逼真，上班表演出欲仙欲死的忙碌，下班表演出领导你先走我来断后的豪迈。
至于偶尔加几天班，冲一下版本节点，我觉得还是可以有的。定期总结每个版本的成败，大家有休息回血的时间，每个版本成败也能促进大家思考学习下次怎么提高，而且由于加班时间比较短，大家也来不及磨练演技，基本还可以坦诚相待。
当然这个行业加班也不可避免，上面说的优缺点，其实老板们也心里有数，作为开发者，既然进了这个行业，如果热爱游戏开发，也只能对得起自己的职业操守，尽力做好手头的工作，演技这东西尽量还是不要去修炼，开发圈子很小，自己的口碑还是很重要的。
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项目，质量上会有很高的要求，我们在下一篇里面再讨论。
未完待续。。。