【在这份1998年由我们的姐妹出版商Game Developer magazine出版的开发反思报告中，Ensemble工作室为我们揭示了在大型PC实时战略游戏《帝国时代》背后的故事】，译者游戏邦ciel chen

最近在一家当地的电脑商店里，我遇到了一件让我乐坏了的事。当时我正在沉浸在对排名最火PC游戏前十名的欣赏当中，然后欧文无意中听到了两个年轻人下面的这段对话：

“你觉得这个《帝国时代》这个游戏怎么样？”第一个人问道。

它的同伴回答说，“啊，这就是微软把《魔兽》和《文明》结合起来用来赚钱的那些游戏。”

由于我总是迫不及待地想要提高我们的销售额，所以我借此机会告诉年轻人，这些游戏不是一家大公司的创意产品，而是一小群有才华的人在他们自己的后院造出来的。

对于我们来说，《帝国时代》不仅仅是一个史诗般的游戏大作，而且是我们一小群人的一个史诗般的旅程，我们希望旅程的重点是能把我们的概念变成一个真正的游戏。一路走来，我们笑过，我们哭过，我们点披萨喝咖啡熬夜，我们学会了很多游戏开发的知识。

对“过去完成时”进行再设计

很明显，《帝国时代》刚开始看上去并不像成品。尽管有人指指点点，但《人类的黎明》(AoE最初的名字)并没有被创造成一个《魔兽争霸2》的克隆版本。（事实上，《魔兽争霸2》在发行之前，帝国的开发都已经顺利进行到一半了。）

相反，最终设计是随着时间的推移而不断发展和完善的，同时也会伴随着一些重大的设计问题。在游戏公司里，我觉的最好的事情就是你能有玩各种不同游戏的员工。

对Ensemble工作室来说确实需要这样的员工，我们的开发人员Tim Deen购买游戏的习惯以及他几乎会去玩所有上新的PC游戏给了我们很大的帮助。是Tim所购买的《魔兽争霸2》让工作室吸引了工作室其余成员的注意。就是那个时候，《帝国时代》的很多游戏内容，比如资源管理、帝国构建以及技术研究得以成型。

然而，我们并不真正了解战斗的内容要怎么做。《魔兽世界2》就如同一股泼在脸上的冰水，让我们清醒地意识到实时战斗是多么有趣的玩法。工作室员工每周总有几次会熬夜一起玩《魔兽世界》。这些即兴的事情在《帝国》进展到成为比《魔兽》还要好玩的游戏之前一直都在发生。

另外一个重大的转变是发生在开发一半的时候，那时候设计者正在研究《帝国》的本地化计划。他们意识到《帝国时代》将会售往亚洲地区，然而亚洲地区存在着不止一种文化。

我们在全公司范围举行会议，决定讲亚洲的早期文明加入到我们已经开发的欧洲、非洲和中东部落的文明当中。尽管这个添加的内容会为美工和设计师制造更多的工作内容，但这个决定最终还是看到了这个游戏在亚洲的可观盈利前景而定下了。

这些所有的变动之所以能够发生，都是因为游戏的设计师敢于采纳工作室其他员工的想法意见。在Ensemble工作室，开发一款人人都为之骄傲都想去玩的游戏并不只是说说而已。也许体现这一核心价值观的最好例子是游戏中的奇迹建筑——玩家可以建造和使用来赢得比赛的倒数第二座建筑。

在1997年早期，《帝国时代》在激烈的战斗上做的很好，但是每个人都觉得游戏还应该再添加一点新玩法。在尝试和否决了各种各样的想法之后，Mark Terrano，我们的通信程序员，想到一个主意——构架一个“末日之钟”来强制玩家放弃他们正在做的事情并对新的挑战做出回应。《帝国时代》充满了美工和程序员想到的各种小点子和后期补充。这种参与度让我们增加了我们对游戏的归属感和自豪感。

在设计师的工作中，有一件事情是真正被低估的，那就是游戏平衡。设计师要花上个把月的时间来调整成本、力量、速度和很多其他的统计数据，就为了创造出一款好玩而没有漏斗与作弊之机可趁的游戏。

当我们不相信他的评价时，他会立即用这个漏洞在比赛中让我们被“打脸”。在一年的大部分时间了，游戏制衡都是首要任务，而且最近的即时战略游戏里，它能比其他游戏内容更能让《帝国时代》获得更多的持久力和更好的游戏体验。

令人激昂的多人游戏之路

多玩家支持是早期设计中的重要组成部分，而《帝国时代》的构建就是这样一种模式——和大部分游戏一样，它无法区分人类玩家和电脑玩家。当DirectX首次出现之时，DirectPlay似乎就成了在最广泛连接类型当中提供通信的最佳选择。

为了支持大量的行动单位，我们使用了修行过的游戏同步模型，通过它整个游戏可以同时在多台机器上运行。只有移动、更改和指令才能与其他机器通信。这种方法的优点是最小化了需要发送的数据量。

而使用这种模型的潜在危险就是它可能会造成游戏在一台机器上的运行和其他机器上的运行不同步的情况。这给《帝国时代》带来了一些难以重现的bug。

负荷计量，确定游戏更新所需的带宽的过程，在完成计算机AI之前就已经做好了，该计量是基于人类玩家的数据流模型得出的。结果，我们一开始就忽略了电脑玩家有时会在短时间内发出大量指令的这个事实。

