总结以SCRUM方法论开发独立游戏的经验
Posted Cocoa开发者社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了总结以SCRUM方法论开发独立游戏的经验相关的知识，希望对你有一定的参考价值。
点击上面蓝色字可免费订阅！
引言
本文并非解释SCRUM的工作原理，毕竟你可以在网络上找到比我们解释得更好的许多免费资源。本文主旨是分享我们小型团队的执行方法，在我们看来，这个方法的最棒之处在于：
1.每个团队成员都能对项目负责；
2.你可以获得比游戏本身更多的知识；
这些原则可以让你轻松发现游戏开发对于团队来说是否很重要。我们都知道优秀的游戏有可能获得成功，而糟糕的游戏当然与此无缘。最重要的是，公司仍然有团队，并且它会随着经验的增长而成长。无论项目结果如何，团队都应该从中汲取大量经验，获得最大化的好处。我们应该鼓励成员的责任心和学习行为，而SCRUM正好完美结合了这一原则。
人物角色（Personas）
我们的工作流程始于人物角色，它是潜在玩家的描述。我们必须先从一些假设入手，因为我们还没有任何玩家。写下我们未来玩家的想象资料，有助于我们推动瞄准他们的设计：这意味着更好的粘性和留存率。以下是人物角色的一个例子：
John，来自美国的28岁汽车机械师
他希望有时间玩游戏，但却总腾不出时间。他有一部诺基亚Lumia 520手机，并在上班时间下载体验免费游戏。他不能在游戏上花太多时间，更愿意在工作间歇玩游戏。他有一些Facebook好友，并且从未在免费游戏上花一文钱。
目标：
*清晰的目标
*较少的控制
*社交游戏
*短暂的游戏回合
当游戏发布后，人物角色就会变成“游戏角色”，我们将通过追踪和直接的反馈获得关于其行为的准确概念。
故事（Stories）
我们根据人物角色定下了生成玩家故事的概念文档：这是一个将问题划分成次问题的好方法，有助于构思每个团队成员应该解决的任务。以下就是故事的一些例子：
我们可以将玩家分为3种类型：
1.新人：第一天的玩家
2.休闲玩家：拥有正常留存率和低粘性的玩家
3.高级玩家：拥有高留存率和粘性的玩家
每个Sprint都有解决一系列故事的目标，而这些故事是从产品储备中选择出来的，并且要迎合基本的Sprint目标：开发一款具有发行潜力的游戏。每个故事都有一系列需要追踪的参数，我们使用的是本文所建议划分的玩家类型。
信号系统（Kanban）
针对我们的信号系统，我们使用了四个栏目：
*去做：还没有被任何人接手的任务
*在做：正处于当前开发状态的任务
*测试：团队中已经完成并需要修正的任务
*完成：可以视为结束的任务
你很容易发现，最后一点相当有歧义。事实上，如果你低估了这一点，它可能就会成为你工作流中的问题。为避免这一点，团队在Sprint计划会议中要腾出一些精力关注作品以及对于“完成定义”的维护工作。
在Thousand Gears，我们有一个小型团队针对诺基亚AppCampus开发一款游戏，为保持目标清晰和可控性，我们选择了短小的迭代（Sprints）。通常每个Sprint阶段持续1周左右。我们通过图表追踪团队的速度，这样我们才能发现团队在Sprint计划会议中能够评估60%的实际时间。
里程碑
我们每周都会推出一款具有潜在发行可能的产品，想象我们将用它来参加游戏竞赛。在每个里程碑尾声时，我们会为自己的游戏生成一个新的增量。我们的里程碑是：
1.预原型阶段：创造概念和执行极为初级的系统来展示主要循环。
2.原型阶段：确定开发游戏首个基本版本的技术和工具。想象一下你将参加Ludum Dare或类似的活动。
3.样本阶段：创造关卡，美术资产并执行功能。
4.Alpha阶段：用基本的漏洞修复来优化内容和美术资产。
5.Beta阶段：最终的漏洞修复。
在每个里程碑末尾，我们都会进行测试。首个测试只在内部进行，其目标是激励团队“行动起来”的斗志。
设计该怎么办？
通常我们并不迷信制作大量文档的方法，我们更愿意创造GDD，它是游戏设计日记（Game Design Diary）的缩写：每个Sprint阶段都会写下一个新的章节并与团队分享。这样我们可以向初始理念添加细节，并保持追踪整个项目的历史。每个团队成员都可以看到开发过程中发生变化的内容及其时间，这有利于进一步分析。此外，从更小的文件入手更容易写下新故事。
总结
游戏开发并没有什么成功秘笈，整个过程就是试验->结果->学习。Scrum并不是一个方法，它是一个方法论：它是更多是关于研究技巧而非通过行动执行逻辑合理路径的哲学性思考。我们应该采用一些明确的决定，所以最好是尽量保持简单性和可衡量性。整个过程是经验性的，你必须掌握许多最佳做法并将其运用于自己的情境和文化，令其更适用于自己的团队成员。
以上是关于总结以SCRUM方法论开发独立游戏的经验的主要内容，如果未能解决你的问题，请参考以下文章