半条命2开发者谈改良版的“去中心化”设计流程在游戏制作中的应用

原作者：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小组在评估设计选择时都思考这样一个问题：这个元素对其它的游戏元素有什么促进作用呢？经过这个过程，人们往往会考虑选择同样的元素，最终的游戏体验自然更加一致。

我们在团队内部展开可玩性测试，让不同的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. 过程是廉价的、可以被舍弃的——衡量它们是如何帮助你成功地实现目标，或者导致你失败。如果你发现某个过程不能发挥作用，勇敢地改变它。

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

While building Half-Life, which shipped in November 1998, Valve created a method of decentralized design called the Cabal Process (described in this article on Gamasutra), which used a small cabal of a few people from various disciplines to tackle the design. Needless to say, when design began on Half-Life 2, we had great interest in applying the same structure and principles to its development, too. However, the greater scope of the sequel posed some problems for the Cabal Process, so we had to tweak it until it worked for us again. This article discusses the revised Cabal Process used to make Half-Life 2.

PROJECT SCALING

Half-Life 2 was a project with ambitious goals. We nearly tripled the team size, and embarked on a huge technology push on all fronts. Acting, physics, AI, sound, rendering, and networking systems were all built from scratch. During the technology push, an expanded version of the original Half-Life cabal met for months, attempting to create a complete design document similar to the first one. Design work during the early phase of development progressed very slowly because we found it difficult to predict what kinds of designs our technology would enable once it was finished. To make matters worse, the resulting design relied on many game elements that were purely theoretical.

By the time the Source technology had matured, we found ourselves in a position similar, in some ways, to where we were at the start of the Cabal Process for Half-Life, but very different in others. In terms of design, we were better off. We had a full story timeline, detailed story snippets, all the major character profiles, a set of locations and drawings, and a fairly clear idea of what technology we would have for the final game. In terms of production, though, we only had a bunch of raw material in the bank: some weapons, some cool monsters (and some not-so-cool monsters), and pieces of interesting levels. However, as with Half-Life, at this stage of development, the technology was not being taken advantage of. You couldn’t play the game all the way through, and none of the levels were tied together in a coherent fashion.

Once we knew what our engine could do and had enough raw material in the bank to use as constraints to drive the design, the Cabal Process began to work as efficiently for us as it had during the development of Half-Life.

The problem now was, given the much larger scale of the game and larger number of people working on the project, the Cabal Process itself became a bottleneck. It couldn’t produce content fast enough. As a result, we created three nearly independent design cabals, each responsible for designing and producing roughly one-third of the game, plus dedicated cabals for art, sound, and acting.

BACK IN THE SADDLE AGAIN

Each cabal consisted of four or five people, half level designers and half programmers. While developing Half-Life, we decided that this was the ideal size. Larger cabals resulted in diluted design meetings and smaller ones risked a dearth of ideas. We included both programmers and level designers because most design iteration occurred through changes to AI, game code, or levels. Each cabal also included one engine programmer who would develop new technology required by the designs. For productivity reasons, we wanted each team member to have a “demanding customer” on the same cabal, someone who consumed that person’s work. Level designers were customers of programmers in that they used the gameplay elements and AI created by the programmers. Programmers were customers of level designers in that they needed levels as a venue to refine their code. The members of each cabal shared an office to reduce communications overhead and, as we discovered, improve prioritization. People were far less likely to get sidetracked by non-critical tasks if their teammates sat nearby to serve as instant triage.

The Half-Life cabal included artists and a writer, whereas Half-Life 2’s multi-cabal structure prompted us to treat artists and writers as shared resources. We created an art team, an acting team, and a sound team (actually just a single sound designer). The art team collaborated with the design cabals on the look of the environments, monsters, and characters in the early stages of development and made the levels look great once the gameplay in those levels was stable. The sound team worked with the design cabals to produce stand-in sounds during gameplay prototyping and to create a final sound treatment of the levels after the design stabilized. The acting team collaborated with the design cabals to seed levels with mission goals and story rewards, and they produced any animations the levels required. The acting team also served as an independent fourth design cabal for the storyheavy sections of the game, such as Kleiner’s Lab, Black Mesa East, and Breen’s chamber.

