|
|
本帖最后由 小篱 于 2015-9-14 15:06 编辑
GameRes游资网授权发布 文 / 顾煜
在国外的游戏行业里面，有一类游戏称为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方案应应急吧。
公司内部各种技术评审，流程繁琐，咱们是大项目了，也该尊重一下流程，写点文档，阐述一下思路吧。
一通加班，终于连滚带爬搞定了，每天上班，看见程序、策划、美术团队都彼此独立的高效并行开发，心情很好。但你以为这就是全部的挑战吗？
大版本
这部分其实和Pipeline部分有点重合，做点补充吧
游戏目录越来越大了，原来用得好好的SVN，速度上的劣势显示出来了。同步一个版本可能要30分钟以上，是不是该升级Perforce，或者用GIT？新版本的SVN效率应该是高了不少，不过存储大量版本管理数据在用户本地也是醉了。GIT以前用过一个版本，莫名其妙会Out of memory，后来再也没有用过，据说Git本地存储+P4团队协作不错，但是版本大了，维护的开销也不小。Perforce速度和稳定性一流，功能强大，历来参与过的大型项目都会用Perforce，就是免费版只有20个用户的许可，更多就要买，比较贵。
编译版本的时间越来越长。Incredible Build之类的产品可以帮上忙，升级电脑和配上SSD也有帮助。但是总体来说迭代的速度肯定受影响。特别是Incredible build，它只能并行加速编译，无法加速link，而增量的link，恰恰是平时程序员日常工作中最常用的功能。没有谁会经常全编译整个项目，一般都是改几个文件编译链接一下进行测试，链接时间长短，影响程序员迭代速度。另外个人比较痛恨动不动就include一堆外部库的同学，虽说不应该重造轮子，但是重量级的外部库，无论是在编译时间，还是在维护成本，甚至在license的法律问题上，都会带来一定的冲击，需要仔细权衡。不同的引擎，在这个问题上会有不同的表现，比如有不少引擎使用大量脚本，就能很好降低编译链接的时间，可是这个问题麻烦的地方在于很少被提前预见，往往当你遇见了，已经是项目膨胀到规模比较大的时候，也没有办法修改了。
大版本带来的学习成本急剧提高。新加入的同学再也没有办法在短时间里面上手，对于新的功能开发，往往需要通读很多相关模块后才能着手开发。冒冒失失的同学有可能会无视已有的功能，重新开发某个基础功能，往往做出来的还是更挫的版本，着进一步加巨了代码膨胀；也有些没有良好开发习惯的同学，火上浇油般copy/paste代码，或者能力不好的同学人肉进行代码混淆化，让后人无法轻易识破代码含义；策划经常改点需求，旧的代码不能满足需求，又不舍得删掉，修修补补，导致可读性持续下降。以上种种，让很多持续4-5年的项目，成为程序员的梦魇，我在这个文件修改一行代码，就在那里引起一个crash，充分向后人诠释了蝴蝶效应的含义。
受限于版本编译速度降低和版本的增大，程序员的开发效率急剧降低。早期开发原型的时候踌躇满志，说这个系统可能有几个方案，咱们多花点时间都做出来比较一下效果吧。后期就会特别慎重，因为都做出来时间上来不及。为了弥补效率的降低，就需要有更多的程序员，更多的程序员带来了管理上的压力和交流上的成本，使增加人后产生的边际效用递减。根据每个团队的成熟度，和leader的管理能力，每个团队都有一定的规模，超过这个规模，再多的人，也无法提高开发效率了。
他们想帮你
说完了项目规模的问题，再说说管理上的问题。
既然是公司内的明星项目，领导们必然会非常重视。他们会给你更多的资源，给你更多的资金支持，也会给你更多的帮助。可很多时候，来自团队外部的帮助，往往是有害的。回到本文标题，越受重视的项目，能得到各级领导的关注就越多，收到的善意也越多，就更容易消化不良。
他们能提供的对你伤害最小的帮助，就是派几个专家来辅助你的工作。
Bruno会做你的创意总监，你只要能在截止日期前完成工作，就不会有问题。
你技术搞不定？我这里有个tech director，做过几百个AAA项目，AAA is his middle name... 先借给你使用两天，记得要还我哦；你项目管理上遇到难题，我借你个project closer，刚刚毕业，他虽然经验不多，但是血统比较高贵，帮你管理一下项目需求，尽快上线吧；听说引擎出问题了，我有个资深外包专家团，专治疑难杂症，你要不要用几天？虽然领导都只是提供更多的好意，但是他的语气如此的不容置疑，你也不好太忤逆他的意思。欢天喜地迎接专家后，发现要么专家不接地气，动不动谈国际先进理念而忽视项目现状，要么根本是水货，水平还不如自己团队，要么没法和团队协作，语言不通，要么没有深入了解过项目就指手画脚，更给项目添乱。我绝对相信他们的帮助是善意的，有时候也能起到一定的作用，但更多的时候会给项目添乱。
他们能提供稍大一点伤害的帮助，是给游戏提意见。不少讲设计师苦逼命运的漫画，满篇都透露出一个信息，就是你的工作技术壁垒越低，越容易被指手画脚，要想活得好，请往技术链上层走。
我想要一个logo：要既严肃又有趣；要精细，但又要保持简洁；
大气，小巧；有科技感，但要像手绘的；看起来很昂贵，但是花费要很少。
在游戏开发领域，通常容易被老板指导的领域，按照可能性排序，一般是 UI > 原画 > 场景 > 策划 > 客户端表现，对于更技术导向的引擎、渲染、动画、服务器等等，往往领导很难找到合适的切入点来进行指导，除非领导正好是那个领域的专家。容易被指导的领域，往往更容易从表现上进行质疑，而要满足领导的质疑会更难；而那些不容易被指导的领域，领导往往只能从数据上来挑战，比如你加载能不能更快点，承载人数能不能更大点，这些点更容易量化，对程序来说也更容易糊（满）弄（足）领导。 领导站得高看得远，意见自然是很有价值的，但问题是这些领域往往是个人都会跑过来提点意见，意见正常情况都不会统一，让下面执行的同学非常为难，最后往往是谁官职大听谁的。官职大的领导，一般的特点就是忙，忙到没有办法来跟进他的建议的执行情况，也许按他建议做出来的最终的效果并不尽如人意，但他无法后续跟进，大家也不敢轻易去改动，最终妥协的结果就是牺牲了版本质量。
最大的麻烦，来自于领导看见了新的竞品、技术、方向，他认为这个代表了先进的生产力方向。于是领导找你谈心，表示那个啥啥啥游戏/技术挺不错的嘛，你就稍微努力一下，咱们也来做点类似的亮点吧。如果开发组的技术选型和原先的设计，和新方向比较吻合，那稍微花点精力也能做出来，如果方向相差比较远，就悲催了。由于领导占领了职位至高点，同时他希望你改进产品，又占领了道德至高点，居高临下的攻击，更容易造成巨大的伤害。很多大型产品一拖再拖，不停加入新的特性，不停追逐新的竞品，在追逐中不停重构，时间一长旧的技术选型又过时，还要考虑排毒，包袱越来越多，如《人月神话》中巨兽陷入焦油坑的比喻，永远在开发，总也不结项。
未完待续......
引用：
[1] Wikipedia, AAA (video game industry)
声明：本文纯吐槽，不影射任何行业产品，请勿对号入座，保留删除评论权利。
|
|
发表于 2015-9-8 16:30:53
