9个不按常规出牌的游戏开发技巧

《Game Developer》的一个最受欢迎的功能便是我们的“不按常规出牌的编码技巧”(诞生于2009年)，在此我们可以帮助开发者打开一些他们为了满足最后期限或通过认证而依靠的非常伎俩。我们将使用9个全新的故事，包括一些来自其它开发学科(除编程以外)的非常规技巧。所以请继续下去，沉迷于同行们的精明想法，并尽可能地放松下来—-因为你并不是唯一一个顶着压力使用非常规小伎俩的人。

RSX，隐藏的文本资产

Joe Valenzuela, Insomniac Games

这一技巧是在PS3上，我们在Insomniac的引擎团队拥有一些我们想要分配到我们的引擎/工具发行的纹理。这是一些像噪音纹理以及面向全屏滤网的资源输入。出于某些并不重要的原因，我们并不想将这些内容作为实际资产文件进行分配，所以我们决定将其转变成二进制数组并将其编译成可执行的内容。这里存在一个负面元素—-我们想要这些内容处在不同的内存块中(RSX可视)，所以我们最终将复制它们，但却因为资源而浪费了一些内存。

PS3工具链拥有一个链接功能能够将特定的部分置于RSX内存中，但它需要使用1MB的页面，在我们的情况中，它将浪费700k内存。所以我们在名为bss(游戏邦注：即bss alias或balias部分)的可执行内容中添加了一个新的数据部分。在我们的最终架构中拥有像3MB的bss等内容，所以拥有足够的空间能够隐藏一些纹理资产。我们尽早运行某些代码从而让我们能够基于crt初始化去初始化目标内存，复制资产，然后再次将bss初始化为0。

不管你是否相信，它都是可行的!存在一些调整元素能够去适应隐藏的bss使用和工具链升级，但从整体上来看它是非常简单的。

这并不是你所寻找的漏洞

Brett Douville，LucasArts

在2002年初，我们正在准备将《星球大战：绝地战斗机》提交到索尼。还剩下一个不是很重要的TCR漏洞，即控制器的模拟棒功能在我们加载任务后过场动画时会关掉，并因此导致控制器的中心亮起了红灯。当我们升级到索尼所需要的程序库版本时，这一漏洞便会出现，最初编写影像加载代码和控制器本身的IOP逻辑的程序员已经在几个月前离开了LucasArts了。

为了尽快解决代码中我并不理解的问题，我在代码中插入了不同颜色的7个清屏代码，希望我至少能够通过检查在模拟控制关闭时屏幕显示什么样的颜色而将其压缩至1，2个部分。但是当我尝试着去重新创造漏洞时，它却已经消失了。

这是一个早前的编程箴言，如果你并不理解原因，你便不能说是解决了漏洞。但在这种情况下，即离最终提交日期只剩2，3天时间，错过漏洞将酿成大错。所以我将所有清屏代码改成黑色，标记了修复的漏洞，并就此收工。我们按时发行了，并且没有TCR的干扰。

Untitled(from gamasutra)

独立探索

Jonathan Garrett，Insomniac Games

《瑞奇与叮当3》是一款不能修补代码或数据的在线游戏。这是非常遗憾的。

每次当游戏发行时便会呈现一个最终用户许可协议。这是储存于静态缓冲区的字符串。这一缓冲区是源自服务器，并且不会检查、规格是否符合缓冲区的要求。

我们利用这一点让EULA下载能够充满静态缓冲区，从而覆盖一个已知的全局变量。这一变量将成为一个特定的网络数据包的回调函数处理程序。一旦安装了这一处理器，我们便能够发送网络数据包并跳跃到被覆盖的全局变量的地址上。该地址是面向一些早前储存在EULA数据中的有效负载代码的指示器。

有价值的数据存在于真正的EULA缓冲和被覆盖的全局变量之间，所以有效负载代码的第一件工作便是恢复这一垃圾数据。一旦完成了这件工作，所有的一切便会恢复正常，修补工作也能得以完成。

这里存在的一个并发症便是EULA文本是复制拷贝字符串的。当它找到一个0字节(这通常都是字符串的结尾)时，拷贝字符串便会结束。我们的字符串通常包含0字节。所以我们创造了一个变异代码，它将不包含任何0字节，并拥有精心创造的引导程序asm。

最终的过程如下：

1.发送过大的EULA

2.EULA缓冲区溢出，杂项数据，回调函数处理程序指示器

3.发送数据包去引导处理器

4.游戏跳转到处理器所指向的引导程序代码

5.引导程序解译有效负载数据

6.有效负载数据下载并储存杂项数据

7.执行补丁

附：在你的发行游戏中包含补丁代码，并且不要使用无限拷贝字符串。

堵塞卡盘

Michael A. Carr-Robb-John, Monolith Productions

