Team Game Production I - 团队游戏设计1·上篇

Team Game Production I, 是我在Guildhall第一学期接触的第一门课，亦是最重要的一门课。“This course introduces the theories of game design and explores the foundational frameworks and language of game development. Students apply game design and development practices to create a 2D game demo as part of small project teams. ”正如课程大纲所说，该课介绍了游戏设计理论、框架和语言，并且通过一个2D小项目来加以实践。

理论

这里介绍几个课程中反复出现强调的核心概念：Loop， Flow

Loop，即不断重复的动作-反馈循环，是游戏玩法的根基。比如Mario中的行走-奔跑-跳跃 或是 FPS游戏中的 移动-瞄准-射击-击杀。随着游戏规模的不同，除了核心循环外，还可能有第二、第三循环。比如解锁关卡，收集成就，击败最终Boss等等。

Flow，即心流，是游戏玩家的理想状态。来自于心理学界Mihaly Csikszentmihalyi（Mihaly Csikszentmihalyi）的理论。通过合适的技能-挑战系数，玩家既不至于因过于简单而枯燥，也不至于因过于困难而焦虑。


Pillar，支柱，即游戏中足以成为基石的关键特性。游戏的pillars在3-5个不等，如 美国末日 的pillars可界定为：制作，故事，AI伙伴，潜行；塞尔达传说：荒野之息 的pillars可界定为：探索，游历，恢复，选择，战斗。

开发框架

首先介绍一下游戏开发流程：概念原型（Prototype）、概念玩法验证（Proof of Concept Gameplay，POCG）、概念技术验证（Proof of Concept Technology，POCT）、切片（Vertical Slice，VS）、Alpha、Beta、最终发布（Launch）。

概念原型阶段，从头脑风暴（Brainstorming）提出概念开始，到纸质原型（Paper Prototyping）验证，再到数字原型（Digital Prototyping）细化，直到Pitch结束。Pitch指的是将完成的原型进行展示，以获得投资人、发行商的认可。

概念玩法验证，在概念原型的基础上进一步，着重验证核心玩法，core loops，pillars足够有趣。

概念技术验证，着重验证技术可行性，包括游戏引擎，开发流水线，开发工具等。

VS，正如其本意，相当于最后完整游戏的一个横切片。其目的在于说服利益相关者（即stakeholder，通常包括了发行商，投资人等）愿意继续资助该游戏开发。

Alpha，包含了游戏的全部完整内容，包括美术素材、程序代码和玩法关卡等。在Alpha阶段之后，游戏将从开发进入修复bug，打磨完善的阶段。

Beta，游戏进一步趋于完善并只待发行，也因此只有严重bug才会被修复。

最终发布，游戏发行上市，可喜可贺，可喜可贺。

上述整个开发流程每个阶段被称为一个里程碑（Milestone），每个里程碑都是一个重要节点，足以决定整个项目的生死存亡。

开发方法

课程中主要出现的开发方法论是：Agile Development，即敏捷开发；配合Scrum和User Story。

首先从团队构成上来说，该课程将60多人的一届学生拆分成了4-5人/组的小队；授课老师担任stackholder；小队中一名成员（多为Production方向的同学）担任Scrum Master；小队全体构成开发团队。

其次从执行流程上说，前述的每个里程碑被划分为若干Sprint；每个Sprint持续1周（这里相较实际的游戏开发Sprint长度进行了压缩）；每周周一按照指定好的Sprint Planning计划展开，直到周五，会进行Retrospective，即回顾会议，全队讨论该Sprint的得失成败，同时指定下一周的Sprint Planning；每天的早上会进行Daily Scrum Meeting，早会中成员将在Scrum Master的引导下依次汇报昨日完成情况，今日任务，有无需要解决的难题；在每个里程碑的末尾，都有规模不一的Playtest，即测试来验证开发成果。测试中暴露的问题和尚未完成的开发内容，一并加入之后的开发计划，纳入Sprint Planning之中。

同时在制定Sprint Planning的过程中，课程采用了User Story的拆分方法。即通过界定用户和其想要实现的效果，来拆分具体的任务。

整个方法论借鉴了软件开发的经典理论，并试图匹配游戏开发的特点。


开发工具

Mindmup

用来取代原有的Word等传统文档记录工具的在线文档工具（MindMup 2），相比word区别在于：

• 基于Word的游戏设计文档（Game Design Documentation, GDD）是线性结构，内容容易出现交叉重叠；Mindmup是非线性结构，对互相引用支持良好，而且支持导出为Word进行后续的归档编辑。
  

• GDD比较笨重，更新频率不足，影响整个项目的沟通效率；Mindmup轻量化，可以迅速及时的更新，更适合敏捷开发。
  

• Word对于多人在线编辑、视频图片超链接等媒体引用不友好；
  

Unity

主流的游戏开发引擎

Perforce

主流的版本控制工具

实例

游戏引擎：Unity
目标平台：Android （Samsung Tab A）
开发成员：2 Level Designer | 1 Programmer | 1 Artist
开发时间：

（1）Prototype

• Brainstorming 09.12
• Paper Prototype 09.14
• Digital Prototype 09.18-26
• Pitch 09.28
  

（2）POCG 10.06-13

（3）VS 10.16-20
（4）Alpha 10.23-11.03
（5）Beta 11.06-11.17
（6）Launch 11.20-11.27

在头脑风暴中，大家随机列出词汇，然后票选感兴趣的组合：


最终我们组选择了 Magic Girl、Skating、Snow这三个词汇的组合。

基于这三个词汇，大家进一步提出玩法概念，比如：在一个被积雪覆盖的场景，玩家需要操控Magic Girl通过滑雪来一点点除去积雪，最终解开正确的路径到达终点；积雪可以利用平板电脑的传感器，当玩家抖动的时候，积雪会滑落；参考line rider（Line Ride）的玩法，Magic Girl在画出的路径上滑雪等等。

结合上述创意，我们最终选择了制作一个解谜游戏：提供给玩家三种颜料，能画出三种不同效果的线条：红色——加速滑行，蓝色——磁性贴附，绿色——普通滑行；玩家需要利用这三种线条完成路径，到达终点。下图是Paper Prototype：





之后的Digital Prototype中，我们开始使用Unity，截图如下：


可以看到在这个原型中，我们实现了最基本的角色生成（Magical Girl用小球简化代替）；画线条；角色沿线条滚动。

第二轮迭代的Digital Prototype 2中，我们补充了更多玩法相关的概念：可收集的钻石；需要避让的障碍物。效果如下图：


Prototype阶段的尾声是Pitch，下图即为Pitch的幻灯片：


可以看到我们先是一句话简介游戏；之后介绍了Core Loop和Pillars；然后介绍了关卡概况和关卡技能学习表；之后介绍了具体的玩法，包括线的种类、障碍物的类型等等；之后介绍了程序和美术上的要点；最后是目标客户。正如前文所述：Pitch指的是将完成的原型进行展示，以获得投资人、发行商的认可。在TGP课程中，老师扮演了投资人的角色，对各组的Pitch逐一提问打分，并指出不足和问题。在Pitch阶段，无法达成标准的组会被取消掉，组员则并入其他组。

Reference:

Design Pillars ? The Core of Your Game