Despite the large structural changes to the Cabal Process, there still were many aspects of the original process (as described in our previous article) that remained intact. The way each cabal generated designs remained largely unchanged. We preserved our edict, “He who designs it, builds it,” in the belief that the best designs are influenced by the realities of production. People who are very cognizant of all the tradeoffs inherent to a given implementation are going to make better design choices. We continued to discourage a sense of sole ownership because we believe that having more hands on a given section of the game ultimately produces higher quality. Our playtesting techniques remained the same, and we continued to use them as a way to settle design arguments. As with Half-Life, the cabals were completely responsible for meeting the quality standards in the levels they owned.

The result was that we had six teams, all of whose work—models, materials, sound, animation, lighting, story, and game design— had to come together in the levels themselves.Clearly, managing this process was going to be tricky but essential for us to succeed.

There were some obvious problems, of course. How would we manage and reduce the cost of the many interdependencies between our six teams? How would we allow every team to apply important constraints to the design? How would we create a consistent design and level of quality in the face of three independent design teams? These problems were eventually solved on a case-by-case basis.

KEYFRAMING PROSE

Half-Life 2 contains more than three hours of acting, and recording the dialogue for these scenes wasn’t always easy. In some cases, it required flying to Los Angeles, exploiting a limited window in an actor’s busy schedule, and using a fixed number of studio sessions, after which we would be on our own. In an ideal world, we would have gone through a more traditional screenwriting process, but that would only have been possible if we knew in advance where our game design process was going to take us. We couldn’t leave all the acting until the end because then there wouldn’t be enough time to improve it; so story and gameplay had to develop concurrently.

At first, the two seemed inextricably linked, which presented an interesting challenge: How would we give the gameplay cabals, whose process (and result) was fluid and unpredictable, the freedom to experiment while presenting a stable enough framework on which we could hang a story? We eventually settled into a process whereby story provided keyframes that served to constrain the game design. For example, in designing the Route Kanal and Water Hazard chapters, we knew the player would start on the run from City 17 forces outside Kleiner’s Lab and finish at Black Mesa East, far from City 17. The story elements that fell between those two story keyframes were purposely left vague until later in the process when the gameplay had solidified. As long as the gameplay cabal satisfied the constraints of the story keyframes, the cabal was free to take the gameplay in whatever direction seemed most promising without fear of leaving the story in an untenable position.

Once a chapter’s gameplay was finalized, the responsible gameplay cabal and the acting cabal met to draw up a list of places within the chapter where story elements could be added. Some were required by the gameplay, such as the delivery of short-term mission goals or the explanation of a game mechanic. Others were important for the story or for player motivation, such as the reinforcement of a larger overarching goal (like reminding the player that they had to get to Eli’s during Route Kanal). Finally, some were story-based rewards that served to enrich the player experience. Even with this process, the story still had to be supple enough to respond to unexpected gameplay demands, such as when Ravenholm moved from before Black Mesa East to after, once the potential of the gravity gun to enhance Ravenholm was realized.

INSIDER ART

The art burden of Half-Life 2 was an order of magnitude greater than that of Half-Life. Half-Life 2 used more than 3,500 models, nearly 10,000 materials, and individual maps as big as 20MB (compared to Half-Life’s 300 models, 4,000 materials, and 3MB map files)—a tremendous investment in visual quality. In order to produce this many art assets with a relatively small team of artists, we had to optimize the art production pipeline and insulate it from gameplay changes as much as possible.

The art production for a chapter began with the creation of concept sketches, which were developed early in the cabal’s design process once the general setting was established. In many cases, the concepts were developed even earlier based on the broad story design, in which case they served to inspire the game design. Once the concepts and gameplay were deemed compatible, the concepts were developed into styleguides— maps devoid of gameplay that would serve as a template for building final production maps. The styleguides both influenced and were influenced by gameplay prototypes that were developed simultaneously. For example, the buggy’s handling characteristics influenced the scale of the coastal landscapes in which it was used and vice-versa.