1993年我完成了《沙漠风暴》;我将其从16位体的Mega Drive/Genesis版本转变成8位体的Master System。这款游戏(12K)超越了预期卡盘的规格，但却不可能转向另一个规格的卡盘。在今天，12K听起来可能非常小，但是在当时却是完全不同的情况。在开发期间，我做了预算安排并计划了所有的声音和图像资源，它们都应该是符合限制的。而我并未认真考虑到的这是代码。在那些日子里，游戏是基于汇编语言进行编写，也就是Z80，所以我只有一个选择。我花了1周的时间去寻找冗余码，并重新编写某些内容以确保不会占用较多内存。

当我完成这项工作时，游戏能够匹配一个卡盘了(只有98字节)。游戏能够被放到ROM中并在QA中测试几天，然后再递交给Sega进行认证。不幸的是它在一开始未能通过认证，而所需要做出的修改很快就耗尽了那98个字节。我认为当我们最终能够发行游戏时，可能就只剩下6个字节了!

道尔顿分配

Jonathan Adamczewski, Insomniac Games

在接近项目的最后，我们发现在玩了游戏几个小时后，影像并不能像预期的那样出现。我们的一个内存分配的破碎导致我们不能分配全屏影片重放所需要的巨大内存组块。

我们需要寻找一种能够保证我们始终能够获得所需内存的方法。但是在这个项目中已经太晚了，如果去考虑整理碎片将具有很大的风险，我们没有足够空闲的内存能够用于设置影片重放，从其它系统中获取额外的空间也是不切实际的做法。

显然当影片播放时，存在许多限制的系统，所以我们将考虑从它们中“借取”一些内存。然而这些潜在的资源也都太小了，要不就是也遭受着同样的碎片问题。虽然GPU存在许多空间，但出于各种原因，我们并不能将其作为影片的缓冲区。所以我们需要另外的空间来源。

让我们着眼于另外一个问题，即在我们的主要游戏资产中出现了一个特别的内存分配模式：当游戏开始时，磁盘加载了许多资产，但是它们在内存中却不会被改变。在这些资产中，有些非常巨大。并且在影片播放时并不需要它们。

这带给了我一个想法：如果我们将复制其中一个最大的资产文件到内存的任何地方会怎样?GPU的内存将作为存放资产的临时场所，然后我们便能够临时重新使用资产中的空间用于影片重放，并在影片播放完成后从GPU内存中复制资产数据。

所以这便是我们的做法。我们选择了用于其中一个游戏英雄(名为Dalton)的最大动画片段。动画系统被关掉了，动画片段被复制到了GPU的内存空间中，内存被交给了影片重放系统。在影片的最后，动画数据将被复制到它所归属的地方，动画系统将重新开始，如果未发生任何糟糕情况的话游戏将会继续。最终执行将变得非常简单，尽管过程并未延伸许多帧去确保所有包含的系统在每个步骤中都是同步的。

在角色的动画内存被占用后，影片系统的内存将被描述为“道尔顿分配”。

认证头疼

Michael Carr-Robb-John, Monolith Productions

任何曾经在主机上写过游戏的人都知道所谓的认证头疼。很大程度上，认证是一种尝试也是一种良好的实践，但却存在一两种要求可能成为让开发者伤脑筋的问题。我们必须处理的一种要求便是在用户选择运行你的游戏时，你必须在短短的4秒钟内呈现第一个画面。如果你拥有巨大的执行内容，你可能需要在控制它前花费2,3秒钟进行加载，并且为了呈现主菜单，你仍需要加载一大堆的视觉和声音元素。

我的游戏从用户选择游戏到呈现第一个画面间需要花费26秒，所以我开始感到头痛了。我的第一个工作便是分割菜单所呈现的内容，将加载特定的全局数据推迟到真正需要的时候。让人惊讶的是，这么做的影响比我所预期的还大;这整整节省了9秒钟。在经过许多调整后，我想办法将时间减少到10秒钟，但是我却不能让它更快地进行加载。在与其他工程师讨论问题的时候，我们终于想到了解决方法。

特定的主机同样也有另外的要求，即你的游戏在进入菜单系统前将呈现两个特定的画面。有趣的是我们必须组织用户在特定时间里略过这些画面。如果我们只加载这两个画面，那么在玩家观看这些画面时大多数屏幕是否能够完成加载，即5.5秒钟是否能够完成加载和呈现。

不幸的是，这仍然不足以满足要求，所以我们最终只能申请豁免。

创造声音

Edward J. Douglas, Flying Helmet Games

很长一段时间我都致力于一个长期运行的赛车游戏系列的影片制作。我们的场景混合了直接的网格和华丽的动作序列。当我们在更多续集中迭代时，我们的野心也变得更大，但是我们的技术迭代却相对缓慢。

汽车的动画是通过一个QA“特技驾驶”去获得基本动作，然后在3D动画程序中进行设计以调整动作的时间和布局，并重新导到我们游戏内部的影片工具中，在这里影片重放将模拟所有的物理和引擎行为。我们将获得许多游戏设置数据，包括控制器的汽油和刹车信息，并呈现在3D文件的元数据中，然后在游戏中进行重现。这里所存在的理念在于，这同时也能够驱动汽车音频系统。

