灯塔实验室

    对牛弹琴

（译注：英文原文为Pearls Before Swine，如果直译的话那大概就是“猪眼不识珠”-_- ）

在合谋的第二个月里，我们（“猪”）已经做了足够多的设计，可以在多个区域着手开发了。到了第三个月，我们已经有足够的内容进行游玩测试（play-test）了。

一个游戏测试环节中会包括一名来自开发团队之外的志愿者（Sierra，我们的发行商，抓来了几个本地人来测试游戏，而他们原本是来送其他游戏的产品注册卡的。）玩2个小时的游戏。坐在测试者身后的是，一名合谋团队里负责该游戏区域的人，以及当前主要负责被测试关卡的关卡设计师。有时候也会有一名工程师，如果新的AI需要测试的话。

除了替测试者启动游戏，在游戏崩溃时重启游戏之外，来自Valve团队的观察人员不允许说任何话。他们只能安静地坐在那里记笔记，同样也不许给任何提示或者提任何问题。没有什么事比这个更令人羞愧了：你被迫在观察过程中保持沉默，而那些测试者一点都不擅长你的游戏，他在你的关卡里转悠了20分钟都没有找到那个“显而易见”的答案。但是现在你意识到那个“答案”其实是完全随机的，所以根本不可能通过正常途径被找出来。

这个生物一开始是被当成一个友好的角色来设计的，但是在游玩测试中发现玩家们倾向与对它先开枪后问话。

肯定能够找到解决设计争议的办法。我们发现，任何个人意见根本代表不了任何东西，至少在下一次游玩测试前没有任何意义。这只是因为，你“确信某样东西肯定好玩”，不代表这样东西“一定好玩”。测试的玩家很可能在测试过程中证明你当时的“确信”完全没有根据。

一个典型的2小时游玩测试环节会产生大约100个“任务项目”（action items）——它们是那些在游戏里需要修复、改变、增加或缩减的东西。前20至30个游玩测试环节对于教会我们这个公司，“哪些元素是有趣的”以及“哪些是无趣的”尤为重要。在整个开发环节里，我们进行了超过200次游玩测试，大约有一半的测试玩家参与了不止一次。从测试环节得到结果被反馈到合谋进程里，让我们能够尽早处理掉那些效果不理想的设计方案，同时能够精心完善那些好的设计。

在项目进行到一半，主要元素都已经就位，大部分游戏流程都可以进行游玩时，开发主要就变成了一项优化工作。为了做这项工作，我们在游戏里加入了一些基本的工具，可以自动记录玩家的位置、生命值、武器、时间以及主要游戏活动——例如保存游戏、死亡、受伤、解决了一个谜题、与怪兽战斗等等。我们随后从多个测试环节中采取这些数据，然后将它们用图表的方式列出，以观察在哪些区域里存在问题。这些问题包括了：玩家处在某个区域里很长一段时间，但是没有遇到任何东西（无聊）；很长一段时间里生命值非常高（太简单）；很长一段时间里生命值非常低（太困难）。这些数据让我们明白玩家最有可能在哪些位置死亡，以及我们最好在哪些位置加进一些好东西。

让玩家看到其他角色犯玩家需要避免的错，这是一个解释你的谜题的有效办法，同时也会提升紧张气氛与环境的价值。

 

另外一个有助于调试（debug）的举措是：让游戏存档能够在不同版本的引擎间兼容。因为我们会自动定期存档，所以如果在玩家测试过程中游戏崩溃了，我们常能回到遇见问题前不久的进度那里。因为即使玩家测试的代码基（code base）是好几个版本前的，那些存档也同样可以用。这让通常情况下较为少见以及难以重现的问题能被相对容易地找到与修复。我们的存档格式让我们能够随意加入数据、删除数据以及删除代码（我们甚至还支持了函数指针（function pointer）），这么做也不会破坏任何东西。这也让我们能够在游戏发售后对游戏作出一些较大的改动，但却不影响玩家们辛苦得来的存档。

 

好心没好报

在我们使用合谋进程以前，我们没有对加进《半条命》的技术设置任何限制。我们默认“如果我们制造了它，它们就会来”，意思是任何新技术能够很自然地被创作游戏内容的团队找到一种有创意的使用方法。这种天真想法最主要的例子体现在我们的“光束”特效上——这是一个能在两点之间生成高度可控，纠缠在一起的发光线条的技术；可以产生例如光照、镭射和神奇能量光束之类的东西。它被加到引擎里去了，参数都被暴露出来了，然后一封解释的电子邮件被发了出去。结果……什么都没有发生。在两个月后，只有一名关卡设计师把它运用到了一张地图里。工程师们面面相觑。