AGENT ORANGE

Initial gameplay prototyping for each chapter took place on orange maps. Orange maps use an orange grid texture for walls and a gray one for floors and ceilings, and using them solved a number of issues we ran into early on.

First, it prevented level designers from investing in the art for an area before the core game mechanics had been validated through playtesting. Effecting this practice dramatically reduced the iteration cost and avoided any early commitment to the look of an area. It also solved the problem of prematurely critiquing art when team members were supposed to be critiquing a gameplay prototype. Finally, it allowed the art team more freedom to experiment with visual themes, since they could do so independent of the gameplay prototypes.

Successful gameplay prototypes and styleguides were used as the basis for building the final levels. Once those playtested successfully, they were handed off to the art team for an art pass. During the art pass, all level designer-created stand-in geometry was replaced by final models. Final materials were applied to the level, lighting was adjusted or recreated from scratch, and auxiliary elements, such as fire, fog, and skyboxes, were added.

Through this process, the playable level was made to more closely match the vision of the original concept art without breaking the gameplay. In practice, though, gameplay did sometimes break in unexpected ways, such as when playtesters refused to walk on a large suspension bridge once a realistically thin-framed model replaced the chunkier, level designer-created predecessor. Because of this inherent dependency between visual design and the communication of game mechanics, the design cabals always held playtests after the art pass to verify that gameplay still worked.

SYMBOLIC LINKS

To allow multiple teams to work simultaneously on a single level without causing stalls, we tried as much as possible to structure our tools around independent files that were connected by a system of symbolic links. Symbolic links are human readable references, resolved at runtime, that both code and content use to refer to another code or content resource. For example, we replaced direct references to raw sound files in our maps with names of entries in a sound script file instead. Each entry in the script file specified such variables as pitch, volume, and random file selection for the sound. This allowed our sound designer to replace or modify sounds without affecting level designers. Before we had symbolic links, level designers had to hand off maps to the sound designer and not work on them until the sounds were finished. Also, by using level-specific sound names for level-specific sounds, the sound designer could change sounds without disturbing other maps.

Our acting sequences used symbolic links to indicate where actors would walk or look in a level. Facial animation, animation blending, and sequencing of a scene’s events could then be authored while another person worked on the world geometry. This technique was also used to script citizen dialogue, allowing our writer to quickly iterate it.

Though these are just a few examples, we pushed symbolic links into as many areas of the pipeline as possible. The general strategy was to increase the number of iterations by specialists by reducing iteration cost, since we believe that more iteration results in a higher quality product. Lower iteration cost also reduced the cost of experimentation, which is really just another kind of iteration. This technique also allowed us to make changes far closer to shipping than previously possible because the interdependencies were removed.

GLOBAL CONSISTENCY

All our chapter designs began with the same core set of design principles, many of which were derived from Half-Life, but some were new. The team wanted to extend the direction of HALF-LIFE without losing sight of what we felt were the things that made it successful. The overarching goal was to create an immersive first-person experience, so we accepted some principles as constraints up front.

Despite the fact that each design cabal followed the same high-level principles, design inconsistencies were a natural consequence of the multi-cabal structure. The designs of the individual cabals reflected the strengths and weaknesses of the various members—therefore each group developed different game mechanics and made different decisions about, for example, the level of difficulty, density of experience, and the relative proportions of combat to puzzles. Our toolset was so large that cabal members tended to prefer designs that used tools they were most familiar with. One team had a rendering specialist, while another had an AI specialist. Some level designers were great at developing combat, while others excelled at optimizing performance. Some were great at authoring terrain, others were best at working with entities, and still others had better artistic sensibilities than the rest. So how did we produce a cohesive game despite all these disparities?

Concept art: Poison zombie

First, we tried to achieve an economical design. Each cabal was encouraged to ask the question, “How well does this element leverage our other gameplay elements?” as a framework for evaluating design choices. This led naturally to a more cohesive experience, since the same elements tended to be used throughout the game.

