作者：Rory McGuire

行业对下一代开发技术的恐惧随处可见，它出现在饮水机上、出现在杂志中，人们在游戏开发者大会和《游戏开发者》杂志上讨论这个话题。随着硬件性能的不断增强，游戏逐渐变得更加昂贵和拟真化，所有的东西都在增加：团队大小、资产需求、时间投入和需要投资者提供的支持资金。用户也期望能获得更好的产品。他们想要更多有着更好功能和技术深度的机制，更密集的多边形艺术，更高的分辨率纹理，更复杂的AI以及更多的测试和QA等。

这种对下一代的恐惧不仅限于行业从业者。这种压力来源于用户，也在用户中蔓延。游戏站点FiringSquad.com说道：“行业内众多游戏发行商和开发商都在抱怨开发成本的攀升，主要原因在于需要大幅扩张美术团队来制作出所有可行的内容。”行业面对的多数问题的本质是他们采用了不当的产品方法论。近百人的团队还在使用10人团队的开发方法。我们其实可以更改和替换开发方法。

传统游戏开发使用的产品方法论是，花大量前端时间来确定意向功能，通常会同时执行机制和关卡等重要元素，最后进行润色。这种通常称为“瀑布”的方法论类似于生产线，前端负责将产品的各个部分拼接起来，后端等待对拼接完成的产品进行润色。这种等待便会产生问题。设计师和发行商无法得知游戏的真正感觉，比如他们最初对机制的评估是否准确，或者功能的执行与原计划是否存在偏差。这样的因素会影响到产品质量。

有个替代方案可以处理传统游戏开发方法论带来的这些问题。这种产品R&D过程和团队管理方式称为“敏捷方法论”。敏捷强调直接将游戏的可论证迭代融入制作过程中，将最关键的元素和功能的迭代优化提前。这种方法还强调了团队的组成和关系，以及团队必须计划和实现项目目标的循环。游戏开发团队会面对许多挑战，美术、工程和设计等不同层面面对的挑战也各不相同，他们需要合作。通向游戏项目完结的道路也非常漫长，较小的游戏需要开发1到2年时间，较大的游戏需要3年或更多的时间。

本文将分析敏捷方法和Scrum方法论，能够直接处理这些问题，它们可能特别适合于面对下一代主机游戏开发的综合性游戏开发者和设计师。

方法论

瀑布（Waterfall）

多数游戏设计或游戏开发书籍对方法论的叙述并不多。作者认为多数开发者使用的都是相同的方法，也就是所谓的“瀑布”。在瀑布方法中，工作持续朝一个方向发展，比如从项目需求或设计阶段到制作和执行阶段。早期阶段的迭代很少，评估的机会并不多。而且，就如同流水一般，但一旦展开工作，就难以颠倒。

在瀑布游戏开发中，游戏设计师或设计小组会先编写游戏设计文件，陈述游戏的许多功能和机制。随后，设计文件被分为许多部分，制作人从中找出所需的功能和资产。这些资产和功能元素的需求由参与项目的各个团队来满足。

因而，一旦展开瀑布方法，需求会流向动画、编程、关卡艺术、角色美工、QA和FX等。随后，每个个人或团队完成一项功能，然后提交成品。比如，设计文件中的角色被递交给制作人或项目主管。然后，它会被分解成各个成分：角色的纹理、动画、被击中时角色呈现出的效果以及攻击或空闲时的模样，最终用AI技术来强化角色。每个部门专注于完成属于自己的成分，然后执行，直到其完成。

然后，结果会回到设计师手中进行调整，递交给QA完成测试，提交给关卡设计师放入关卡中，然后回到各部门手中完成漏洞调试工作。在这个角色的制作过程中，其他个人和团队正致力于完成他们手中的机制。同一天的时间里，单个开发者可能需要处理多种不同的机制。这种方法论的本质是逐渐渗透，游戏的许多机制从0开始，随着时间渐渐完善。

敏捷

