游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

深入分析Valve创造《半条命》的设计过程

发布时间:2014-09-24 11:10:23 Tags:,,,,

作者:Ken birdwell

尽管《半条命》获得了巨大的经济成功(游戏邦注:获得了年度50款游戏大奖并在全球范围内卖出了超过100万份),但是有些人注意到,它并不是一开始就是赢家—-实际上,Valve在游戏上的首次尝试惨遭失败。说得好听点它只是一款中等的游戏,并带有折磨着许多游戏的经典问题。本文将讨论如何把我们最初关于《半条命》的看法变成开创性成功的团队工作,或者说是“阴谋的过程”。

用良好的心愿铺平道路

我们最初所设定的发行日期是1997年11月—-即游戏实际发行的1年之前。这一日期将让Valve拥有1年的时间去开发神奇的Quake TC(这是一次彻底的转变—-全新的网络,全新的关卡)。到了1997年的9月末,即接近我们最初时间表的最后日期,我们已经完成了许多工作,但仍存在一个主要问题—-游戏并不是很有趣。

是的,我们拥有很酷的怪兽,但是如果你不能基于我们所计划好的方式与之进行打斗,这便只是一些愚蠢的内容。我们拥有一些很酷的关卡,但是它们未能有效组合在一起。我们拥有一些很酷的技术,但多情况下,这只是出现在1,2个场景中。所以你不能一直顺畅地玩游戏,所有的这些关卡都不是有效地整合在一起,在游戏的大部分内容中还存在一些严重的技术问题。虽然存在某些有趣的个体内容,但从整体上看游戏是不可行的。

最明显的答案便是继续致力于游戏开发几个月,解决所有的问题并最终将其发行到市场上。对于依赖于发行商的公司来说,这真的是最常见的发展路线—-带有可预见的结果。因为Valve是非常独立的,我们中的任何人也都不相信自己能够创造一款我们所有人都喜欢的游戏,所以我们不觉得1,2个月会有什么不同。所以这时候我们必须做出一个艰难的决定—-我们决定重新开始并修改游戏的每一阶段。

birdwell(from gamasutra)

birdwell(from gamasutra)

幸运的是,游戏中拥有一些我们所喜欢的内容。我们分配了一小组的人去识别出游戏的任何工作状态中所存在的每一个愚蠢的理念,每一个很酷的方法以及每一个有趣的内容,并将其整合到单一的原型关卡中。当关卡开始变得有趣时,他们便会添加更多不一样的有趣内容。如果一个理念并不有趣,他们便会将其删除。当需要一个软件功能时,他们便会简化它直至能够在几天内完成这项内容的编写。他们会花一个月的时间共同致力于这个小小关卡中,而剩下的我们则不需要做任何事。当他们完成工作后,我们全部人都会开始玩这一关卡。这真的很棒。这是一种愿景。这将变成我们的游戏。虽然这需要他们投入大量的工作,但在看到该关卡时,我们都非常满足。我们所需要做的便是创造超过100个有趣且没有问题的关卡。

所以,跟我说说你们的童年

阴谋前的过程中的第二步便是分析你的原型关卡的乐趣是什么。我们相处的第一个理论便是“体验的密度”理论—-发生的的以及玩家在每个时间单位和地图上的每个领域所做的“事情”的数量。我们的目标是,在下一个刺激物(不管是怪物,特别的效果,情节点还是行动后续等等)出现前,玩家不需要等待太长时间。因为我们不能真正将所有的这些体验带给玩家(游戏邦注:不间断的系列内容只会让人觉得无聊),所有的内容都是基于距离而不是时间,任何活动都是从玩家的控制中开始。如果玩家想要更多行动,他们需要做的便只是向前移动,如此在几秒钟内便会有事情发生。

我们想出的第二个理论便是玩家承认理论。这意味着游戏世界必须在玩家每次执行一次行动时承认他们。例如,如果他们在射枪,世界便需要通过一些比声音更为永久的内容去承认它—-可以有一些视觉上的证据去证实他们刚刚开枪了。我们可能会喜欢在墙上凿个洞,但是基于技术和游戏流,我们真的不能这么做。相反地,我们应该选定“贴标”—-所有表面的子弹痕迹和爆炸记号,这将作为行动的永久记录。这同样也意味着如果玩家推动某些可推动的事物,那么该对象不应该忽视他们,而是应该移动起来。如果他们使用铁锹击打某物,该对象就应该出现破裂。如果他们进入一间还有其他角色的房间,那些角色至少应该看着他们去成人玩家的存在(如果不叫他们的名字的话)。我们的基本理论便是,如果世界忽视了玩家,那么玩家也不再会在乎世界了。

最终理论便是玩家应该始终因为自己的失败责怪自己。如果游戏毫无警示地杀死他们,玩家便会责怪游戏并开始讨厌游戏。但如果游戏暗示危险的来临,并呈现给玩家逃离的方式,那么即使他们牺牲了,他们也只会将过错怪在自己身上;他们让游戏失望了,所以需要更努力地进行尝试。当他们获得成功时,游戏将会给予他们一定的奖励(游戏邦注:可能是基于脚本的续集,特效等等),他们也会因此更加喜欢自己和游戏。

