为什么越受重视的游戏项目越难开发好（02期）

作者声明：本文不影射任何行业产品，请勿对号入座。

接着上一篇文章，继续说一下大团队大版本的弊病。

大版本

这部分其实和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 > 原画 > 场景 >策划 > 客户端表现，对于更技术导向的引擎、渲染、动画、服务器等等，往往领导很难找到合适的切入点来进行指导，除非领导正好是那个领域的专家。容易被指导的领域，往往更容易从表现上进行质疑，而要满足领导的质疑会更难；而那些不容易被指导的领域，领导往往只能从数据上来挑战，比如你加载能不能更快点，承载人数能不能更大点，这些点更容易量化，对程序来说也更容易糊（满）弄（足）领导。 领导站得高看得远，意见自然是很有价值的，但问题是这些领域往往是个人都会跑过来提点意见，意见正常情况都不会统一，让下面执行的同学非常为难，最后往往是谁官职大听谁的。官职大的领导，一般的特点就是忙，忙到没有办法来跟进他的建议的执行情况，也许按他建议做出来的最终的效果并不尽如人意，但他无法后续跟进，大家也不敢轻易去改动，最终妥协的结果就是牺牲了版本质量。

·      最大的麻烦，来自于领导看见了新的竞品、技术、方向，他认为这个代表了先进的生产力方向。于是领导找你谈心，表示那个啥啥啥游戏/技术挺不错的嘛，你就稍微努力一下，咱们也来做点类似的亮点吧。如果开发组的技术选型和原先的设计，和新方向比较吻合，那稍微花点精力也能做出来，如果方向相差比较远，就悲催了。由于领导占领了职位至高点，同时他希望你改进产品，又占领了道德至高点，居高临下的攻击，更容易造成巨大的伤害。很多大型产品一拖再拖，不停加入新的特性，不停追逐新的竞品，在追逐中不停重构，时间一长旧的技术选型又过时，还要考虑排毒，包袱越来越多，如《人月神话》中巨兽陷入焦油坑的比喻，永远在开发，总也不结项。

未完待续。。。