行业对下一代开发技术的恐惧随处可见，它出现在饮水机上、出现在杂志中，人们在游戏开发者大会和《游戏开发者》杂志上讨论这个话题。随着硬件性能的不断增强，游戏逐渐变得更加昂贵和拟真化，所有的东西都在增加：团队大小、资产需求、时间投入和需要投资者提供的支持资金。用户也期望能获得更好的产品。他们想要更多有着更好功能和技术深度的机制，更密集的多边形艺术，更高的分辨率纹理，更复杂的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优先完成的目标。
在接受他们客户的评论时，这些团队的目标是展示游戏的“垂直分片”(vertical slice)，比如关卡集、完整的可玩机制或协调适当的功能。尽管单次迭代无法完成所有机制，但是团队可以专注于一项机制。比如，AI角色很难在单次srint内完成。但是该AI角色的单个行为可以在单次sprint中编程、制作动画、配音和添加到关卡中，最终得到可以被测试的产品。
记住这两个元素，客户可以查看产品，了解已经完成的内容、正在进展中的工作以及产品开发进展速度。客户不需要猜测或盲目信任，他们能够看到直接的成品，而且往往可以拿起控制器体验游戏结果，而不是盯着数据表或线框图。scrum还让客户可以更自由地处理多个迭代进程。
如果制作和评估的成品与预期效果有出入，客户在sprint期间有空间改变项目目标。因为scrum的迭代过程和sprint的短期工作循环，重新确定项目目标几乎不会导致大量工作和时间的浪费。
瀑布与scrum
瀑布开发给游戏设计师带来的问题是，只有当对象的所有元素都构建完成并拼接起来时，他们才能从全局来衡量对象的效果和价值。比如，设计师或许需要构建文件中描述的围绕AI的关卡。参考设计文件，设计师发挥自己的想象和猜测，让经验丰富的人给自己提建议和评估成果，最终将关卡提交给美术人员开始构建各种元素。设计师及其主管知道没有人真正体验过角色，但是为了保证制作的流畅开展，设计师和关卡美术设计师必须假定AI能够像预想的那样发挥作用。但是，尽管工作继续开展下去，问题依然存在。
假如负责制作角色的程序员发现，文件中陈述的AI机制无法实现，那又如何呢？如果AI运转良好，但动画无法让机制恰当地呈现出来，那又如何呢？如果负责角色的设计师意识到，某个功能并不有趣，那又如何呢？对于这些问题，答案无疑是浪费共更能、浪费精力和时间、浪费开发预算甚至导致团队成员对项目失去信心。从开发进程的角度来看，最可能出现的结果可总结为：产品质量下降。
瀑布方法产生的另一个问题是，当部门相互赶超，会出现“匆忙和等待”的情况。每个人都在尽可能快地完成自己的任务，然后等待下一个目标。可以想象下，这条装配线上带子的移动速度不时发生变化，有时完全停下来，有时以合理的速度和节奏运行，偶尔却会显得格外疯狂。生产过程中这种不规律的节奏对制作人、财务负责人和所有项目参与者都不利。对于设计师来说，它会从根本上影响他们的工作。反复无常的流程会影响产品的功能和质量，尤其是需要融合多种不同元素的功能。
比如，思考下游戏中的恐怖机制，玩家因忽然遭遇邪恶的BOSS而受到惊吓。这样的机制需要靠细微之处的设计才能获得成功，设计团队需要测试、评估、迭代并完善美术、音效和剧本。这些过程绝对不能在团队对产品整体情况毫不知情的情况下完成。
瀑布方法总是会让设计师处在不良的情境中，虽然游戏的篇幅和广度在项目初期就已经确立，但镜头、控制和AI等组成游戏最重要动态的深度却渗透缓慢，只在接近项目末期时才呈现出完整的形态。
上述情景是项目的典型传统做法。完成游戏的预制作后，他们投入到设计文件所列举的机制和资产制作中。根本问题在于，所有人都以为这些机制最终的结果都将同设计文件保持一致。
描述瀑布项目进程的另一种方法是，用曲线来呈现产品已完成功能随时间的进展情况，如图3所示。项目时间线右侧是提交给发行商的时间，它是固定的。随着开发的进展，在项目进入至关重要的末期阶段时，游戏机制开始呈现出最终的形态和功能。
假如当项目几近结束，需要提交时，却发现某些至关重要的成分无法发挥之前计划的功能，那又怎么办呢？因为提交时间是固定的，所以出现上述情况要么意味着需要加班加点，要么就是删除项目中与这些功能相关的所有资产和内容。最终导致的结果是，团队浪费了资源、资产和经历，产品质量也受到了影响。
scrum和瀑布的最根本性差别在于，scrum的交流层次是建立在日常协作的基础上，项目期间各团队都会开展交流和商讨。在上述瀑布范例中，我们的设计师在围绕AI构建关卡时，使用的是描述角色样式的文件和自身的想象力。如果在同样的范例中使用scrum，设计师就能够同团队其他成员合作。比如，设计师说出了自己的目标：我需要能够让我更容易进行导航迭代的AI。那么，下个阶段就是直接通程序员合作实现目标。
设计师和程序员配合，尝试不同的做法，寻找最佳的技术，以使AI表现出意向行为。如果程序员遇到了障碍，因为设计师也参与到这个过程中，所以他可以直接更换其他解决方案。这种方法并不局限于设计师同程序员间的合作。同样的方法还可以运用于，设计师同动画师配合完成对角色移动的设计，或者同环境美术人员配合完成关卡布局工作。最终的结果是能够得出较好的解决方案，因为scrum确保了所有任务参与者都能够协调配合。
scrum的想法是，负责制作和执行的人对目标和可能遇到的障碍最为熟悉。对于角色移动所需的动画的了解，谁能够超越动画师？对于如何让AI移动到特定地点的了解，谁能够超越程序员呢？
通过明确设计最终目标，它让设计师和执行功能或关卡的人之间有了交流的机会，同时让所有参与者都能够有机会提出实现目标的最佳方法。对于技术和美术的了解，设计师不及程序员和美术人员。我们能够做的就是确定短期目标，并在数周的时间里配合团队完成制作，然后对最终结果进行评价，决定是否使用。这种对小片段快速迭代的强调使最终产品和设计师均获益匪浅。
presubmission quality(from gamaustra)
通过快速迭代，设计师可以在短时间内看到完整的机制。这让设计师可以迅速发现机制的状态以及游戏开发的前进方向。对于首席设计师和项目主管来说，他们每数周就能够了解项目的进展情况，在每月与团队的交流中就能够发现他们的努力是否会满足自己的最终目标。
因为每个独立的功能都由某个团队来完成，所以如果被删减不会影响到之前已经制作完成的内容。在独立功能被融入整个开发流程之前，对其进行更改不会导致工作时间和精力的浪费。
对于关卡设计师来说，这也意味着他们可以围绕已证实有效和有趣的机制来构建关卡。设计师随后可以回到某个关卡或区域，为其添加新功能，但在此之前游戏也可以先期推向市场。
finished functionality(from gamasutra)
专注于单个机制而不是分别制作并相互渗透，这种做法似乎会令人感到害怕。但是，应当注意到是，基础机制和关卡构建是游戏走出工作室必要条件。额外的功能能够为游戏填色，但是并非如此至关重要。优先构建最重要的东西而不是将其放在项目末期，意味着内容制作者(游戏邦注：比如设计师)能够直接围绕具体功能构建关卡。
此外，在项目早期获得功能性中心机制意味着，游戏无需依赖于那些可能被删减的机制，这些内容可以根据客户的需要进行删减或扩展。而且，产品拥有者和设计师可以决定哪些功能对游戏最有效，然后将其确定下来，包括更多用来呈现游戏中功能出众之处的内容。
随着时间的不断延长以及未尝试技术和硬件等更多因素的出现，发行商和投资者面对复杂情况时的思维逐渐从“让我们来尝试下!”转变为“我也不知道该怎么做。”下一代游戏开发的成本会进一步增加，所以出现上述反应是合理的。
如果使用scrum，产品拥有者和发行商可以通过多次迭代来规避风险。如果未曾证实有效的功能或游戏概念确实无法发挥作用，那么团队可以迅速进行重新评估并做出改变。如果那些功能有非凡的表现，团队和产品拥有者可以决定专注于游戏的这些层面，甚至让游戏开发朝全新的方向发展。
而且，随着开发时间的增加，产品面向的市场也在不断发生变化。新颖的想法会迅速变得稀松平常，因为其他同类产品会迅速在市场中出现。scrum让发行商和设计师带领产品远离竞争，同时将转变的风险降到最低。如果产品功能需要发生改变，或者出现游戏项目需要完全取消这种最糟糕的情景，发行商失去的也就是两周到两个月的时间，而不是两个季度或两年。
总结
在scrum这样的敏捷方法论中，游戏设计师能够获得众多的好处。项目主管和首席设计师可以定期看到项目的整体进展情况，他们要面对的不是抽象的表格和数据，而是可以亲身体验。对于关卡设计师，他们可以专注于围绕现有机制构建关卡。如果使用scrum，关卡设计师可以使用完整的机制，也就不用进行无谓的猜想。
scrum可以让游戏开发中的所有人受益，不只是设计师，因为它可以讲“死亡竞速”降到最小。发行商和项目主管可以审核每次迭代中的团队表现，意味着他们可以安全的预测团队未来的表现情况。
最重要的是，使用敏捷方法论和scrum让设计师可以同执行功能和技术的人协调配合。对话、提问和交流能够使问题实现有机的跨部门解决。这样团队就可以事先排除可能导致浪费时间和精力的臆断，通过协作让游戏开发产生最佳结果。
通过快速迭代，设计师可以在短时间内看到完整的机制。这让设计师可以迅速发现机制的状态以及游戏开发的前进方向。对于首席设计师和项目主管来说，他们每数周就能够了解项目的进展情况，在每月与团队的交流中就能够发现他们的努力是否会满足自己的最终目标。
因为每个独立的功能都由某个团队来完成，所以如果被删减不会影响到之前已经制作完成的内容。在独立功能被融入整个开发流程之前，对其进行更改不会导致工作时间和精力的浪费。
对于关卡设计师来说，这也意味着他们可以围绕已证实有效和有趣的机制来构建关卡。设计师随后可以回到某个关卡或区域，为其添加新功能，但在此之前游戏也可以先期推向市场。
finished functionality(from gamasutra)
专注于单个机制而不是分别制作并相互渗透，这种做法似乎会令人感到害怕。但是，应当注意到是，基础机制和关卡构建是游戏走出工作室必要条件。额外的功能能够为游戏填色，但是并非如此至关重要。优先构建最重要的东西而不是将其放在项目末期，意味着内容制作者(游戏邦注：比如设计师)能够直接围绕具体功能构建关卡。
此外，在项目早期获得功能性中心机制意味着，游戏无需依赖于那些可能被删减的机制，这些内容可以根据客户的需要进行删减或扩展。而且，产品拥有者和设计师可以决定哪些功能对游戏最有效，然后将其确定下来，包括更多用来呈现游戏中功能出众之处的内容。
随着时间的不断延长以及未尝试技术和硬件等更多因素的出现，发行商和投资者面对复杂情况时的思维逐渐从“让我们来尝试下!”转变为“我也不知道该怎么做。”下一代游戏开发的成本会进一步增加，所以出现上述反应是合理的。
如果使用scrum，产品拥有者和发行商可以通过多次迭代来规避风险。如果未曾证实有效的功能或游戏概念确实无法发挥作用，那么团队可以迅速进行重新评估并做出改变。如果那些功能有非凡的表现，团队和产品拥有者可以决定专注于游戏的这些层面，甚至让游戏开发朝全新的方向发展。
而且，随着开发时间的增加，产品面向的市场也在不断发生变化。新颖的想法会迅速变得稀松平常，因为其他同类产品会迅速在市场中出现。scrum让发行商和设计师带领产品远离竞争，同时将转变的风险降到最低。如果产品功能需要发生改变，或者出现游戏项目需要完全取消这种最糟糕的情景，发行商失去的也就是两周到两个月的时间，而不是两个季度或两年。
总结
在scrum这样的敏捷方法论中，游戏设计师能够获得众多的好处。项目主管和首席设计师可以定期看到项目的整体进展情况，他们要面对的不是抽象的表格和数据，而是可以亲身体验。对于关卡设计师，他们可以专注于围绕现有机制构建关卡。如果使用scrum，关卡设计师可以使用完整的机制，也就不用进行无谓的猜想。
scrum可以让游戏开发中的所有人受益，不只是设计师，因为它可以讲“死亡竞速”降到最小。发行商和项目主管可以审核每次迭代中的团队表现，意味着他们可以安全的预测团队未来的表现情况。
最重要的是，使用敏捷方法论和scrum让设计师可以同执行功能和技术的人协调配合。对话、提问和交流能够使问题实现有机的跨部门解决。这样团队就可以事先排除可能导致浪费时间和精力的臆断，通过协作让游戏开发产生最佳结果。（以上由长沙软件开发编辑整理于网络，如想获知相关信息请访问www.sjin.cn ）
武汉SEO www.quliangwen.org.cn