在合谋进程里，我们意识到了一点：即使关卡设计师们知道了某个特征（feature）的存在，但他们真的不是很清楚那个东西到底有什么用。参数都非常晦涩难懂，而且如果把它们错误地组合起来了，会让光束产生非常难看的效果。它们没有加上合适的材质，而如何设置它们也非常令人迷惑。最后我们清楚了，技术本身其实只占所有工作的很小一部分，而整合、训练以及后续动作是让技术对游戏有用的必要条件。写代码通常只占问题的一小部分。

 

方形楔子

（译注：完整的成语应该是，Square peg in a round hole，顾名思义，就是不合适）

从实践角度来说，不是每一个人都适合我们在“合谋”中进行的那种团队设计活动，至少一开始是这样的。那些有很强个性的人，口头表达能力差的人，或者那些不喜欢在小组里工作的人，我们不应该强迫他们进入合谋进程。我们在挑选组员的时候，把重心主要放在那些有许多团队设计经验的人身上，而不是有游戏设计经验的人身上。即便如此，到了最后几乎每一个人都通过各式各样的途径参与到了合谋中来。在我们越来越适应这个进程，且在产生很好的结果后，将那些很不情愿的人拉进来也变得容易一些。至于我们目前的项目，例如《军团要塞2》（Team Fortress 2），合谋团队往往包括12名或以上的成员，很少会低于8名。后来小组讨论会的时间也缩短了，成员们发散思维的速度也快了，不过我不知道我是不是应该建议大家一开始就组成这样规模的小组。

《半条命》里几乎所有的东西都是合谋团队完成的。最初这么做似乎增加所有东西的开销，但是这么做的一个重要特点就是：能够将每一个致力于设计的人纳入到创作过程里。一旦每一个人都能在设计上齐心协力，所有的设计都不再是“个人的”，整个游戏设计变成了“我们的”。

这种“我们的”想法延伸至每一个关卡。游戏里几乎每一个关卡最后都至少在开发的不同阶段经过三个不同关卡设计师的手，还有些关卡被所有人修改过。虽然所有的关卡设计师都擅长做任何相关的事情，但是他们都对关卡设计的某些方面有个人的偏好。有人可能会处理几何图形，有人可能会处理怪兽和AI布置，我们的材质艺术家可能会介入去做一个纹理混合（texturing pass），可能之后有人会完成一个光照混合，他们通常会因为时间表有冲突而交换各自的角色。在项目的最后，这变得尤为重要，那时候人们会在不同的时段完成工作。如果一个游戏测试环节里显示出了某样东西需要调整，任何有空的关卡设计师都可以去调整这样东西。这避免了游戏因为需要某个特定的人而遇到的瓶颈。

通过将传统的战斗行为安排在更有挑战性的环境里，我们可以加强紧张感和悬念感。

 

这个办法也拓展到所有的代码、材质、建模、动画、声音等方面。所有的东西都进行了源代码控制（source control），任何人都能和源代码同步，然后做出任何必要的修改。只要有一点点的自律，这个过程并没有听起来那么随便。还有一个好处是，我们很容易就能生成每日记录，里面记下了谁做了哪些改变。随后我们把这些信息反馈到游戏测试环节，只测试改变的部分。监控改变的部分同时也能帮助建立项目日程，我们因此能够比较精确地估计任何一个组成部分的稳定程度与完整程度。这也能让我们在进程中系统地加入特征，并将影响控制在最小。一旦技术部分完成之后，负责该特征的工程师能够同步所有的美术源，然后重建任何受到该次改动影响的文件（模型、材质、关卡等）。

 

工人控制生产的手段

尽管我们一再强调团队活动的重要性，但是大多数《半条命》中的主要特征还是通过个人的积极性产生的。每个人都对“游戏应该是怎样的”抱有不同的看法，或者至少在加入哪些特征上有不同的想法。“合谋进程”为这些不同的建议提供了一个交流平台，因为我们已经达成共识——设计想法能够源自任何一个人，这给了成员们他们所需要的权力。如果某个想法必须要提出者以外的人去实现，或者说它会影响到游戏的其他部分，那么建议提出者们得组成一个合谋小组，然后试着说服那些关键人物，“他们的想法是值得尝试的”。在项目最初，这么做很容易，因为所有人都极大低估了这个方法的工作量。但在项目的中后期，对项目影响越大的决定会越难通过。这也有助于过滤掉大多数设计调整，只留下那些对玩家影响最大，但是工作量最小的。

