《神話時代》制作大揭密

簡體傳統

制作第一代的Age of Empires游戏非常难。由于没有经验，很多不熟悉的东西都要去尝试一下才知道行不行。要经历很多挫折，甚至放弃最初美好的设想。会犯不少错误，也会有很多经验教训。由于没有过去的成功（或者哪怕是失败）做参照物，你的游戏设计只能跟着感觉走。开发团队没有经验，则计划和实际相差甚远，进度亦无法掌控。各项任务之间协调不周，有时候一个重大的任务没有完成，妨碍其他相关任务，只能见机行事、见缝插针。这些因素交织在一起，形成一个游戏公司在草创阶段的常见的混沌状态。对第一次开发游戏的人们来说，他们所需要克服的问题，仅仅用“挑战”这个词来形容也许是太轻描淡写了。

      到了第二代（Age of Empires II : The Age of Kings），就容易多了，虽然你当时也许并没有意识到。当你的第一个游戏发售后，你可以得到宝贵的反馈信息，籍此了解自己在什么地方做对了，什么地方做错了。你对自己的团队更加熟悉和了解。你也有了一个成熟的引擎，还有一些内部开发的工具，你知道公司的技术实力和局限。特别是从设计师的角度看，你知道在续集里要加上哪些设计要素——那些由于时间和技术原因在第一作中没能体现出来的原始设想。

      游戏的第三代标志着一个时代的终结。经过前面两个游戏（如果它们都是很成功的话），你对玩家的口味一清二楚了。不幸的是，很多玩家已经玩过了这两个游戏，和其增强版或者扩充版，有点腻了，想要一些新鲜口味了。但是如果你胆敢删除或者修改一些固有的游戏设定，你就会收到另一群玩家的铺天盖地的EMAIL抗议，还有在BBS上发动的请愿。所以，到这个时候，原作的任何一个设定，都是抛舍不下的。到了第三作的时候，你的引擎和工具已经渐呈老态，急需开发新的内部引擎或者购买学习新的商用引擎。
这就是我们设计组在《神话时代》项目伊始所面临的状况。最令我们捏着一把汗的问题就是：“我们怎么才能超越《帝国时代》？”

      Ensemble Studios的游戏项目从来都是野心勃勃的，而且我们的雄心壮志随着每个游戏的完成都不断增长。项目的野心不断扩张，团队的规模逐渐壮大。而且我们是在同时多面出击：我们在开发一个全新的引擎，一个全新的多用户网上功能，与此同时，我们要开发一个全新的可以超越《帝国时代》的游戏。在这个游戏中，我们将引入新的设计要素，包括神力（God powers）和神兽部队（myth units），还有更强的单机战役设定。
在这里我不想老生常谈。不断膨胀的项目野心和有限的资源之间必然的矛盾，市场部对游戏内容的干预，还有人力资源等问题，都不在本文讨论范围之内。我要着重介绍的，是《神话时代》的设计。虽然设计师是Ensemble Studios的灵魂，是由他们掌舵来决定一个游戏的方向，但他们不会把自己的意志强加给其他人。设计师们需要把项目组的勃勃野心控制在可控范围内，并协调和编程和美工之间的关系。他们需要保证信息反馈的畅通，同时又要小心不能陷入无休止的争论。

【标题】成功经验

1、采用复进式设计（Iteration）
Ensemble的基本游戏设计流程是这样的：早点把可玩的游戏做出来，然后不断测试调整各项游戏设计要素直到达到最优状态。几乎所有的游戏设计要素都经过这个过程。有的设计要素被修改了无数次。而且我们勇于抛弃那些怎么调整也不合适的要素。

《神话时代》中的神力（God Power）是一个很好的例子。在我们纸上作业做出原始设计时，神力和英雄（Hero）是这么设定的：在用户界面上有一个按钮，只要随时一按，英雄就可以在其当前所在地点使用威力强大的神力。这个设定简单明了！

