《帝国时代2》曾火遍全球 却一度陷入陷入失败边缘

1999年10月，《帝国时代》的续作《帝国时代2》正式发行，并于当月一举拿下PC游戏的销量冠军。这款持续两年研发，曾经一度因为前作的成功，而导致团队过于自大以至于连续犯下错误，陷入危机，通过一系列的努力和自我救赎，终究给团队、发行商微软，以及所有喜爱帝国时代的粉丝交出了一份满意的答卷。

半年之后，作为制作团队成员的Matthew Pritchard为知名游戏媒体撰稿，详细描述了《帝国时代2》开发期间的一系列波折，以及最终走向成功的秘诀。Matthew Pritchard作为Ensemble Studios的一名主要程序员，参与开发了《帝国时代》以及其续作《帝国时代2》。由于十分在意工作流程中的效率与速度。在工作室里被其他成员称为“优化者”（The Optimizer）。


以下为编译全文：

“假如现在手上在做的这个游戏，卖了一百万份……”，这或许是一句豪言壮语，又或许是藏在心底而无人知晓的秘密。但我相信对于任何一位参与过PC游戏制作，并为此呕心沥血的设计者来说，都曾幻想过这样一个看似十分美好的结果。也正是这样一份对于美好未来的憧憬驱使着我们不断向前。不过，你知道吗？在我看来，事实并非如此。如果要问我心中的真实想法，那我会明确地告诉你， “……要真就这么点出货量，我会非常失望的。”

追名逐利

两年前（1998）由Game Developer刊发的调查报告里，我给你们讲过Ensemble Studios（全效工作室）的传奇故事。这是一家年轻气盛，野心勃勃的游戏工作室，克服了诸多挑战后，制作出了《帝国时代》（下称AOE）。

要知道在1997年，那个堪称RTS类游戏（即时战略类游戏）群雄纷争的年代，《帝国时代》在全球范围内达成了接近三百万的出货量，再加上之后又是将近百万销量的《罗马崛起》拓展包。但故事还没结束。尽管AOE的后续销量势头强劲，一直保持在PC销量榜的前列，甚至于在发售后的一年半再次杀入了销量榜前十。但真正使我们感到惊喜的是一份AOE购买者的数据调查。

诚然我们的主流用户一直都是14-28岁左右的男性硬核玩家。但我们的受众还要更加广泛，在老年用户，女性群体，包括喜爱其他类型游戏的玩家中，我们的产品销量也能取得骄人的成绩。然而事情并不总是一帆风顺，倒不是说AOE的成功会让我们得意忘形。有一说一，商业上的成功为团队带来的不仅仅是利润，跑车和美女，还有一系列全新的挑战。这其中就涉及到我们接下来的作品。注定不会再像第一个那样，成功得如此轻易了。

出续作

所有人都知道Ensemble Studio的下一个作品就是AOE的续作。其实我们团队在AOE远未完成开发的时候，就已经和发行商签下了出续作的合同。对于这款续作，整个立项过程中唯一不用动脑子的地方就是设置世界观和历史背景了。结合我们之前在AOE中使用的元素，《帝国时代2：帝王世纪》（下称AOK）所采用的历史背景自然而然就锁定在中世纪了。


然而，就像一个刚刚霸榜的当红乐队走下舞台回到自己的排练房一样，对于下一步该做什么，成员之间各有各的想法。是选择保守地继续沿袭着前作AOE的那种游戏机制呢？还是提出一些大胆的想法并付诸于行动？对于任何一个想要延续爆款神话的团队而言，这都是个价值千万的问题。不过相比于之前提到的乐队，他们还算幸运的。至少乐队们不用急着去适应不断发展的电脑硬件与游戏技术所带来的革新与变化。

而反过来对于我们这些从业者而言，针对游戏及其他领域不断衍生的变革做出预判，已是一个不成文的事实。但就像很多人说的，所谓预判有时就是个骗局。就拿之前提到的消费者数据调查来讲，这批受众才是最有可能入手我们续作的消费群体。也正因如此，团队里的每一个人都把注意力放在这件事上。如何让这批人数众多且各有喜好的用户跑出家门，购买续作？答案很明显，在AOE的基础上做得更好，然后顺其自然。