然而，我们用第一个补丁解决了这个疏忽。不过有一点——《帝国时代》通信能力在动态适应延迟的方面比预期的要好。当一个命令生效时，一个滑动窗口会延迟实际的游戏时间，这样所有的玩家都可以收到指令，并且在执行这个指令之前不必暂停游戏。

解决玩家游戏掉线的问题给Mark Terrano带来了挑战。因为掉线是不可预判的，通常都没法知道到底发生了什么——可能是游戏的逻辑出了问题，也可能是winsock、物理连接或者是ISP这些方面的问题，而且这个问题可能是发送者这边的也有可能是接收方那边的问题。因此无论什么时候、什么人，要想解决游戏的掉线问题都是一个大工程。

我们从多人游戏中学到的经验就是要充分利用通信测试工具（例如自动日志和校验码）。此外，我们发现了，创建一个简单的通信数据流模拟器程序可以有很多的好处，还能将通信代码与游戏的其他部分分隔开来。

我们还发现DirectPlay也是存在问题的。难以重现的bug、古怪的行为以及糟糕的文档使这个过程变得更加困难。IPX（一种互联网协议）的保证数据包交付是一个更值得注意的例子。在中国游戏开发者大会(CGDC)上，微软承诺将提供DirectX 5的功能，甚至这个功能可能会包括在测试版中。

游戏画面的制作

在《帝国时代》中所有的2D sprite都以3D模型的形式开始了生命。《帝国时代》包含了20兆的游戏内置sprite图片内容。即使所有的显示都是2D形式的，我们还是早早地就决定了以3D模型来制作游戏中所有的图。我们使用的是3D Studio和3D Studio Max来进行美术制作。

由于3D渲染是非常耗时的，每个美工都要有两台机器，两台机器通常都是200MHz、128M内存的奔腾处理器，这在当时比程序员用的设备还要好。游戏中的所有对象都使用的是3D模型，他们所包含的各种多变性数量从几千到10万不等。这然后这些模型会被添加纹理、被做成动态化并加之以渲染，最后输出为一个有着固定的256色调色板的.FLC(Autodesk Animator)动画文件。

到目前为止，我所描述的游戏制作程序和许多其他游戏是相同的。然而，在这一点上，美工们有多了一个耗时的步骤——这个.FLC动画文件被交给了一个2D动画专家，它把这个动画用帧进行了分解，用photoshop“清理”了每一个图片。

这个“清理”过程包括打磨细节并平滑不规则多边形的边缘。因为《帝国时代》大部分的sprite的屏幕分辨率在每个方向上只有20到100个像素，所以我们有意识到提高画质质量是相当重要的。于是当《帝国时代》在1997年的E3大展上展示的时候，我们的美工受到了许多其他公司同行的赞赏。

我们决定为游戏中所有对象使用3D模型的决定为美术的其他方面提供了便利，因为这些3D模型成为了随时可供使用的静态背景图像（出现在菜单、状态画面和各种动画场景中）。其中包括了3分钟的开场的动画场景本身就是一个专项。

在《帝国时代》使用的256色调色板（实际上只有236色）是有些问题的。该调色板的选择和设定是在项目一开始（大部分模型和纹理都还没添加之前）就板上钉钉了。结果我们发现色彩频谱中的一些某些部分——比如木纹理的褐色——几乎没有可用的颜色来呈现最佳的视觉效果。

在游戏的开发过程中，调色板没有被修改，因为这会设计到重新划分和修改游戏中的每一个图像——这里的时间代价太大了。另一方面，由于调色板的颜色范围比较宽、颜色也很均匀，这使得游戏图形看起来更明亮更令人愉悦。如果我们在做一个8位颜色的游戏，我们会在开发过程进一步的时候再生成调色板。

运行速度的追求

性能是除了极其简单游戏外几乎所有游戏的一个问题，尤其是对《帝国时代》来说。当我加入Ensemble工作室，这款游戏还在处在早期阶段，进行得还很缓慢。这时候有两个最大的问题就是图形引擎（速度非常慢）和各种更新程序，这让游戏过程中偶尔会有一秒的停顿。

如果我们想要有一个最先进的系统，那么一些优化就必不可少了。从这里开始，故事的个人色彩会变重，因为我在《帝国时代》该方面做了大量的工作。

我开始尝试处理超过10W行C++代码所做的事情(源代码在完成之前会上升到超过22万行)。在花了几个星期的时间研究了我们手头上所有的游戏内容后，我提议对推行引擎解构进行一次重大的修改，包括在汇编中编写一个主要部分。

当《帝国时代》的原设计组问我基准测试场景的帧率是否可以从当前的7-12帧/秒提高到20帧/秒的时候，我内心是汗颜不已的，不过终究还是希望能有更多的进步，于是我接下了这个要求。

我不能直接把就得图像引擎撤掉，因为这样会牵扯到其他的所有人，于是我在接下来的五个月时间里大多都在为新引擎干活。在这个过程里，我取得了一些些进展，我将帧率提升到了10-14帧/秒，然而是在最后一个新设计被投入使用的时候，经过一个通宵达旦，这个巨大的突破得以实现。

令我吃惊的是，基准测试运行的速度现在达到了55帧/秒。所以在第二天能回到办公室的时候，看到原来龟速的动画流畅地运行时，我的内心是激动无比的。然而我的工作并不全部都在图形引擎的改进上。