可是，当我们把这个设计要素在游戏中实现，并开始测试后，我们马上发现：这个设定实在是太差了！由于神力的威力极为强大，而且只能发生在英雄所在的地点，这就迫使对方集中全部兵力，不惜一切代价在最开始的时候先将英雄干掉，否则后果不堪设想。在这种情况下，英雄成了众矢之的，每每最先牺牲，反倒像是最弱的。测试的时候这么玩下来，大家最后都嘟嘟囔囔的：“怎么一点英雄的感觉都找不到？”而且，神力是在英雄所在地点发生的，如果是陨石之类，好像英雄自己被砸，形象实在十分不堪。

我们随即尝试了几种改进办法。一种新的设定是闪电柱（lightning rods），英雄必须使用它来释放神力。这样做可以使得英雄不再是众矢之的，而且神力所作用的地方也不一定是英雄的所在地。但经过测试，人们觉得这个设定没意思。另一种设定是可以用资源来购买神力，就像在游戏中购买其他武器一样。经过测试，这个设定也被否决。我们总共试验了大概10多种不同的设定。

最后，在多次尝试之后，我们才找到最终的解决方案，也就是玩家最后玩到的设计。英雄和神力脱离关系。英雄被用来消灭神兽部队（这才能显示英雄的独特威力），而神力被转移到主游戏界面上，且只能一次性使用。这样神力的重要性和特殊性得到突出。

因为神力是游戏中最重要的游戏要素之一，所以我们在尝试过六七个不成功的设定后，并不气馁，还得继续尝试下去，直到寻找出合适的设定。每一次新的设定，都需要编写新的代码和制作新的美工素材，才能把效果展现出来并测试之。多次抛弃不成功的设定，意味着我们做了很多无用功，很多代码和美工作品都被抛弃了。但不管怎么说最终我们实现了既定目标：找到了令我们比较满意的设定。值得强调的是：我们的游戏设计流程也许并不是效率最高的，但它起码是一种有效的方法。
2、让每个人都参与游戏性测试（play-test，又称测玩）
游戏开发界一个令人惊诧的现象是：有多少游戏开发人员是完全依赖外部的游戏测试人员来告诉他们游戏是否好玩，而他们自己是不玩游戏的！来自玩家和专门测试人员的外部反馈信息是十分重要的——特别是在游戏设计的中后阶段。但如果仅仅依赖各种外部反馈来设计游戏的话，那么这个游戏将没有自己的灵魂和个性，成为一团浆糊。在Ensemble，每个开发团队成员每周至少亲自测玩（play-test）游戏一次。这种策略使得游戏开发者和他们所开发的游戏距离更近——如果这个游戏连他们自己都觉得没有意思，那怎么能够指望它来征服广大的玩家呢？公司特为此作出了强制性的规定：规定每天早上和下午或者晚上的多个时间段被是专门的测玩游戏时间。

我们发现这种大规模的组员内部测玩制度有以下几点好处：测玩使得游戏开发组的每一个成员都对游戏的目前状态心中有数，使他们感到自己是游戏（和游戏设计过程）的真正主人，有利于找到Bug，并可以帮助确认游戏何时才能令人满意可以发售了。像前面所提到的神力的设定问题，就是被我们的组员最先发现的。他们经过测玩发现了这个缺陷，然后成群结伙地跑到设计师的办公室来抗议。如果我们没有让组员们测玩，《神话时代》很有可能就包含着这个有缺陷的设定发售了。

3、使设计研讨会小型化
在开发《帝国时代》和《帝王时代》（The Age of Kings）的时候，我们曾经让开发团队的全体成员都参与游戏设计（起码是在初始设计阶段）。在《帝王时代》的一次漫长的会议中，我们试图为游戏中的兽群作出一个设定。会上一般是让每个与会者都发言。一圈下来后再讨论。可是几个发言之后，讨论已经自发地变得无法控制，连一圈都轮不下来了。在这种情况下，我们不得不放弃让所有组员与会的制度，而是只邀请部门头目（department lead）来开会讨论游戏设计。这些部门头目把各自部门中员工的意见汇总反馈给我们，并代表那些员工在会上讨论，最后他们把会上讨论的内容向各部门的员工传达并获取新的意见和反馈。到了开发《神话时代》时，这种方法也不灵了。因为《神话时代》光部门头目就有12个左右。这么多人来开会，效率也是很低的。