地下组织

在项目最初的11个月中,我们一直在寻找一位正式的“游戏设计师”—-能够露面并将所有的内容整合在一起的人。我们着眼于无数简历并面试了许多应聘者,但却没人拥有我们所需要的特质。最终,我们得出一个结论便是,根本不存在这样理想的人。相反地,我们应该通过整合公司每一部门的优势,并将其集中在一个所谓的“阴谋”小组中而创造我们自己的理想型。

这个小组的目标是创造一个能够表明所有关卡,主要怪物互动,特效,情节设置和设计标准等细节的完整文件。该小组将制定每个怪物,武器,以及NPC的出现时间和方式,以及我们希望玩家拥有怎样的技能,我们将如何教授他们这些技能等等内容。虽然这听起来让人害怕,但这的确是我们所做的事。我们认为“阴谋”过程将取得巨大的成功,而这也将成为《半条命》成功的重要元素之一。

“阴谋”会议是半结构化的头脑风暴会议,经常致力于决定游戏的一个特殊领域。在每次会议期间,一个人将负责工作记录并详细描写设计过程,而另一个人将负责通过绘图去详细解释布局和其它细节内容。“阴谋”会议通常有几天是为特定领域想出一个高级别的理念以及听起来很有趣的特殊事件。

一旦创造了足够多的理念,它们便会被重新整合到一个较为粗糙的故事线中。一旦完成了这一工作,几何结构的描述和草图便会诞生并与所有重要事件以及发生场所标记在一起。我们在一开始便知道在某些游戏领域我们想要看到什么,但很多时候其它领域总是作为“户外”或“一些拥有大怪物的地方”。其它领域的创造并不需要游戏中的一个特殊点。在几周时间里这些设计可能都是悬而未决的,直到我们清楚地看到它们是不合适的,或者它们能够维系起两个不同的领域。还会诞生其它部分去突出一个特定的技术功能,或者只是提供给游戏整合一块在前期“阴谋”试验中所创造的集合结构的理由。说来也奇怪,当尝试着去匹配这些人工常数时,我们总是能够创造出最棒的内容。我们最终将习惯于放置一些无关的要求到每个领域中,然后竭尽所能地想出一种合理的方法将其组合在一起。通常情况下,在会议的最后我们将发现最初的理念不如我们围绕着它所创造的所有组件有趣,即使没有最初的理念,我们所设计的用于解释它的结构也能够更好地运行着。

在“阴谋”会议中,每个人都会做出贡献,但我们发现并不是所有人在每一天都能带来贡献。这些会议很累人,我们想着可能大概有一半的人在经历了2,3次会议后仍没有任何想法,但是突然间便会看到其他人所看不到的方向并成为剩下几周时间的工作贡献者。为什么这种情况如此不清晰,但是重要的是每次会议都必须拥有5,6个这样的人,如此才不会因为缺少输入内容而导致会议的停滞。

“阴谋”小组每周的会面是4天,每天6个小时,这种情况一只会持续5个月,直到项目最终结束。媒体的会议只维持6小时,因为在6个小时后,所有人不管是心理还是生理会开始疲惫。在这期间,所有参与者并不能做任何其它工作,他们只能阅读邮件并编写每天的笔记内容。

最初的“阴谋”小组包含3位工程师,1位关卡设计师,1位作家和1位动画师。这代表了Valve中的所有主要小组的组合以及项目的每个方面,并倾向于带有最多产品经验的人(不一定是游戏经验)。“阴谋”小组只包含那些真正在游戏中发行过组件的人;不存在特定的设计师。“阴谋”群组中的每一位成员都是那些想要真正完成自己的设计任务,或者至少有能力完成这些工作的人。

birdwell(from gamasutra)

birdwell(from gamasutra)

“阴谋”过程的前几个月对于那些过程外部的人来说蛮痛苦的。目前我们还不清楚为了完成某些事情能够将尊严死死地压在脚下,或者游戏的愿景能够滤过许多并不乏味的人。结果显示,相反的情况才是对的;参与者将会因为在封闭的状态下工作而疲惫,并会受到合作过程的激励,从而优化了最终的设计和深度。

从内部看来,如果“阴谋”过程的成功很明显,那么将会出现迷你“阴谋”小组去想出各种设计问题的答案。这些迷你“阴谋”小组将包含最受决策影响的人,并尝试着包含问题外部的人,以确保他们拥有看待问题的全新视角。我们同样也努力保持最初“阴谋”小组的成员资格足够灵活,并且每个月都会贯穿过程快速变换成员,当然了,也总是会留下一些前期成员。这能够避免成员热情的耗尽,并确保所有过程的参与者都曾使用过“阴谋”小组决策的结果。

最终结果便是一份超过200页详细描述游戏所有内容(包括高处按键应该怎样设置以及它在任何关卡中的使用时间等等)的文件。这包含了所有关卡的粗略图纸,以及这些关卡所需要的任何技术,声音或动画的内容清单。