上世纪90年代末期，许多新的软件开发方法论开始出现，这些方法论来源于从网页applet开发到系统动力NASA航空等各种团队。每种方法论都有其自身的优点和缺点，尽管各有不同，但是多数方法论之间都存在许多共同点。

2001年，许多曾参与过这些方法论制作的人在犹他州召开大会。此次大会得出了一个中心思想体系和一则宣言：

1、一个可运行软件的价值要高于陈述软件功能的文件。

2、与客户定期合作的价值要高于陈述产品功能的合约。

3、个人解决问题的价值要高于进程或工具。

4、最重要的是，它们的价值随计划的进展而改变。

执行凌驾于文件记录之上、利用客户合作以及解决问题和改变的能力，这就是敏捷性。敏捷方法论的中心原则很简单，但是却有着丰富的内涵，它可以用于任何复杂的产品开发系统中。

Scrum

随着敏捷开发使用的普及，出现了各种不同的方法论。有些来源于敏捷，有些是已经被人用过却从未完全定义或运用到软件开发中的系统。scrum便是此类方法，这种生产R&D的方法来源于日本汽车和消费电子制造业。从定义上来说，scrum指橄榄球比赛中的一种调遣方法，即队伍中的每个人都参与到移动球的动作中。

作为一种方法论，这种精神也可以被运用到产品开发中，项目团队被重新划分组织成小团队，这些小团队密切配合，完成项目的某个具体成分。迭代开发受到重视，项目被划分成可被呈现、测试和功能评估的“可运载”成分。

scrum的主要原则之一是，团队中的每个人都参与到过程中。scrum将制作过程分解成短期工作循环，称为sprint。在每个sprint开始时，这个项目团队确定目标，自我组织进入小scrum团队。scrum团队由不同类型的成员组成，包括美术设计师、设计师和程序员。每个团队的目标由项目管理者、制作人和发行人在计划会议上确定，但团队可以自行决定实现sprint目标的方法和途径。一旦进入sprint，团队就可以完全自行管理他们的日常计划和任务执行。

熟悉scrum的人经常会提到，项目会因这种方法也受到拖延。对于这种情况，sprint期间各scrum团队召开每日会议便成了scrum方法的重要成分。会议可以短至5到10分钟，其目的是确保工作朝着正确的方向、识别过程中遇到的各种障碍以及每日取得的进展能够被参与项目的所有人所了解。这样的做法会让团队成员产生归属感，项目进展的透明性也会让团队成员明白自己的义务，最终使制作效率得到提升。

因为团队都是自发组成的，所以日常的评论能够让所有团队锁定正确的目标，让所有人都能够了解产品最真实的现状，包括外观和表现。每个sprint完成后，团队阐述其获得的成就，他们的产品拥有者或“客户”（游戏邦注：比如工作室管理者和发行商）可以对这个过程进行评估。随后，客户决定需要在下个sprint优先完成的目标。

（图1：scrum的简单图示。游戏功能被程序员、美术人员和设计师分解成独立的任务，随后他们在两周到一个月的时间内完成这些任务。他们既要为自己的任务负责，也要在日常会议中为其他人的任务提出看法。迭代完成后，对结果进行评述，项目总监和发行商根据最新的工作情况决定下一个优先迭代的目标。）

在接受他们客户的评论时，这些团队的目标是展示游戏的“垂直分片”（vertical slice），比如关卡集、完整的可玩机制或协调适当的功能。尽管单次迭代无法完成所有机制，但是团队可以专注于一项机制。比如，AI角色很难在单次srint内完成。但是该AI角色的单个行为可以在单次sprint中编程、制作动画、配音和添加到关卡中，最终得到可以被测试的产品。

记住这两个元素，客户可以查看产品，了解已经完成的内容、正在进展中的工作以及产品开发进展速度。客户不需要猜测或盲目信任，他们能够看到直接的成品，而且往往可以拿起控制器体验游戏结果，而不是盯着数据表或线框图。scrum还让客户可以更自由地处理多个迭代进程。

如果制作和评估的成品与预期效果有出入，客户在sprint期间有空间改变项目目标。因为scrum的迭代过程和sprint的短期工作循环，重新确定项目目标几乎不会导致大量工作和时间的浪费。