听起来多棒哦，但把这句话具体量化细节到每一个工作步骤和流程上几乎是不可能的。大家心里都明白，对于那些没能够跟紧时代步伐的工作室，以及在尝试中不断浪费时间而渐渐偏离玩家预期的团队，游戏这个行当可是十分残酷的。


开始着手制作AOK的时候，我们认为之前AOE里那些现成的代码和工具是能够拿过来直接用的。这样一来，相比于原作，续作的开发会来得省事不少。基于这一不动脑子的想法，我们预计AOK只要一年左右的时间就能开发完成。这也算是把之前设想过，但没能实现的功能重新呈现出来的一次机会。说不定还能在整个电子游戏史上留下浓墨重彩的一笔呢。

于是我们决定就这么干。为了显著提升AOK的游戏性，工作室里有一张长长的清单，上面的每一条都是成员们期望实现的想法和计划。参考着这张清单，我们在游戏设计上添加了一系列充满灵性的新玩意，比如地图外的贸易（off-map trade），资源的可再生，战斗时的角色肖像，设计精巧的外交选项，甚至于宗教系统等等。除此之外，美术，声效以及其他游戏内容都得到了扩展，更加大胆又充满创意，且看似可行…讲到这，你或许能猜到后面的结局了。

进度展开的几个月后，现实让预想分崩离析。我们是如此得不自量力，团队在游戏的设计策划上也失去了重点。一时间不知道该做什么了。我们一而再，再而三地背离了可以使续作在RTS类型上走得更好的道路，不断地朝着相反的方向尝试着。慢慢意识到问题的严重性，我们之前想在一年之内将续作完成的想法已然无法实现。更不要说还要保证续作的质量维持在前作的水平线上。

无论是对于Ensemble Studio，还是我们的发行商微软而言，这段时期都非常低迷。尽管团队的那些成员状态调整得还算及时，但由于微软的某些员工说了句：“兄弟们实在不好意思，我们已经提前告诉老板今年说什么都会有一款帝国时代的续作放出来了。”

我们不得不提出一套应急方案。工作室需要再花一年来研发帝国时代的续作，以此把流程拉回正轨然后完成足够优秀的游戏内容。至于微软，我们也准备了一套方案来帮助他们度过难关。那就是利用现有的一小部分资源来完成一套对AOE十分关键的额外拓展包。

更为重要的是，拓展包必须赶在98年的圣诞节发布，以此来补上本应由AOK出席的空缺。就这样，《罗马复兴》（下称ROR）诞生了。但我们还没法松下这口气。不像AOE发售前后有一段预留期，虽然它也是晚了一年才推出的。但AOK的发布日期经过调整已是板上钉钉了。身处那段特殊时期，整个团队的压力还是很大的，毕竟心里要时刻牢记游戏完成的日子。


我们做对了什么

所有能使AOK成为3A游戏的事情，我们都做了。而清单上的那些想法必须一一放弃，然后从头开始。尽管短时间内决定再花一年研发多少难以接受，但我们深知这才是正确的决定。毕竟Ensemble Studios承诺过续作会更加优秀，也决不会食言。为了赶回进度，我们雇了一批新的程序，美术和策划。新老员工由于陡增的压力也慢慢凝聚在了一起，逐渐成为了一支真正的团队。

1. 处理掉前作留下来的主要问题

抛开AOE的成功和当时围绕着它的赞美，游戏本身仍有两个地方是被玩家重复指出和批评的：由AI控制的愚蠢电脑角色和糟糕的寻路功能。说实话，他们的批评是对的。因为这两个问题实在太过明显。而且我们知道如果不去着手处理，以一种看得见的方式有效处理，那么AOK即便顺利完成，也一样会被广大玩家和用户喷得体无完肤的。这倒不是说其他的RTS类游戏就没有类似问题，毕竟我们的竞争对手不是它们，而是曾经的自己。