我还花了大量的时间来识别和优化游戏中数不清的进程。由于这款游戏是实时类型的，所以有很多要涉及到的改进来让一个进程来在多个回合中展开，这样就不用暂停游戏到进程结束为止了。最后，所做的优化得到了丰厚的汇报——我们得以将默认的分辨率从640×480提高到了800×600。

我从这次经历中学习到了一个实践经验，那就是了解到——一款游戏在接近完成时究竟还能有多烧钱多耗时。通常在一个游戏项目的早期，引擎会显示出很好地性能，但这样的游戏并不是最终版——当你将简单的测试版本换成复杂的最终版本（添加了AI、UI等等各种各样的内容）之后，你会在实际性能表现上看到一个完全不同的世界。这也确实是《帝国时代》身上发生的事。当我们接近完成时，所有的松散端都被绑紧了，许多性能上的提升都被换成了新特性。

我们在开发过程中做得好的方面

游戏被分为各个独立的引擎和游戏组件。有大概途中，有人担心代码库的扩展在某些领域已经远远超出了最初设计预期，这样会让每个新的变更和添加内容看起来会变得像很丑的黑客。于是我们的首席程序员Angelo Laudon和Tim Deen用了两个礼拜来把代码库分成两个部分，一个是总引擎（Genie）,以及游戏本身（Tribe）。

这种转换非常成功，并且让《帝国时代》的程序员能够保持良好的面向目标的设计。这样做的好处是让代码更好修改和扩展，从而节省了程序员内大量的开发时间。

我们让游戏的数据库有了驱动力。多亏了面向目标化的设计，《帝国时代》几乎没什么对象的代码是需要被硬编码到程序中的。相反，巨大的信息表描述了游戏中出现的每个对象的每个特征；社记者们使用了一个超过40个悖论的表格来控制和塑造游戏。因此，他们能够不断地更新和调整游戏，然后在不需要程序员的情况下依旧能测试他们的改变。

我们保持和发行商的密切联系与协作。关于我们如何同我们的发行商微软保持密切的联系我还没法说出什么是够好的，不过我们的合作确实帮助了《帝国时代》的发展。通过让他们保持对我们“开发内部消息”的悉知，当发生什么事情的时候，微软会协助我们而不是跟我们对着干。

这种关系如何帮助我们开发进展的最好例子就是——我们处理日程推迟安排的方式。每次发生一些事情让开发进程需要比预期更多的时间时；或者新的问题出现时，我们都会和微软进行有效的沟通来延缓日程。

他们清楚地知道发生了什么以及发生的原因，他们重申了他们无论花多少时间都要帮助我们开发一款高质量游戏的承诺。因此，我们不感到惊慌失措和精疲力竭，而是保持专业的态度专注于我们自己的目标。

我们玩自己的游戏

尽管这件事听起来挺简单，但它的重要性是非比寻常的。在整个开发的过程当中，每个公司的员工不仅仅玩游戏来进行测试，而且会带着享乐的目的去玩《帝国时代》。

于是，我们就非常了解游戏的有趣之处以及人们可能从游戏中得到些什么。我们20个成员决定齐心协力让游戏玩法的乐趣不会被妥协或者被冲淡。

性能良好

如果你想让你的游戏具备广泛的吸引力，那么游戏的性能表现就很重要了。 《帝国时代》能够让8个玩家在一个P120系统上以16兆的内存顺溜地运行。而和《横扫千军》相比，32兆的内存、至少要200MHz的CPU来跑8个玩家的游戏。《帝国时代》之所以能达到这种级别的性能是付出了大家辛勤的努力的。程序员把额外的精力用来控制内存消耗并识别程序瓶颈所在，而美工们则剔除了额外的动画帧来重组图形以使空闲内存最大化。

公司尊重自己的员工。关于Ensemble工作室对员工和他们的家庭的待遇，我确实得说点什么。众所周知，软件开发，尤其是游戏开发，都需要牺牲大量的时间，这让他们在个人关系上犹如炼狱一般。

Ensemble公司贴心周到的管理让员工的家庭成员可以加入公司举办的众多晚宴和其他活动之中，这让家庭成员们感到他们是随时受到办公室欢迎的。除此之外，在工作室达到一个里程碑之后，一定会让员工休息几天去和他们的家人联络感情。如果需要的话，他们可以有弹性地安排时间，另外还有鲜花或者其他表示感谢的礼物会定期送到家人家里。

公司管理层的这种细致做法的成果是显而易见的；公司的士气和忠诚度高出了我14年以来所见到所有软件开发公司。这让我的妻子热爱我工作的程度都跟我一样了。

本地化真的有效。从刚开始，我们知道微软想要发行包括日语在内6个语言版本的《帝国时代》。在大概我们开发到一半的时候，我们更新了我们的代码库已提供全面的本地化支持。这就要求删除和替换源代码中的所有文本引用，并且只能从一个外部资源文件中来维护所欲的游戏文本。

这还让我们在文本的起草和表现上有了严格的限制。我们只能用Windows GDI——这是大多数游戏都不乐意做的。这还意味着有一些比如按钮之类的界面项目需要尽可能地扩大化好放下可能增长的译后标题文本，这会限制了设计者在用户界面上的创作。

但是我们还是屈服了，确切地按照指导方针去做了。而让我们感到惊喜的是，这个转换渡过得很迅速而且没有什么痛苦。并且当微软的翻译人员告诉我们本地化《帝国时代》是他们做过最流畅最不头痛的项目之后，我们感觉就更好了。