瀑布与scrum

瀑布开发给游戏设计师带来的问题是，只有当对象的所有元素都构建完成并拼接起来时，他们才能从全局来衡量对象的效果和价值。比如，设计师或许需要构建文件中描述的围绕AI的关卡。参考设计文件，设计师发挥自己的想象和猜测，让经验丰富的人给自己提建议和评估成果，最终将关卡提交给美术人员开始构建各种元素。设计师及其主管知道没有人真正体验过角色，但是为了保证制作的流畅开展，设计师和关卡美术设计师必须假定AI能够像预想的那样发挥作用。但是，尽管工作继续开展下去，问题依然存在。

假如负责制作角色的程序员发现，文件中陈述的AI机制无法实现，那又如何呢？如果AI运转良好，但动画无法让机制恰当地呈现出来，那又如何呢？如果负责角色的设计师意识到，某个功能并不有趣，那又如何呢？对于这些问题，答案无疑是浪费共更能、浪费精力和时间、浪费开发预算甚至导致团队成员对项目失去信心。从开发进程的角度来看，最可能出现的结果可总结为：产品质量下降。

瀑布方法产生的另一个问题是，当部门相互赶超，会出现“匆忙和等待”的情况。每个人都在尽可能快地完成自己的任务，然后等待下一个目标。可以想象下，这条装配线上带子的移动速度不时发生变化，有时完全停下来，有时以合理的速度和节奏运行，偶尔却会显得格外疯狂。生产过程中这种不规律的节奏对制作人、财务负责人和所有项目参与者都不利。对于设计师来说，它会从根本上影响他们的工作。反复无常的流程会影响产品的功能和质量，尤其是需要融合多种不同元素的功能。

比如，思考下游戏中的恐怖机制，玩家因忽然遭遇邪恶的BOSS而受到惊吓。这样的机制需要靠细微之处的设计才能获得成功，设计团队需要测试、评估、迭代并完善美术、音效和剧本。这些过程绝对不能在团队对产品整体情况毫不知情的情况下完成。

瀑布方法总是会让设计师处在不良的情境中，虽然游戏的篇幅和广度在项目初期就已经确立，但镜头、控制和AI等组成游戏最重要动态的深度却渗透缓慢，只在接近项目末期时才呈现出完整的形态。在图2中，我们可以看到某个范例项目，机制被提交到各个部门手中，他们分别处理属于自己的片段，意图在几个月后呈现出完整的产品。

上述情景是项目的典型传统做法。完成游戏的预制作后，他们投入到设计文件所列举的机制和资产制作中。根本问题在于，所有人都以为这些机制最终的结果都将同设计文件保持一致。

描述瀑布项目进程的另一种方法是，用曲线来呈现产品已完成功能随时间的进展情况，如图3所示。项目时间线右侧是提交给发行商的时间，它是固定的。随着开发的进展，在项目进入至关重要的末期阶段时，游戏机制开始呈现出最终的形态和功能。

假如当项目几近结束，需要提交时，却发现某些至关重要的成分无法发挥之前计划的功能，那又怎么办呢？因为提交时间是固定的，所以出现上述情况要么意味着需要加班加点，要么就是删除项目中与这些功能相关的所有资产和内容。最终导致的结果是，团队浪费了资源、资产和经历，产品质量也受到了影响。

scrum和瀑布的最根本性差别在于，scrum的交流层次是建立在日常协作的基础上，项目期间各团队都会开展交流和商讨。在上述瀑布范例中，我们的设计师在围绕AI构建关卡时，使用的是描述角色样式的文件和自身的想象力。如果在同样的范例中使用scrum，设计师就能够同团队其他成员合作。比如，设计师说出了自己的目标：我需要能够让我更容易进行导航迭代的AI。那么，下个阶段就是直接通程序员合作实现目标。

