游戏设计的敏捷方法学8页

【转载】游戏设计的敏捷方法学游戏设计的敏捷方法学作者：封烨来源：游戏创造02-23-2019目前，业界弥漫着一股对次世代游戏开发的恐惧空气，GDC上谈，Game Developer杂志也谈。

随着硬件能力的不断提升，开发更高自由度、更逼真的游戏成为业界追求的最新目标，为了实现这一目标，随之而来的一切也都在膨胀：团队人数、美术资源需求、人时投资，当然啦，对投资者的资金需求也随之膨胀了起来。

玩家的胃口越来越大。

他们希望有更先进的技术以支持更好的游戏机制、更细腻的建模、更高分辨率的纹理、更复杂的人工智能、更多的测试以及更好的质量保证，没完没了。

而这种恐惧不仅蔓延了业界，就连媒体和玩家也感觉到了。

游戏网站FiringSquad曾撰文："游戏发行商和开发商，他们无一例外都在抱怨疯涨的开发费用，其中主要原因是美术团队的人数在呈几何级数增长。

"【注释01】据笔者分析，业界所面临的大量问题，都源于其使用的开发方法学。

目前人数超过100人的团队却仍在使用当年十个人搞定一切的方法学，而这些老的开发方法早就过时了。

传统的游戏开发所使用的方法学，需要在前期花费大量时间，定义功能，还经常需要在前期实现一些重要的元素，如游戏机制和关卡，一直延续到最后的疯狂赶工。

传统的方法学(通常称为瀑布模型)其实与一条生产装配线没有什么区别。

在生产线的前端开始把产品的各个部分拼凑在一起，而生产线的后端就在等待加工打磨，就是这等待的过程产生了问题。

游戏策划和发行商永远都无法获知游戏的真正感觉，比如他们早先制定的游戏机制是否正确，现行的实现是否完全遵循了早先的设计。

类似种种，最终造成了产品质量的下降…有另一种方法学正好可以解决传统游戏开发方法学带来的问题。

在产品研发流程和团队管理方式中，它被恰当地称为"敏捷方法学"。

敏捷开发注重于开发可供演示的游戏版本，并能很快地将其加入到产品中，以及在最重要的游戏元素和特性上按优先级创建垂直分片(vertical slice)。

敏捷也注重团队管理和处理其内部关系，以及团队完成项目目标的计划和周期。

游戏开发团队所面临的挑战可谓五花八门，而且由于职责有别，美术、程序和策划团队还要协同工作。

游戏项目的时间跨度也很长：短则一到两年，长则三年以上，甚至个别游戏需要五年乃至更长时间。

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

方法学方法学在大多数游戏设计或游戏开发的书籍中鲜有提及。

他们都假设大部分开发人员都无一例外地使用同一种做法，这种做法常被称为瀑布模型。

在瀑布模型中，工作都按照先后顺序安排，例如从项目需求或设计阶段到生产和实现。

在项目的早期阶段中，几乎没有迭代，这样就很难提供评估的机会。

不仅如此，一旦项目运行起来，要想返工就必定面临着覆水难收的局面。

在瀑布模型的游戏开发中，首先由游戏策划或者策划部成员编写游戏设计文档，其中会定义很多游戏机制和特性。

接下来这份设计文档被分解为小块部分，由制作人拿去丰富其中需求的功能和资产，之后对于功能和资产的需求就被分派到所有项目成员的头上。

接着就开始瀑布模型的流程了，这些需求瀑布式地流向动画、程序、关卡美术、人物美术、测试、特效等人的手上。

一旦某人或者某团队完成了一项特性，就将其交给下一个人或下个团队。

例如一个人物，由开始时的设定文档，到制作人或项目主管的手上，从这里它被细分为多个部分：人物模型和纹理贴图、人物动画、人物被击或者攻击时播放的特效以及驱动人物行为的人工智能技术，然后每个部门专注于各自分到的部分，完成实现直到可以进行组装。

然后，东西回到策划手里做调整，交给测试员进行测试，再让关卡策划在关卡中重现，之后退回各个部门进行除错。

在制作这个人物的同时，其他人或其它团队也在实现他们负责的部分。

同一天中，一个制作人员会同时针对几个不同的机制工作。

这种方法学的实质是一种沉淀作用，需要对大量的游戏机制同时进行加工。

敏捷开发上世纪90年代末，一批新型的软件开发方法学开始显露头角。

它们来自于各种团队的开发实践，从网页小程序到装备到美国国家航天局的应用系统都有。

每种方法学都有自己的注意事项，当然也受到来自各方的褒扬和批评。

虽然它们各有千秋，但其中的大多数方法学都有几点共通的基础。

2019年，在犹他，几位新型方法学的实践先驱们组织了一次峰会，峰会就中心意识形态达成普遍共识，并发表了共同宣言：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个月的项目。

团队开始于预制阶段，并把所有机制和资源所需的工作都逐一写入文档中。