问题继续蔓延到之后的几个续集，即在续集中，我们的场景非常复杂，并混合了手动捕捉和记录的汽车动作。早前关于使用引擎元数据去驱动汽车的音频样本的做法已经不再有效—-数据不可能存在了!音频团队不能像影片那样时候再处理音频，因为任何场景都拥有汽车，这取决于玩家的选择和修改，所以音频需要是程序化的。但直到现在，我们的游戏已经获得了许多音频奖项，特别是汽车的引擎声，所以我们决定继续使用它。

在测试之际，我们面对了各种不确定性，但我们那拥有独创性且疯狂的影片，音频和AI程序团队找到了解决方法。汽油和刹车元数据是基于3D场景中一个漂浮的立方体呈现出来。如果一位美术师参与进来并在3DS Max等关键帧编辑器中“绘制”曲线的话，他们将能够创造出他们想要的汽车引擎声。一些音频团队成员临时学习了3DS Max，并通过直觉判断模式转变模式应该是怎样的，并将其压缩在适当的时间范围内。这听起来很棒，但在这最后的几分钟内，我们知道如果想要在下一个续集中使用同一的技术基础，我们便需要一些更强大的技术。

所以在完成这款游戏后我离开了该工作室，在几年后我遇到了一位在我离开后加入该工作室的音频师。这是在我意识到他们从未升级技术不久前，他也是这系列游戏最新续集的“引擎声音创造者”。

好运气

Richard Morwood

我有一列背景纹理，并编写了游戏代码，从而在滚动屏幕时能够将其呈现出来。我的一个背景图像被略过了，即使在花了许多时间去排除故障后仍不清楚具体原因。我们距离截止时间还有5天，所以我在背景列表的纹理中插入了一个额外的参考。这样就没有更多“被略过的”背景了。

HR技巧

Ben Burbank

当我习惯效劳于一家大型公司时，其中一名员工明确了推动自己职业生涯的最佳方法便是为更多同事编写负面的绩效评价。这将帮助他获得更高的年度员工排名，并为他带来更多将近和股权分配。但他告诉我，这种方法变得越来越困难，因为你需要确保你所评价的对象是不同管理者的下属，如此才不会有人识破你的诡计。我关于避免这种循环的方法便是离开并选择其它更小但却更棒的工作场所。

鼓励奖

Chris Pruett，Robot Invader

[编者注释：这并不是一个不符合常规的游戏开发技巧----但是我们认为这是使用工作技能去解决现实世界问题的一种便捷方法。]

我的妻子玩的电子游戏并不多，但是有一系列游戏却是她从小便沉浸于其中的，那便是《勇者斗恶龙》。几年前，她开始在我那上了年纪的PlayStation上完《勇者斗恶龙VII》。在玩了80个小时后，她惊讶地发现自己的保存文件损坏了。它出现在继续游戏的菜单上，但却不能再选择了。她感到非常震惊且生气。并发誓再也不玩这款游戏了。

我发现一台二手的DexDrive能够读取并编写PC上的PS1内存卡，它在eBay上的售价是15美元。我并未告诉妻子我在尝试着挽回它的保存文件—-我并不想在给了她希望后又让她失望，因为我并不敢保证这一方法可行。如果数据遭到了不可挽回的损害，丢失将会是必然的。另一方面，我也觉得尝试着挽救这些文件不会什么损失。

基于DexDrive，我可以把破损的文件储存在PC上，并在一个十六进制编辑中检查它。我最终将其印刷出来并使用荧光笔标记了十六进制;尽管PS1保存在8kb的组块中，但是将8kb文件打印成十六进制数据却需要好几页。使用PS1模拟器的作者所编写的非正式规格，我明确了主要的数据组块：页眉，图标图像，以及保存数据本身。不幸的是，破译原游戏状态数据具有挑战性;几天后我发现这需要比我所计划的更多的工作量。

相反地，我选择专注于数据的页眉部分。因为图标的设置，我可以准确地说出页眉的开始与结束位置。如果继续游戏的菜单能够呈现出保存文件已经被损坏的信息，也许这便只是页眉被损坏而已。我通过从其它保存文件中复制了页眉数据，并将其黏贴在我的妻子的破损保存文件的页眉部分去测试这一点。然后我将这一数据保存到内存卡并加载它。

奇迹般地，它发挥了作用。继续游戏的菜单显示了来自其它保存文件的数据，但一旦完成了加载，她的游戏将完全恢复。在订购DexDrive和修补保存文件间，整个过程大概花了我3周的时间。在某天晚上我启动了游戏并呈现给她带有奇怪名字的保存文件的继续游戏菜单。它加载了游戏并惊讶地发现了自己的进程，角色，统计以及所有道具都回来了。她真的非常兴奋，但在我们进一步讨论前她已经开始转向一个不同的地下城了。