游戏设计的敏捷方法学

目前，业界弥漫着一股对次世代游戏开发的恐惧空气，GDC上谈，Game Developer杂志也谈。随着硬件能力的不断提升，开发更高自由度、更逼真的游戏成为业界追求的最新目标，为了实现这一目标，随之而来的一切也都在膨 胀：团队人数、美术资源需求、人时投资，当然啦，对投资者的资金需求也随之膨胀了起来。玩家的胃口越来越大。他们希望有更先进的技术以支持更好的游戏机 制、更细腻的建模、更高分辨率的纹理、更复杂的人工智能、更多的测试以及更好的质量保证，没完没了。

　　而这种恐惧不仅蔓延了业界，就连媒体和玩家也感觉到了。游戏网站FiringSquad.com曾撰文：“游戏发行商和开发商，他们无一例外都 在抱怨疯涨的开发费用，其中主要原因是美术团队的人数在呈几何级数增长。”【注释01】据笔者分析，业界所面临的大量问题，都源于其使用的开发方法学。目 前人数超过100人的团队却仍在使用当年十个人搞定一切的方法学，而这些老的开发方法早就过时了。

　　传统的游戏开发所使用的方法学，需要在前期花费大量时间，定义功能，还经常需要在前期实现一些重要的元素，如游戏机制和关卡，一直延续到最后的 疯狂赶工。传统的方法学（通常称为瀑布模型）其实与一条生产装配线没有什么区别。在生产线的前端开始把产品的各个部分拼凑在一起，而生产线的后端就在等待 加工打磨，就是这等待的过程产生了问题。游戏策划和发行商永远都无法获知游戏的真正感觉，比如他们早先制定的游戏机制是否正确，现行的实现是否完全遵循了 早先的设计。类似种种，最终造成了产品质量的下降……

　　有另一种方法学正好可以解决传统游戏开发方法学带来的问题。在产品研发流程和团队管理方式中，它被恰当地称为“敏捷方法学”。敏捷开发注重于开 发可供演示的游戏版本，并能很快地将其加入到产品中，以及在最重要的游戏元素和特性上按优先级创建垂直分片（vertical slice）。敏捷也注重团队管理和处理其内部关系，以及团队完成项目目标的计划和周期。游戏开发团队所面临的挑战可谓五花八门，而且由于职责有别，美 术、程序和策划团队还要协同工作。游戏项目的时间跨度也很长：短则一到两年，长则三年以上，甚至个别游戏需要五年乃至更长时间。

　　这篇文章讲述了如何运用敏捷方法学和其中的Scrum方法学以应对上述的挑战，它可能特别适合于游戏开发人员，尤其是进行次世代开发的策划。

　　方法学

　　方法学在大多数游戏设计或游戏开发的书籍中鲜有提及。他们都假设大部分开发人员都无一例外地使用同一种做法，这种做法常被称为瀑布模型。在瀑布 模型中，工作都按照先后顺序安排，例如从项目需求或设计阶段到生产和实现。在项目的早期阶段中，几乎没有迭代，这样就很难提供评估的机会。不仅如此，一旦 项目运行起来，要想返工就必定面临着覆水难收的局面。

　　在瀑布模型的游戏开发中，首先由游戏策划或者策划部成员编写游戏设计文档，其中会定义很多游戏机制和特性。接下来这份设计文档被分解为小块部分，由制作人拿去丰富其中需求的功能和资产，之后对于功能和资产的需求就被分派到所有项目成员的头上。

　　接着就开始瀑布模型的流程了，这些需求瀑布式地流向动画、程序、关卡美术、人物美术、测试、特效等人的手上。一旦某人或者某团队完成了一项特 性，就将其交给下一个人或下个团队。例如一个人物，由开始时的设定文档，到制作人或项目主管的手上，从这里它被细分为多个部分：人物模型和纹理贴图、人物 动画、人物被击或者攻击时播放的特效以及驱动人物行为的人工智能技术，然后每个部门专注于各自分到的部分，完成实现直到可以进行组装。

　　然后，东西回到策划手里做调整，交给测试员进行测试，再让关卡策划在关卡中重现，之后退回各个部门进行除错。在制作这个人物的同时，其他人或其 它团队也在实现他们负责的部分。同一天中，一个制作人员会同时针对几个不同的机制工作。这种方法学的实质是一种沉淀作用，需要对大量的游戏机制同时进行加 工。

　　敏捷开发

　　上世纪90年代末，一批新型的软件开发方法学开始显露头角。它们来自于各种团队的开发实践，从网页小程序到装备到美国国家航天局的应用系统都 有。每种方法学都有自己的注意事项，当然也受到来自各方的褒扬和批评。虽然它们各有千秋，但其中的大多数方法学都有几点共通的基础。