最后我们将部门头目列席会议的重点放在了开发任务管理和进度监控上，而不再讨论游戏设计的问题。针对游戏设计，我们专门组织了一系列的小型会议。这种会议由4-5个核心人员所参与，其中有一半是游戏设计师。会议专门用来对游戏设计进行自由讨论（brainstorming）。游戏中的各种要素，如各文明的特色和优势、神兽部队的能力设定、和神力等，都是在这种会议上讨论出来的。我们总是尽量把这些设计研讨会安排在公司以外的地点，这样就不会被打扰。由于每个人的日程表都是紧紧的，我们必须很早就预先安排好这些研讨会的日期。这样所有与会者才能有准备，并准时到场。为了避免张扬，我们把这种会议叫成“小宠物会议”（small pets）。这个命名的由来是这样的：我们把会议上提出的设计要素称为恩宠[YSHA1]的要素（pet features），使得它们听起来不那么严肃。这样没能参加会议的组员们不会太敏感。

虽然不是所有人都能亲自参与研讨会，但我们力求做到组里每个人都有机会发表自己的看法。为此，我们在会后会将讨论的问题和结论向全公司公布。公司里面的每个人都可以向我们提出意见或者建议，我们评估这些反馈，对设计做出必要的修改。这样，既保证了每个人都有参与权，又能保证我们高效高速地完成游戏设计。
4、利用基于数据的开发工具（Data-driven tools）
我们在《神话时代》设计过程的最初阶段就制作了各种基于数据的工具（data-driven tools）。这是一件事半功倍的事情。在最初阶段，程序员们费了很多时间和精力去编制这些辅助工具。在那个时候游戏设计师们在焦急地等待着游戏达到可试玩的程度。表面上看，编制这些工具耽误了游戏的开发进度。但一旦开始测玩，各种工具的威力开始显现。利用它们，游戏设计师可以直接修改调整游戏内容而无需每次都麻烦程序员了。这样省却了大量的时间。举一个例子：虽然从表面上看《神话时代》有36种神力，但实际上某些神力的内在机制是类似的。程序员只需要编写一段通用的代码，通过输入不同的数据我们就可以实现并测试几种貌似不同的神力。比如说有一种神力可以用来转换部队（switch units）。程序员编写好代码后，通过操纵数据，我们设计师就可以毫不费力地把敌人的部队转换成一群猪，或者把友方的法老转换成埃及冥神（Osiris）之子。

当然，在工具上花费太多时间和精力也有其不利的一面。因为首先这些东西是玩家看不到的，你的努力也许并不为人所感激。其次，你可能是在为了设计而牺牲编程。也就是说你占用了宝贵的编程时间，去给设计师提供工具。在《神话时代》开发的最后阶段，设计师有他们所需要的一切工具，但一些设计要素却没有时间去实现了（没有编程时间了）。

5、注重战役（campaign）设计
注：所谓战役，是指在单机模式下，由故事主线所连接起来的一系列战役。每一个战役有不同的场景和目的。战役之间用过场动画来描述故事情节。

《帝国时代》和《帝王时代》中的诸多战役（campaigns）虽然有些乐趣但却没有太多闪光的地方，它们是由1到2个设计师独立完成的，比较单薄。在《神话时代》的计划阶段，我们就决定给单机模式下的战役设计以足够的重视，使其成为游戏的招牌卖点。我们新招了几个员工，并为游戏中的动画和镜头使用着实花费了一些心血。我们还特地跑到好莱坞去使用了一些专业的配音演员。

我们以前从未尝试过这种史诗性的、着重人物性格刻画的剧本。我们为此做出了巨大的努力。我们指定了一个故事委员会（story committee）来审核剧本。在游戏开发的最后阶段，负责战役设计的游戏设计师和负责过场动画的动画师每天都得进行数次沟通，以保证协调一致。这些努力没有白费，最终我们完成了一个广受好评的单机模式下的战役设计。

