原作者：Brian Jacobson&David Speyer
译者：Vivian Xue
本文最初刊登于2005年9月的《游戏开发者》杂志上。
Valve在开发《半条命》（发行于1998年11月）的过程中，创造了一种名为“Cabal Process”去中心化设计流程，即让拥有不同知识结构的人们组成一个小组，共同处理设计问题。因此在《半条命2》设计之初，我们自然希望能再次运用这种方式进行开发。然而，由于续作开发范围的扩大，我们在应用Cabal Process的过程中遇到了问题，因此我们不得不对它进行调整以使它重新发挥作用。本文讨论了改进版的Cabal Process在《半条命2》制作过程中的应用。
项目规模的扩大
《半条命2》是一个具有宏伟目标的项目。我们将团队规模扩大为原来的近三倍，并从各方面大力推进技术进步。游戏的动画、物理效果、人工智能、声效、渲染和网络系统都是从零开始建立的。在技术推进过程中，我们扩充了原《半条命》Cabal小组，成员们讨论了几个月，试图写出与上一份类似的完整的设计文件。开发早期，我们的设计工作进展十分缓慢，因为我们发现我们很难预测在技术推进完成后，它究竟能帮助我们实现什么样的设计方案。更糟糕的是，最终的设计成果依赖于许多游戏元素，而这些元素仍处于理论阶段。
当我们的“Source”3D引擎技术成熟时，我们发现自己处于一种似曾相识的境况中，从某些方面来看，它与我们刚开始进行《半条命》Cabal Process时很相似，但在其它方面又迥然不同。在设计方面，我们的情况比之前好多了，我们拥有了完整的故事时间线、详细的故事片段、所有主要人物的简介、一套场景图，并且我们对游戏最终将具备的技术也一清二楚。不过在制作方面，我们只有一些原始的素材：一些武器、一些很酷（和一些不怎么酷的）的怪物、几个关卡。然而，与《半条命》一样，在开发的这个阶段，技术还派不上用场。你无法从头到尾地打一遍游戏，关卡之间也没有任何连贯性。
当我们了解了引擎的能力，并且拥有了足够的素材作为推进框架设计的约束后，Cabal Process便开始有效地发挥作用了，就像在《半条命》的开发过程中一样。
此时的问题是，由于游戏和制作团队的规模都扩大了，Cabal Process遇到了瓶颈，它的内容生产效率不够高。因此，我们组建了三个几乎独立的Cabal设计小组，每个小组负责设计和制作大约三分之一的游戏，我们还组建了专门研究美术、音效和动画的Cabal小组。
回归正轨
每个Cabal小组由4至5人组成，一半是关卡设计师，另一半是程序员。在开发《半条命》时，我们认为这是理想的规模。如果小组规模更大，讨论的效果会下降，而缩小规模会导致想法枯竭。我们选择让程序员和关卡设计师一起工作是因为大多数的迭代工作都会牵涉到AI、代码或关卡的修改。每个小组里都有一位引擎程序员，为设计提供技术支持。为提升工作效率，我们希望每个团队成员都成为一名“高要求的顾客”，“消费”彼此的工作成果。比如关卡设计师是程序员的“顾客”，他们使用程序员创造的游戏元素和AI。程序员是关卡设计师的“顾客”，因为他们需要在关卡的基础上改进代码。我们让每个Cabal小组的成员在同一个办公室里工作，这不仅减少了通讯开销，还促进了人们优先处理工作。我们发现，当其他团队成员在周边即时地指出关键任务时，人们更不容易被琐事干扰。
《半条命》的Cabal小组包含了美术设计师和一名脚本策划，而《半条命2》的多小组结构促使我们将美术设计师和脚本策划视为共享的资源。我们创建了一个美术团队、一个动画团队、一个音效团队（实际上只有一位音效师）。在开发早期，美术团队帮助Cabal设计小组绘制场景、怪物和人物的外形，并在游戏玩法确定后进一步优化了关卡。音效团队在游戏原型设计时期为Cabal设计小组创作临时的音效，在设计敲定后为创作最终版本的关卡音效。动画团队协助Cabal设计小组设置关卡任务目标和奖励，并提供关卡所需的动画。动画团队同时作为一个独立的Cabal设计小组负责一些剧情密集的部分，比如克莱纳博士的实验室、黑山基地东区和布林博士的办公室。
尽管我们对Cabal Process的结构做了较大的调整，原始流程的许多方面依然保持不变。每个Cabal小组生成设计的方式与之前并无二致。我们仍然遵循“谁设计，谁制作”的原则，因为我们相信如果设计人员不能亲自参与制作，好的设计会在执行过程中偏离预期。在某个执行过程中，清楚了解方案优劣性的人们能够做出更好的设计选择。我们一如既往地反对将设计视为某种专属权力，因为我们相信让更多的人参与到游戏某个部分的创作中，最终能产出更高质量的成果。我们的可玩性测试（Playtesting，通过指定一组玩家试玩游戏的某个片段来寻找游戏的缺陷，游戏邦注）与原先保持一致，它依旧是我们解决设计分歧的方式。与《半条命》一样，每个Cabal小组对他们设计的关卡的质量负责。
最终，我们拥有了六个团队，我们必须将他们的工作成果——模型、素材、音效、动画、光效、剧情和游戏设计——统统融合进关卡里。显然这个过程很棘手，但也是我们成功的关键。
当然，我们要面对许多明显的问题：我们要如何统筹六个独立团队的工作并降低成本？我们应该如何发挥各个团队的重要作用同时避免发生设计冲突？我们要如何使三个独立设计团队形成一致的设计风格和质量水平？我们最终逐个解决了这些问题。
创建关键帧
《半条命2》包含了长达三个小时的动画，为这些场景录制对白并不总是一件容易的事。某些情况下，我们需要飞往洛杉矶，利用演员繁忙日程中的某一个空档，在摄影棚里争分夺秒地拍摄，之后我们就只能靠自己了。在理想状态下，我们本可以按照更传统的流程编写剧本，但前提是我们必须事先知道设计最终会变成什么样子。我们不能把所有的动画制作留到最后完成，否则我们将没有足够的时间来改进它。因此，我们必须同时开发剧情和玩法。
起初，这两者似乎密不可分，这也为我们带来了一个有趣的挑战：鉴于Cabal小组的设计过程（和结果）变化无常，我们应该给与他们多大的自由度，同时又能确保剧情在一个足够稳定的框架内展开？我们最终确定了一个设计流程，让剧情作为约束游戏设计的关键帧（key frame）。例如，在设计运河航道和水障碍区章节的时候，根据剧情我们知道玩家将从17号城市出发，摆脱克莱纳博士实验室外的敌人，最终到达黑山基地东区。我们有意地将这两个关键帧之间的剧情要素模糊化，等到确定玩法后再补充细节。在Cabal小组认可了剧情关键帧后，他们可以任意地设计其中的玩法，而不必担心剧情站不住脚。
当一个章节的玩法设计完成后，相关的玩法和动画Cabal小组合作列出章节内可以添加剧情要素的场景。其中一些要素是玩法所必需的，例如短期任务的交付或者游戏机制的介绍；一些对剧情和玩家激励起重要作用，比如对一些更大的中心目标进行强调（比如提醒玩家他们必须在运河航道章节里到达伊莱实验室）。除此之外，还有一些属于丰富玩家体验的奖励性要素。即便按照这个流程进行设计，我们仍然需要让剧情具备较高的灵活性，以适应不可预测的玩法的变化，比如我们通过重力枪增强了莱温霍姆章节的体验后，它被挪到了黑山基地东区章节的后面。
美术设计
与《半条命》相比，《半条命2》的美术设计负担比前者大出好几倍。《半条命2》使用了超过3500个模型，将近1万个素材，单幅地图的大小最高达到20兆（对比《半条命》，模型300个，素材4000个，3兆的地图文件）——我们在视觉效果上做了巨大的投入。为了制作数量如此庞大的素材，同时保持相对较小的团队规模，我们不得不优化制作过程，并尽可能地将它与游戏玩法变化分离开来。
每个章节的美术创作从创建概念草图开始，在设计早期，各个Cabal小组在确定了大致故事背景后着手进行这项工作。很多时候，在大致剧情后我们就开始设计这些概念图了，它们为游戏设计提供了许多启发。一旦这些概念和玩法合拍，它们将成为风格指南（style guide）——缺乏玩法的地图将作为最终版本的模板。这个风格指南与游戏模型相互影响。比如，越野车的操控特性影响了它的使用场景——海滨景观的设计，反之亦然。
橙色Agent模型
每章节的初始模型建立在橙色地图上。我们用橙色网格纹理代表墙体，灰色网格代表地面和天花板。这种做法帮我们解决了早期遇到的一些问题。
首先，在游戏的核心机制在通过可玩性测试之前，关卡设计师们不需要在美术设计上投入过多的精力。这大大降低了迭代成本，并且避免人们过早地陷入视觉设计的压力中。其次，它帮助游戏设计团队将注意力从对艺术设计的批判转移到游戏模型上——这才是他们在开发早期应该关注的重点。最后，它使得美术团队能够更加自由地试验各种视觉主题，鉴于他们的工作与游戏建模分离了开来。
成功的游戏模型和风格指南是我们制作最终版本关卡的基础。一旦它们通过了可玩性测试，它们将被交到美术团队手中进行艺术审核。过程中，美术师们将对关卡设计师们设计的几何体进行艺术加工替换，修改或重置光线，并增添一些辅助视觉元素，例如火焰、迷雾、天空效果，从而形成最终版本。
经这一过程制作出来的关卡不仅更接近原始艺术概念，而且不会破坏游戏玩法。尽管在实践中，我们确实遇到了游戏玩法遭破坏的一些意想不到的情况，例如当我们用一个更加逼真的细框架吊桥替代之前关卡设计师设计的更结实的版本后，测试玩家们不愿意往桥上走了。正是由于视觉设计与游戏机制传递的信息之间存在这种内在联系，我们的Cabal设计小组总是在艺术审核过后进行可玩性测试，验证游戏玩法是否被破坏。
符号链接（Symbolic Links）
为了保障各个团队同时制作某一个关卡且避免工作停滞，我们尽可能将我们的工具构建成独立文件，并通过符号链接系统将它们关联起来。符号链接是人类可解读的引用（references），在运行时被解析，其中的代码或内容用于指向另一个代码或内容。例如，我们用声音脚本文件的条目名称替换了地图上指向原始声音文件的直接引用。每一个脚本文件条目都详细说明了声音的音高、音量、和随机文件选择。由此一来，我们的音效师便可以在不影响关卡设计师的情况下替换或者修改声音。在我们使用符号链接前，关卡设计师需要将地图交给音效师，等到声音编辑完毕后才能继续设计地图。同时，通过在声音上标识出关卡信息，音效师在更改声音时不会影响到其它地图。
我们的动画序列中也使用了符号链接来标出每个关卡内演员将往哪个方向行走或者看向哪里。这样一来，一些人在进行脸部动画制作、动画合成和场景事件排序时，其他人便可以同时设计地图上的几何体。这种方式同样被应用到了人物对话脚本制作上，帮助我们的脚本策划更快地对它进行迭代。
我只举出了一些例子，事实上符号链接在我们的制作过程中得到了非常广泛的应用。由于我们相信迭代的次数越多，游戏的质量也会越高，因此我们的总体战略是在增加迭代次数的同时降低成本。迭代成本越低，试验成本也就越低，试验其实就是另一种意义上的迭代。另外，由于符号链接技术使不同团队可以独立工作、互不依赖，我们因此能够在发行前夕修改游戏，这在之前是不可能实现的。
实现全局一致
我们所有章节的设计都围绕着一套相同的核心设计原则，其中的许多沿袭了《半条命》的设计原则，但也有一些是全新的。我们的团队希望在吸取《半条命》成功经验的基础上，对它进行扩展。我们的首要目标是打造沉浸式的第一人称体验，因此我们保留了一些之前的原则。
尽管每个Cabal设计小组都遵循相同的指导原则，但在多小组结构下，难免会产生设计上的不一致。每个独立Cabal小组的设计反映了不同小组成员的长处和弱点——可想而知各个小组将开发出不同的游戏机制，他们对关卡难度、游戏体验的强度和战斗与解谜内容的比例等也将有着不同的看法。我们的工具组的数量太过庞大，以至于Cabal小组成员更愿意使用他们所熟悉的工具。有些团队里有渲染方面的专家，有些团队里有AI方面的专家。有些关卡设计师擅长设计战斗，有些擅长优化性能。一些擅长设计地形，一些擅长制作实体，还有一些对艺术更敏感。大家擅长的事物如此不同，要如何共同协作做出一款游戏呢？
首先，我们试图考虑设计的经济性。我们鼓励每一个Cabal小组在评估设计选择时都思考这样一个问题：这个元素对其它的游戏元素有什么促进作用呢？经过这个过程，人们往往会考虑选择同样的元素，最终的游戏体验自然更加一致。
Concept art: Poison zombie
我们在团队内部展开可玩性测试，让不同的Cabal小组测评彼此创造的游戏机制，以此寻找和分享成功的机制。例如，莱温霍姆的制作小组让重力枪以特殊的方式与一些特别的物体（比如锯片）进行互动，这为暗能城堡的制作小组提供了启发，他们从而制作出了增强版的超级重力枪，跟着弗里曼制作小组用重力枪衍生出的能量球来打开“Nexus gates”。后来，能量球还被整合成为了联合军突击抢的第二攻击模式。
这些可玩性测试还帮助团队成员们发现了一些其它方面存在的不一致性，例如视觉效果、战斗和谜题等等。当一个Cabal小组发现另一个小组的制作更出色时，两个小组很快会集中到一起进行技术探讨。
由于某些设计元素，如武器和怪物，在各个Cabal小组间是通用的，有时更改这些元素必然会导致其它小组设计的关卡失衡。为了解决武器失衡的问题，我们成了一个武器Cabal小组，由来自三个Cabal设计小组的代表、一名硬核FPS玩家和另一名不太专业的玩家组成，这样两种类型玩家的需求都能够得到满足。武器Cabal小组的任务是制作一套种类丰富而战斗力均衡的武器，每一款武器都具有独特的功能，但没有任何一款具有明显优势（至少我们暂时不希望出现这种情况）。武器Cabal小组调整武器在游戏中的分布，以避免出现武器过于密集或者很难找到武器的情况，这样玩家才能在游戏全程中保持稳定的节奏。武器Cabal小组同时还与设计团队合作，确保武器介绍足够有趣，能激励玩家学习使用它们。
我们在进行项目管理决策时也秉持一致性的原则。Cabal设计小组每周对跨小组使用的资源（管理、美术、动画）进行审查，使团队成员们清楚了解设计决策。这些审查的目的是帮助各个Cabal小组按照一致的开发范围、节奏、交付目标和方式展开工作，。
在可能的情况下，我们使用比较性的指标（比如每个级别设计周内能交付多少张地图？）来评估每个Cabal小组的产出。我们不间断地发布代码——我们把它当做小组间的共享资源，需要的小组可以使用它——它同时是另外一种帮助团队了解设计选择的方式。我们尽了最大的努力实现各个小组同步交付，这也提高了团队内可玩性测试和其他跨小组反馈机制的有效性。它迫使各个小组在同一时间段内解决相似的问题，并促进了积极竞争。任何一个小组都不希望自己落后，或是自己的成果在可玩性测试中表现较差。
第二次全面审查
在游戏制作开始前，我们就已经计划等游戏到Alpha阶段时对它进行全面质量审查，对我们的选择进行整体评估。我们很快意识到我们必须进行第二次审查，以解决首次审查中遗留下来的关卡一致性问题。第二次审查只花了我们四个月的时间，但它大大提升了游戏质量。
在Alpha阶段开始时，游戏各部分质量参差不齐，节奏变化也很大。由于各制作小组很难了解其他小组制作部分的开头和结尾，章节间的过度非常突兀。章节间的难度跳跃设置也不合理，其中的一些任务完成起来太过简单了。拿章节过度来说，只要让每个小组了解彼此的过度设计，它不是什么大问题。我们遇到的最难解决的问题是如何保证质量上的一致。
在Alpha初期，为了对游戏进行整体评估，整个团队暂时放下了游戏制作，从头到尾打一遍游戏，将自己发现的问题记录下来供大家讨论。为了将不同的反馈整理成连贯有效的信息，我们从6个Cabal小组中各选取一名成员，再加上一些其它人组成一个新的小组，在整整一周内每天聚在一起开会，逐章节地对整个游戏进行评判。
这个小组负责向其它团队提供反馈，以使每个团队都能最大程度地提高游戏的整体质量。最终由各个Cabal设计小组根据这些反馈来决定如何修改游戏，并将资源用在他们认为能够实现最佳效果的地方。
这个小组重点讨论了每一章节的亮点和缺陷。亮点必须被打磨和放大，这是我们最大化游戏质量最便捷的方式。我们还注意到我们可以借鉴一些热门的游戏机制，这不仅能帮助我们充分利用我们的最佳元素，还能提升设计的经济性和一致性。
缺陷是游戏中那些令人受挫、困惑、空洞或者制作粗糙的部分。我们用一些解谜内容或者downtime（游戏中让玩家休息的时间，游戏邦注）来中和节奏过快的内容，以免玩家感到精疲力竭，同时我们对空洞的部分进行补充。一些缺陷由于弥补成本过高最终被我们直接剔除了，这个过程令我们倍感痛苦，因为项目开发到这个阶段，任何内容的删减都意味着曾经的大量投入付诸东流。这使我们感到在项目后期删减内容比早期更加令人难过，所以最好一开始就保持果断。不过我们也告诉自己，（这是由于）我们比消费者要更在乎这些内容，毕竟消费者看到的只是最终产品。同时一想到删减后剩下的内容将得到更多的关注、从而达到更高的质量水平，我们也感到宽慰了许多。
多次迭代，最大化收获
我们中的许多人都对经过二次审查后游戏质量的大幅提升感到惊讶，毕竟这次花的时间相对较短。我们认为多次迭代是《半条命2》成功的关键，也为我们未来的项目指明了方向，最重要的好处是它使我们做出了更佳的决策。
在《半条命》和《半条命2》的开发过程中，我们发现我们在项目后期做的决策总是要优于早期决策。一部分是由于我们积累了更多的实践经验，从而更加了解项目。例如，在进入alpha阶段的6个月前我们就开始研究暗能城堡了，与其他章节不同的是，我们当时并没有计划好要在这个章节内要使用什么元素。暗能城堡的所有游戏元素的建模只花了一天时间，而我们对这个章节的首次审核花了三周时间。超级重力枪的诞生是由于当时我们发现重力枪是游戏中一个非常成功的元素。由于我们充分了解引擎，一旦选定游戏机制我们可以快速将它应用到游戏里，因此整个开发过程的效率极高。
另外一些决策必须等到项目后期才能进行定夺，因为它们需要基于更完整的产品。例如，在开发早期，游戏的前两个章节莱温霍姆和诺瓦矿场刚制作完时，我们很难判断怎样算“足够好”（相对于可怕的“不够好”），但是随着游戏内容逐渐完整，判断标准变得清晰明了。同样的，平衡关卡和游戏节奏也只有等到游戏成形后才能进行。
显然，过晚做决策可能会导致发行延期。为了避免这个问题，我们在做决策时会优先考虑时间上的限制。越临近发行期限，大范围的更改就越不可取。例如，在游戏模型制作期间，我们可以添加新技术或AI、定义空间、重新排列关卡。在艺术审核过后，对几何体以及光线进行更改将受到限制。在alpha阶段后，游戏机制、美术资源、关卡进度、游戏人物和大部分的对话都固定了，除非改动内容对其余部分影响不大且被充分理解，否则不做更改。我们推动符号链接系统的努力上在这一阶段得到了回报，它使我们能够以低成本进行大量重要的改动。
成果总结
制作《半条命2》使团队中的每个人都受益匪浅。每个成员都为我们共同创造的产品感到由衷的骄傲，并期待复制这个过程，这也许比游戏的销量更能证明这个过程的成功。希望我们从制作《半条命2》中获得的经验能够成为通用的方法，并可以被应用到其他项目中。以下是我们认为最重要的一些经验教训：
1.分散化设计过程。
2.尽早定下粗略的、但事关游戏开发全程的设计（比如武器、剧情、基本的怪物行为）。最小化资金投入，直到你的游戏质量达到了临界点再进行迭代，使一款良好游戏变成一款伟大的游戏。
3.不要从理论上设计游戏。先通过建立模型来验证设计，它并不需要看起来很精致（比如我们之前提到的“橙色”地图）也许你可以使用之前的模型。
4.如果你设立了一年的开发周期，试着在八个月内达到alpha阶段，留下几个月进行设计迭代。根据我们的经验，alpha后每一周的工作比alpha之前四个星期的工作更有价值。
5.让每位团队成员都拥有一名“高要求的顾客”——这是提升效率和工作优先化处理的好方法。
6.在传统的开发范围、质量和时间的权衡中，缩小范围并通过迭代取得更好的结果。
7.仔细思考开发过程中发生停滞的环节，尝试减少停滞的情况。
8.使用符号链接技术消除开发停滞，这样做还可以尽可能降低项目后期的迭代成本。
9.过程是廉价的、可以被舍弃的——衡量它们是如何帮助你成功地实现目标，或者导致你失败。如果你发现某个过程不能发挥作用，勇敢地改变它。
游戏邦编译
原译文：http://www.gamasutra.com/view/news/259479/Classic_Postmortem_The_making_of_HalfLife_2.php
Steam 
App Store 
闽公网安备 35020302034348号