We used team-wide playtests to expose game mechanics created by one cabal to the other cabals so that they could identify and share the successful game mechanics, spreading them throughout the game. For example, the Ravenholm cabal enabled the gravity gun to interact in specialized ways with particular objects (such as the sawblades). This inspired the Citadel cabal to make the super gravity gun. The energy balls resulting from that work were later used by the Follow Freeman cabal to open the Nexus gates. Later still, they were incorporated into the alternate-fire for the Combine assault rifle.

These team-wide playtests also helped highlight the inconsistencies in other areas, such as quality of visuals, combat, and puzzles and so forth. When one cabal saw that another was producing better work, the two groups were quick to come together and discuss the techniques they were using.

Because certain design elements, such as weapons and monsters, crossed cabal boundaries, it was sometimes hard to change those elements without breaking another cabal’s levels. We solved this problem for weapons by forming a weapons cabal, which comprised representatives from the three gameplay cabals and included both hardcore FPS and less expert players so that the needs of both player types were considered. The weapons cabal’s goal was to produce a varied and balanced palette of weapons, wherein each had a unique function but no obvious best weapon emerged (at least not until we wanted it to). The weapons cabal tuned weapon placement within the game timeline to eliminate clumping and droughts, so players would get a steady flow of new weapons as they progressed through the game. The weapons cabal also worked with each design team to make sure the weapons had an interesting introduction, with enough incentive shortly thereafter for players to use learn how to use the weapon.

Many of our project management decisions were also made with global consistency in mind. The gameplay cabals had weekly reviews with cross-cabal resources (management, art, animation) to help propagate design decisions. These reviews had the goal of helping each cabal operate with similar scope, schedule, deliverables, and methods.

We used comparative metrics where available (how many maps per level-designerweek are you trying to ship?) to analyze each cabal’s output. Code was constantly published—in order for one cabal to use it, it had to be made available to all—and shared as another means of propagating design choices. We did our best to synchronize the deliverables across groups, which increased the effectiveness of team-wide playtests and other cross-cabal feedback mechanisms. It forced the teams to solve similar problems at the same time, and it fostered positive competition. No cabal wanted to be behind or have lower-quality levels when it came time for the playtest.

A SECOND GO AROUND

Even before production began, we planned to do a quality pass over the entire game once we hit alpha to evaluate all our choices within the global context of the game. It quickly became apparent that we would also need to use this second pass to solve consistency problems that had not been solved during the first pass over all the levels. This second pass, which ended up taking only about four months, resulted in a huge improvement in the quality of the game.

At the start of alpha, the game’s quality was fairly variable, and it had wildly varied pacing. Transitions between chapters were often nonsensical, as it was hard for one design cabal to predict what another was doing at the beginning of the adjoining section. There also were fairly large inconsistencies in the level of difficulty from chapter to chapter. Some of these problems were fairly straightforward to fix. Chapter transitions, for example, were trivial to smooth out once each cabal could see what was on both sides of the transition. Of all the inconsistencies, the most difficult one to solve was ensuring consistently high quality across the entire game.

To evaluate the game as a whole, at the beginning of alpha, the entire team took a break from building the game to play through the entire experience, sending feedback for general discussion. As a means of distilling the disparate feedback into a consistent actionable message, a new group called the Cabal Cabal was formed, a team that included one member of all six teams, as well as a few others, and which met daily throughout the weeklong, teamwide playtest to critique, chapter by chapter, the entire game.

The Cabal Cabal’s goal was to provide feedback to the other teams so each could maximize overall quality. The final decision of how to respond to the feedback was left up to each responsible design cabal, with each cabal allocating its resources where it felt the best results could be achieved.

The Cabal Cabal focused its discussions on the high and low points of each chapter. The high points were identified for polish and amplification, as these presented the easiest opportunities to maximize quality. Opportunities for crosspollination of highly popular game mechanics or experiences were noted, which helped us not only leverage our best elements, but also improve our design economy and consistency.