设计师和程序员配合，尝试不同的做法，寻找最佳的技术，以使AI表现出意向行为。如果程序员遇到了障碍，因为设计师也参与到这个过程中，所以他可以直接更换其他解决方案。这种方法并不局限于设计师同程序员间的合作。同样的方法还可以运用于，设计师同动画师配合完成对角色移动的设计，或者同环境美术人员配合完成关卡布局工作。最终的结果是能够得出较好的解决方案，因为scrum确保了所有任务参与者都能够协调配合。

scrum的想法是，负责制作和执行的人对目标和可能遇到的障碍最为熟悉。对于角色移动所需的动画的了解，谁能够超越动画师？对于如何让AI移动到特定地点的了解，谁能够超越程序员呢？

通过明确设计最终目标，它让设计师和执行功能或关卡的人之间有了交流的机会，同时让所有参与者都能够有机会提出实现目标的最佳方法。对于技术和美术的了解，设计师不及程序员和美术人员。我们能够做的就是确定短期目标，并在数周的时间里配合团队完成制作，然后对最终结果进行评价，决定是否使用。这种对小片段快速迭代的强调使最终产品和设计师均获益匪浅。

通过快速迭代，设计师可以在短时间内看到完整的机制。这让设计师可以迅速发现机制的状态以及游戏开发的前进方向。对于首席设计师和项目主管来说，他们每数周就能够了解项目的进展情况，在每月与团队的交流中就能够发现他们的努力是否会满足自己的最终目标。

因为每个独立的功能都由某个团队来完成，所以如果被删减不会影响到之前已经制作完成的内容。在独立功能被融入整个开发流程之前，对其进行更改不会导致工作时间和精力的浪费。

对于关卡设计师来说，这也意味着他们可以围绕已证实有效和有趣的机制来构建关卡。设计师随后可以回到某个关卡或区域，为其添加新功能，但在此之前游戏也可以先期推向市场。

专注于单个机制而不是分别制作并相互渗透，这种做法似乎会令人感到害怕。但是，应当注意到是，基础机制和关卡构建是游戏走出工作室必要条件。额外的功能能够为游戏填色，但是并非如此至关重要。优先构建最重要的东西而不是将其放在项目末期，意味着内容制作者（游戏邦注：比如设计师）能够直接围绕具体功能构建关卡。

此外，在项目早期获得功能性中心机制意味着，游戏无需依赖于那些可能被删减的机制，这些内容可以根据客户的需要进行删减或扩展。而且，产品拥有者和设计师可以决定哪些功能对游戏最有效，然后将其确定下来，包括更多用来呈现游戏中功能出众之处的内容。

随着时间的不断延长以及未尝试技术和硬件等更多因素的出现，发行商和投资者面对复杂情况时的思维逐渐从“让我们来尝试下！”转变为“我也不知道该怎么做。”下一代游戏开发的成本会进一步增加，所以出现上述反应是合理的。

如果使用scrum，产品拥有者和发行商可以通过多次迭代来规避风险。如果未曾证实有效的功能或游戏概念确实无法发挥作用，那么团队可以迅速进行重新评估并做出改变。如果那些功能有非凡的表现，团队和产品拥有者可以决定专注于游戏的这些层面，甚至让游戏开发朝全新的方向发展。

而且，随着开发时间的增加，产品面向的市场也在不断发生变化。新颖的想法会迅速变得稀松平常，因为其他同类产品会迅速在市场中出现。scrum让发行商和设计师带领产品远离竞争，同时将转变的风险降到最低。如果产品功能需要发生改变，或者出现游戏项目需要完全取消这种最糟糕的情景，发行商失去的也就是两周到两个月的时间，而不是两个季度或两年。

总结

在scrum这样的敏捷方法论中，游戏设计师能够获得众多的好处。项目主管和首席设计师可以定期看到项目的整体进展情况，他们要面对的不是抽象的表格和数据，而是可以亲身体验。对于关卡设计师，他们可以专注于围绕现有机制构建关卡。如果使用scrum，关卡设计师可以使用完整的机制，也就不用进行无谓的猜想。

