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

2019-01-21

杨智

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

参考

Design Pillars?The Core of Your Game


专栏地址：https://zhuanlan.zhihu.com/zhiyanggame

参与评论