Low points were typically sections of the game that were frustrating, confusing, empty, or simply very rough. Sections of the game that were relentless to the point of being fatiguing were broken up with puzzles or downtime while sections that felt empty were filled with additional content. Some low points were too costly to fix, which led to a final round of cuts. These amputations were really painful because anything cut this late in the project had been invested in heavily. This taught us that the only thing more painful than an early cut is a late one, so it’s best to be decisive in the beginning. But we reminded ourselves that we cared far more about that content than our customers would, since they would only see the final product. It was also comforting to remember that cutting content meant the rest of the game would receive more attention and thus achieve a higher quality.

MULTIPLE ITERATIONS, MAXIMUM GAINS

Many of us were surprised at the large improvement in quality between the game at alpha and the game after we finished our second pass, given the relatively short amount of time it took. We now consider multiple iterations to be a key to Half-Life 2’s success and a mandate for future projects, the major benefit being that it allowed us to make far better decisions.

During the development of both Half-Life and Half-Life 2, we found that decisions made later in the project were always better than decisions made earlier. Some were better simply because they were better informed by the experience we had in making the game up to that point. For example, work on the Citadel began only six weeks before alpha, and unlike the rest of our chapters, we didn’t already have a plan for what major gameplay element was going to be used. The prototype of all gameplay elements in the Citadel levels took a single day, and our first pass on that chapter was finished in three weeks. The reason the super-gravity gun was created was that we knew at that point in development that the gravity gun was a highly successful element in our game. Development was extremely efficient because we knew the engine well enough to choose game mechanics we could implement very quickly.

Other decisions couldn’t possibly be made until later in the project because they required more of the product to exist around them before they could be made. For example, the qualifier “good enough” (and its dreaded opposite, “not good enough”) proved especially elusive during the early production phases of Ravenholm and Nova Prospekt (the first two chapters produced), but became clear and well understood once the game was assembled as a whole. Balancing the level of difficulty as well as maintaining an appropriate pace were two other problems that couldn’t even be addressed until we saw the game as a whole.

Obviously, making certain decisions too late in development can wreak havoc with a shipping schedule. We used time as the primary constraint on how issues could be resolved to avoid this problem. The closer we were to shipping, the less acceptable it became to make changes with broad dependencies. For example, in the prototype phase, new technology or AI could be added, spaces could be defined, and levels could be reordered. After the art pass, changes to the world geometry and the general lighting scheme were constrained. After alpha, the game mechanics, art assets, level progression, characters, and most dialogue were fixed and could only be altered for cases in which the repercussions were isolated and well understood. Our investments in symbolic links really paid off during this phase because it allowed us to make a large number of fairly significant changes with low cost.

FRUITS OF LABOR

Creating Half-Life 2 was a tremendous learning experience for everyone on the team. Behind commercial success, perhaps one of the more creditable signs that our process succeeded is that everyone on the team is genuinely proud of the product we created, and excited to repeat the process. Hopefully some of the many lessons we learned creating Half-Life 2 are generally useful and could be applied to other projects. Here are some of those lessons that we feel are most important:

Decentralize your design.
2. Make rough, but global decisions early (weapons, story, basic monster behaviors). With investment comes constraints; minimize investment until you hit critical mass of quality, then iterate until good becomes great.
3. Don’t design using theoretical mechanics. Validate designs first using prototypes. It doesn’t have to look good at all (use “orange” maps) and perhaps can be prototyped in your previous generation technology.
4. If you have a one-year schedule, try to reach alpha in eight months to give yourself a few months to iterate your design anew. In our experience, every week of work after alpha is worth well over four weeks of work prior to alpha.
5. Create demanding customers for everyone on your team—it’s a great technique for improving efficiency and prioritization.
6. In the traditional tradeoff of scope, quality, and time, reduce scope to get better results through iteration.
7. Attempt to reduce pipeline stalls by carefully thinking about where those stalls occur in your production pipeline.
8. Use symbolic links to eliminate pipeline stalls and allow as many low-cost late changes to your work as possible.
9. Processes are cheap and disposable— try to measure how they are succeeding or failing to achieve game and company goals. Don’t be afraid to change a process if it stops working.（source：Gamasutra）