我们最后分配了一个人去关注着整个故事线以及维持整个文件的完整性。这一设计就像一部30个小时的电影,所们最终创造了比一个休闲基础更多细节的内容。我们发现在这一过程中拥有一个专业作家的重要性。除了能够往我们的角色中添加更多个性,他在记录主题结构,情节变化,节奏和一致性的能力真的很有价值。

珍珠头在猪猡面前

直到“阴谋”过程的第二个月,我们已经拥有足够的游戏设计能够开始某些领域的开发。而在第三个月,我们拥有足够内容能够组合在一起并开始进行测试。

游戏测试过程包含一个外部志愿者将玩游戏2个小时。来自致力于该游戏领域的“阴谋”小组的成员以及负责被测试关卡的关卡设计师将做在他后面。有时候,如果测试的是AI的话,后面还会坐着一名工程师。

除了为他们打开游戏并在崩溃时重新设置,来自Valve的观察者不能再说任何话。他们必须安静地坐着并记笔记,不能提供给测试者任何暗示。没有什么比安静地看着游戏测试者在你的关卡中跌跌碰碰20分钟还不能走出来更郁闷了。

这也是解决任何设计争论的一种肯定的方式。显然你所提供的任何个人选择并没有任何真正的意义,至少在下一次游戏测试到来前是这样的。只是因为你确信一些可能变得有趣的内容不一定真的会这样;游戏测试中可能仍会呈现并证实你的看法大错特错。

典型的2小时游戏测试将创造100个“行动项”—-需要被修改,添加或从游戏中删除的内容。前20或30次游戏测试将教会我们作为一家公司什么元素是有趣的而什么又是无趣的。在整个项目过程中,我们最终执行了超过200次的游戏测试,并且有一半的测试是由重复的玩家所完成。来自测试的反馈将被带回“阴谋”过程中,让我们能够先发制人地删除那些不能有效运行的设计,并详细说明那些可行的设计。

在接近项目中间段时,一旦敲定了主要元素并且我们可以基于大多数方式玩游戏,那便主要是调试阶段的问题。为了做到这些,我们添加了基本检测仪表到游戏中,自动记录玩家的位置,生命状况,武器,时间以及任何主要的活动,如保存游戏,思维,受伤,解决一个谜题,与怪物打斗等等。然后我们将从多个过程中获得结果并将其组合在一起寻找任何存在问题的领域。这些关于玩家从未感到无聊,拥有很多生命值(太简单),拥有较少生命值(太困难),并玩了很长时间的领域将清楚地告诉我们,他们可能在哪里死去以及在哪里添加哪些内容更合适等等。

帮助调试的另外一点便是确保不同引擎版本间的“游戏保存”格式可兼容。因为我们能够基于特定的时间间隔自动保存游戏,如果玩家测试者在游戏中崩溃了,我们便拥有某些与他遭遇漏洞的位置相近的内容。即使他们所测试的代码基础版本有点旧,这些文件也仍然能够运行,这让原本容易找到并修改的漏洞变得难以复制。我们的游戏保存格式让我们能够随意添加数据,删除数据,添加并删除代码,并且不会影响任何其它内容。这同样也让我们能够在发行游戏后在不妨碍玩家艰难获得成功的游戏前提下做出一些主要的改变。

好人难做

直到“阴谋”过程开始时,技术便会直接被添加到《半条命》中。假设“如果我们创建了它,它们便会出现,”这意味着任何技术将自然地找到内容创造者的创造性使用。关于这点的一个主要例子便是我们的“光束”效果,即在亮点间连接可调节且弯曲的线;如闪电,激光,神秘的能力光束。这会被添加到引擎中,并暴露出参数,然后发送电子邮件去解释它。结果却是什么都没有。在2个月后,只有一位关卡设计师将其置于地图上。

在“阴谋”过程中,我们意识到尽管关卡设计师了解功能,但是他们却不知道它是关于什么。所有的参数都很含糊,错误的组合也将导致光束拥有非常难看的效果。不存在有效的纹理能够用于它们身上,并且设置它们有点神秘。显然,技术本身只是工作的一小部分,整合,瞄准和跟进才是创造对游戏有用的技术的必要条件。编写代码并不是多大的问题。

憨夫成龙

实际上,并不是每个人都适合我们在“阴谋”过程中所执行的群组设计活动,至少不是一开始就能够适应。带有强烈个性的人,带有糟糕语言能力的人或者不喜欢在群组环境下创造的人都不应该被迫进入这样的过程。我们会选择那些带有许多群组设计经验,特别是游戏设计经验的人。虽然如此,到最后几乎每个人都是处于某种类型的“阴谋”小组中,我们也将更加适应这样的过程并开始获得真正好的结果。对于现在的项目,如《军团要塞2》,“阴谋”小组总是由12多名成员所组成,很少会少于8名。会议最终会变短,并更快速地传播理念,但我不确定会推荐最初的小组规模。