1、过于重视设计，设计主导（design driven）的程度太深
由于整个项目是围绕着设计师们展开的，设计师们是明星，程序员为设计师提供他们想要的工具。最终，设计师们如愿以偿地获得了各种工具（基于数据的工具，如前所述），并利用这些工具来进行设计和调试。但到最后我们意识到：设计师做了很多程序员可以做得更好更快的工作。如果让程序员来做，可能要比专门编制这些工具更省时省力。

在设计规格书（design specs，又称设计纲要，是描述游戏设计的文档）方面，由于我们在以前的项目中，规格书做得过于笼统，导致程序员没有完全掌握设计师的意图并实现其设想。我们这次不惜矫枉过正，事无巨细都放到了设计规格书中，导致设计规格书庞大而驳杂，有些内容写上去之后就从来没有人阅读了。我们的设计规格书精确到了什么程度呢？精确到了对scenario editor中各种图标（icon）的样式，按钮（button）的各种状态和位置等，都做出了详细的描述。
这么做的后果，就是新进的设计人员只是在很低的层面从事没有创造性的工作，即完善一本已经很庞大驳杂的设计规格书。他们花费时间精力，去撰写如“当你按下这个按钮（button），它应该陷下，直至你松开鼠标，它应该恢复正常的状态。当按下按钮时，应该发出一种音效，就像树枝折断的声音……”这样繁琐而枯燥的内容。这可真要令他们发疯！在下一个项目中，我们还会一如既往地重视游戏设计，但我们将把设计提高到一个比较高的层次，不再搞这么复杂的设计规格书了。我们将要充分信赖程序员和美工，让他们有一定自主性，去补充完成细节。
2、剧本过于宏大
在开发伊始，我们就希望《神话时代》能够有一个如伊里亚特（荷马史诗）般宏大感人的剧本。我们也希望游戏中的人物有血有肉，并且能够相互之间进行交互。一句话，我们需要一个宏大的剧本和海量的对话。虽然Ensemble的设计师们有一些零星的写作经验，但没有任何人有完成如此宏大的剧本的把握。而且我们对过场动画（用来表现故事主线）的机理也是心中无数。

虽然如此，事情终究是要做的，我们也只好硬着头皮上阵。剧本经过千辛万苦编出来了，然后是在全组范围内征求修改意见。大家纷纷提建议。这个人喜欢这个角色，那个人喜欢那个角色。这剧本修改起来可就困难了。删改任何一个角色，马上有人提出抗议。随便改动一点情节，就会牵一发动全身，对剧本的主线造成损害。最后，我们不得不放弃在全组寻求剧本修改意见的作法，指定了一个2人小组专门负责修改润色剧本。在将来，我们会在一开始就限定剧本在小范围之内寻求反馈和修改意见，这样才能保证我们及时把剧本的各项内容敲定，包括故事的长度、角色数量、情节细节等。

编制这样宏大的剧本，制作如此众多的素材，并且按质按量完成，是需要切实的熬出来的经验的。如果你也正准备开发一个这么大的游戏，并且没有经验的话，那我的建议是：把项目各项工作的所需时间乘2，而把项目的预期内容削减一半（角色数量、对话行数、scenario数量等）。

3、大的制作组内部很难达成一致意见
在Ensemble Studios，我们曾力求让所有组员对游戏设计达成共识。这是我们公司创立之时的指导思想，也是我们的游戏设计流程的根本。当公司只有十几个人的时候，它曾经十分有效。即使当我们扩张到20多人的时候，把大家聚集起来（我们一般都在一起吃午饭，所以可以利用午饭时间召集会议）讨论问题，仍然是行之有效的方法。但当公司继续扩张，把所有组员聚集起来开会就不是一个很有效的方法了。更为严重的是，在很多问题上人一多，意见一多，就形成僵局。很多设计决定，都是各方妥协的结果。这种妥协，产生的是各方都不太满意但又都凑合同意这平庸化的设计。用我们的话来说，就是“和稀泥式设计”。