scrum可以让游戏开发中的所有人受益，不只是设计师，因为它可以讲“死亡竞速”降到最小。发行商和项目主管可以审核每次迭代中的团队表现，意味着他们可以安全的预测团队未来的表现情况。

最重要的是，使用敏捷方法论和scrum让设计师可以同执行功能和技术的人协调配合。对话、提问和交流能够使问题实现有机的跨部门解决。这样团队就可以事先排除可能导致浪费时间和精力的臆断，通过协作让游戏开发产生最佳结果。

游戏邦注：本文发稿于2006年6月28日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Paper Burns: Game Design With Agile Methodologies

Rory McGuire

A fear of next generation development can be seen everywhere; it’s at the water cooler, it’s in magazines, it’s talked about at the Game Developers Conference and in Game Developer Magazine. With increased hardware capacity allowing for ever more expansive and immersive games, everything is growing: Team sizes, asset requirements, person hour investment, and of-course required capital from investors to support it all. Audiences are also expecting more. They want more mechanics with greater functional and technical depth, denser polygon art, higher resolution textures, more complex AI, more testing and quality assurance, and the list goes on.

This fear of the next generation is not confined to the industry. The press has caught, and with them the consumer. Game site FiringSquad.com said, “Game publishers and developers industry-wide are complaining of ballooning development costs, mostly due to art teams that have to grow exponentially to create all the content that’s possible.” A vast majority of the problems facing the industry are deep seated in the very production methodology that is employed. Teams of approximately 100 people are still using methodologies developed for a time when ten people were considered a bloated team. There are alternatives.

Traditional game development uses a production methodology that spends a lot of front-end time, defining intended functionality, often with implementation of important elements such as mechanics and levels waiting around until the mad scramble at the end. The traditional methodology, often called Waterfall, isn’t dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish. The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn’t end up to original specifications. Factors like these are what degrade product quality..

One alternative addresses exactly these problems with traditional game development methodology. It is, a product R&D process and team management style aptly referred to as Agile Methodology. Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives. The challenges faced by game development teams can be numerous and as varied as the divide between the discipline, such as art, engineering and design, that need to work together. The road to the end of game projects is also long; short games are in development for one to two years, bigger titles are running the gamut from a three years, and in exceptional cases up to five or more.

This paper will cover how the Agile method and a specific methodology, Scrum, can directly address these challenges, and perhaps are especially suitable for the complexity game developers, and explicitly designers, face with next-gen console development.

Methodologies

WATERFALL

Most game design or game development books contain very little about methodology. They assume the vast majority of developers use the exact same approach, a method often referred to as Waterfall. In the Waterfall approach work moves sequentially in one direction, such as from a project requirements or design phase to production and implementation. There is very little iteration in the early phases, leaving little opportunity for evaluation. What’s more, much like running water, once the sequence is in progress the process is not easily reversed.

In Waterfall game development, a game designer or group of game designers will first create the game design document, where they lay out many of the features and mechanics. The design document is then broken up into smaller chunks which producers use to extract required functionality and assets. The requirements for these assets and functionality elements span the spectrum of teams involved in the project.

Thus begins the sequence of the Waterfall method, as the requirements “flow down” to animation, programming, level art, character art, QA, FX, etc. This continues as once an individual or team is done with a piece of a feature, they then hand it to another. A character, for example, would begin with the design document and get handed to a producer or a project director. From there, it would be broken out into its components: The mesh and texture of the character, the animation, the effects the character plays when hit, attacking or idling and finally the AI technology which powers the character. Each department focuses on its component, then work to implement it until its bears some semblance of completion.

It’s then moved back to the designer for tuning, handed off to QA for testing, to the level designers to populate in levels, then bounced back to various departments for bug fixes. While this character is being worked on, other individuals and teams are working on their pieces of specific mechanics. In the same day, a single developer may work on pieces of several different mechanics. The nature of the methodology is a percolation, where the game’s many mechanics are brought from the ground up over time.

AGILE

In the late 1990s, a number of new software development methodologies began surfacing, derived from teams ranging from web applet development to systems powering NASA flights. Each methodology possessed its own do’s and don’ts, its own mantras and blasphemies, yet despite their variances, a majority of them had several fundamental things in common.