在《半条命》中,几乎所有内容都是由“阴谋”小组所设计。这在一开始似乎会增加开支,但这能帮助所有人真正参与到创造过程中,并投入于设计中。一旦所有人变成一个整体沉浸于设计中,设计便不再是由个体所拥有的单独组块,而是变成属于“我们的”完整游戏设计。

“我们的”理念会延伸到所有的关卡中。几乎游戏中的每一个关卡最终都是由至少3个不同的关卡设计师在开发过程中的某些时刻进行编辑,有些关卡设置包含了所有参与者。尽管所有的关卡设计师都擅于几乎所有内容,但是他们也都有自己更加喜欢的某些关卡设计部分。有些人将负责几何结构,有些人将负责怪物和AI的设置,我们的纹理美术师将介入并执行纹理变化,然后还有些人将完成灯光变化,并在需要的时候转变角色。这在项目最后变得特别重要,即当人们在不同时间完成不同工作时。如果游戏测试揭示了某些内容需要做出改变,那么空闲的关卡设计师应该对此作出改变,而不应该让游戏因为缺少特定的设计师而遭遇瓶颈。

这一理念同样也延伸至所有的代码,纹理,模型,动画,声音等等。这些都是处于源控制下,任何个体都能够同步到源代码中并作出任何改变。基于少量自我控制,这不如听起来那么随意。它带有附加利益能够轻松获得关于由谁改变了什么内容等信息的记录。然后我们将把这些信息带回游戏测试循环中,只测试改变后的内容,并通过监督改变并获得关于任何一个组件的稳定性与完整性的估计而为项目调度带去帮助。这同样也让我们能够系统地通过正规过程添加功能,并且不会造成太大影响。一旦完成技术部分,工程师将被分配去同步所有源创作并重新创造受改变影响的所有文件(包括模型,纹理,关卡等等)。

工人控制制作方式

即使完全专注于小组活动,《半条命》的大多数功能却只是通过个体提倡而出现。每个人对于游戏到底该是怎样的,或者至少我们应该执行怎样的功能都带有意见分歧。“阴谋”过程为这些理念提供了一个让人倾听的空间,因为它接受了射击理念是来自任何人的事实,并提供给人们更多他们想要的权利。如果理念要求除了创造者之外的其他人去执行工作,或者理念影响了游戏的其它领域,它们便需要开始一个“阴谋”过程并尝试着说服其他重要的参与者他们的理念值得付出努力。在项目的开始,这是很容易做到的,因为每个人都低估了需要执行的工作数量,但到了项目中间和最后阶段,我们将更加难以完成更具破坏性的决定。这同样也帮助过滤掉所有设计改变,除了那些那些来自玩家并对开发工作具有影响的内容。

通过不断的游戏测试,反馈,回顾与编辑循环,“阴谋”过程在删除不符合我们想要的质量标准的部分扮演着重要角色。这是“阴谋”过程最初备受争议的部分,但也是最重要的部分之一。就其本质来看,“阴谋”过程避免了其它等级结构中的内部个人冲突。因为问题是在相对客观的游戏测试中识别出来的,因为它们的解决方法达到了共识或至少得到了一个同事的支持,并且不存在每个人都可以反抗的权利。

每一天,200页设计文件所提供的细节其实并不明确。它并未回答每个领域所要求的1001个特定细节,或者每日开发的无数创造细节。任何设计文件其实只是一个参考框架,帮助你完善任何可能性的内容。帮助扩展所有大局理念的“阴谋”过程并未将其整合到任何文件中—-重要的是需要感受到游戏,但却因为太过朦胧而难以用言语形容。这同样也能够提升个体优势并削减个体劣势,然后设置一个让个体能够对游戏造成影响的框架。在《半条命》中,这是少有的不包含10多个不同人的直接工作的领域。

为了让较高的等级结构更有效率,他们需要一个能够了解所有人工作以及个体工作的成员,而其他愿意成为下属的人仍然能够真正执行设计工作。考虑到最高级游戏的复杂性,这其实并不现实—-如果你非常擅于做某份工作,为什么你会想要成为别人的下属呢?另一方面,完美无结构的组织将遭受缺少信息和控制的打击—-如果每个人只是做着自己的事,那么在最终所有内容将不可能有效地组合在一起。

在Valve,我们很高兴看到“阴谋”过程的结果。当然,我们仍会因为过分的野心以及拥有不现实的期待而遭遇挫折,但这最终将得到纠正,而“阴谋”过程也能够帮我们想出最理想的应对方法。考虑到我们最初遭遇的失败,以及我们最终游戏超越了个体的预期,那些最初感到不情愿的人现在也成为了这一过程的支持者了。

成功的“阴谋”过程的提示

包含一位来自各种功能区(编程,美术等等)的专家。讨论会议上没人真正理解的问题便是在浪费所有人的时间。

写下所有内容。在会议期间进行头脑风暴很有帮助,但除非能够写下所有内容,否则在短短几天内你们便会遗忘掉最佳理念。在此的目标便是创造一份包含尽可能多关于游戏内容以及关于人们需要致力于什么任务的更重要问题的答案。

