四周时间并不比二小时的编程时间有成效

在Warsztat(一个波兰的游戏开发组织)工作的几年中，我发现一个有 趣的现象。经常我们会组织一些编程竞赛，这些竞赛通常分为两种形式。一种是个人行动，一般只有2个小时的时间，另外一种是长时间的(数天/周)。作为一个 额外的要求，前者通常限制只允许使用基本的API(SDL, OpenGL等)，而后者通常没有限制(可以使用各种引擎，UDK/Unity等)。

结果有点让人吃惊。很多人更愿意参加短竞赛。但不管游戏是在2个小时里开发出来的，还是在4周内开发出来的，它们中优秀的部分的在水平上一样的。为什么？

1. 4周的开发期并不意味着开发的时间是672或224小时。在一些极端的情况在，4周的竞赛跟2个小时的竞赛一样，也就是这4周的最后2个小时在起作用。
2. 很多的游戏体现出来的实际是一个创意。事实上：你4周内想出来的创意未必就比10分钟内想出的好。
3. 2小时竞赛的开发过程压力强度非常的大。大部分的时间都是用来改进核心功能(因为也没有其它的)。
4. 另一方面，在长周期竞赛项目里，人们最初只是关注一些无关紧要的功能。一旦你开始琢磨着添加一个界面组件，把它做成一个内置的MP3播放器，或把界面弄的色彩斑斓，你的项目就开始失败了。

这也许是我们得到的最重要的教训。如果你需要很快的完成某项事情，代码可能会写的很差，但也会很短小、简练和灵活。如果没有时间的约束，程序的复杂度，功能项和缺陷率会上一个等级。给日后维护带来的工作量并不体现在现在。

在4周的编程时间里，你可以进行数次的快速迭代编程，每一次都对游戏的核心功能进行改进。但如果一开始你就把一些以后未知的特征功能考虑进去，写这 部分功能以及修改bug会耗去大部分的时间。诚然，你可以用这4周时间写出大量的assets测试，但核心的游戏娱乐方式设计的足够好吗？

最后，给你们一个绝对有价值的C(++)忠告：当增加新功能时，从最小的核心功能开始：

1. 全局函数 — 如果你需要去显示分数，不要犹豫，立即写出void DisplayScore()。如果你的游戏是单人玩的，把分数存成全局变量。看看，你至少节省了10分钟的写getter、setter和设计给模块通 信的时间。不需要做这些。如果游戏是多人玩的，你需要为每个人记录和显示分数。但如果你的游戏不是多人玩的，你没有任何理由实现能显示任意多人的任意分数 的功能。相信我，你将会遇到比显示分数复杂的多的多的问题。
2. 如果你的函数需要用到共用代码或需要辅助函数，请把它们组织到一起，最好是放在一个单独的文件里。时刻想着静态函数和变量 — 跟“OO”的静态相反，文件的静态是可见的。这样做很好，因为你可以把所有跟字体相关的操作都放在一个文件里，把把所有内部数据都放在静态全局变量里。辅 助函数可以做成静态的，通过共享的header对外开放(如果你写出简单的代码，整理工作从来不会耗费你太多的时间)。
3. 只有在必要的时候才把函数提升为类。记着，类意味着对象，对象意味这相互关系，而相互关系意味这复杂。你的游戏设计会酷到留有大量的时间处理代码的复杂吗？
4. 只有当上面说的这些不够好，设计模式或其他新奇的东西才能成为你的求助目标。永远不要走到这一步。

英文原文：Simplicity Oriented Programming