另类游戏开发人员的趣闻轶事
导语：游戏开发人员往往需要与摄像师、设计师等非开发人员合作，因此也会比单纯的应用软件开发人员面临更多的问题，当游戏项目出现问题时，很多按部就班的传统方法不能起到作用，这时，往往一些剑走偏锋的办法却能解决问题。
任何拥有编程经验的人都知道，为了在规定期限内解决问题或完成某些开发任务，有时不得不对项目作一些快速的修复，或者使用一些本身就存在瑕疵的方法。一个未能按期完工而导致无法如期发行的游戏项目，往往面临着被取消的命运。而更糟的是，接下来你会因此而失去工作。为了防止出现类似的事情，来看看发生在下列开发者身上的经典趣闻轶事，是否会令你惊讶。
图片来自互联网，与本文无关。
编程反规则
一个名为 Noel Llopis 的开发者刚毕业参加工作，进入了他的第一个游戏项目。这个游戏项目进展很顺利，大家都看好这个项目，然而遇到了一个问题，游戏运行时要求占用内存大小在1.5MB 以内，但现在内存的占用值远大于这个数。Llopis 和他的伙伴们用缩小图像、取消多模式、压缩图像纹理等一切办法后，内存占用量有所下降，但仍无法小于1.5MB 这个值。除非削减游戏内容，但这是不可能的。这时，一个在此类项目上拥有多年经验的开发者提出一个源文件，并指出其中一行：静态字符缓冲区[1024 * 1024 * 2]; “看到了吗？” 他说。然后点了一下删除键。这令 Llopis 极度震惊，因为这与编程原则极度不符甚至相反。那个开发者表示，他删除的确实是在早期开发中为程序预留的两兆内存占用块。而从以往的经验来看，永远不可能削减那些“能削减内存”的预算内容，所以，现在一个经常性的做法是，总是把预留的内存占用块释放掉，让给那些真正需要占用内存的内容。他走出办公室，向大家宣布他已经减小了内存占用问题。他是使这个项目顺利结束的英雄。但是当时，Llopis 还是被这种“野蛮”的做法吓着了。本来是为着项目顺利完成而预留存储块所做的未雨绸缪工作，却在时间和经验的改变下变成不得不释放的滑稽事件。
干扰计划
互联网是有史以来最伟大的发明，它能改善生产力也能产生破坏作用。比如 Twitter 和论坛，博客和教学网站，可以激励和教育人们，但它们也可以使人不断为任何事情而分心从而完全摧毁所有希望。Jay Barnson 在过去一段时间坚持执行了一个计划，他在工作的间隙，（比如一个五分钟的休息时间，每隔一小时）花上几分钟检查电子邮件和 Twitter，或玩一会游戏或做一件其它的只需短时间的事情。他认为如果不这样做，浏览器的唯一用途是用于阅读参考手册页。Jay Barnson 认为与其对互联网上的那些信息所牵挂担忧，不如使用这种短暂的“干扰”计划，从而把干扰变成了一种激励。
作缓存
当 Andrew Russell 处理事情时，为了改善系统性能，往往采用紧密循环，希望在每个迭代过程中产生的数据量尽可能小。这意味着，最理想的是一个数组或矢量对象（不是指针）只包含计算所需的数据。在这种方式下，当 CPU 读取数据的第一个迭代循环时，接下来的几个迭代会装入数据缓存等待处理。开发者可以使用更少更快的指示去做，由于 CPU 会加速，编译器不能得到改善。这是高速缓存的一致性决定的，这篇文章有个很好的例子，不仅仅通过数据线性算法而得到高速缓存相干算法，有兴趣可以看看。
当我生气时你会不喜欢我
Nick Waanders 曾经工作在 THQ 工作室。他们开发的一款游戏曾经是早期的 Xbox 360 游戏之一。大概在一年半以前，他们开始使用 PC 机引擎，并不得不对这款游戏进行完整转换。在这个游戏项目正式运行前的 3 个月时，它在 Xbox 360 机上的运行速率只有 5fps（帧每秒），显然，这个游戏需要进行大大的优化。Nick Waanders 对此做了性能测试，发现项目中的一些模型过于详细需要删减，一些着色渲染代价太大等各方面存在的一些问题。但是对于一个由 100 个开发人员组成的开发团队，总是在分派任务时相应的负责人还在到处乱窜。很难说服一个由 100 人组成的团队改变工作习惯，不过，Nick Waanders 为此提出了一个只需花费一小时的解决方案。他拍了四张不同表情的图片，一个很高兴的表情，一个平时的正常表情，一个有点生气的表情，一个拉扯头发的愤怒表情，他把这些图片与帧速率相关联。如果游戏测试时速率超过 30fps，就显示高兴的图片，如果在 20fps 以下，就是生气的图片。这个解决方案开始实施后，进行游戏优化的相关人员会即时“看到”Nick Waanders 对其优化工作的反应。最后，他们在规定期限内顺利将该游戏的速率提升到了 30fps。