并不是所有理念都是好的。这也包含你的理念。如果你拥有一个所有人都认为很愚蠢的理念,请不要一意孤行。其他人也会拥有愚蠢的理念。如果你不断鼓吹自己的理念,他们也会去鼓吹自己的理念,如此你们只会陷入一个僵局。如果一个理念真的很棒,也许它只是出现在错误的地方。之后再将其提出来。你将设计30个小时的游戏玩法,如果你真的想要添加自己的理念,有可能它将适合游戏的其它地方。也许其他人在下个月便会认可你的理念。

只计划已经发挥作用,或者你敢保证能够在游戏测试前运行的技术元素。不要指望任何在游戏发行前未能做好准备的内容。的确,幻想很酷的技术是件有趣的事,但是围绕着从未完成或还未优化的元素去设计游戏是毫无意义的事。如果某些内容的落实是没有结果的,那就果断抛弃它,越早越好。

避免所有一次性技术元素。任何要求工程工作的内容都必须用于游戏中的多个点上。工程师的速度真的很慢。他们可能需要花费好几个月的时间才能完成一份工作。如果他们所创造的内容只使用一次,那便等于在浪费有限的资源。他们的主要目标应该是创造能够用于各个地方的工具和功能。如果他们能够花费一个月的时间去创造能够用于各个地方的内容,你们就赢了。但是如果他们花费了一周时间只创造出10秒钟的游戏玩法,这便是在浪费时间。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转功,如需转载请联系:游戏邦

The Cabal: Valve’s Design Process For Creating Half-Life

by ken birdwell

While Half-Life has seen resounding critical and financial success (winning over 50 Game of the Year awards and selling more than a million copies worldwide), few people realize that it didn’t start out a winner — in fact, Valve’s first attempt at the game had to be scrapped. It was mediocre at best, and suffered from the typical problems that plague far too many games. This article is about the teamwork – or “Cabal process” — that turned our initial, less than impressive version of Half-Life into a groundbreaking success.

Paving the Way with Good Intentions

Our initial target release date was November 1997 — a year before the game actually shipped. This date would have given Valve a year to develop what was in essence a fancy Quake TC (Total Conversion — all new artwork, all new levels). By late September 1997, nearing the end of our original schedule, a whole lot of work had been done, but there was one major problem — the game wasn’t any fun.

Yes, we had some cool monsters, but if you didn’t fight them exactly the way we had planned they did really stupid things. We had some cool levels, but they didn’t fit together well. We had some cool technology, but for the most part it only showed up in one or two spots. So you couldn’t play the game all the way through, none of the levels tied together well, and there were serious technical problems with most of the game. There were some really wonderful individual pieces, but as a whole the game just wasn’t working.

The obvious answer was to work a few more months, gloss over the worst of the problems and ship what we had. For companies who live and die at the whim of their publishers, this is usually the route taken — with predictable results. Since Valve is fairly independent, and since none of us believed that we were getting any closer to making a game we could all like, we couldn’t see how a month or two would make any significant difference. At this point we had to make a very painful decision — we decided to start over and rework every stage of the game.

Fortunately, the game had some things in it we liked. We set up a small group of people to take every silly idea, every cool trick, everything interesting that existed in any kind of working state somewhere in the game and put them into a single prototype level. When the level started to get fun, they added more variations of the fun things. If an idea wasn’t fun, they cut it. When they needed a software feature, they simplified it until it was something that could be written in a few days. They all worked together on this one small level for a month while the rest of us basically did nothing. When they were done, we all played it. It was great. It was Die Hard meets Evil Dead. It was the vision. It was going to be our game. It was huge and scary and going to take a lot of work, but after seeing it we weren’t going to be satisfied with anything less. All that we needed to do was to create about 100 more levels that were just as fun. No problem.

So, Tell Me About Your Childhood

The second step in the pre-cabal process was to analyze what was fun about our prototype level. The first theory we came up with was the theory of “experiential density” — the amount of “things” that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on. Since we couldn’t really bring all these experiences to the player (a relentless series of them would just get tedious), all content is distance based, not time based, and no activities are started outside the player’s control. If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen.

The second theory we came up with is the theory of player acknowledgment. This means that the game world must acknowledge players every time they perform an action. For example, if they shoot their gun, the world needs to acknowledge it with something more permanent than just a sound — there should be some visual evidence that they’ve just fired their gun. We would have liked to put a hole through the wall, but for technical and game flow reasons we really couldn’t do it. Instead we decided on “decals” — bullet nicks and explosion marks on all the surfaces, which serve as permanent records of the action. This also means that if the player pushes on something that should be pushable, the object shouldn’t ignore them, it should move. If they whack on something with their crowbar that looks like it should break, it had better break. If they walk into a room with other characters, those characters should acknowledge them by at least looking at them, if not calling out their name. Our basic theory was that if the world ignores the player, the player won’t care about the world.