In 2001, several of the those who had helped spawned the half dozen or so methodologies in use organized a summit in Utah. The result was a central ideology, and a manifesto to go along with it:

A working piece of software had more value than a document that indicated what the software should do.

Regular collaboration with customers was valued more than extensive contracts that outlined the intended usage of a product up front.

Value individuals solving problems rather than processes or tools.

And most importantly, they valued responding to change over following a plan.

Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The central tenets to Agile Methodology were short, but they had large implications, and they were applicable to any complex product development system.

SCRUM

As use of Agile development grew, a number of different methodologies surfaced. Some were derived from Agile, others were systems that had been in use but never fully defined or applied to software development. One such method was Scrum, an approach to product R&D which had its roots in Japanese car and consumer electronics manufacture. By definition, scrum refers to a maneuver in rugby where everyone on the team is involved in an action to move the ball.

As a methodology, the same approach is applied to product development in spirit, where project teams are reorganized into small teams that work closely together on specific components of a project. Iterative development is stressed, with the project divided into components that are “shippable” pieces that can be demonstrated, tested and evaluated for functionality.

One of the principal tenets in Scrum is that everyone on the team is involved in the process. Scrum breaks down production into short work cycles called Sprints. At the beginning of each Sprint, the entire project team meets to create objectives and self-organize into small Scrum teams. The Scrum teams are interdisciplinary, with artists working alongside designers working alongside programmers. Though the goal of each team is determined by project managers, producers and publishers at the planning meetings, the teams ultimately decide the path they will use to achieve their goals for the Sprint. Once into the Sprint, the teams are completely self-managed in their daily planning and execution of tasks.

As recited often by those familiar with Scrum, projects become delayed one day at a time. For this reason, a critical component of Scrum is daily meetings among individual Scrum teams throughout the Sprint. The meetings can be as brief as 5-10 minutes, and are designed to ensure that objectives are on track, any impediments to progress are recognized, and daily accomplishments are seen by everyone involved. The process creates a sense of ownership among every member of the team, and its transparency is designed to create accountability among team members that ultimately boosts productivity.

With the team self organizing, regular reviews keep the team on target and give everyone a full diagnostic of the product in the purest form possible; how it looks and performs. At the completion of every Sprint, the teams conduct reviews that demonstrate their accomplishments, and allow their product owners or “customers,” such as studio managers and publishers, to evaluate progress. The customers can then determine what the priorities are for the next Sprint.

(Graphic01: A simple visualization of Scrum. Game features are broken down into individual tasks by programmers, artists and designers, they then work on these for an iteration of two weeks to a month, accounting for their tasks and to each other in a daily meeting. At the end of the iteration a product review occurs of all work done for that iteration where project directors and publishers can determine how to prioritize the next iteration based on the work done in the latest.)

The goal for these teams when reviewing with their customers is to demonstrate a “vertical slice” of the game, as in a piece of a game such as a single level hub or a completely playable mechanic or a tuned feature. While not all mechanics can be delivered in a single iteration, the individual pieces of them become the vertical slices that teams focus on. For example, an AI character is very difficult to deliver in a single Sprint. Yet a single behavior of that AI character can be fully programmed, animated, have sound attached to it, be deployed in a level, etc., resulting ultimately in something that can be tested.

With these two elements in mind, a customer can look at a product and see exactly what’s been achieved, where it’s going, how fast production is progressing, etc.. A customer does not need to guess or have faith, they can see a direct diagnostic, and often by picking up a controller rather than looking at spreadsheets or wireframes. Scrum also gives customers flexibility from iteration to iteration, just as it does product teams.

Customers have room to redirect project goals between Sprints if what’s been created and evaluated is not living up to expectations. And because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.

Waterfall vs. Scrum

