为什么越受重视的游戏项目越难开发好(一)

发表于2015-10-01
评论16 7.4k浏览

为什么越受重视的 游戏项目越难开发好(二)?

为什么越受重视的 游戏项目越难开发好(三)?

为什么越受重视的 游戏项目越难开发好(四)?

为什么越受重视的 游戏项目越难开发好(五)?

    声明:本文不影射任何行业产品,请勿对号入座,保留删除评论权利。

    在国外的游戏行业里面,有一类游戏称为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方案应应急吧。
    • 公司内部各种技术评审,流程繁琐,咱们是大项目了,也该尊重一下流程,写点文档,阐述一下思路吧。

    一通加班,终于连滚带爬搞定了,每天上班,看见程序、策划、美术团队都彼此独立的高效并行开发,心情很好。但你以为这就是全部的挑战吗?

    未完待续。。。

    如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

    游戏学院公众号二维码
    腾讯游戏学院
    微信公众号

    提供更专业的游戏知识学习平台