A final theory was that the players should always blame themselves for failure. If the game kills them off with no warning, then players blame the game and start to dislike it. But if the game hints that danger is imminent, show players a way out and they die anyway, then they’ll consider it a failure on their part; they’ve let the game down and they need to try a little harder. When they succeed, and the game rewards them with a little treat — scripted sequence, special effect, and so on — they’ll feel good about themselves and about the game.

Secret Societies

Throughout the first 11 months of the project we searched for an official “game designer,” — someone who could show up and make it all come together. We looked at hundreds of resumes and interviewed a lot of promising applicants, but no one we looked at had enough of the qualities we wanted for us to seriously consider them the overall godlike “game designer” that we were told we needed. In the end, we came to the conclusion that this ideal person didn’t actually exist. Instead, we would create our own ideal by combining the strengths of a cross section of the company, putting them together in a group we called the “Cabal.”

The goal of this group was to create a complete document that detailed all the levels and described major monster interactions, special effects, plot devices, and design standards. The Cabal was to work out when and how every monster, weapon, and NPC was to be introduced, what skills we expected the player to have, and how we were going to teach them those skills. As daunting as that sounds, this is exactly what we did. We consider the Cabal process to have been wildly successful, and one of the key reasons for Half-Life’s success.

Cabal meetings were semi-structured brainstorming sessions usually dedicated to a specific area of the game. During each session, one person was assigned the job of recording and writing up the design, and another was assigned to draw pictures explaining the layout and other details. A Cabal session would typically consist of a few days coming up with a mix of high level concepts for the given area, as well as specific events that sounded fun.

Once enough ideas were generated, they would be reorganized into a rough storyline and chronology. Once this was all worked out, a description and rough sketch of the geometry would be created and labeled with all the key events and where they should take place. We knew what we wanted for some areas of the game from the very start, but other areas stayed as “outdoors” or “something with a big monster” for quite some time. Other areas were created without a specific spot in the game. These designs would sit in limbo for a few weeks until either it became clear that they weren’t going to fit, or that perhaps they would make a good segue between two other areas. Other portions were created to highlight a specific technology feature, or simply to give the game a reason to include a cool piece of geometry that had been created during a pre-cabal experiment. Oddly enough, when trying to match these artificial constants, we would often create our best work. We eventually got into the habit of placing a number of unrelated requirements into each area then doing our best to come up with a rational way to fit them together. Often, by the end of the session we would find that the initial idea wasn’t nearly as interesting as all the pieces we built around it, and the structure we had designed to explain it actually worked better without that initial idea.

During Cabal sessions, everyone contributed but we found that not everyone contributed everyday. The meetings were grueling, and we came to almost expect that about half of the group would find themselves sitting through two or three meetings with no ideas at all, then suddenly see a direction that no one else saw and be the main contributor for the remainder of the week. Why this happened was unclear, but it became important to have at least five or six people in each meeting so that the meetings wouldn’t stall out from lack of input.

The Cabal met four days a week, six hours a day for five months straight, and then on and off until the end of the project. The meetings were only six hours a day, because after six hours everyone was emotionally and physically drained. The people involved weren’t really able to do any other work during that time, other than read e-mail and write up their daily notes.

The initial Cabal group consisted of three engineers, a level designer, a writer, and an animator. This represented all the major groups at Valve and all aspects of the project and was initially weighted towards people with the most product experience (though not necessarily game experience). The Cabal consisted only of people that had actual shipping components in the game; there were no dedicated designers. Every member of the Cabal was someone with the responsibility of actually doing the work that their design specified, or at least had the ability to do it if need be.

The first few months of the Cabal process were somewhat nerve wracking for those outside the process. It wasn’t clear that egos could be suppressed enough to get anything done, or that a vision of the game filtered through a large number of people would be anything other than bland. As it turned out, the opposite was true; the people involved were tired of working in isolation and were energized by the collaborative process, and the resulting designs had a consistent level of polish and depth that hadn’t been seen before.

Internally, once the success of the Cabal process was obvious, mini-Cabals were formed to come up with answers to a variety of design problems. These mini-Cabals would typically include people most effected by the decision, as well as try to include people completely outside the problem being addressed in order to keep a fresh perspective on things. We also kept membership in the initial Cabal somewhat flexible and we quickly started to rotate people through the process every month or so, always including a few people from the last time, and always making sure we had a cross section of the company. This helped to prevent burn out, and ensured that everyone involved in the process had experience using the results of Cabal decisions.

The final result was a document of more than 200 pages detailing everything in the game from how high buttons should be to what time of the day it was in any given level. It included rough drawings of all the levels, as well as work items listing any new technology, sounds, or animations that those levels would require.

We also ended up assigning one person to follow the entire story line and to maintain the entire document. With a design as large as a 30-hour movie, we ended up creating more detail than could be dealt with on a casual or part-time basis. We found that having a professional writer on staff was key to this process. Besides being able to add personality to all our characters, his ability to keep track of thematic structures, plot twists, pacing, and consistency was invaluable.

Pearls Before Swine

By the second month of the Cabal, we (the “swine”) had enough of the game design to begin development on several areas. By the third month, we had enough put together to begin play testing.