Waterfall development creates a problem for game designers in that no object can be considered complete until all of the dependencies on that object have also been built and moved into the process. For example, a designer may build a level centering around AI which exists solely in documentation. Using the design document as reference, the designer makes a best guess, has it evaluated by seniors, and hands off the level to an artist to begin building the meshes. The designer and his managers know that no one has actually got to experience the character enough to design a level around it, but in order to keep production flowing the designer and level artist will have to assume the AI will work as promised. But while the work continues, the questions remain.

What if the programmer for the character determines that getting the AI mechanic to work as documented isn’t attainable? What if the AI works, but animation can’t get the mechanic to look right? What if the designer responsible for the character realizes that the functionality isn’t fun? Answers in the negative to these questions mean lost functionality, lost person-hours, some portion of the development budget wasted, even a psychological outcome such as loss of faith in the project. Whatever the drawback to the development process, it is best summed up in its most likely outcome: Degraded product quality.

Another substantial problem with Waterfall occurs when departments outpace each other, resulting in a “hurry up and wait” situation. Everyone is going as fast as they can when their piece of the Waterfall is in their lap, then waiting for the next piece when their portion is complete. Imagine an assembly line where the belts moved at variable speeds, sometimes completely stopped, other times moving at a comfortable pace and occasionally blazing. A chronically irregular pace during production has downsides for producers, financial officers and just about everyone involved. For designers it affects their job at a fundamental level. Inconsistent progress can substantially affect the functionality and quality of essentially any features that require different elements to come together.

For instance, consider a horror mechanic in a game, such as a moment when the player is surprised by a vicious boss encounter. A mechanic such as this relies on nuances for its success, and for a design team to test, evaluate and, as is nearly always needed, reiterate, they need finished art, sound and scripting. It certainly can’t be tested in a black box.

Waterfall will always put designers at a disadvantage, simply because while the breadth of a game is established at the project outset, the depth that makes up the game’s most important dynamics such as camera, tuned control, A.I., etc., “percolate” slowly and begin to take final shape only near the end of the project. In Graphic02 we can see a demonstration of this for a sample project, where mechanics have been handed off to various departments who are working on individual pieces, with the intention of delivering the finished product several months down the line.

(Graphic02: Progress at eight month mark on a sample project using Waterfall.)

The scenario is quite typical of a project at eight months. The team has moved out of pre-production and has laid the ground work for all the mechanics and assets outlined in the design document. The fundamental problem occurs in the assumption that all of these mechanics will be delivered and delivered well.

Another way to depict the progression of a Waterfall project is as a curve representing a product’s finished functionality over time, as depicted in Graphic03. Here, the right side of the timeline on the project is the delivery date -submission to a first party, handing over a master to the publisher, etc. It is immovable, the veritable brick wall. As development progresses, the game’s mechanics begin to take final form and function as promised during the critical final phases of the project.

(Graphic03: Finished functionality over time.)

What if as the team nears that brick wall, critical components do not function as promised? The inevitabilities are death marching, or cutting features late in the project along with the all the assets and content dependent on those features. The ultimate result is wasted resources, assets and person-hours, and quite likely, degraded product quality.

The most fundamental difference between Scrum and Waterfall is the level of communication Scrum establishes through daily collaboration towards goals approaching in a span of weeks instead of years. In the Waterfall example, our designer was building a level centering around A.I. using documentation and assumptions on how the character might be delivered. Applying Scrum to the same example, the designer works hand-in-hand with members of the team. For instance, the designer declares the goal: “I need AI to behave in a way that lets me easily iterate on its navigation.” The next step is working directly with programmers.

Together, the designers and programmers investigate options, coming to a consensus on what is the best technology to implement to get the desired behavior. Should the programmers run into impediments, the designer is imbedded in the process and able to have direct input on any alternative solution. The approach is not confined to how designers work with programmers. The same pipeline applies to, for instance, a designer iterating on how a character moves with animators, or how a level is laid out with environment artists. The end result is going to be better solutions, with Scrum ensuring that those who need to be part of the process have input.

Scrum presumes that the people creating and implementing the work are going the most knowledgeable on how to get to a goal and where the landmines are on the way there. Who would know more about the animations needed for a character to move than the animator? Who would know more about how the A.I. moves to a position than a programmer?