本地化给了我们非常大的助益，因为我们为此有了一个可以用于所有游戏译后文本的单一可执行文件，这样就可以避免避免在跟踪BUG和发行多个版本的游戏更新所带来的巨大麻烦。

我们是一个尊重所有成员的团队。《帝国时代》这个项目规模让我们整个团队需要在一起工作很长一段时间。我们会说我们雇佣新成员的一个标准是必须能够互相尊重每一位团队的成员。

有了这样的互相尊重之后，加上公司对于员工的宽厚待遇，这让每个成员在团队里有一种大家庭之感和团队精神。我们避免了分成不同的群组而让大家对项目产生隔阂感，因此即使在严重的危机时刻，成员的态度和情绪依然高昂不气馁。

如果我们的团队脾气暴躁，还充满派系斗争，我真的不认为《帝国时代》能在1997年取得那样的成功。

那些出错的或者本可以做的更好的方面

我们开发周期里的beta测试进行的太晚了。在1997年8月份，我们对《帝国时代》进行了公开beta测试，但是我们却没能发挥出这次的测试的潜力。我们已经非常接近项目的尾声了，以至于若非收到什么非常有使用价值的反馈，我们并不想做出什么游戏上的变动。宣传手册已经做好印刷准备了，大部分的设计都已经板上钉钉了。我们当时所能做的就是修复所有被发现的bugs。而对于将来的任何项目，我们发誓，一定要在更早的时候的进行beta测试。

我们和微软的QA人员（质检人员）沟通不足。项目大部分的错误报告都是通过我们的数据库来处理的，而我们的开发者并没有直接和测试人员进行交流。结果很多错误解决的时间变得很长，新的特性也尚未经过测试。

单单靠中间数据是不足以让测试人员和开发者知道别人在想什么的。在未来的项目里，我们想为每个程序员指派一个测试人员，让他们每隔几天进行一次电话交流。

在接近开发尾声的时候，我们还真的在一些成员身上施行了一下这样的方法，他们在测试和bug解决方面的效率得到了巨大的提升。

我们有时不听从指挥而没能做好协作开发。另一个可以促进开发的人员交流方面是我们的团队内交流。每个小组——编程组、美工组、游戏设计组和音效组都有一个领头人负责跟进自己小组每个成员的进度。当外部人员对开发内部人员提出新的要求时，这个领头人就会成为两方的沟通的桥梁。

随着《帝国时代》开发的日益发展以及压力增大，当成员直接去满足自己项目需求的时候，就破坏了这个系统的规则。我们就为此付出了代价——成员们不知道变成上的变动或者美工给游戏添加的新内容，于是混乱的程度日益增加，这导致了时间的消耗和分散。于是我们所有的人不得不停下来搞清楚到底发生了什么事。

我们未能充分地测试多玩家游戏和MODEM（调制解调器）之间的连接。我们开发环境上的一个问题就是它无法配上典型的用户终端系统。在开发的过程中，《帝国时代》的多人游戏部分有进行过广泛的测试。

当我们在办公室玩游戏的时候，我们运行比较快的机器，在满内存的情况下能在高速局域网中相互通信。当我们测试联网游戏玩法的时候，我们的通信是通过公司的T1线路进行的。在测试中我们没有意识到的是——大多数玩家使用的会是MODEM（调制解调器）和商业互联网服务供应商之间的网路。

出现这个错误的不只是我们，微软的测试实验室也出现了同样的情况。结果，Modem连接的游戏都没能得到充分的测试。于是游戏bug只有在网络延迟时间较低时才比较少，这驱使网速慢的玩家都弃游了。而我们的高速网络掩盖了这样一个事实——在某些不寻常的情况下，《帝国时代》会要求达15K美秒的网络宽带——这甚至是56k的MODEM所能提供上传速度的6倍速。

结果，当多人游戏出现问题时，我们有点吃惊。尽管我们用第一个补丁包解决了这个问题，不过这样的情况的出现是我们无法接受的。现在，我们每个开发者都有一个MODEM以及不同的ISP可以用，因为Modem测试是我们测试流程的一个大项目。

开发部分内容依赖于没有按时交付的产品（微软的DirectX 5a）。这也是游戏的MODEM没能得到测试的第二个原因：微软DirectPlay的交付与质量问题。之前承诺过的特性，甚至布包括beta版本的发行都没能在游戏的最终版本延迟发行时出现。

Direct X 5a直到游戏发行前1个月才能够使用。在此期间，我们的通信程序员通宵达旦写的功能受到了期待却没能交付。等待被许诺的的驱动程序和SDK是开发人员必须面对的难题之一——即使作为发行商的微软也无法控制这样的情况。

我们没有制定做补丁的计划。尽管版本1.0a的补丁包取得了成功，但对于我们没有制定做这个补丁包的计划这件事来说，还是有问题的。一般的关电视，如果你知道你需要发布补丁，那么你一开始就不应该把游戏运转起来。

尽管这个观点有所道理，但是事实是这样的——没有游戏开发者能测试出一款匹配上首批5万的游戏购买玩家电脑配置的游戏；你的顾客会用各种你做梦都想不到的方式来尝试各种玩法，以及在你从未听说过的硬件和驱动程序上运行游戏。环顾一下，今年几乎每一款重大游戏的发行都有补丁或者更新。

与其否认这一事实，我们更愿意在未来调配资源与期望，这样我们就可以在游戏运行的几天或者几周后发布一切必要的更新，而不是几个月。