A play-test session consists of one outside volunteer (Sierra, our publisher, pulled play-testers from local people who had sent in product registration cards for other games) playing the game for two hours. Sitting immediately behind them would be one person from the Cabal session that worked on that area of the game, as well as the level designer who was currently the “primary” on the level being tested. Occasionally, this would also include an engineer if new AI needed to be tested.

Other than starting the game for them and resetting it if it crashed, the observers from Valve were not allowed to say anything. They had to sit there quietly taking notes, and were not allowed to give any hints or suggestions. Nothing is quite so humbling as being forced to watch in silence as some poor play-tester stumbles around your level for 20 minutes, unable to figure out the “obvious” answer that you now realize is completely arbitrary and impossible to figure out.

This was also a sure way to settle any design arguments. It became obvious that any personal opinion you had given really didn’t mean anything, at least not until the next play-test session. Just because you were sure something was going to be fun didn’t make it so; the play-testers could still show up and demonstrate just how wrong you really were.

A typical two-hour play-test session would result in 100 or so “action items” — things that needed to be fixed, changed, added, or deleted from the game. The first 20 or 30 play-test sessions were absolutely critical for teaching us as a company what elements were fun and what elements were not. Over the course of the project we ended up doing more than 200 play-test sessions, about half of them with repeat players. The feedback from the sessions was worked back into the Cabal process, allowing us to preemptively remove designs that didn’t work well, as well as elaborate on designs that did.

Toward the middle of the project, once the major elements were in place and the game could be played most of the way through, it became mostly a matter of fine-tuning. To do this, we added basic instrumentation to the game, automatically recording the player’s position, health, weapons, time, and any major activities such as saving the game, dying, being hurt, solving a puzzle, fighting a monster, and so on. We then took the results from a number of sessions and graphed them together to find any areas where there were problems. These included areas where the player spent too long without any encounters (boring), too long with too much health (too easy), too long with too little health (too hard), all of which gave us a good idea as to where they were likely to die and which positions would be best for adding goodies.

Another thing that helped with debugging was making the “save game” format compatible between the different versions of the engine. Since we automatically saved the game at regular intervals, if the play-testers crashed the game we would usually have something not too far from where they encountered the bug. Since these files would even work if the code base they were testing was several versions old, it made normally rare and hard to duplicate bugs relatively easy to find and fix. Our save game format allowed us to add data, delete data, add and delete code (we even supported function pointers) at will, without breaking anything. This also allowed us to make some fairly major changes after we shipped the game without interfering with any of our players’ hard-won saved games.

No Good Deed Goes Unpunished

Until the Cabal process got underway, technology was added to Half-Life freely. It was assumed that “if we build it, they will come,” meaning that any new technology would just naturally find a creative use by the content creation folks. A prime example of this fallacy was our “beam” effect, basically a technique for doing highly tunable squiggly glowing lines between two points; stuff like lightning, lasers, and mysterious glowing beams of energy. It was added to the engine, the parameters were exposed, and an e-mail was sent out explaining it. The result was … nothing. After two months only one level designer had put it in a map. Engineering was baffled.

During the Cabal process, we realized that although the level designers knew of the feature, they really had no clear idea of what it was for. The parameters were all very cryptic, and the wrong combinations would cause the beams to have very ugly-looking effects. There were no decent textures to apply to them, and setting them up was a bit of a mystery. It became very clear the technology itself was only a small part of the work and integration, training, and follow-through were absolutely necessary to make the technology useful to the game. Writing the code was typically less than half the problem.

Square Pegs

Practically speaking, not everyone is suited for the kind of group design activity we performed in the Cabal, at least not initially. People with strong personalities, people with poor verbal skills, or people who just don’t like creating in a group setting shouldn’t be forced into it. We weighted our groups heavily toward people with a lot of group design experience, well ahead of game design experience. Even so, in the end almost everyone was in a Cabal of one sort or another, and as we got more comfortable with this process and started getting really good results it was easier to integrate the more reluctant members. For current projects, such as Team Fortress 2, the Cabal groups are made up of 12 or more people, and rarely fewer than eight. The meetings ended up being shorter, and they also ended up spreading ideas around a lot quicker, but I’m not sure I’d recommend that size of group initially.

Just about everything in Half-Life was designed by a Cabal. This at first seemed to add a bit of overhead to everything, but it had the important characteristic of getting everyone involved in the creation process who were personally invested in the design. Once everyone becomes invested in the design as a whole, it stops being separate pieces owned by a single person and instead the entire game design becomes “ours.”

This “ours” idea extended to all levels. Almost every level in the game ended up being edited by at least three different level designers at some point in its development and some levels were touched by everyone. Though all the level designers were good at almost everything, each found they enjoyed some aspect of level design more than other aspects. One would do the geometry, one would do monster and AI placement, our texture artist would step in and do a texturing pass, and then one would finish up with a lighting pass, often switching roles when needed due to scheduling conflicts. This became critical toward the end of the project when people finished at different times. If a play-test session revealed something that needed to be changed, any available level designer could make the changes without the game getting bottlenecked by needing any specific individual.

