半条命系列的设计过程
翻译 by puz（H3D）
半条命 1 设计过程 -‐-‐-‐ CABAL 过程 2
1），体验密度(experiential density) 2
原文在 http://valvesoftware.com/company/publications.html 寻找。翻译中有很少一部分太 单机相关的内容略过。
半条命 1 是 VALVE 公司第一个产品，也是一个本来要废弃的产品。1996-1997 年 VAL VE 为自己第一个游戏购买了 QUAKE 引擎，并花了 1 年制作了一个 QUAKE 增强华丽版游 戏。在 1997 年 9 月底，制作了 1 年之后，半条命制作团队发现游戏一点也不好玩。这时离
预定上市日期的 1997 年 11 月没有几天了。 游戏虽然有很酷的怪兽，但是不按预定方式与之战斗，怪物就变为了蠢货。 游戏也有
一些很酷的关卡。但是它们放在一起非常不协调。游戏还用了一些很酷的技术，但是在游戏 中只会出现 1-2 次之后就看不到了。游戏无法让人从始至终地一直玩下去。虽然有一些非常 好的闪光的碎片，但是整个游戏就是不太行。
显然，这个时候应该再多 1-2 个月，把一些最糟糕的问题解决掉，然后就这个修改后的 版本赶紧发行。但是结果谁都能想到，那会是个糟糕的产品。也根本不会是制作团队想要的 东西。由于 Valve 公司比较独立，不会由于发行商的一个念头左右生死。在评估 1-2 个月内 无法做出实质改变后，团队做了个非常痛苦的决定 --- 从头来过，重新进行游戏制作的所有 阶段。
于是团队建立了一个小组。把游戏中所有有价值的部分都提取出来，做成一个独立的关 卡原型。当关卡变得有乐趣后，逐渐加入更多的变化。如果这个原型需要一些软件技术特性， 小组就简化这个特性直到几天能够完成它放入关卡。小组的人花了一个月一起完成这个关 卡，这段时间其他人基本上就什么都不做。当关卡完成后，所有人玩了一下，发现找到了方 向。这个游戏，规模会非常大，玩起来非常恐怖，需要巨大的工作量。除了看到这个，团队 没有什么其他可以让自己满意的了。团队需要再做 100 多个这样有趣程度的关卡。他们认为 可以做到。
接下来团队对那个新做的关卡原型进行了分析，以找到这个关卡为什么有趣的原因。主 要有 3 点理论。
1）， 体验密度(experiential density)
体验密度定义为：在玩一个关卡时，单位时间单位面积中，游戏中发生的事件和玩家可 以操作的事件的总和
体验密度的目的在于，一旦开始活动，玩家不应该在两次刺激之间等待太久。刺激点诸 如怪物，特殊效果，情节点，动作序列播放等。所以游戏内容放置是基于距离放置，而不是 基于时间的。这些内容在玩家可控范围之外时，是不会激活的。当玩家希望更多操作和行动， 他只用不停的往前走就可以了。只用走一小会，肯定就会有什么事发生。
2）， 用户反馈(player acknowledgment)
顾名思义，当用户做了任何操作时，游戏世界都应该给予相应的反馈。类似玩家射击， 游戏世界中应该留下弹痕等。
用户反馈（认知）理论为：如果游戏世界忽略玩家行为，玩家也不会在意游戏世界。
（用户反馈是游戏体验核心，游戏设计中已经是常识也是重中之重。此篇文章写于上世 纪 90 年代，机器硬件不足以在视觉给出足够体验，所以要特此强调。并且提到的都是 3D 渲染与物理反馈。这个理念也是导致半条命 2 成为第一个成功基于物理引擎制作玩法的游 戏。 By puz）
比如用户推什么东西，这个东西要动。用铁管砸什么东西，被砸的东西要断裂。玩家走 进一个有其他 NPC 的房间，其他 NPC 应该感知到玩家，至少 NPC 眼睛应该看着玩家。
这个理论意思是，当用户失败，应该总是让用户埋怨自己。而不是游戏。 假如一个玩家在没有得到任何警告提示的情况下被杀，玩家会责备游戏并且开始讨厌这
个游戏。但是如果游戏在危险来临前提示用户，并且给用户指出一条逃生的方法。那么这个 玩家不管什么原因死亡后，只会责备自己玩的不好。接着继续努力破关。当努力成功后，游 戏会用一些特效或者一段镜头脚本奖励玩家。这样玩家对自己和游戏都会满意。
（无论什么游戏，游戏关卡都应该让玩家有“哦这个游戏有点挑战，但是我只努力了一 下集中了一点注意力就战胜了，好爽”的感觉。 By puz）
（Cabal 直译为阴谋集团，代表含义是半条命游戏策划是靠一个集体决策的组织来形成 的，以下作为专用语不加翻译。By puz）
Valve 花了 11 个月寻找理想游戏策划，但没有找到。最后决定建立一个团体，由公司 中不同专业的人共同组成。（这也就是 1997 年 9 月下旬，发现游戏做出来了，但是不好玩那 个时候才开始组建）
这个团体的目标是创建完善文档，用于详细描述所有关卡，主要怪物的交互，特效，情 节，以及设计标准。CABAL 团体要决定“何时”以及“如何”给玩家呈现每个枪械，怪物 和 NPC。玩家应该掌握什么技巧，游戏应该如何教会玩家。正如“阴谋集团”这个称谓一 样。开发团队认为 Cabal 过程非常成功，是半条命成功的关键要素之一。
Cabal 会议是半组织形式的头脑风暴会议，专注于游戏某个特定部分。在每个会议中， 会有一个人专门负责记录会议内容，写出游戏设计。让另外一个人来绘图，来解释布局和其 他一些细节。一个 Cabal 会议往往由几天的讨论组成，混合了从游戏某部分的高层概念讨论， 到一些具体的有趣特性和关卡事件的讨论。
会议产生了足够的点子后，团体会把这些重组成一个粗糙的故事线和年代表。当这些都 搞定后，会创建一份说明，和一张绘制几何图形的草图。在草图上会标记出关卡中会发生的 关键事件和发生地点。如图：
团队还发现把一些并不关联的特性放在一起，比如一些特殊技术，一些已经做好的网格 物体。为了让他们联系起来而做的创造性工作往往效果很好。
在 Cabal 会议期间中，每个人都有所贡献，但是并不是每个人在每天都能贡献。开会非 常累人，常常有一半人，在连续 2 到 3 个会议中都坐在那里一言不发。但是之后有人突然看
到一个其他人没看到的方向，于是成为下 1-2 个星期会议的主要贡献者。为什么发生这种情
况还不知道原因。但是要至少保持每个会议有 5-6 人比较好。这样不会因为没有新点子输入 而让会议卡壳。
Cabal 团体每周会面 4 天，每天开 6 小时会，这样进行了 5 个月。然后断断续续的召开 直到项目尾声。每天只开 6 小时会的原因是，6 小时会议之后人都会极度疲惫。
初始 Cabal 团队组成为 3 个工程师，1 个关卡设计师，1 个作家，和一个动画师。组成 人要求有丰富产品经验。团队只包含真正在游戏中制作东西的人。没有专职策划。团队每个 人都要设计。
起先 Cabal 之外的人对这个形式是有怀疑的。个人的自我/自负是否能够被超越，从而 集体得到一些有用的设计。以及是否游戏会被多人集体打磨成没有闪光平庸的东西。但结果 正好相反。 参与其中的人已经厌倦了隔离状态的工作，他们被合作过程激励，从而得到了 很好的结果---始终保持着着精良和有深度的设计。
在团体内部，一旦 Cabal 过程得以成功，一个“mini-cabal”组建起来，用于解决各种 设计问题。Mini-cabal 团体的人具有高效的决策能力，又能保持对事物新鲜的视角。
同时，始终保持 cabal 人员的流动。每个月都流动一些成员。每个月，保持上次会议成 员的一部分，然后补充一些新鲜的人员。人员都是公司各部门的人。以保证参与过程的每个 人都有使用 cabal 过程成果的经验。
Cabal 过程最终结果 ，是一个超过 200 页，记录了游戏所有细节的文档。包括从 high-button 应该什么样子，到每个关卡都是一天中的什么时间，等等。文档包括了所有关卡 的草图，以及这个关卡需要的新技术，声音，动画等工作项列表。
团队专门设置了一个人跟踪整个故事线和维护整个文档。最后因为有 30 个小时的电影 情节设计，团队找到一个专业作家来完成游戏的故事。
Cabal 过程工作 3 个月后，已经有了足够的素材进行游戏测试。一个测试会议由一个测 试人员（志愿者）玩 2 个小时游戏。坐在测试玩家后面的是 Cabal 里负责这个关卡区域的人，
和相应关卡设计师，偶尔也会有 AI 程序。 观察者在过程中不允许说话，只能记录。有时候就干瞪眼看着玩家在某个地方卡 20 分
钟。而不能提出“显而易见”的办法。显然，这里的设计是一定有问题的。 测试也是解决团队不同意见争执的最佳办法。大家都会意识到，个人的主张在下一轮玩
家测试之前，没有什么意义。玩家终会告诉你，你的设计是否真像你想象得那样有趣。以及 为什么无趣。
一般 2 小时的测试，会带来 100 条左右的工作项 --- 为游戏修改和增删的条目。开始的 20-30 次玩家测试极度关键。它教会了 valve 作为一家游戏公司，什么元素是有趣的，什么 是无趣的。整个项目有 200 多次玩家测试。一半测试是重复玩家。玩家测试的结果会返回 cabal 过程。使得提前把不好的东西去掉，然后集中精力制作好的部分。
在项目中期，主要元素加入游戏中后，游戏关卡能够被大部分玩通过。设计优化变得很 重要。一些基本统计功能加入游戏。包括玩家血，位置，武器，时间，和一些主要行为，包 括存盘，死亡，被打，解决谜题，和怪物干架等。然后把数次测试的数据拿出来绘制成曲线。 来查看问题。这些问题包括，玩家在一个区域太长时间没事情做。太长时间血量一直很多（太 容易），太长时间血量一直很少（太难）等。这也给设计者提供了一些主意，比如更容易在 哪里死亡，哪个地点更好加一些补给等。
另外一个对 debug 帮助很大的功能是保持存盘格式的一致性。多个引擎版本也能使用同 一个存盘文件。这样当崩溃时，很快可以复现问题。
通过 cabal 过程，团队得知一个新特性技术（3D 技术）要得以在关卡中普及应用，写 好代码只是事情的一小半。还需要整条流水线以支持关卡制作人员（贴图 特效 网格 关卡 等）利用好技术。
（忽略一部分制作相关信息）
并不是所有人都适合 cabal 过程。至少不适合 cabal 初期的过程。比如有太强个性（攻 击性，与人合作难）的，口头表达能力不行的，不喜欢创意思维的，都不用迫使他们进入 cabal 过程。 团队倾向找有过团队设计经验的，有游戏设计经验的人。
尽管如此，到最后几乎每个人或多或少都参加过某个 cabal 过程。Cabal 过程越顺利， 就越能够让更多人加入。
Cabal 过程让所有人参与创造过程，每个人都对游戏设计做出贡献。一旦每个人都为游 戏贡献了设计，这些设计就不再是每个人拥有的单独部分，而是整个游戏设计成为了“大家 的”。
这个“大家的”概念延展到每一个游戏关卡。每关至少有 3 个不同设计师参与制作。有 的关卡甚至所有人都参与。关卡师样样通，建模 ，放置怪物和 AI，贴图后打光等这些工作 经常交换进行。这样带来很大好处。不会给整体制作带来瓶颈。
这个“大家的”概念也延展到代码，贴图，建模，动画，音效等领域。在代码管理下， 每个人都可以对游戏进行修改。每天都会有一份修改记录，谁改了哪些内容都会记录。进行
用户测试时，只测试修改过的内容。这有助于监控进度，更好地评估一个组件的稳定性和完 成度。同时帮助系统地给游戏加入新特性而不产生冲突。
不管怎么强调团队主动性，半条命中大多数的核心特性都是个人创造力的结果。关于游 戏应该是什么样子，或者必须做什么，每个人都有自己的想法。Cabal 过程让这些想法被大 家听到。在这个过程中，任何人提出的一个设计想法都有可能被接受。这就给了参与者他们 想得到的最大权利。如果一个人提出的想法需要另外一些人来实现，或者想法与其他人有冲 突，那么提出想法的人必须启动一个 Cabal 过程，去说服那些对这个想法实现很关键的人。 在开始时，这个过程非常容易。因为所有人都低估了要实现当初做的那些决定的工作量。
到了项目中后期，那些不好的（破坏力大）的决议就会越来越难推行下去。这也帮助过滤掉 一些对设计的改变，只保留用最少工作就可以对最多玩家造成影响的设计。
通过持续的玩家测试，收集反馈，回顾检查，和编辑，Cabal 过程成为一个关键步骤， 用于去掉游戏中不符合质量预期的部分。不管制作者对砍掉内容多么有感情，他们可以很理 性的接受。这个过程很自然的规避了在那些更多层级关系的组织中，由于个人固执己见发生 冲突的情况。通过玩家测试，问题解决方案往往可以达成一致。或者至少是由单独的平等地 位的人提出来。所以不存在那种需要反抗的权威。
在日常开发中，即便是一个 200 页的文档，也无法回答所有开发中碰到的细节问题和开 发中产生的数不尽的创造性点子。任何设计文档，都只是一个框架 。开发工作从它起始， 并且在多人开发过程中不断增添可能性，并且成为无缝衔接的整体。Cabal 过程帮助在团队 中传播这个游戏的整体感觉（big picture）--- 最关键的是要大家都对游戏有清晰的感觉，而 不是基于文档文字的模糊认识。同时 Cabal 过程也帮助最大化个人能力，最小化个人弱点。 它建立一个框架，使得个人得以最大化对游戏内容产生影响。在半条命中很少有某个区域少 于 10 人的直接工作。
在一个高度组织化的组织中，为了高效，一个部门必须有一个人懂得其他人所有工作， 至少他可以象其中一个人一样好的工作。其他人乐于作为下属，同时依然要足够好，去实现 游戏设计。对于一个复杂游戏开发，这一点并不现实。假如你和上级一样好，为什么甘愿为 下属。反过来，在一个极度无组织的团体中，信息传递和控制都是极为困难的。大家个干个 的，工作很难统一。
（对于复杂游戏的高度组织化开发，作者有个假设，就是大家都是专家。在创意行业人才环 境相对充裕，同时行业比较发达的情况下，有这个可能。比如国外 3A 级单机游戏行业。不 过对于游戏研发历史最多 10 年的天朝，以及儒家文化的亚洲（日本），开发大型复杂游戏一 般需要高度组织化的生产，以便于少数专家带领大多数水平一般的从业人员开发对创意和质 量要求并不那么高的产品。或者以集体主义精神和长幼尊卑等级观念，来弥补个体创造力和 专业能力的不足。尤其创造力。对于中国，创造力和专业能力 2 者都要弥补。所以在 valve， 是靠非常重型和工程化的“玩家测试”来解决扁平组织中意见不统一的问题。 这也基于参 与 cabal 的人员自己都具备高度的职业水平，创意，团队创意经验，深厚产品开发经验的。 前面对于 cabal 人员选择有讲。 译注 by puz）
在 Valve，Cabal 过程取得了巨大成功。虽然团队依然受到太大野心，有时太多不切实 际的期盼等困扰。但是最终这些都被摆平，由 Cabal 过程得到了优化的妥协方案。由于项目
最初的失败，和最终超过预期的成功。即便是当初对 Cabal 最怀疑的人也加入了支持行列。
会议要包括所有领域的专家进行讨论。不要浪费在一个大家都不是专业人员的话题上。
把所有会议内容记录下来。头脑风暴得到的好点子如果不写下来过几天就会被忘记。文 档应该尽可能多的记录，尤其记录对于那些要开展工作提出问题的答案。
不是所有的主意都是好主意。这些不好的主意也可能是你提的。如果你自认为一个特别 棒的点子被大家认为很傻。就不要强行推进了。如果你推进，那么其他人就可以强行 推进自己的。这样就进入了僵局。 也许这个主意只是被提错了地方。留到下个会议， 或者游戏其他部分的讨论时再提出。
在一个游戏测试之前，只基于已经完成，或者你肯定将会被及时完成的技术工作，来进 行计划。基于一个未被完成好的技术特性来设计是没有用的。如果实现一个设计的技 术工作无法完成，那么砍掉这个设计。越早越好。
避免在整体游戏中，一个技术特性只被使用 1-2 次。技术开发很慢。如果一个需要 1 个
月才开发完成的技术特性只被使用 1 次。这是对有限资源的浪费。技术人员的目标总 是希望创建的工具和技术能够在游戏中到处使用。如果一个月的技术工作能够提高每 个人的生产力，那就是成功了。如果一个星期的工作只在游戏中出现 10 秒钟，那么就 是浪费。
Ken 有 15 年的项目经验。主要完成半条命中的动画和 AI 工作。之前的工作包括卫星 网络，密码学，3D 假肢设计工具，3D 表面重建等。他放弃电子工程学位转而学习艺术学位。 因为 Ken 觉着比起愚蠢的微分方程课程，艺术学位与创造性思维更有关联。
PPT 演示翻译
明显的后验性 --- “当我看到我才知道” 有很多种解决方案
主观的 直接分析的挑战
定义目标和约束 想出一个主意来满足它们 做一个试验来检验这个主意 评估试验的质量 评估主意的质量 评估目标的质量 重复以上过程
正确的态度 良好定义以及可测量的目标 经过很好沟通过的目标
是否是小众产品 是否有很大市场
良好设计的测试
“产品焦点”帮助定义好的目标
关注产品质量（Care more about the quality of the product than your particular contribution to it） 以用户体验来过滤目标
好的用户体验等于成功
目标：有乐趣的游戏 主意：游戏设计 玩家测试：试验 玩家测试结果：评估游戏设计 重复以上过程
QA？
平衡？ 焦点测试？ 乐趣？
玩家得到了你设计的体验么？ 你设计的体验令人满意么？
研究那些影响用户体验的要素 游戏代码/NPC 行为
特效 环境 音效 教学 节奏 难度
玩家测试现场
! 确保测试内容的设计者参与测试 简化评估
优先级 动机
! 模拟玩家在客厅的情况 不给任何提示 不回答任何问题 不提供外部奖励
! 使用外部测试人员
! 询问玩家
不要过多依赖提问 往往玩家没有体验到的东西比较有意义 询问不带诱导性的问题
! 通常发生在产品生产后期 解决最糟糕的设计
! 晚期测试一般意义不大 做实质性的修改太晚了
使用玩家测试的结果驱动游戏开发 创建 15 分钟的粗糙 可玩原型 玩家测试
使用测试结果来确立下周工作的优先级 重复直到完成
当玩家测试看起来不那么痛苦后，我们也觉着 OK 了
粗糙原型与最终产品
不要让一些假设来妨碍玩家测试 不一定是问题 如果是，玩家测试会给出解决的优先级 玩家测试会产生解决方案
不要担心画面
美术风险远比游戏性小
对于学习非常有用 容易衡量一个元素增长价值或者危害 避免设计上的争论 使用测试结果来驱动产品开发的各个方面
玩家测试出的问题可以迭代解决 正确的优先级
寻找合理走向
不要过于完美化 不要摇摆不定
完成一个成功的游戏要素后再进行下一步
产品级的好处
建立起一个特定的质量体系 针对游戏关键特性，研究游戏设计方面的风险 针对最成功的游戏要素进行优化 度量风险，速度，成本
Pre-production 阶段，建立初始产品方向 故事
美术概念，风格 主设计概念 NPC，枪械，汽车 章节主题
创建游戏原型地图
有些游戏发行时的主要游戏元素是在 pre-production 之后开发的
用新的方法重复使用过去成功的游戏元素
解决跨部门的问题 有些突击队在整个项目期间都存在 “武器的 Cabal 组织” 更多突击队是临时的
一个游戏设计团队使用了另外一个团队的游戏元素 在一个被良好测试的地图上做出的决策，作为一种约束
在 alpha 阶段整体评估产品质量 产品优缺点在所有设计团队中沟通
基于整个公司对产品的反馈 由所有设计团队和美术/动画/音效团队的成员组成 设计团队负责处理反馈
修改和删除由独立的设计团队驱动 所有修改都在 alpha 阶段完成
在 alpha 阶段应该做什么修改 不要引入新的核心游戏元素 无情的删除最糟糕的问题 如果必要，用已有的游戏元素来增加“体验密度”
有些东西需要等到游戏完成才能够测量
游戏节奏 难度曲线 多样化
章节与章节之间的一致性
工程化的过程可以用于游戏设计
让产品团队驱动游戏设计
让玩家测试驱动游戏产品开发
• Allow for a final iteration over your entire game once it’s playable from beginning to end
Valve 公司的一系列产品，半条命 1，2，portal， counter strike 都是里程碑似的作品。 在 FPS 游戏史上举足轻重。并且叫好叫座。名利双收。其公司游戏开发方法论从半条命 1 开始，一直贯彻并深化发展。后续又造就了半条命 2 和 PORTAL 这样依旧具有革命性创新 性的产品。和前面章节所描述的游戏设计方法密切相关。
随着手机游戏兴起。讲究单局游戏乐趣的类单机游戏体验重新又回到游戏制作的主流范 畴。日本卡牌+手动操作单局游戏形式风靡后，由于契合移动游戏体验方式，得以快速发展。 随着移动硬件性能快速发展，移动游戏的 3D 化，高端化，重型化也得到极大发展。是今后 移动游戏开发的趋势之一。而随着 unity3d 等移动 3D 游戏开发工具的成熟。10-20 人团队也 有可能开发出大受欢迎的移动游戏产品。这摆脱了过去动辄几十人上百人的 PC 网络游戏开 发模式。使得中小型团队创造力和生产力得以极度发挥。移动游戏生命期短，市场竞争激烈， IOS 渠道狭窄，安卓平台极度分散。这对产品开发速度和质量都有较高要求。只有品质非常 优秀的游戏，具备一定创新性，才有可能杀出重围在十几万款手机游戏中脱颖而出。手游开 发成为一个整体团队身心高度投入，快速生产，并且对创造力有一定要求的开发过程。
而 Valve 公司一直采用的 Cabal 过程，有极大借鉴意义。
Cabal 过程简单而言就是由一个跨部门的极端扁平化设计小组集体决策游戏设计，尽可 让团队参与开发的人轮流参与其中。通过极为频繁和强度很大的玩家测试步骤，来驱动设计 的决策和产品开发。通过 Cabal 这种极端扁平化的组织，和头脑风暴会议，尽可能发挥成员 所有人的创造力，来提高游戏设计质量。用玩家测试来保证游戏设计的正确性和游戏性。
虽然 Cabal 过程是针对单机游戏，基本是按照单机体验，顺序过关，玩遍所有关卡的模 式来进行游戏设计。但是对当前移动游戏设计有较大共通之处。
手游目前主要形式，粗略的分，
1 是以简单有趣但有操作深度的单机单局玩法为基础（很多近似过去掌机街机等形式，
特点为一局时间较短，几分钟。或者一些创新的动作/策略等）。
2 是以卡牌形式的角色/装备升级数值玩法配合极简单局表现。
3 是一些适合移动的客户端游戏移植（策略，RPG 等）
4 是一些重型 PC 游戏移植（比如 FPS，MMO） 由于移动游戏进行基于网络同步链接的多人游戏比较困难。所以绝大多数游戏在实质单
局游戏时，都是摆脱网络进行的。这就让移动游戏的核心玩法重新回到了单机形态。在其基 础上建立异步交互的游戏机制。
所以移动游戏研发，很大程度上是基于单机玩法的游戏制作。由于机能限制，游戏研发 的重点并不在于技术研发（不靠高端深入的软件技术提高游戏性），而是在于游戏设计和内 容制作。而这一点恰恰是 Valve 公司 Cabal 游戏制作过程针对的目标。
如何对 Cabal 方法进行改造，使之适合中国国情，是一个有挑战性的工作。
最重要应该是调动团队对要制作目标的热爱和参与感。发挥个人能动性与能力。允许犯 错，允许在一定范围个人自主发挥。
参考 Cabal 过程。建立集体决策，快速生产粗糙原型，制订依靠频繁测试检验游戏性、 找到解决方案和优化游戏设计方向的工程方法。
要明确和解决：
1 基于原型迭代测试的方法。
2 游戏设计的集体讨论决策模式。
3 最小增量开发迭代模式
4 集体决策过程中一些扁平化带来问题的收集和解决方案。
4 非 FPS 过关单机游戏，尤其有成长的数值手机游戏，从试玩中也许较 FPS 难得到很明确 的问题反馈，和解决方案。数值体验的感觉，也很难通过玩家采访得到相对准确定性和定量 的结论。