我们未能如常地处理好“意外”时间。在开发期间，我们经历了几起突发事件，这让我们，作为一家公司，竟然停止了我们手头上正在做的事情。这些事件包括了游戏的demo版本的制作以《帝国时代》素材的新闻报道。

虽然大部分的事件是有益于公司的，但我们并不是很擅长应对这些事件，而且这些事件也让我们抛下了我们的日程安排。这些突发事件大多是在开发后期出现的，也是它们影响最大的时候。所以我们未来游戏的目标之一就是尽可能地减少意外事件的影响，做到尽可能地提前告知，并且让尽可能精简的人员去应对这些事件以限制影响的范围。

我们没有充分利用自动化测试的优势。在开发的最后几个星期里，我们开设了一款可以再9台电脑上自动相互对抗的游戏。除此之外，包含开发平台和调试器的第二台电脑可以监控每一台参与游戏的电脑。这些游戏尽管是随机生成的，还是会被记录下来，这样如果发生了什么事，我们就可以不断地重复这个游戏直到我们找到问题所在为止。

本身允许在加速条件下运行的游戏会被留下彻夜运转。这是个巨大的成功，让我们得以在很大程度上把问题隔离出来。我们主要就失败在没能在早期开发中做到这点——这能节省我们大量的时间和精力。现今，我们未来所有产品计划中都把从第一天开始的自动化测试列入到其中。

《帝国时代》的开发团队，Matt Pritchard是在前排右数第二个

吸取所有的教训

当《帝国时代》投入市场进行生产时，我们给自己开了一个大派对来发泄压力。事实证明，我们狂欢得过早了。在《帝国时代》上架后，我们开始收到关于找不到路、单位AI行为问题、人口限制问题以及多人游戏问题的反馈。

除此之外还发现了一些漏洞，玩家可以利用这些漏洞在游戏中得到不公平的优势。Ensemble和微软的管理层都采取了行动，决定为《帝国时代》做一个补丁。

尽管时间是从别的项目中挤出来的，并且花了比预计还要长的时间，但最后的补丁还是相对成功的——它极大地提高了多人游戏的游戏质量，修正了漏洞，并且解决了所有之前提到的游戏问题。这让《帝国时代》得以发展到今日之势——当然了我希望你们的硬盘上有装这款游戏。
【Matt Pritchard设计了《帝国时代》的图形引擎，他还参与了《帝国时代2》、《神话时代》以及《黑暗地带：51区》的制作。这篇文章最初发表于1998年三月的《游戏开发者杂志》上】

本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao

I had an experience in a local computer store recently that caused me to burst out laughing. I had stopped to self-indulgently admire the top-ten PC games display when I overheard the following exchange between two young men:

“What do you think about this one, Age of Empires?” wondered the first.

His companion shot back, “Aww, the Borg at Microsoft just combined Warcraft and Civilization to cash in on these kind of games.”

Always eager to boost our sales, I took this opportunity to tell the young men how AoE wasn’t the creative product of a giant corporation, but of a small group of talented people living right in their own backyard.

For us, Age of Empires was not only a game of epic proportions, it was an epic journey for a small band of people determined to turn an idea into a real game company. Along the way, we laughed, we cried, we consumed pizza and caffeine, and we learned a great deal about making games.

age_of_empires_screen_1.jpg

Designing the Past Perfect

Obviously, Age of Empires didn’t start out looking like the final product. Despite some accusations, Dawn of Man (AoE’s original title) wasn’t created to be a Warcraft II clone. (In fact, Warcraft II wasn’t released until after AoE’s development was well underway).

Instead, the final design was evolved and refined over time, with a few significant design events along the way. One of the best things I think you can have in a game company is a staff that plays a lot of different games.

This was true of our staff at Ensemble, and was helped in no small part by programmer Tim Deen’s habit of buying and actually playing almost every new PC game as it came out. It was Tim who brought Warcraft II to the attention of the rest of the Ensemble staff. At that time, many of AoE’s game elements, such as resource management, empire building, and technology research, were taking clear shape.

However, we didn’t really know what to do about combat. Warcraft II was a splash of cold water in the face, waking us up to how much fun real-time combat could be. Several times a week, the staff would stay late to play multiplayer Warcraft. These impromptu events continued until AoE reached the point in development when it became more fun to play than Warcraft.

Another major shift occurred a little over halfway through development, when the designers were looking at AoE’s localization plans. They realized that AoE would be sold in Asia, but didn’t include a single culture from that region.

We held a company-wide meeting and decided to add early Asian civilizations to the early European, African, and Middle-Eastern tribes that we’d already developed. Though the addition would create more work for the artists and designers, the enhanced appeal that the game would have in Asia would make this a profitable decision.

All of these changes occurred because the game’s designers weren’t afraid of taking design input from the rest of the staff. Making a game that everyone would be proud of and would want to play was something that got more than just lip service at Ensemble. Perhaps the best example of this core value is the Wonder, the penultimate building that a player can build and use to win the game.

In early 1997, AoE was great for slugfests, but everyone felt that the game play needed to offer something more. Numerous ideas were tried and rejected. Then Mark Terrano, our communications programmer, hit upon the idea of building an “Armageddon Clock” that would force players to drop what they’re doing and respond to the new challenge. AoE is chock full of little ideas and touches that were thought up by the artists and programmers. This participation tangibly increased the sense of ownership and pride that we all took in the game.

One of things that is truly underappreciated about the designer’s job is play balancing. The designers spent months and months adjusting costs, strength, speed, and many other statistics in an effort to create a game that was fun to play and yet didn’t offer any loopholes or cheats.