　　2001年，在犹他，几位新型方法学的实践先驱们组织了一次峰会，峰会就中心意识形态达成普遍共识，并发表了共同宣言：

　　1、可以工作的软件胜过求全责备的文档。

　　2、客户合作胜过合同谈判。

　　3、人和交互胜过过程和工具。

　　4、随时应对变化胜过刻板遵循计划。

　　实现高于文档，随时和客户合作，解决问题的能力以及敏捷地应对变化。敏捷的核心内容很简短，但它喻含了伟大的思想，使得敏捷适用于任意复杂的产品开发系统。

　　Scrum

　　随着敏捷开发不断的成长，一些不同的方法学开始显山露水。其中一些是从敏捷中演化而来，另一些则是从某些正在使用但从未有完整定义、或未有应用 软件开发实践的系统中得来。其中一种称为Scrum的方法，这是一种产品研发的手段，源于日本汽车和消费类电子产品制造业。根据定义，Scrum是一种橄 榄球战术，让所有在场的球员都参与球的争夺。

　　作为一种方法学，同样的参与思想被贯穿于产品开发的原则之中，项目团队被重新组织成若干个小团队，对于特定的项目组件进行紧密合作。Scrum强调迭代开发，把项目分为若干可供提交的组件，对这些组件可以进行演示、测试和功能评估。

　　Scrum的一个重要核心是要求团队里的每个人都参与流程。Scrum把产品细分为若干个较短周期，称为Sprint。每个Sprint开始 时，整个项目团队就制定目标并自愿划分为小团队。Scrum团队是跨工种的，即美术、策划和程序在一起工作。虽然每个团队的目标是由项目经理、制作人和发 行商制定的，但团队有自主权制定如何实现Sprint的既定目标。一旦进入了Sprint状态，团队就完全自主地进行日常计划并执行任务。

　　就像Scrum老手经常提到的，项目无时无刻都在延迟。有鉴于此，Scrum的一项重要组成部分就是在Sprint过程中，独立的Scrum团 队间需要进行每日例会。会议长短控制在5至10分钟，目的是确认目标可行性，找出前进障碍，并让每天完成的部分通知所有团队成员知晓【注释02】。这一流 程帮助每一个团队成员树立主人翁意识，流程高度透明的设计也培养了团队成员的责任心，用以最终推动生产效率。

　　团队自主管理中，例行检讨提供了团队把握方向的能力，并让每个人可以以最清晰的形式评价产品：它看上去如何，它表现得如何。在每个Sprint 完成之时，团队通过检讨来演示他们的成果，并让产品管理者或者“客户”，如工作室经理和发行商，来评估他们的进度。然后客户根据评估来确定下一个 Sprint周期中的优先级安排。

图01：Scrum的简单图示。

　　游戏特性被划分为独立的任务，分配给程序、美术和策划，然后他们开始以两周到一个月为周期进行迭代开发，在每日例会中总结自己的任务。在每个迭 代结束时有一个产品检讨，检讨迭代期间所有的工作，然后项目总监和发行商根据此次迭代的结果决定如何在下一个迭代中进行优先级安排。

　　让团队协同客户进行检讨的目标是为了演示游戏的“垂直分片”，也就是游戏的一部分，例如一个单独的关卡或者一个完整可玩的游戏机制，抑或是一个 调整过的特性。虽然不是所有的机制都能在一次迭代中完成，但它的独立部分可以由团队作为垂直分片进行加工。举例来说，若是一个拥有人工智能的人物难以在一 次Sprint中完成，但人物的某一单一行为却可以进行编程，制作动画，加上音效，安放在某一关卡中等等。最终它还是会成为一个可测试的单元。

　　遵循这两点，客户就能够确切看到产品中究竟实现到什么程度，它未来的走向以及它的开发速度的快慢等等。客户就不必猜测，不必盲从，他们能看到的 是一个直接的诊断报告，而且经常可以拿起手柄试验一把，而不是只能看到一堆表格或线框模式的画面。Scrum还能在迭代和迭代之间给予客户灵活度，就像它 能给予产品开发团队的那样。

　　如果创建和评估的游戏未能达到期望值，客户还可以在Sprints之间从容重定项目目标，而且由于Scrum的迭代流程和Sprint的短工作周期，对一个项目进行重定义很少会造成大量工作成果浪费。

　　瀑布VS. Scrum

