为什么想写
我曾花费一年独自做了一个游戏。尽管在开发后期我已经意识到“美术”和“设计”上的开发成本已经超出我的能力与时间预期,但最终还是咬牙完成并上架steam了。我认为它从产品角度来说没有价值,但是从工程角度来说,它算是个“完整的游戏”。
而现在,我在一个大型团队做一个大型游戏。像团队中的其他开发者一样,我肯定希望项目可以更快更好地做完,并且获得自己应有的利益。然而实际却发现,自己所做的大大小小的事情,虽然大体上是在推动项目前进,但做事的方式,远不是最快最好的,同时对于个人,也很难最大化地追求到自己的利益。从感觉上讲,就是很多事情“不合理”。
这当然是情有可原的。在团队中推进一个大项目前进,每个人都是这样走走停停的,需要停下来和同伴交流信息,需要和老大汇报成果,需要和其他管理者沟通进度,这样团队才能更准确地把握前进方向。而对于个人,也必然无法保证总走在能使自己利益最大的路上。因此对于团队做项目,“总以最快最好地方式推进项目,并且最大化的得到个人利益” 这样的“合理”只能是一个“理想”。
尽管如此,在做这个项目时我还是经常有“焦虑”和“郁闷”等负面情绪。也许是因为我过于追求一切的合理性。但更可能是,这个项目的现状和“理想”差距过于巨大了,它不合理的程度已经超过了正常的容忍度,在这走走停停的路途中“停”的时间太多了。之所以说“更”可能,是因为我感受到我的同事们大多也有类似的负面情绪。
无论如何,“追求合理”肯定不能说是错的,这是人的本能,而越优秀的人就越有“追求更好”的倾向。我所在的团队可以说聚集了一批优秀的人,所以因感觉到“不合理”而产生的负面情绪并不罕见。
那怎么办呢?去更合理的团队与项目吗?这当然是一个很正常的选择,也是很多同事的选择。但是每个人的情况都不一样。对于我来说,留在这里是相对最好的选择,所以我只能继续面对这些负面情绪。
同时,我也在想,既然我感受到了这么多不合理的事情,那我何不趁自己感情这么强烈的时候将它们表达出来呢?先不管他们是否真的有价值,关键是未来我很可能再没有第二次机会进入这样大型的团队,做这样大型的项目,感受这样大型的“不合理”了。因此,现在正是我对这个话题最感同身受的时候,是最适合我去记录和思考这些问题的时候。
主题
直白来说,我要写的内容是对这些“不合理”的吐槽。但我想必须给自己明确一个主题,否则讨论的内容就会过于发散。我想,最能准确表达我想讨论的主题是:
在大型团队做大型游戏的时候,你将被迫面对一些看似不合理事情,这些事情阻碍了团队开发的速度,也确实会让自己的利益得不到满足,但是却难以避免。我将根据自己的环境去描述这些现象并带上自己肤浅的思考。
然而,这样的主题去作为“标题”的话,显得过于冗长。所以我想了一个更简短的标题:
《游戏开发团队并非蚂蚁协作》
这来源于我对“蚂蚁”的认识:它们的团队协作总是那样的高组织性和高效率,而遇到危机时也会团结起来共同克服,其中的个体甚至甘愿为团队牺牲。相比较下,“游戏开发团队”就不是这样,甚至可以说处于相反的情况:
- 蚂蚁团队中的每个个体分工明确,相互之间的交流依靠化学信号,整个团队像是一个高效运转的机器,这是刻在蚂蚁的基因里的。而我们的游戏开发团队中的个体,并非天生就知道自己该干什么才能让团队的效率最高。
- 蚂蚁团队中的个体,团队的利益高于个体的利益。但游戏开发团队中的个人,显然要先考虑自己的利益。这无须指责,毕竟蚂蚁团队面临的都是严肃的生死存亡问题,但是我们游戏开发团队里的个人,说白了只是和团队 “合作赚钱” 罢了。既然是合作,那肯定要考虑自己的利益。
- 与蚂蚁团队不同,游戏开发团队所要解决的问题是开发好一个大型游戏。而大型游戏是一个拥有复杂结构和庞大内容的软件工程。
我认为,蚂蚁团队与游戏开发团队的这些不同之处,是游戏开发团队无法像蚂蚁团队那样高协作性和高效性的“根本原因”。但显然这个“根本原因”是无法解决的,所以永远不能苛求游戏开发团队能真正达到 “像蚂蚁团队那样高协作性与高效性同时每个个体又没有怨言”。这就是这个标题的意思。
虽然“根本原因”是无法解决的,但以此而衍生的一些具体的问题却是有方式优化的。这些问题正是我想讨论的内容。
理想情况下,我应该从根本原因出发,展开出一个个问题以及由这些问题交织出的新的问题,但可惜我对这些问题的理解并不够深,视野也并不够宽,所以无法说出整个问题的全貌,所以除开这个第(0)篇之外其他篇都是相对零散的,我只能尽量保证有一定的先后顺序。
根本原因
虽然刚才已经谈到了“根本原因”,但请让我再以明确的方式表达出“根本原因”:
我认识到的根本原因就是两点:
- 团队是由 不同的个体 组成的
- 大型游戏是 复杂而庞大 的软件工程
而这两点又意味着更具体的情况,下面就简单解释一下。
不同的“利益主体”
我这里的“利益”不单指薪酬,更准确说是 “回报率”:
回报率
=
收益
付出
回报率=\frac{收益}{付出}
回报率=付出收益
其中:
- “收益” 并不单指钱,很多人将“自己的成长”,或者“资质的积累”看得也很重。
- “付出” 主要指时间,但是相同时间上,有人付出了更多的精神压力(比如焦虑于一些事情),我认为也算是一种“付出”。
而不同的利益主体,意味着团队的利益是需要分配的,意味着利益有一定的争夺情况,分配者也要注意公平性。这些会衍生出一些更具体的问题。
不同的“大脑”
每个“大脑”都存有各自独一无二的知识与经验,在面对同样问题时也不会做出完全一样的决定。
而不同的的大脑,则意味着大部分信息都需要沟通。而又因为利益主体也是不同的,所以每个个体又需要通过汇报等方式来追求更多的利益。这些会衍生出一些更具体的问题。
工程结构上“复杂”
我这里的“结构复杂”意思是,开发过程中会出现很多概念。并且这些概念之间又有各种类型的联系。举个例子:
为了完成一个 “关卡”,需要制作很多放在 “关卡” 里的 “模型” ,这些 “模型” 的 “模型资产” 的 “材质” 需要 “技术美术” 去开发,如果 “技术美术” 发现材质中需要一些高级特性需要改动到 “引擎” 的底层代码,又需要 “引擎程序员” 去改动相应的代码。而 “关卡” 中的 “模型”,又并不是所有都由 “关卡美术师” 去摆放的,还有很多是 “程序化生成” 的,它们可能由 “自动化流水线” 去按照一定频率来自动生成。此外,这些 “关卡” 的开发其实划分成了很多 “阶段”,只有这个 “阶段” 被领导“审核”过确认符合预期后,才能进入下一个阶段的开发。而我们的 “引擎” 代码也不是程序员改动完就能立马看到的,这也需要经历一些“审核”和“对应流程”,才能最终被其他开发者看到。。。
这些 “概念” 牵扯到很多方面,不仅是技术上的概念,还有人员分工的概念,开发任务上的概念,流程上的概念等等。
大型游戏往往会有更多的 “概念”。而又因为团队是由不同的个体组成的,所以每个人理解的概念都是不同的,不可能有人能理解清楚项目中所有的概念的。这就为沟通带来了阻碍,进而会衍生出一些更具体的问题。
工程内容上“庞大”
我这里的“内容庞大”意思是,开发内容的量级会很大。例如:一个小型游戏可能只有几个 “关卡” 和几十个 “模型”,但是大型游戏却可能有几十个 “关卡” 和成千上万的 “模型”。
这意味着,你需要采用一些工业化的方式来优化开发,否则就会有很多重复的工作。
此外,又由于 “大脑” 是不同的,那么相同类型的内容被不同人去做的话是有可能出现“风格不一致”的情况。这又会衍生出一些“规范制定”相关的问题。
总结
在大型团队做大型游戏的时候,你将被迫面对一些看似不合理事情,这些事情阻碍了团队开发的速度,也确实会让自己的利益得不到满足。根本原因在于:
- 团队是由 不同的个体 组成的
- 大型游戏是 复杂而庞大 的软件工程
这个根本原因是无法解决的。但以此而衍生的一些具体的问题却是有方式优化的。所以我想根据自己的环境,去描述这些问题并带上自己肤浅的思考。