我们不得不改变了策略。设计部门就游戏设计向所有组员收集反馈，然后分析整理，做出决策。但是，在项目中途改变人们的既成习惯是不容易的。很多人抗议，说他们提供的反馈意见没有得到重视，被黑洞吞噬掉了！这迫使我们制定新的制度，我们要将反馈信息的分析和决策过程整个记载下来，并将其用Email传达给所有组员。但是我们马上又陷入另一个怪圈：当你在Email里为一项设计决定做出解释后，马上收到5封Email不同意你的逻辑和结论，并要求回复。

最终我们忍无可忍了！设计师们只能有两个选择：做他们应该做的事情——完成游戏设计；或者陷入永无休止的争论中，解释并扞卫每一项设计决策。

虽然如此，我们现在仍然认为：项目组的大小是一个变量。它的变化将影响到如何在组员中达成共识。项目组大的，达成共识比较困难。但设计部门还是应该最大程度上和所有组员交流并获得共识。在《神话时代》开发后期所采用的“小型设计研讨会”（前面介绍过），比较有效，我们将把它更正规化制度化起来，应用到我们以后的项目中。

4、标新立异，多新多异？
开发续作，挑战很多。其中一个人所共知的困难是：你必须保留前作中受到好评的要素，同时还必须提供一些新的要素，使得新游戏有别于旧游戏（否则玩家为什么要买新的游戏？）。《神话时代》的前作《帝国时代》系列是非常复杂的游戏。我们知道我们不能简单地把《帝国时代》拿来，在它上面简单附加一些新的功能。我们得有所取舍，进行深层次的改动和改进，这样《神话时代》才能脱颖而出。对这个问题，大家有足够的认识。但每个人对“改动”的理解，却又是不一样的。有的人主张只进行小的改动，比如把《帝国时代》中的骑士改成牛头马面。有的人则主张进行伤筋动骨的大改动。理解的不一致，导致后面设计工作中的争论。

比如，我们对游戏中的人口模型进行了数次改动。最初的设计中，我们去除了《帝国时代》中的房子的功能。一些组员认为这个改动太大了，《帝国时代》的玩家们会不满意。而另一些人则认为改动还太小，仅仅去除房子还不够，他们提议做更多的改动。

当然，所有这些改动，玩家们最后的反应都是很强烈。他们一方面为新的游戏设计要素鼓掌称快，另一方面又对哪怕是最微小的删改提出抗议。例如，在《神话时代》中你不能选择你方的色彩。虽然是一个和游戏性无关的功能，但很多玩家对此极为不满。

对于如何使得一个游戏（特别是续作）标新立异卓然不群，并没有理想的解决方案。现在的游戏都非常复杂，无法在项目一开始的vision statement（游戏总设计目标）中清楚地定义这个游戏是如何“新”和“异”的！我们在今后的项目中，将试图更早地对这个问题进行探讨并达成共识，避免这次出现的这么多不同意见和争论。
5、未完成的工具
因为我们要采用一种新的引擎，并且没有任何前作的代码可以重用，所以我们一开始就很明智地安排了很多时间来开发各种工具。可惜的是，因为这些工具是内部使用的，当其他方面出了问题急需人手时，编写工具的程序员经常被抽走帮忙。有些工具到最后也没有完成，而需要使用这些工具的游戏设计师一直无奈地等待到了项目最后。在漫长的等待中，我们觉得与其坐等不如绕过工具做点什么，很多内容就是这样非常规地被塞到游戏中。我们真是有点象黑客了！一个很好的例子就是scenario中的计算机方的AI。这个部件很晚才完成。当它完成时，游戏设计师们早已在游戏中用scenario triggers制作了模仿计算机方AI的脚本。这种方式不值得提倡，因为使用非常规的方法放入的内容很难修改，不利于我们调整游戏设计（前面提到的复进式设计）。

在未来的项目中，我们（和游戏开发业所有人一样）需要明确认识到这些工具的重要性和价值，要给予工具足够的开发时间。另外，我们也应给予那些最终将要和游戏一起推出的，面向玩家的工具以足够的重视。象这次《神话时代》的scenario编辑器，就很令我们不满意！