游戏设计的敏捷方法学
作者：封烨（译）
原文链接为：gamasutra/view/feature/2742/paper_burns_game_design_with_.php
目前，业界弥漫着一股对次世代游戏开发的恐惧空气，GDC上谈，Game Developer杂志也谈。随着硬件能力的不断提升，开发更高自由度、更逼真的游戏成为业界追求的最新目标，为了实现这一目标，随之而来的一切也都在膨 胀：团队人数、美术资源需求、人时投资，当然啦，对投资者的资金需求也随之膨胀了起来。玩家的胃口越来越大。他们希望有更先进的技术以支持更好的游戏机 制、更细腻的建模、更高分辨率的纹理、更复杂的人工智能、更多的测试以及更好的质量保证，没完没了
而这种恐惧不仅蔓延了业界，就连媒体和玩家也感觉到了。游戏网站FiringSquad曾撰文：“游戏发行商和开发商，他们无一例外都 在抱怨疯涨的开发费用，其中主要原因是美术团队的人数在呈几何级数增长。”【注释01】据笔者分析，业界所面临的大量问题，都源于其使用的开发方法学。目 前人数超过100人的团队却仍在使用当年十个人搞定一切的方法学，而这些老的开发方法早就过时了
传统的游戏开发所使用的方法学，需要在前期花费大量时间，定义功能，还经常需要在前期实现一些重要的元素，如游戏机制和关卡，一直延续到最后的 疯狂赶工。传统的方法学（通常称为瀑布模型）其实与一条生产装配线没有什么区别。在生产线的前端开始把产品的各个部分拼凑在一起，而生产线的后端就在等待 加工打磨，就是这等待的过程产生了问题。游戏策划和发行商永远都无法获知游戏的真正感觉，比如他们早先制定的游戏机制是否正确，现行的实现是否完全遵循了 早先的设计。类似种种，最终造成了产品质量的下降……
有另一种方法学正好可以解决传统游戏开发方法学带来的问题。在产品研发流程和团队管理方式中，它被恰当地称为“敏捷方法学”。敏捷开发注重于开 发可供演示的游戏版本，并能很快地将其加入到产品中，以及在最重要的游戏元素和特性上按优先级创建垂直分片（vertical slice）。敏捷也注重团队管理和处理其内部关系，以及团队完成项目目标的计划和周期。游戏开发团队所面临的挑战可谓五花八门，而且由于职责有别，美 术、程序和策划团队还要协同工作。游戏项目的时间跨度也很长：短则一到两年，长则三年以上，甚至个别游戏需要五年乃至更长时间
这篇文章讲述了如何运用敏捷方法学和其中的Scrum方法学以应对上述的挑战，它可能特别适合于游戏开发人员，尤其是进行次世代开发的策划
方法学
方法学在大多数游戏设计或游戏开发的书籍中鲜有提及。他们都假设大部分开发人员都无一例外地使用同一种做法，这种做法常被称为瀑布模型。在瀑布 模型中，工作都按照先后顺序安排，例如从项目需求或设计阶段到生产和实现。在项目的早期阶段中，几乎没有迭代，这样就很难提供评估的机会。不仅如此，一旦 项目运行起来，要想返工就必定面临着覆水难收的局面
在瀑布模型的游戏开发中，首先由游戏策划或者策划部成员编写游戏设计文档，其中会定义很多游戏机制和特性。接下来这份设计文档被分解为小块部分，由制作人拿去丰富其中需求的功能和资产，之后对于功能和资产的需求就被分派到所有项目成员的头上
接着就开始瀑布模型的流程了，这些需求瀑布。