团队游戏设计第一课（上）：Loop、 Flow理论研究与实践

杨智

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

理论

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

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

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


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

开发框架

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

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

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

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

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

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

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

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

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


开发方法

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

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

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

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

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

开发工具

Mindmup

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

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

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

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

Unity

主流的游戏开发引擎

Perforce

主流的版本控制工具

实例

游戏引擎：Unity

目标平台：Android（Samsung Tab A）

开发成员：2 Level Designer|1 Programm​er|1 Artist

开发时间：

（1）Prototype

Brainsto​rming 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​阶段，无法达成标准的组会被取消掉，组员则并入其他组。

参考

Design Pillars?The Core of Your Game


专栏地址：https://zhuanlan.​zhihu.​com/​zhiyangg​ame