为什么越受重视的游戏项目越难开发好(二)
发表于2015-10-01
为什么越受重视的游戏项目越难开发好(一)?
为什么越受重视的 游戏项目越难开发好(三)?
声明1:本文纯吐槽,不影射任何行业产品,请勿对号入座,保留删除评论权利。
声明2:本文不代表我个人的经历,吐槽不代表我加入的公司、领导和团队有类似问题。
接着上一篇文章,继续说一下大团队大版本的弊病。
大版本
这部分其实和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,刚刚毕业,他虽然经验不多,但是血统比较高贵,帮你管理一下项目需求,尽快上线吧;听说引擎出问题了,我有个资深外包专家团,专治疑难杂症,你要不要用几天?虽然领导都只是提供更多的好意,但是他的语气如此的不容置疑,你也不好太忤逆他的意思。欢天喜地迎接专家后,发现要么专家不接地气,动不动谈国际先进理念而忽视项目现状,要么根本是水货,水平还不如自己团队,要么没法和团队协作,语言不通,要么没有深入了解过项目就指手画脚,更给项目添乱。我绝对相信他们的帮助是善意的,有时候也能起到一定的作用,但更多的时候会给项目添乱。
- 他们能提供稍大一点伤害的帮助,是给游戏提意见。不少讲设计师苦逼命运的漫画,满篇都透露出一个信息,就是你的工作技术壁垒越低,越容易被指手画脚,要想活得好,请往技术链上层走。
![](http://gameweb-img.qq.com/gad/20151010/php8e26Ka.1444442414.jpg)
我想要一个logo:要既严肃又有趣;要精细,但又要保持简洁;大气,小巧;有科技感,但要像手绘的;看起来很昂贵,但是花费要很少。
在游戏开发领域,通常容易被老板指导的领域,按照可能性排序,一般是 UI > 原画 > 场景 > 策划 > 客户端表现,对于更技术导向的引擎、渲染、动画、服务器等等,往往领导很难找到合适的切入点来进行指导,除非领导正好是那个领域的专家。容易被指导的领域,往往更容易从表现上进行质疑,而要满足领导的质疑会更难;而那些不容易被指导的领域,领导往往只能从数据上来挑战,比如你加载能不能更快点,承载人数能不能更大点,这些点更容易量化,对程序来说也更容易糊(满)弄(足)领导。 领导站得高看得远,意见自然是很有价值的,但问题是这些领域往往是个人都会跑过来提点意见,意见正常情况都不会统一,让下面执行的同学非常为难,最后往往是谁官职大听谁的。官职大的领导,一般的特点就是忙,忙到没有办法来跟进他的建议的执行情况,也许按他建议做出来的最终的效果并不尽如人意,但他无法后续跟进,大家也不敢轻易去改动,最终妥协的结果就是牺牲了版本质量。
- 最大的麻烦,来自于领导看见了新的竞品、技术、方向,他认为这个代表了先进的生产力方向。于是领导找你谈心,表示那个啥啥啥游戏/技术挺不错的嘛,你就稍微努力一下,咱们也来做点类似的亮点吧。如果开发组的技术选型和原先的设计,和新方向比较吻合,那稍微花点精力也能做出来,如果方向相差比较远,就悲催了。由于领导占领了职位至高点,同时他希望你改进产品,又占领了道德至高点,居高临下的攻击,更容易造成巨大的伤害。很多大型产品一拖再拖,不停加入新的特性,不停追逐新的竞品,在追逐中不停重构,时间一长旧的技术选型又过时,还要考虑排毒,包袱越来越多,如《人月神话》中巨兽陷入焦油坑的比喻,永远在开发,总也不结项。
未完待续。。。