　　瀑布开发对游戏策划来说会产生问题，因为在某一对象的所有依赖对象都被创建出来并归入流程之前，它无法被称作真正完成。例如，策划可能创建一个 以AI为中心的关卡，但AI只存在于文档中，以设计文档为参考，策划只能尽最大可能臆测，让资深的策划帮忙评估，然后将这个关卡交给美术去建模。策划及其 主管都知道没人熟悉以人物为中心的关卡，但为了让开发进程继续下去，策划和关卡美术只能假设未来的AI将会拥有预期的行为。虽然工作继续下去了，但问题也 保留下来了。

　　万一写人物AI代码的程序员发现文档里描述的AI机制根本是不可行的话怎么办？万一AI可行，但动画师发现没法配合这套AI怎么办？万一负责这 个的策划后来突然发现这个功能压根不好玩怎么办？如果没法正面回答这些问题，通常意味着舍弃功能、浪费人时、浪费部分项目经费，甚至可能滋生某种心理障 碍，例如对项目失去信心。无论对开发流程产生什么负面影响，把它们归纳起来基本上就是：产品品质的下降。

　　瀑布产生的另一个大问题，在于部门之间的进度不平均，造成了一种“赶进度和等进度”的现象。只要工作所需的材料拿到手了，瀑布中的每个人都必须 尽可能快地完成工作，然后到工作完成之后，只能等待下一份工作所需的材料。就像装配生产线上，履带的速度时快时慢，有时甚至完全停滞，有时速度正好，有时 却像飞一样快。开发中如果长期存在不规则的速度会对制作人、财务以及所有相关的人都产生负面影响。而对策划来说，这种影响是致命的。对于策划需要不同元素 进行整合的工作特性，不一致的开发进度会很大程度上影响他们设计的功能和质量。

　　举例来说，考虑一个游戏中的恐怖效果，比如玩家遭遇一个异常凶残的boss。像这样的效果需要恰当的色调，需要策划的测试、评估，需要反复修正，需要完成的美术资源、音效和脚本。如果上述元素配备不齐，那么策划对恐怖效果本身进行设计以及单独测试无疑是浪费时间。

　　瀑布总是让策划处于不利的位置。因为游戏的尺度范围是在项目的开始时制定的，而游戏的可玩性，游戏最重要的动态特性，诸如镜头、操控、AI等， 则是在游戏项目接近尾声时才逐渐成型的。图02中，我们观察一个示例项目，游戏机制被送交多个部门进行制作，每个部门负责独立的部分。目标是在几个月后提 交完成的产品。

图02：使用瀑布开发的项目，在八个月时的进度。

　　这是个典型的耗时8个月的项目。团队开始于预制阶段，并把所有机制和资源所需的工作都逐一写入文档中。最大的问题存在于，它假设所有的机制和资源都能按时提交并且质量过关。

　　另一种描述瀑布开发的进度方法是用一条曲线按时间走向来表示产品已完成的功能，如图03所示。这里，项目时间轴的最右侧是提交日期——比如向第 一方厂商提交产品，把master后的拷贝交给发行商等等。这是雷打不动的死线。随着开发的进行，游戏的机制在项目最后的紧迫时间内开始最终成型并按要求 的那样工作。

图03：已完成的功能和时间之比。

　　万一当团队接近死线，重要的部件却无法像当初预想的那样工作怎么办？不可避免的是疯狂赶工或砍掉项目中所有和该特性相关的资源和内容。最终的结果就是浪费资源，浪费人时并且极有可能造成产品品质下降。

　　瀑布和Scrum之间最本质的区别在于Scrum的交流频度建立在每日合作的基础上，以数周为单位，而瀑布则以年为单位。在瀑布的例子中，我们 的策划围绕着文档中假设的的人物AI来创建关卡。而在Scrum中，同样的例子应用，策划和团队成员进行的则是“联袂”的紧密合作。例如，策划声明其目标 是“我需要一个AI，可以让我方便按他的行动调整他的行为”。下一步就是直接和程序员合作。

　　这样，程序员和策划一同研究可行性，从而就实现需求功能所用的最佳技术达成一致意见。一旦程序员陷入了困境，策划就进入流程并直接转向其它替代 的解决方案。这种做法不仅限于程序员和策划的合作。同样的流程，可以应用于策划和动画师合作一个人物的移动动作，也可以应用于策划和环境美术合作如何安排 一个关卡。最终的结果将会是更好的解决方案，因为Scrum保证了流程中所需要的人都会在流程中做他最擅长的工作。

　　Scrum假定创建和实现任务的人是团队里对于这部分工作最有把握，最有经验的人，他们知道如何实现目标以及哪里会有隐藏的陷阱。谁会比一个动画师更了解角色行走动画呢？谁又会比程序员更了解AI呢？

