|
4. Jamming the cartridge 塞满磁带 Michael A. Carr-Robb-John, Monolith Productions 在1993年，我将Desert Strike从16位的主机移植移植到8位的主机。游戏所需要的磁带大小约为12K，并且更大容量的磁带超出了预算。现在12K听起来非常小，但是在当时 是笔不小的预算。在开发过程中，所有的图形和声音资源都被我压缩到了极限，唯一的可以压缩的只有部分代码。在那个时候，游戏一般采用的是汇编语言，我们采 用的是Z80汇编，所以我只有一个选择。我花了一周的时间查找了冗余代码，并且用内存占用更小的方式重写（一般会消耗更多CPU）。 当我完成之后，游戏安装到磁带只有98B的剩余空间！游戏被刻录成ROM经过几天的测试之后，提交到世嘉进行认证。不幸的是第一次测试没有通过，之后修复bug很快用完了这98B。当我们发布的时候，剩余空间只剩下6B。
5. The Dalton Allocator Jonathan Adamczewski, Insomniac Games 在一个快要结束的项目，我们发现在长时间游戏之后，触发过场动画无法正常播放影片。因为我们的内存分配器不能可靠分配足够内存，以供影片全屏播放。 我们需要找到一种方法以确保我们可以得到足够的内存。但是已经到了项目的晚期，我们没有预留足够的内存供影片播放使用，而且采用碎片整理堆的风险太大，从其他的模块得到剩余的内存也不切实际。 可以明确，影片播放的时候其他很多模块处于空闲状态，所以我们可以考虑从其他模块得到内存。然而这些潜在的内存来源要么太小，要么同样受困于碎片问题。GPU有大量的内存空间，但是因为一些原因影片播放器不能直接使用它做缓冲区，因此我们需要一些其它来源的地址。 转到另一个问题，我们游戏为主要资源分配内存的一个特性模式被发现了，当游戏开始的时候我们从磁盘载入资源，这些资源在内存中不会被修改。其中一些资源非常大。而影片播放的时候它们都不会被使用。 所以我们最终的做法。我们选择了游戏中的一个英雄（名为Dalton）最大的一套动画。过场动画触发时，在动画系统关闭之后将这套资源拷贝到GPU 的内存中，然后将资源占用的内存给影片播放系统使用。在影片播放结束后，动画资源被复制回原来的内存中，动画系统重新开始，游戏正常运行就像什么都没有发 生一样。实现的过程相当简单，虽然跨越了数帧以确保所涉及的系统的每一个步骤都安全的同步。 影片系统的内存被描述为从”the Dalton Allocator”分配，在动画资源的内存被强占之后。 （我发现这种事情在工作室已经有一些历史，在项目早期没有预留足够的空间，所以在GPU内存中随意塞入几个东西）
6. Certification headache Michael Carr-Robb-John, Monolith Productions 任何一个为游戏机开发过游戏的人都曾经为通过认证头疼过。大多数情况下，认证的标准一般只是一个惯例并且是良好的做法，但是总有一些标准会成为开发 商最头疼的问题。其中一个这样的标准就是，我们必须保证在用户选择开始游戏后4秒内显示第一帧画面。如果你的程序很大，在进入主菜单前至少要加载2-3 秒，而此后你还要加载一大堆的声音和资源文件。 我的游戏在用户开始游戏后需要26秒，所以这对我来说是个大问题。我的第一个优化是找出主菜单所必需的资源，其他资源都延后到需要时加载。出乎意 料，这样做优化了9秒的时间。在做了许多其它优化后，加载时间减少到10秒以内，但我没法再继续优化下去。在和另一个工程师讨论之后，我终于找到了最好的 办法。 这个游戏机要求在进入主菜单前必须播放2帧特定的画面，而且用户不可以跳过这2帧画面。这样就有了一个办法，我们最初只加载这2帧画面，在用户看这2帧画面时再加载主菜单所需要的资源，让我们来下……balabala……这次只画了5.5秒。 很不幸，这还是不能达到标准。所以最终我们不得不申请豁免，当然我们通过了（因为离标准已经很近了）。 
7. Painting sounds Edward J. Douglas, Flying Helmet Games 我长期为一个赛车系列游戏从事动画艺术工作。我们的游戏场景是一些网格和动作序列的组合。在我们的续作中，我们的野心越来越大，但是我们的技术更新比较慢。 我们的动画制作过程是，是从一个特效软件制作基础的动画，然后导入到三维动画程序中调整动作的时间和位置，接着重新导出到游戏的动作工具加入物理和 引擎的模拟信息，大量游戏数据被捕获，包括气体和来至控制器的信息，并保存在3D文件的元数据中，然后在游戏中再现。当时的想法是通过这个（读取对应3D 文件中的音效数据）驱动游戏的音效系统。 在几个续作之后问题又来了，在混合了手工捕捉的记录和汽车动作后，我们的动画变的非常复杂。以前老的通过使用3D文件的元数据来驱动我们汽车的音频 样本的做法行不通了——因为数据可能不存在。音效团队不可能像提交动画一样提交音频，因为在什么场景使用什么汽车取决于玩家的选择，所以音频需要能动态选 择。但是，我们游戏的音效已经赢得了无数奖项，特别是汽车发动机的声音，所以我们觉得继续使用它工作。 公测即将开始，事情变的疯狂起来，但是由我们的过场动画，音效，AI组成的疯狂而又才华横溢的团队找到了解决的办法。油门和刹车在3D场景中采用一 个浮动的立方体表示。如果一个艺术家加入，并且使用类似3D Max的编辑软件绘制一些曲线，他们可以画出期望的发动机声音曲线。音频团队的几个成员临时学习3D Max的使用，并且使用他们的直觉来判断什么转速模式采用什么样的声音曲线，然后赶在发布前，导入到所有场景。最终的音效听起来不错，但是最后采用的手段 让我们明白，我们需要更新技术保证续作能有更好的表现。 也是只有我是这么想的，在那个版本之后，我离开了工作室。几年以后，我遇到了一个做音效的家伙，在我之后加入了团队。不久后，我就意识到，他们并没有更新技术，他就是那个为最新续作绘制”发动机声音”的家伙。
|