By simply declaring the spirit and end goal of the design it opens a dialogue between designers and the individuals implementing the feature or level, which in turn lets all parties involved figure out the best method to achieve the goal. Designers aren’t programmers or artists so presuming we know the best path in all methods of technology and art is foolish. What we can do is determine a short goal and work with the team over a couple of weeks, then review the product and determine if it’s up to snuff. An emphasis on rapid iterations in small pieces benefits the end product and designers immensely.

Through rapid iteration designers are able to watch whole complete mechanics come online in very short order. This lets designers immediately see the status of a mechanic and where the game is heading. For lead designers and project directors, this let’s them get a status check every few weeks on exactly the destination of the project and have a month to month diagnostic on a team’s progress and whether or not they should meet their end goals.

Because a team is delivering entire vertical slices features can be cut without immediate repercussions to previously made content. No dependent features have moved into development which means that scope can be reduced with a clear conscience and without wasted work.

For level designers this also means that their levels can be built around mechanics that are proven and fun in and of themselves. While a designer can return to a level or area at a later time to layer in new functionality as it comes online, the game can ship without them doing so. Moreover if the level is fun with the things the designer has, imagine how it’ll play when the designer get the things he doesn’t have.

It may seem scary to focus on individual mechanics instead of getting everything to bare bones functionally and then letting it percolate. Yet, note that the fundamental mechanics required to ship the game and build levels are the first out of the door, as determined by the product owner. Additional features which add spice to the game but are not critical can be layered in. Building the most important things first instead of receiving them at the very end means that content creators (such as designers) can directly build levels around a specific functionality.

Moreover, attaining functionality central mechanics early means there are no dependencies on mechanics that may need to be cut; scope can always be cut or expanded to suit the customer’s needs. Additionally, product owners and designers can determine what features are working best and then “hammer down” on them, including more content that uses the functionality to showcase it better in the game.

Rapid iterations also minimize an increasing trend in the industry: Risk aversion.

With bloated schedules, more investment and factors such as untried technology and hardware, publishers and investors face far more complications with a mentality of “Let’s try it!” to one of “I don’t know about that.” As costs rise for investors moving into the next generation, this is a perfectly reasonable and expected response.

Using Scrum, product owners and publishers can follow risky goals for a several iterations. If unproven features or game concepts don’t pan out, the team can easily re-evaluate and redirect. If those features are a hit out of the park, the team and the product owner can decide to concentrate on those aspects of the game, and even take the game in a completely new direction.

Also, as development time increases, the product can face a changing market. What may have been a fresh idea can rapidly become stale as competing titles beat your project to market. Scrum let’s publishers and designers separate their title from the competition with very little risk involved. If product features need to be changed, or in a worst case scenario a game has to be completely cancelled, the publisher loses two weeks to two months instead of two quarters to two years.

Conclusion

Within Agile methodologies such as Scrum, game designers gain a tremendous number of benefits. Individuals such as project directors and lead designers can see whole complete pieces at regular intervals, and instead of measuring progress by abstracts they can measure it by putting their thumbs on a controller. For level designers, they are able to build levels that focus around existing mechanics. Using Scrum, those mechanics are online and taken to their fullest extent so the levels the designers do create are part of a complete whole, with a better view of how the mechanic is going to look on disk.

One feature of Scrum that benefits everyone in game development, not just designers, is a minimization of “crunches” and “death marches.” Publishers and project leads are able to get diagnostics on the team’s performance every iteration, meaning they can safely predict how a team will perform. Within a methodology like Waterfall where features percolate, any aspect of the game that isn’t up to snuff has to be “crunched on” to ensure the game is shipped.

Most importantly, using Agile methodologies and Scrum puts designers at the table with the individuals implementing features and technology used to power the game. Conversations are initiated, questions are asked, dialogue and cross department problem solving occurs organically. Assumptions that lead to wasted time and effort are checked at the door, and a collaboration can be reached that gets the best game out in the most efficient way possible. (Source: Gamasutra)