At this point, I realized that Tim Deen was truly a gamer’s gamer. During development, if any of the various iterations of AoE’s design opened up a way for one player to take advantage of another player and thus make the game one-dimensional, Tim would find it.

And when we didn’t believe his assessments, he would promptly show us by using the loophole to kick our butts at the game. For the better part of a year, play balancing was a prominent task, and it paid off in giving AoE more staying power and better game play than many others in the recent crop of real-time strategy games.

Blazing the Multiplayer Path

Multiplayer support was an integral part of the early design, and AoE was structured in such a way that most of the game could not differentiate between human and computer players. When DirectX first came out, it appeared that DirectPlay would be the best choice for providing communications over the widest variety of connection types.

To support a high number of moving units, we went with a modified game synchronous model, where the entire game is simultaneously run on all machines. Only moves, changes, and commands are communicated to other machines. This approach has the advantage of minimizing the amount of data that has to be sent.

The unanticipated danger of using this model is that it can generate a condition where the game on one machine becomes out of sync with the game on other machines. This caused some very hard-to-reproduce bugs with AoE.

Load metering, the process of determining how much bandwidth the game updates required, was done before the computer AI was completed, and was based on the data flow model taken from human players. As a result, we initially missed the fact that computer players would sometimes issue large numbers of commands in quick bursts.

We did, however, address this oversight with the first patch. An area where AoE’s communications worked out better than expected was the game’s ability to dynamically adapt to latency. A sliding window delays the actual game time when a command takes effect, so that all players receive the command and do not have to pause before executing it.

The problem of handling players who have dropped from a game presented Mark Terrano with difficult challenges. Since drops are unpredictable, usually there is no way to know what happened. The problem could be the game logic, Winsock, the physical connection, or the ISP, and could exist on either the sender’s or receiver’s side. Getting the game to handle drops by anyone at anytime required a great deal of work.

One of the lessons learned from the multiplayer experience was to make full use of communications testing tools, such as automated logs and checksums. Also, we discovered that creating a simple communications data flow simulator program could provide great benefits and isolate the communications code from the rest of the game.

DirectPlay also turned out to be problematical. Difficult-to-reproduce bugs, quirky behavior, and poor documentation made the going more difficult. Guaranteed packet delivery for IPX was one of the more notable examples. At the CGDC, Microsoft promised to deliver this feature with DirectX 5 and even included in the beta.

However, when DirectX was actually released, this feature was nowhere to be found. The cost of that one missing item was the extra time we had to spend writing our own guaranteed delivery system and a bad packet generator program with which to test it.

Painting the Scene

All of the 2D sprites in AoE began life as 3D models. Age of Empires contains 20MB of in-game sprite graphics. Even though all of the displays are 2D, we decided early on that all of the graphics in the game would be taken from 3D models. We used 3D Studio and 3D Studio MAX for art production.

Because 3D rendering is so time-consuming, each artist was issued two machines each, both usually 200MHz Pentium Pros with 128MB of RAM, which at the time was better equipment than the programmers were using. The objects in the game were created as 3D models that had anywhere from a couple thousand to 100,000 polygons. The models were then textured, animated, and rendered out to a .FLC (Autodesk Animator) file with a fixed 256-color palette.

So far, the process I’ve described is identical to that of many other games. At this point, however, the artists added another time-consuming step. The .FLC files were handed off to a 2D specialist, who took the animation apart frame by frame and “cleaned up” each image with Photoshop.

The clean-up process involved sharpening detail and smoothing the edges of the irregular shapes. Since most of the sprites in AoE had screen dimensions of only 20 to 100 pixels in each direction, the visual quality improvement that we realized was significant. When AoE was shown at the 1997 E3, the artists received numerous compliments on their work from their peers at other companies.

The choice to go with 3D models for the in-game objects provided benefits for other art needs, as they were readily available for use in the static background scenes that appear on the menu, status screens, and the various cinematics. The cinematics, including the three-minute opener, were a fulltime project unto themselves.

The 256-color palette (actually 236) used in AoE was something of a problem. The palette was chosen and set in stone at the very beginning of the project, before most of the models and textures had been created. As a result, it turned out that some portions of the color spectrum, such as browns for wood textures, had too few available colors to get the best visual quality.

The palette wasn’t revised during the development process because that would have required rerendering and touching up every image in the game ‘ far too expensive time-wise. On the other hand, the palette did have a wide and balanced range of colors, which contributed to the overall bright and cheerful look of the game’s graphics. If we do another 8-bit color game, we’ll generate the palette at a point further along in the development process.

Going for Speed

Performance is an issue for all but the simplest of games, and it certainly was for AoE. When I joined Ensemble, the game was still in an early form and slow. The two biggest problems were the graphics engine (which was just plain slow) and various update procedures, which produced occasional pauses of up to a second in game play.

If we were going to sell to anything but the most cutting-edge systems, some serious optimization was in order. The story gets personal here, as I did a great deal of the work on this part of AoE.

I started by trying to get a handle on what the over 100,000 lines of C++ code did (the source would rise to over 220,000 lines before it was finished). After spending a few weeks studying what we had, I proposed a major overhaul of the graphics engine structure, including writing a major portion in assembly.

AoE’s original design team asked if the frame rate of a benchmark scenario could be raised from its current 7 – 12 fps to 20 fps. I told them yes. Inside I was sweating bullets, hoping that I could deliver that much improvement.