针对电脑AI的问题，我们特意聘请了一位有着丰富AI行业经验的专家，Mario Grimani。在他的指导下，之前AOE使用过的AI系统被摈弃了。转而开发并采用了一套更为专业，依靠脚本运行的全新AI。当Grimani在一边编写代码的时候，游戏设计师Sandy Petersen会领着策划团队在旁边为新AI制作全新脚本。另一方面，我们鼓励工作室的全体成员都参与进这个项目里。他们会不断地把对战过后得出的战术添加进去，以至于研发后的AI可以应付全年龄段的玩家，并且基于玩家的策略做出不同的反应。

至于寻路功能，拼尽全力迅速解决才是王道。为此游戏引擎的移动系统经过重新设计，团队开发了各自分开的三种寻路系统和两种障碍系统。为此五位成员花费了大量的时间和精力才得以解决这一问题。一个高级寻路系统可以跨越整张地图的范围计算出大体的移动路线，而换成低级寻路系统则有可能会径直穿过最近的单位编队，不做出任何的回避行为。站在玩家和用户的角度，像是这样显著的改变，也能够让他们注意到团队的付出和随之而来的体验提升。

2. 只在适当的范围内不断改进

AOK和 AOE之间的区别并没有当初设想的那么大，毕竟团队最后决定把RTS的游戏体验作为最主要的提升方向。这里面有些只是交互上的提升，比如“寻找下一个空闲中的农民”指令，完全自定义热键，以及……等等。其他的一些改动则是针对游戏本身的机制，例如城镇中心的警钟（摇响警钟，所有的农民都会跑进城镇中心进行防御），游戏自带的建筑科技树，当然还有自动阵型的功能，这也是广受好评的几个功能之一。

所谓自动阵型，也就是让一队被选中的单位以一种合理的方式自行编队，能扛在前面的单位置于前排，而需要保护的单位则尽可能地放在队伍后面。经过自动编队的单位不会在移动过程中“散架”，相比于已经被广大RTS玩家习惯操控的“自由军团”（毫无队形可言）要高出不少。

为此程序员Dave Pottinger起初创造了一个基于回合制战争游戏系统的编队模式，但随着游戏研发进度的推移以及我们对于游戏的整体理解和视角也在改变，这一复杂的编队系统被相对简单的给取代了。毕竟核心是为游戏本身的体验服务。


在为AOE编写图像引擎的时候，我会在工作时采用166MHz Pentium处理器，然后回到家在自己的486（早年的Inter处理器）上进行测试。我的目标是一块2MB的显卡，但游戏只能跑出1MB显存的效果。如今我在 500 MHz Pentium III 的系统上有一块32MB的TNT2 显卡。这些游戏玩家配置上的典型变化也反映出玩家对游戏画面效果上的日益期待和追求。

对AOK而言，我可以很自豪地说这款游戏符合甚至超出了多数玩家心中的预期。当你在玩AOK的时候，第一个会关注到的点就是游戏中所使用的比例。AOK中单位之间的长短基本大同小异，但建筑与周围的环境例如树一类的装饰物就不再一致了。从比例上来说，你会发现它们都很大，控制的单位看上去就像是能自由进出建筑物一样。城堡和奇观在屏幕上都显得极具视觉冲击力。而美术本身也比原先的好出太多。我们的整个美术团队都从之前开发AOE和ROR的过程中积累了不少经验和技巧，而AOK正好为他们提供了一个融会贯通，展示成果的平台。

当然，不仅是单位与建筑之间的比例关系。在AOE中，游戏的地形表现总会给人一种“人工草皮”的很不自然的感觉。而手动制作过渡地块（transition tiles）的需求又将游戏本身的地形纹理限制在四种，等到开发AOK的时候，我们设计了一个全新的地形系统。

这允许我们将地形混合在一起，通过阴影表现高低海拔，极大地增加了可使用纹理的数量，甚至还混合出了水的纹理效果。当我们在1999年的E3展会上演示AOK的时候，所有的竞争对手都不敢相信AOK仍然是一款256色的游戏。在我看来，这算得上是我们至今为止所获得的最高评价了。

3. 更好地使用BUG追踪软件和紧要关头时的管理

