神刀安全网

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

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

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 四周时间并不比二小时的编程时间有成效

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