之所以写这篇文章是因为在机核网内读到了不少愿意做游戏的爱好者发言，从口吻上判断不少还是学生，缺少工程学方面的经验。希望本文能够帮助各位游戏爱好者了解一点基本的工程学知识，助力各位的开发工作。因为本人从事程序开发，这篇文章是以程序员的角度写的。

计算机科学和软件工程学的一大区别就是前者属于科学，而后者属于工学。如果读者的年龄在二十五岁往上，或许会记得《军团要塞2》里面“工程师”的那一则广告。工程学是负责“解决问题”的学问；相较于纯粹的科学，这里的问题指实际而非理论的问题。用上面这张古老梗图的上下文来举例，工程学关注的问题是“如何将叉子固定在杯子上”。这样的方法不一定够巧妙，但是一定够结实。一般来说，游戏开发很少涉及前沿的科学研究，而更多关注于如何组织团队，在一定时间、一定成本的限制下交付成果，是一个典型的工程学问题。

在进行任何具体的开发工作之前，团队能够坐下来开一小时的会，同步整个团队对即将开发的作品有一个共识是很重要的。作为程序员，应该要对自己的水平有正确的认识，能够回答什么能做、什么做不了的重要问题。这些问题对于其他人来说未必是显然的。例如，做一款4D扫雷可能需要一个月，但是做一款基于语音识别、用机器学习技术制作的游戏，就算是最简单的demo也可以轻易花费三倍时间。

除了明确“什么能做”的问题，还需要拟定一个大概的时间表。具体的粒度当然因项目而异。本人曾经参与过的学生项目一般都以周为单位推进。在一切的最开始，一切的估计当然不会是完全精确的，但是一个大致的估计能够给所有人一个具体的目标，给人很好的不摸鱼的理由。

制定时间表的重要参考是一份需求文档。所谓的需求文档是具体地列出了程序员应该做什么的一张列表，用清晰的语言说明开发中需要达成的具体目标。举例来说，“玩家能够在场景中自由移动”是很模糊的表述，而“根据玩家在键盘上输入WASD能够进行有加速度为x，最大速度为y的四向移动”则要清晰一些。

尽管写文档肯定不算是最有趣的工作，但是它应该是最早完成的工作。相反，如果需求无法以清晰的语言表述（“我想要一个这样的效果”），则意味着大伙对自己的想法并没有一个明确的、可执行的计划。在这种情况下，本人的建议是不要继续进行开发：如果原本的计划是建八层楼，那么三个月后再加上第九层是很困难的。

在拟定大概时间表的同时，也要明确项目的规模。在很好的朋友之间，一款游戏可能可以一直做下去。如果是陌生人组建的队伍，每个人的时间都是有限的，对彼此的忍耐也没有那么高。在项目开始的时候，就要讲清楚项目大概会开发几个月，每周每人预期应该工作多长时间。一般人会低估完成项目所需的时间；二八定律总是很有用的。

避免人月神话：一个妇女能够十月生一个孩子，但是十个妇女不能够一月生一个孩子。

除了指定时间表，执行计划也是很重要的。开发过程中产生分歧是常事，有人摸鱼、有人着急也是很正常的。“玩游戏的都是朋友”在这种场合是不适用的，在组建团队的一开始就应该明确每个人的权责，以及在有分歧时的最终解决方案：可以是投票、可以是队长一言堂，但是规则应该明确。

团队中应该有一个明确的队长。按照时间表，队长应该每隔固定的时间召开会议，同步全队的进度，并且根据实际情况灵活调整计划。如果计划已经拖延到了超出预期、无法弥补的程度，那么中途停止也比强行继续下去更好。

这一点应该结合项目的规模来看。两三天的项目通常不会有太大的问题，对于两三个月及以上的项目，钱的问题是需要摆在台面上来说的。游戏开发需要长时间投入的脑力活动，这样的劳作是很有经济价值的，要充分意识到自己和他人的价值，避免打白工，也避免让别人打白工。

可以理解，很多小项目并没有什么钱，开发的成本其实是大伙自己分担的。这种时候彼此其实都是对方的投资人，也要提前说好将来如果有收益的话分账的方法。（即使大部分游戏其实赚不到什么钱，这点也要有预期）。

大概是上个月的时候，看到本站有一篇招程序的帖子。大意是万事俱备，只欠程序；工期多长无预期，最后按照实际贡献分账。这种不清不楚的情况是很容易事后产生矛盾的。为了避免将来的不愉快，事先把一切都说清楚是最简单的办法。