在AOE的开发过程中，整个办公室当时只有一台机器可以连接到RAID上，它曾经是微软的测试员用来管理已知BUG的。我们经常会靠那台电脑连上数据库，如果另一头的复印机心情还不错的话，就会人手打印一份纸质的BUG报告。当然成员之间也有另一款软件来记录BUG或是交换意见。但软件的使用许可并非每一个人都有。说到底，这样一套系统无法满足团队的需求，但当时的我们手头上也就只有这些家伙了。

而等到开发AOK的时候，情况就截然不同了。有了ThinRIAD（新的解决方案）的支持，每位成员都能直接通过网页浏览器进入BUG数据库。这样一来，每个人的桌面上都开着一样的系统，任何时候需要都可以直接进入，随时随地上传更新资料，团队整体追踪BUG的能力也得到了显著提升。我们也就能专注于优先事项，避免许多不必要的错误，从而省下不少时间。


记得在开发AOE最后的半年时间里，团队几乎没怎么休息，马不停蹄地赶着工作进度。成员的压力都很大，有时甚至影响到了健康和婚姻。作为一家负责任的公司，为了避免这样的情况再度发生，Ensemble Studios调整了团队的成员结构。在一线岗位上任用了一大批年轻未婚的职员，而那些已经有家庭的老员工则负责在幕后主导工作进度。

另一方面，为了确保团队不出差错。我们预先设置了多个进度点来合理规划这段紧张的工作流程。上班时间从早10点到晚12点，每周三的晚7点可以提前下班，这样员工就能早点回去和家人团聚。公司有双休日，并且提供工作日的伙食。

这一系列措施在大多数情况下还是十分有效的，尽管“家庭之夜”的设置（每周一次，允许员工和自己的家人一道和团队进餐）后来被指出是弊大于利的。相比于设想的效果，类似的活动往往会使员工分心。不过就总体而言，对这段紧要关头的处理安排，制作人Harter Ryan还是值得表扬的。

4. 合理使用软件工具和自动测试

在AOE的开发工作结束之后，团队还另外开发了不少远程软件和游戏内置的小工具。以此来帮助程序员更为容易的上手和处理相关事务。其中一直拿来用的工具有ArtDesk，一个能够将游戏图像的标准格式转换为我们独有格式的多目的程序。凭借这一软件，团队能迅速浏览和分析图像数据上的内容，并为游戏生成许多自定义的数据文件。这一简单易学的GUI-based程序替代了不少早已过时的DOS指令行的功能。此外，它还能够自运行许多任务。长远来看为整个游戏开发过程省下了不少时间。

值得一提的是，Herb Marselas也付出了许多努力，编写了诸如Lint，BoundsChecker, 和TrueTime这样的小程序。相比于之前AOE的开发过程，我们使用这些工具的频率也有明显增加。要知道它们对于编程代码质量上的提升是无价的。

最后，关于游戏中内置的小程序，例如不同单位之间战斗的对比模拟器，也让游戏策划能更加科学地平衡游戏性。这些细节不单单节省了时间成本，还提高了游戏本身的品质。有效使用类似的软件和工具最终带来的成果是十分显著的。唯一不足的地方就是当时缺少了对于美术资源管理的小程序。

5. 主动迎合搭载系统的需求

一款预期要卖出上百万份的游戏，自然需要在绝大多数的机型上都能够流畅地跑起来。当然我们也可以要求自己的用户使用尖端的操作系统或是特殊的高级显卡，但显然这是不存在的。不过像AOK这样的8位2D游戏，绝大多数显卡的配置还是能够跑起来的。但对内存和处理器运行速度而言就是另一回事了。AOK游戏内所采用的全新系统都需要相应的硬件配置驱动。优化问题在开发阶段的最后几个月一直都是团队工作的重点。

好在直到最后一刻，一些小技巧的运用和图像细节上的变更使我们能够达到CPU（Pentium 166MHz, MMX-supported CPU）的要求。而32MB，最低配的内存要求，我们也努力实现了，但还是有些许保留。多人模式里的大型地图依旧需要额外的8到16MB的内存才能正常运行起来。