This idea also extended to all code, textures, models, animations, sounds, and so on. All were under source control and any individual was able to synch up to the sources and make whatever changes were necessary. With a little bit of self–control, this isn’t as random as it sounds. It had the added benefit in that it was fairly easy to get a daily record of exactly what was changed and by whom. We would then feed this information back into the play-test cycles, only testing what had changed, as well as helping project scheduling by being able to monitor the changes and get a pretty good estimate of the stability and completeness of any one component. This also allowed us to systematically add features throughout the process with minimal impact. Once the technical portion was completed, the engineer assigned to the feature was able to synch to all the source artwork and rebuild any and all files (models, textures, levels, and so on) affected by the change.

The Workers Control the Means of Production

Even with all emphasis on group activity, most of the major features of Half-Life still only happened through individual initiative. Everyone had different ideas as to what exactly the game should look like, or at least what features we just had to do. The Cabal process gave these ideas a place to be heard, and since it was accepted that design ideas can come from anyone, it gave people as much authority as they wanted to take. If the idea required someone other than the inventor to actually do the work, or if the idea had impact on other areas of the game, they would need to start a Cabal and try to convince the other key people involved that their idea was worth the effort. At the start of the project, this was pretty easy as most everyone wildly underestimated the total amount of work that needed to be done, but toward the middle and end of the project the more disruptive decisions tended to get harder and harder to push through. It also helped filter out all design changes except for the ones with the most player impact for the least development work.

Through constant cycle of play-testing, feedback, review, and editing, the Cabal process was also key in removing portions of the game that didn’t meet the quality standards we wanted, regardless of the level of emotional attachment the specific creator may have had to the work. This was one of the more initially contentious aspects of the Cabal process, but perhaps one of the more important. By its very nature, the Cabal process avoided most of the personal conflicts inherent in other more hierarchical organizations. Since problems were identified in a relatively objective manner of play-testing, and since their solutions were arrived at by consensus or at least by an individual peer, then an authority that everyone could rebel against just didn’t exist.

On a day-to-day basis, the level of detail supplied in even a 200-page design document is vague at best. It doesn’t answer the 1,001 specific details that each area requires, or the countless creative details that are part of everyday development. Any design document is really nothing more than a framework to work from and something to improve the likelihood that work from multiple people will fit together in a seamless fashion. It’s the Cabal process that helped spread around all the big picture ideas that didn’t make it into any document —things that are critical to the feel of the game, but too nebulous to put into words. It also helps maximize individual strengths and minimize individual weaknesses and sets up a framework that allows individuals to influence as much of the game as possible. In Half-Life, it was the rare area of the game that didn’t include the direct work of more than ten different people, usually all within the same frame.

In order for highly hierarchical organizations to be effective, they require one person who understands everyone else’s work at least as well as the individuals doing the work, and other people who are willing to be subordinates yet are still good enough to actually implement the design. Given the complexity of most top game titles, this just isn’t practical — if you were good enough to do the job, why would you want to be a flunky? On the other hand, completely unstructured organizations suffer from lack of information and control — if everyone just does their own thing, the odds that it’ll all fit together in the end are somewhere around zero.

At Valve, we’re very happy with the results of our Cabal process. Of course, we still suffer from being overly ambitious and having, at times, wildly unrealistic expectations, but these eventually get straightened out and the Cabal process is very good about coming up with the optimal compromise. Given how badly we failed initially, and how much the final game exceeded our individual expectations, even our most initially reluctant person is now a staunch supporter of the process.

Tips for a Successful Cabal

Include an expert from every functional area (programming, art, and so on). Arguing over an issue that no one at the meeting actually understands is a sure way to waste everyone’s time.

Write down everything. Brainstorming is fine during the meetings, but unless it’s all written down, your best ideas will be forgotten within days. The goal is to end up with a document that captures as much as is reasonable about your game, and more importantly answers questions about what people need to work on.

Not all ideas are good. These include yours. If you have a “great idea” that everyone thinks is stupid, don’t push it. The others will also have stupid ideas. If you’re pushy about yours, they’ll be pushy about theirs and you’re just going to get into an impasse. If the idea is really good, maybe it’s just in the wrong place. Bring it up later. You’re going to be designing about 30 hours of game play; if you really want it in it’ll probably fit somewhere else. Maybe they’ll like it next month.

Only plan for technical things that either already work, or that you’re sure will work within a reasonable time before play testing. Don’t count on anything that won’t be ready until just before you ship. Yes, it’s fun to dream about cool technology, but there’s no point in designing the game around elements that may never be finished, or not polished enough to ship. If it’s not going to happen, get rid of it, the earlier the better.

Avoid all one-shot technical elements. Anything that requires engineering work must be used in more than one spot in the game. Engineers are really slow. It takes them months to get anything done. If what they do is only used once, it’s a waste of a limited resource. Their main goal should always be to create tools and features that can be used everywhere. If they can spend a month and make everyone more productive, then it’s a win. If they spend a week for ten seconds of game play, it’s a waste.(source:gamasutra)

 


上一篇:

下一篇: