为什么越受重视的游戏项目越难开发好（一）
声明：本文不影射任何行业产品，请勿对号入座，保留删除评论权利。
在国外的游戏行业里面，有一类游戏称为AAA游戏，Wikipedia上面的定义是：[1]
In the video game industry, AAA (pronounced "triple A") is a classification term used for games with the highest development budgets and levels of promotion or the highest ratings by a consensus of professional reviewers. A title considered to be AAA is therefore expected to be a high quality game or to be among the year's bestsellers.[5][not in citation given] For a title to remain AAA post-launch, it must be either commercially or critically successful.上述引用文字纯粹用来增加逼格，只要看这段中文就好了：简单来说，AAA游戏就是一些开发预算非常高、推广预算非常充足、质量很高的三高游戏，通常都被期望能有很好的商业成功。
开发AAA游戏是大型游戏开发企业的最终追求，每年他们都会投入大量资源开发AAA游戏。目前单机游戏不算太景气，单机行业主要的推动力量，还是依赖这些名称后面有个数字，数字每年+1的产品。
类似的做法在国内也比比皆是，每一个大型开发商都有自己的旗舰产品，我们也可以认为这些产品就是国内的AAA游戏。毋庸置疑，对AAA游戏开发的重视，会让这些公司从上到下，都对这些产品投入资源和重视。但是一个有趣的现象，就是很多大作往往难产，或者拖上很多年，就像一个无底洞，吸引公司不停投入，但进展缓慢。
同样的现象，在很多项目里面不停的重现。这里面一定有什么地方不对，导致投入和产出不成比例。我们来分析几个原因：
早期原型阶段的高效造成了效率错觉
在项目早期的原型阶段，往往1-2个程序员在很短的时间内就能做出很多东西，这会让团队低估整个游戏的开发难度。这里面又有几个不同的情况：
- 在早期阶段，如果是用unity、cryengine或者unreal这样的商业引擎，那一开始就可以根据自己要做的游戏类型，直接套用引擎自带的现成的框架或者demo，还有market place给你直接选择原型。刨除学习成本，在很短的时间里面，一个大致的游戏原型就出现了。
- 如果用成熟的自研引擎，那参考上一条，肯定有之前成功的项目，一下就拉来一大票可用的代码和资源，简单拼凑一下就有demo了。
- 如果是从头开发的自研引擎，那开发早期团队规模小，引擎规模也小，系统少，不需要考虑多人合作，不需要考虑各个系统能和谐工作，简单hack一下，就把原型搞完了。负担少，自然跑得快。
很快，一个出色的Demo做出来了，领导龙颜大悦，这几个人果然靠谱，才花了这么一点点时间和资金，就做了一个好原型。往往管理层就会产生一个错觉，这是一个优秀的团队，我多投点钱，组建一个大点的团队，分分钟搞出一个AAA游戏去赚一笔。但作为一个成熟的开发者，请一定要抵制这样乐观的想法。你们的团队或许很强，你们积累应该很多，你们背后站着整个公司的支持，你们手捏几千万的预算，但是这一切并不一定代表一个成功的游戏。没有谁欠你一个成功，再好的产品原型也可能无疾而终。
原型阶段的高效，来源于规模小，小带来了高效。
- 因为规模小，你们自己的东西不多，所以可以考虑用现成的demo改改就上
- 因为规模小，团队不用磨合，没有政治，没有八字相合相冲，大家为了一个目标奋斗
- 上去就搞，沟通成本也很低，不用预约什么会议室，吼一嗓子，明天游戏里面就看见你要的特性了。
- 因为规模小，各个系统关联不多，不容易有一周做完一个特性原型，整合进版本分支，把方方面面流程理顺，crash调完，最终额外多花了二周的事情发生
- 因为规模小，每个人的意见都容易被尊重到，大家都有一种在创业的感觉。
- 因为规模小，大家期望也低，做什么出来都让人眼前一亮。
- 小demo，往往美术资源都是东拼西凑，很快能凑出来。
开发效率递减问题
实际情况非常残忍，作为AAA游戏，规模一定会变大，游戏规模导致的开发效率递减问题会逐渐提上议事日程。
你不能总做demo
Demo终于做完了，立项了，大家意气风发，准备大干特干。但你却发现，引擎上似乎有一点点小问题。
商业引擎带来的早期红利很快就会消失，你总要脚踏实地一个个做自己要的特性，到时候你就会发现，对引擎不熟悉，改个什么东西总是很别扭; 或者引擎有大量你不要的特性，带来了额外的负担; 或者卖引擎的时候说的天花乱坠，拿到手一看怎么和说好的不一样呢; 引擎开发商说好的24小时支持呢？
如果是自研引擎，操心的事情也一样不少。程序Hack的特性，没法让策划、美术进行多人协作，你说要不要改一下？那边一堆硬编码，应付demo的，必须要数据驱动啊，数据驱动以后就可以扔给内容开发人员去维护了，程序员肯定不能拒绝这个诱惑；demo里面一大堆没做完的镜头特性，优先级不高，汇报的时候让领导自行脑补的，你不会打算让玩家也脑补吧？一面是程序承诺的一堆特性迟迟做不出，一面是闲着没事的策划和美术开始唱起了家乡的歌谣，四面楚歌的压力应该可以想象吧？
Demo完成后通常要一段不小的时间，重新组织队伍，整理重构架构，这个downtime，在每个项目中都不少见，但通常都比较隐性，不容易被注意到。
他和我不一样
团队总会扩大，你会发现林子大了什么鸟都有。
- 有些人就是没法谈到一起去，交流效率变低；
- 有些人理解和你不一样，一个特性做来做去就是不到位；
- 有些人能力超强但是不能合作，一个人在一边solo；
- 有些人加班太少，东西来不及做也不管；
- 有些人加班太多，弄得团队人心惶惶；
- 有人太不好学，跟不上项目的节奏；
- 有些人太好学，一直兜售各种不成熟的技术，试图整合进项目来添乱。
每个参与项目的新员工，都会带来交流成本的提升，大家的背景不一定一样，习惯也未必相同。有人想来刷项目经验，有人纯粹来学习，有人赶来救火，有人不情愿却被领导扔进来。人多的地方就有文化，搞搞文化建设，组织学习活动，经常面试一下新人，这要花多少时间啊..
重建pipeline
- 场景资源不能靠拼凑其他游戏的资源了，是不是要搞个合适的外包流程，再去申请点外包经费？
- 策划填xml都快要起义了，咱们是镇压他们呢，还是让程序给他们做个图形化工具？
- UI不能硬编码了，咱们上一个scaleform吧？前面做的东西翻新一遍，分分钟搞定看上去是不太可能了。
- 人肉构建受不了了，做个版本要2个小时，每次出版本整个项目留下来等，还要不要回家了。做个自动构建 + 每日构建 + 自动单元测试 + 数据自动convert + 构建权限管理 + 自动冒烟测试 + 自动部署 + 代码review系统 + 分布式编译，能有的全加上，怎么也不是1个月能搞定的事情吧。。。
- 美术反映某一关的开发进度来不及了，要多人一起上去群P。尼玛做编辑器的时候没有打算让你们群P啊，做点临时merge方案应应急吧。
- 公司内部各种技术评审，流程繁琐，咱们是大项目了，也该尊重一下流程，写点文档，阐述一下思路吧。
一通加班，终于连滚带爬搞定了，每天上班，看见程序、策划、美术团队都彼此独立的高效并行开发，心情很好。但你以为这就是全部的挑战吗？
未完待续。。。