不过言而总之，在1999年的圣诞季上发布的那些游戏中，AOK可是要求配置最低的那一波了。而这极低的配置要求，恰恰拓宽了市场中潜在的用户数量。

我们走了哪些弯路？

尽管我不想这么说，但是我们开发AOK时遇到的困难确实比当时开发AOE的时候还要多。现在我就来分享一下，在我们制作了一款成功续作的背后，我们还有那些不足。

1. 我们仍然没有补丁升级流程

这个问题从AOE时期就存在，甚至直到我在写这篇文章的时候我们仍没有解决这个问题。我曾在盘点AOE的时候就列举了一些设置补丁升级流程的原因，现在又多了一个新的原因：防止多人游戏中的作弊。起初在AOE中，玩家会利用在游戏中发现的bug去赢得比赛。之后的情况变得更糟。游戏中出现了一种叫做“训练者”的程序，这个程序确实能够优化游戏代码，然而，这种程序同时也允许玩家在游戏中直接进行作弊。


投石机是游戏中最受欢迎的单位

仅作为开发者而言，我们甚至不确定是否发布补丁或者何时发布补丁。结果就是，整个1999年，我们不停地被自己的粉丝指责，他们认为我们不关心那些影响在线游戏平衡性的问题，这些问题让很多玩家都放弃了我们游戏的在线功能。关于在线多人对战中的作弊问题我认为有太多可以写的，我甚至希望在不久的将来专门为它写一篇文章。我们尝试过和我们的发行商解决这个问题，并且也被承诺会有一个补丁升级系统。

很不幸，AOK上线时存在着一些很严重的BUG亟待解决。这些BUG虽然不会让游戏崩溃，但是如果不立刻解决，我们的游戏以及声誉都会再一次受到重创。

2. 测试版本的泄露问题

这个问题其实源于我们AOE的成功。几乎所有游戏的测试版本都会或多或少地在一些盗版Q渠道中传播，这些渠道以warez（类似于国内游戏破解团队，免费的技术团队）这个名字而被人熟知。我们曾吃惊地看到，我们的alpha版本在正式版本上线8个月前就泄露了。很幸运的事，因为那时我们还并不被关注，所以在游戏发行之前几乎没有人受到游戏泄露的影响。

在AOE的成功下，AOK则是完全不同的一个故事了。AOK本身就是一个万众期待的产品，各种不同的破解团队都试图拿到我们的最新版本，虽然屡屡受挫，但他们仍可以拿到我们最新版本之前1、2周的版本。现在看起来，我能想到地方都可能泄露我们的测试版本，比如微软的游戏测试员、送给杂志的预览版，甚至内部人员。很可惜，我并没有能力得知谁才是真正的源头。

最令我们头疼的是新加坡和香港地区的盗版。他们将破解版本的AOK刻在光盘上并自己印上了美术封面，这些光盘在整个环太平洋地区都有售卖。在韩国，甚至在微软总店前经营的游戏商贩也在卖盗版的AOK。这些盗版产品甚至在eBay上都有出现。尽管目前我们不知道我们的收入情况是否会因此受到极大重创，但是我们自尊心确实受到了打击。以后我们所有的游戏，甚至包括单人游戏，我们都要让他们处在我们自己设计的安全框架内执行。

3. 游戏测试方面我们遇到了很多问题

在测试方面中，我们遇到了很多我们之前遇到的问题。目前较好的一点是我们新的办公室有一篇专门的测试区域，这里有多台同等配置的机器。不好的一点是我们并没有把测试环节做到最好。

很多时候我们的游戏测试是没有规划地进行的，并且我们也没有对其给予足够的重视，这使得我们获得反馈的时效性和意义大大降低了。有时候我们甚至无法区分，到底我们测试是为了找出具体的BUG和问题还是仅仅为了有趣。

我们公司有一个整体的时间表，然而时间冲突和执行力不强导致了大部分的游戏都是一批人在玩。我们玩了太多的多人模式，而单人模式则没有给予足够的重视。而且一些人确实是把测试游戏当成玩游戏了，他们对其他玩家说垃圾话、庆祝游戏胜利、输掉游戏后愤然离开。