　　先简要说明设计的精神和目标，建立策划和其余组员之间的对话，就这样，让所有有关人员可以讨论实现目标的最佳手段。策划不是程序员，也不是美 术，所以我们如果对技术或艺术装懂，那无疑是愚蠢的。我们能做的是，同团队一起，设定一个为期几周的短期目标和工作，然后检验产品以判断是否达到了要求。 对于快速小型迭代开发投入精力，会为最终产品和策划带来极大的益处。

图04：SCRUM的进度

　　通过快速迭代开发，完整的游戏机制以很短的间隔涌现出来，策划能够对其进行完整的观测。这让主策划和项目总监能以周为单位进行项目目标的状态检测，并可以以月为单位进行团队的进度诊察并决定是否需要继续该目标。

　　因为团队创建的是整个垂直分片的特性，它可以被完全砍掉而不会和之前创建的内容产生冲突。开发中不允许加入依赖相关的特性，所以特性范围被合理地缩减，从而也避免了工作浪费。

　　对关卡策划这也意味着他们可以围绕机制来创建关卡，并且关卡可由自己来保证是有趣的。当策划能够在稍后返回一个关卡以加入更多已制作完备的功能 时，游戏其实已经可以出片了。如果关卡仅仅在策划手里已经非常有趣了，想象一下一旦策划手里获得了他不曾拥有的东西时，这个关卡会变成什么样子。

图05：SCRUM完成的功能和时间之比。

　　要集中注意力在独立的机制上，而不是把所有的东西做一个大概，然后细细打磨——这可能看上去很可怕。然而，考虑到首先和玩家接触的，是游戏必需 的和创建场景时的基本机制。其余非必要的特性，例如作为调味剂的特性，可以在稍后加入。在一开始创建最重要的特性，而不是在最后才把他们拼凑起来，意味着 内容创建者（如策划）可以直接围绕某一特定功能创建关卡。

　　此外，获知中心机制越早，意味着相依赖的机制被砍掉的机会越少。机制范围总是可以根据玩家需要收缩或展开。而产品作者和策划可以判断什么样的特性表现得最好，并精修之，包括使用该特性的更多的内容，让其在游戏中表现得更好【注释03】。

　　使用Scrum，产品作者和发行商可以跟随几个迭代过程制定风险目标。如果未经验证的特性或游戏概念没能最终实现，团队就可以很容易地重新评估和重定方向。而一旦发现这些特性确实很棒，则团队和作者可以决定在这方面多下工夫，甚至也可以将游戏转到一个全新的方向上去。

　　而且，随着开发时间的增长，产品面对的是一个变化中的市场。一个游戏的新点子可能很快就随着市场竞争而变成了馊主意。Scrum让开发商和策划 可以把游戏和竞争分离，几乎不带任何风险。如果产品的特性需要变更，甚至糟糕到要完全取消整个游戏，那么发行商损失的是两个礼拜到两个月的时间，而不是两 个季度或两年的时间。

　　结论

　　有了诸如Scrum的敏捷方法学，策划将会获得非常大的助益。项目总监或主策划可以以固定的时间间隔观察整个开发，不用去空想或猜测进度，他们 可以直接拿起手柄体验进度。对关卡策划来说，他们可以围绕已完备的机制建造关卡。使用Scrum，这些机制是完备的并可以任意使用，所以策划设计的关卡可 以成为整体的一部分，而且可以对机制有个更好的见解。

　　Scrum对所有游戏开发人员有助益的特性是，它最小化了加班和疯狂赶工的情况。开发商和项目主管可以在每次迭代过程中得知整个团队的效率状 况，意味着他们可以完整预知团队的效率。而用诸如瀑布的方法学，特性是在最后慢慢成型的，任何没有达到要求的特性都必须进行赶工以保证游戏顺利发片。

　　最重要的是，使用敏捷方法学和Scrum让策划和其他团队成员能够坐在一张桌子旁边，建立对话、开始提问，交流和跨部门的问题都将以机制的形式得到解决。在项目伊始就检查将导致时间和工作浪费的假想情况，以最有效率的合作来迎接最强大的游戏。

　　【注释】

　　[01]Recent article on Firingsquad.com by Jakub Wojnarowicz regarding Nintendo in the next generation. http://firingsquad.com/features/nintendo_revolution/default.asp

　　[02] A full definition of the guidelines and principals that were defined by the Agile Manifesto founders can be found at Agilemanifesto.org

　　[03]Noel Llopis, lead R&D architect at High Moon recently wrote a feature for Game Developer on a “Day in the life.” In that article he describes how a Scrum team meeting is organized and how individuals deal with tasks. It can be found on his blog at: http://www.gamesfromwithin.com/articles/0602/000104.html