通过游戏测试、反馈、评估、编辑，这种经常性的循环，“合谋进程”通常也有助于移除那些不满足质量要求的游戏部分，不论那些关卡的设计者对于该关卡是多么有感情。最初这是“合谋进程”比较有争议的方面，但或许这也是最重要的方面之一。因为“合谋进程”本身的特点，它能够避免大多数个人间的冲突——这些冲突常见于等级等森严的机构。因为问题是通过相对主观的游戏测试发现的，而问题的解决办法是通过达成了共识，或者至少需要一个同事点头。这样的话，那种每一个人都能反抗的权威并不存在。

让玩家置身于一个士兵与外星人的冲突中，可以帮助制造一种“环境是活跃的”错觉。Valve也能借此炫耀能将玩家风险减到最低的战斗AI。

 

按每天的工作量计算，即使是一份200页设计文档里的细节最多只能算作“笼统”。它不会包含每一个在区域中需要的1001个细节问题，或是每天开发过程中出现的，数不胜数的创意细节。任何设计文档的作用只是一个框架，团队以此为前提进行开发；文档本身能够增加多人合作的可行性，仅此而已。正是“合谋进程”帮助拓展出那些没有被写进任何文档的全局观——这些东西对于游戏的感觉非常重要，但是写成文字又会变得含糊不清。合谋同样能最大化个人的优势，并且最小化个人的弱势，建立一个框架——在其中的个人能够尽可能多地影响游戏。在《半条命》里，几乎很少会有低于10不同的个人直接在一块区域上进行工作，他们通常都处在一个框架之中。

为了让一个等级森严的组织变得有效率，他们会要求某一个人能够精通其他每一个人的工作——至少要和具体开发的人一样精通。而其余希望在他手下干活的人也要能够真地将那些设计付诸实践。考虑到大多数顶级游戏的复杂程度，这一点也不实际——如果你已经强到能够胜任这项工作，你为什么想给人打下手？另一方面，完全无序的组织会受制于缺少信息与控制——如果每一个人只是埋头单干，那么最后能将所有人的工作整合起来的可能性接近于零。

在Valve里，我们都很满意“合谋进程”产生的结果。当然，我们仍会因为野心过大吃苦头，很多时候会有非常不切实际的期望。不过这些东西最后都能得到解决，因为“合谋进程”擅长的地方就是提出最优的妥协办法。看到我们一开始的项目有多失败，而最后的成品又远超我们每一个人的预期，即使起先最不情愿的人现在也变成了“合谋”的忠实支持者了。

 

成功“合谋”的小窍门

• 团队中应该要有来自每一个功能区域的专家（程序、美术等）。在会议上讨论没有人了解的话题肯定会浪费每一个人的时间。
• 写下所有的东西。会议中可以有头脑风暴，但是除非全都写下来了，你最好的想法会在几天后淡忘。目标是写一份关于你游戏尽可能多，而且合理的文档。更重要的是要回答这个问题——成员们应该开发哪些东西。

游戏中一名主要角色的第一次成形。现在我们亲切地称他为“宇宙骑手伊凡（Ivan the Space Biker）”。

 

• 并非所有的想法都是好的。也包括你自己的。如果你有了一个“绝妙的想法”，但是所有人都觉得很傻，那么不要勉强。其他人也会有愚蠢的想法。如果你勉强坚持你自己的，那么其他人也会坚持他们的，然后就陷入了死循环。如果这个想法真的很好，也许它只是生不逢时。以后再提出来。你会设计大约30个小时的游戏流程；如果你真的很想保留那个想法，它可能会适用于其他地方。也许其他成员会在下个月来实现这个想法。
• 对于技术方面的东西，只有在它们已经能够工作或者你很确信它们能在下一次游戏测试之前能够奏效的话，你才能计划将这些东西加入游戏中去。不要寄希望于那些直到你发售游戏前几天才能奏效的东西。是的，梦想着一些很酷的技术是很有意思的，但是围绕那些可能永远无法实现的东西去设计游戏是徒劳的；或者，这样的游戏在发售前达不到质量标准。如果不行的话，那就抛弃掉，越早越好。
• 避免只用一次的技术元素。任何需要工程方面工作的东西必须至少要在游戏中的2个地方使用。工程师们的速度很慢，他们会花费几个月去完成某样东西。如果他们的成果只会用到一次，那么这是一种资源的浪费。他们的主要目的应该是制作所有地方都适用的工具和特征。如果他们花费了一个月的时间，让其他所有人的工作效率上升了，那么这就是一次胜利。如果他们花费了一个礼拜的时间在10秒钟的游戏流程上，那么这就是一种浪费。

 

译注：

The original post was  from Gamasutra by Ken Birdwell, and was translated to Chinese by J_Lu from Beacon Labs.

欢迎转载，转载即意味着你同意了授权条款。商业机构转载须要事先得到作者授权，并且提供给作者转载的链接以供作者检查是否符合条款。