测试问题也不仅仅发生在我们公司。在微软，一个测试员曾被发现近一个月内，在测试的所有游戏中，他都打开了作弊系统，他玩并不是为了测试，而是为了赢。这使得那个团队先前2个月获得的反馈只能全部失效。

4. 没有专门的美术资源管理系统

AOK中图像独立框架多达数万个，我们并没有很好的去管理它们。程序员的源码控制系统可以帮助他们整合基础输出代码，设计师也有游戏的数据库系统。但是在与游戏美术资源方面则没有能够对等的系统，美术往往不知道他所做的东西是否其他人也在做。除了在办公室里走动交流，他们没有其他的方法能够让他们快速得知其他美工在做什么。

此外，我们没有一个系统能够告诉我们到底哪些素材已经被用上了而哪些素材还在闲置状态。当我们成长为一个公司的时候，这些问题就变得越来越大。为了解决这个问题，我们将建立一个类似于源码控制系统的整合系统的美术资源管理系统，并将其利用与未来的所有项目中。

5. 存在于第三方API和软件中的问题

这个问题曾经在AOE中就发生过。微软的DirectPlay API目前仍然存在着大量的问题，换句话说，它现在还并不完美。其中它最大的问题是API次要部分记录和测试的缺失。

AOK开发的最后阶段，我们的通讯程序员Paul Bettner会与DirectPlay的开发者沟通，然后经常会出现下面这种情况：Paul试图去解决某些问题但DirectPlay开发者则表示由于一些Bug，可能并不能解决这些问题。他们往往知道这些BUG的存在，但是从来没有记录过他们。


一个游戏战役中的场景。升级的图像引擎和建筑规模允许我们创造相比AOE更为震撼的场景。

DirectPlay并不是唯一的问题。我们曾决定利用DirectShow去处理一些我们的动画部分，然而很快我们就失败了因为它不好用。之后出问题的还有微软的官方服务器设计软件。

由于没有足够的测试和修正时间，这款区域设计软件在开发进程中运用过晚，出现了大量的问题。很不幸，只意味着那些通过TCP/IP协议直连进行游戏会比在官方服务器上进行游戏更加可靠，这是件及其令人沮丧的事情。这并不是都怪这个软件，因为我们确实也没有足够及时地向他们反映我们的诉求。

表演还将继续

回顾成功后的历程我十分触动。AOE的成功是很多其他游戏从业者未曾体验过的。那次的成功让我们有了更大的野心，这也允许我们公司可以自己掌控自己的命运。我记得当我们当时第一次拿到AOE版税支票时的场景，在那之前我从没有手握过上百万美元的支票，那感觉实在是太棒了。我们不停地回味着我们所做的那些事，我们觉得自己太厉害了。

时间久了，我们开始变得自大起来。拥有AOE这样的成功经历，我们很快就忘乎所以甚至在想我们下一年还要继续工作。在一些诸如游戏开发者大会和E3这样的产业活动中，我们当中一些人的某些举动真的让我们十分尴尬。就算你成功了，你也不能太嚣张，毕竟游戏产业是一个很小而且变幻莫测的产业，没什么事情是绝对的。举止得当并且多结识产业中的其他人远比关注当下让人心跳加速的成功重要的多。我们只要关注，自己是否一直在进步，而且一直在挑战自己成为更好的开发者就够了。

现在所有早期的现象都在显示，AOK将会成为像它前辈一样的一枚重磅炸弹，甚至可能做得更好。我们甚至不敢相信报道对它会有如此正面的报道。根据PC Data，AOK是10月份销量第一的游戏。AOE的巨大成功让我们能够继续向前去制作一个更加伟大的游戏。

尽管这个成功让我们能够继续成长，也让我们获得了更多的关注和资源，但也给我们带来了很大的压力，并催生出了许多新的挑战。人们提高了对于我们的期待，一方面我们认为这让我们在开发过程中的难度变得更大，另一方面我们也认为这是对于我们第一部游戏成功的奖励。最终，我们成功创造了一款值得我们骄傲的作品，我很幸运我是这其中的一员。

via：游戏葡萄