I couldn’t just go ahead and rip out the old graphics engine, as it would hold up everyone else, so I spent the next five months working mostly on the new engine. Along the way, I managed some incremental improvements that upped the frame rate to 10 – 14 fps, but the big breakthrough came during an all-nighter, when the last piece of the new design was put into place.

Much to my surprise, the benchmark scenario was now running at 55 fps. It was exciting to come back into the offices the next day and see the formerly sluggish animation running silky smooth. But my work was not all on the graphics engine.

I also spent a great deal of time identifying and optimizing myriad processes in the game. Since the game was real-time, many improvements involved spreading out a process over several turns rather than of stopping the game until it completed. In the end, the optimizations paid off handsomely and allowed us to raise the default resolution from 640×480 to 800×600.

A practical lesson that I learned from this experience was how much additional overhead and slowdown a game can acquire as it approaches completion. Often, early in a game project the engine will show great performance but the game’s not finished. When you replace the simple test levels with the complex final levels, add all the AI, UI, and bells and whistles, you can find a world of difference in actual performance. This was true for AoE as well. As we approached completion and all of the loose ends were tied off, many of the performance gains were traded in for new features.

Things That Worked Out (S)well

1. The Game was broken into separate engine and game components. About halfway through development, there was concern that the code base had expanded far enough beyond the initial design in some areas that every new change and addition would look like an ugly hack. Lead programmer Angelo Laudon and Tim Deen took two weeks and separated the code base into two separate sections, the general engine (Genie), and the game itself (Tribe).

The conversion was very successful and allowed the AoE programmers to retain a nicely object-oriented design. The benefit here was that it made the code much easier to modify and extend, saving the programmers a great amount of development time.

2. We made the game database driven. Thanks to the object-oriented design, almost nothing about any object in AoE is hard-coded into the program. Instead, huge tables of information describe every characteristic of every object that appears in the game. The designers used a system of over forty Paradox tables to control and shape the game. As a result, they were able to constantly update and tweak the game, and then test their changes without having to involve a programmer.

3. We stayed in close contact and working together with the publisher. I can’t say enough good things about how the close contact with our publisher, Microsoft, helped the development of AoE. By keeping them “in the loop” on our progress, they worked with us instead of against us as things happened.

The best example of how this relationship aided development is the way we handled schedule slippage. Each time something took longer than expected or new problems cropped up, we effectively communicated the delay to Microsoft.

With a clear understanding of what was happening and why, they reaffirmed their commitment to assist us in producing a quality game, whatever amount of time that would take. So instead of being panic-stricken and whacked out, we remained professional and focused on our goals.

4. We played our own game. While this may sound simple, it’s very important. Throughout the development process, every person in the company not only play tested, but played AoE with the purpose of having fun.

As a result, we were very in tune with why the game was fun, and what people were likely to get out of it. We had 20 guys who were determined not to let the game play be compromised or watered down.

5. Performance was good. Performance truly means a lot if you want your game to have broad appeal. Age of Empires can adequately run an eight-player game in 16MB of RAM on a P120 system. Contrast that with Total Annihilation, which requires 32MB and at least a 200MHz CPU for an eight-player game. Achieving this level of performance required a group effort. The programmers expended extra energy on keeping memory consumption in check and identifying bottlenecks, while the artists culled extra animation frames and reorganized the graphics to maximize free memory.

6.The company respected its employees. I have to say something about the way Ensemble Studios treated its employees and their families. It is well known that software development, especially game development, involves great sacrifices of time and can be hell on personal relationships.

Ensemble’s thoughtful management respected that by going out of their way to include families at numerous company dinners and other events, and to make them feel welcome to come by the offices at any time. Additionally, after crunching hard to meet a milestone, they would insist that employees take a couple of days off to catch up with their families. People were allowed flexible schedules if they needed them, and flowers or other tokens of appreciation were sent to the families periodically.

The result of this deliberate action by company management should be obvious; company morale and loyalty was higher than I have ever seen in fourteen years of software development. My wife loves my job as much as I do.

7. Localization really worked. From the beginning, we knew that Microsoft wanted to release AoE in six different languages, including Japanese. About halfway through development, we updated our code base to provide full localization support. This required stripping out and replacing all text references in the source code and maintaining all game text in an external resource file.

It also placed severe restrictions on how we could draw and display the text. We had to use the Windows GDI exclusively, something most games shun like the plague. It also meant that interface items such as buttons had to be sized to hold the largest possible translated form of their captions, limiting the clever things one could do with the design of the user interface.

But we buckled down and did it, following the guidelines exactly. And to our pleasant surprise, the conversion was swift and painless. We felt even better when the translators at Microsoft told us that localizing AoE was the smoothest and most pain-free project they had ever done.

The benefit to us was enormous in that we had a single executable program file that was the same for all translated versions of the game, thus avoiding the huge headache that comes with tracking bugs and releasing updates for multiple versions.

8. We worked as a team that respected all its members. A project of AoE’s size required that we all work together in close quarters for extended periods of time. One of our expressed criteria in hiring new people is that we must be able to respect each other.

This respect, complemented by the company’s actions towards its employees, fostered an excellent sense of family and team spirit among everyone. We avoided having different groups develop a sense of isolation from the project, and as a result, attitudes and spirits remained high even during the worst crunch time.

Had tempers flared and cliques developed, I honestly don’t believe that AoE could have made it out the door in 1997.

Things That Went Wrong Or We Could Have Done Better

1. We held the beta test too late in the development cycle. A public beta test of AoE was held in August 1997, but we didn’t come near to exploiting the full potential of it. We were too close to the end of the project to make any game play changes, despite the wealth of useful feedback we received. Manuals were already set to be printed, and most of the design had been set in stone. All we could really do was fix any bugs that were found. For any future projects, we vowed to hold the beta testing earlier.

2. There was inadequate communication with the QA people at Microsoft. For most of the project, bug reporting was handled through a database and developers didn’t directly communicate with the testers. As a result many bugs wound up taking much longer to resolve, and new features went untested.

An intermediate database was simply not enough to let testers and developers know what the other was really thinking. In future projects, we would like to assign a specific tester to each programmer and have them communicate by phone every couple of days.

Near the end of development, this did happen for a couple people, and for them productivity with testing and bug resolution was drastically improved.

3. We sometimes failed to coordinate development through the leads. Yet another area where personnel communication could have improved the development was among our own teams. Each team Programming, Art, Game Design, and Sound has a lead person who is responsible for keeping track of what each member of his or her team is doing. The lead is the go-to person when someone outside has new requests for the team.

As the development of AoE progressed and the pressures rose, adherence to this system broke down as people went direct to get their needs filled quickly. We paid a price for it. People didn’t know about programming changes or new art that was added to the game, and the level of confusion rose, creating a time drain and distraction. We all had to stop at times just to figure out what was going on.

4. We failed to adequately test multi-player games with modem connections. One problem with our development environment is that it isn’t comparable to the typical end user system. During the course of development, the multiplayer portions of AoE were tested extensively.

When we played a game in the office, our fast machines, stuffed full of RAM, communicated with each other on our high-speed LAN. When we tested Internet play, our communications were handled through the company’s T1 line. One thing that we failed to realize in our testing was the fact that most players would be using dial-up modem connections to commercial Internet service providers.

And it wasn’t just us; the same situation applied to the testing labs at Microsoft. As a result, modem connection games were under-tested. Bugs that were harmless when ping times were low resulted in dropped games for users on slower Internet connections. And our high-speed network masked the fact that under certain not-so-uncommon circumstances, AoE could require 15K of network bandwidth per second — six times what even a 56K modem can provide on the uplink side.

As a result, we were taken a bit by surprise when reports of multiplayer game problems rolled in. Though our first patch fixed this problem, the situation was unacceptable. Now, each developer has a modem and several different ISPs are used, as modem testing is a big part of our testing process.

5. Portions of development relied on products that were not delivered on time. There was a second reason that modem games were under-tested; problems with the delivery and quality of DirectPlay from Microsoft. Features that were promised, and even included in beta releases, weren’t present when the delayed final release was delivered.

Direct X 5a wasn’t available to us until a month before the game shipped. In the meantime, our communications programmer was burning the midnight oil writing the functionality that was expected but not delivered. Waiting on promised drivers and SDKs is one of the harder things that developers have to deal with; even those with Microsoft as a publisher have no control over them.

6. We did not plan for a patch. The version 1.0a patch, even though it was a success, was problematic in that as a company we had not planned for it. The general argument is that if you know you are going to need to release a patch, then you shouldn’t be shipping the game in the first place.

While one can take that stand, it’s also a fact that no game developer’s testing can match that of the first 50,000 people who buy and play the game. Your customers will do and try things that you never dreamed of, while running on hardware and drivers that you never heard of. Looking around, nearly every significant game released this year has had a patch or update released for it.

Rather than deny this reality, we would like to allocate resources and expectations in the future so that we can release any necessary updates days or weeks after our games ship, rather than months.

7. We didn’t manage “surprise” events as well as we could have. During the development period, we experienced several sudden events that caused us, as a company, to stop what we were doing. These events included the creation of a demo version of the game and materials for press coverage of AoE.

While most of the events were beneficial to the company, we weren’t very good at handling them, and they threw off our schedules. These disruptions mostly came late in development, when their impact was felt the most. One of our goals for future games is to minimize the impact of unplanned events by giving advance notice when possible and restricting them by minimizing the number of people that have to respond to them.

8. We didn’t take enough advantage of automated testing. In the final weeks of development, we set up the game to automatically play up to eight computers against each other. Additionally, a second computer containing the development platform and debugger could monitor each computer that took part. These games, while randomly generated, were logged so that if anything happened, we could reproduce the exact game over and over until we isolated the problem.

The games themselves were allowed to run at an accelerated speed and were left running overnight. This was a great success and helped us in isolating very hard to reproduce problems. Our failure was in not doing this earlier in development; it could have saved us a great deal of time and effort. All of our future production plans now include automated testing from Day One.

The Age of Empires development team. Matt Pritchard is front row, second from right.

Patching It All Up

Once AoE was shipped off to production, we threw ourselves a big party to let off some stress. It turns out we were a bit premature in our revelry. Shortly after AoE arrived on store shelves we began receiving feedback on problems with the path finding, unit AI behaviors, population limits, and multiplayer play.

Additionally, some bugs were found that a player could exploit to gain an unfair advantage in the game. Management was stirred to action at both Ensemble and Microsoft, and the decision to do a patch for AoE was made.

Although time was taken away from other projects, and it took longer than desired, the patch was a success; it vastly improved the quality of multiplayer games, fixed the bugs, and addressed the game play concerns that had been raised. And that brings the development of AoE to where it is today, which I hope is somewhere on your hard drive…（source：gamasutra.com  ）