- 参考资料：华中科技大学-熊硕《游戏学导论》（系列课程）
- 本系列博客中，未标注“思考”、“便签”的部分，多摘引、校饰自熊硕老师的课件原文。
五、游戏策划·工程，SPIRAL
工程模型（Engineering Model）
将面向过程与面向对象的开发思路抽象为工程模型，我们将得到“瀑布模型”与”螺旋模型“。 对于游戏开发，我们通常选择螺旋模型，因此，接下来的讨论主要基于螺旋模型。
便签-5.1
由于博客配图较为麻烦，这里笔者不对瀑布模型与螺旋模型进行配图阐释，但是纯粹的语言文字又难以详细描述二者的区别与优劣。笔者鼓励读者在此自行搜索并学习相关知识，以便更好地理解接下来的内容。值得注意的是，在Jesse Schell的《游戏设计艺术》中，相关内容也有较为全面的解释，值得读者针对性地进行学习。
迭代
- 迭代基于螺旋模型，在每次回环的过程中对项目进行优化或添置。
- 迭代过程是一个循环递增的过程。
- 每一个循环都包括想法创意、游戏原型、原型测试、分析评估与循环重复。
工程准备工作
- 需求分析
- 主题元素、故事线、内容、题材、受众等等。
- 定义目标
- 开始定义游戏元素之前，明确游戏目标（比如“打败下界亚伯伦”）。
- 同时，记得明确游戏的目的（区分 “目标” 与 “目的”）：纯粹的娱乐 / 学习 / 释放压力 / 获得技能 / 人类热点。
- 头脑风暴
- 产生三个左右的初始创意。
- 将所有的初始创意展示给相关的干系人，比如上层指导者或者潜在用户，以检查创意设计是否在这个方向上，同时检查创意是否能与其他媒体进行融合。
反思-5.1
笔者认为，头脑风暴的氛围与产出质量，是决定一个团队内部合作积极性与游戏产品实际表现（尤其是创意角度）的关键。在这里，笔者整理了一些比较常用的小组头脑风暴方法，以供参考： 头脑风暴的四条基本原则： 1. 追求数量，列出所有的想法，不论它们看上去或听起来多愚蠢。 2. 忍住批评，头脑风暴里没有坏想法（“批评”是唯一的坏想法），任何点子都是潜在的最终答案。 3. 包容创意，鼓励哪怕最天马行空或不着边际的想法出现，疯狂正是我们所追求的。 4. 以别人的想法为基础，对提出来的点子进行扩充，多用 “是的，并且……” #### 引导式小组头脑风暴法 遵循四条基本原则轮流发言展开讨论，在过程中，协调人随时可以捡起那些被抛弃的想法，将它重新放在台面上。讨论结束后，寻找是否有两个可以结合在一起的两个或更多想法，试着实现 1 + 1 = 3。最后，经过讨论，选出最具有潜力、最被欢迎的想法。
群体决策法
阐释头脑风暴的规则并提出问题，让所有参与者将想法匿名填写并由协调人收集、展出，由参与者投票选出最好的想法。好的想法可以直接进入下一轮讨论，或是进入其他讨论小组以为其提供方向或前提。
群体传递法
阐释头脑风暴的规则并提出问题，每个人都在自己的纸片上写下一个点子，并传递给下一个人，供其补充想法。轮流执行，直到每个人都拿回自己原本的纸片，也都参与到了每个其他人的想法扩充中。让每个人阐释他们更新后的点子，并由小组进行投票
- 确定游戏的引擎与形式
- 是桌游还是电子游戏？目前团队的限制是什么？优势与天花板在哪？
- 用什么引擎？橙光？Cocos2d？RPGmaker？Unity？UE？引擎是否与工程结构相吻合？
步骤A：创建动作清单
- 列出你希望在游戏中可以做的事情（动作）
- 需求动作：第四章提到的各类需求要素。
- 系统动作：选择角色，save&load。
- 在动作内容与用户目标之间建立强链接。
- 失败案例：《暗黑破坏神 · 不朽》成为暴雪嘉年华的笑话
- 如果发现有动作和游戏目标没有连接起来：
- 确定是否是无意义的游戏动作。
- 试着让游戏动作有意义。
步骤B：确定核心规则
- 确定游戏中应该包含哪些规则。
- 关于游戏规则的具体定制，我们将在第九章详细说明原理与技巧，内涵是博弈论。
- 规则是有边界的。
- 但要注意规则制定时的常见问题：
- 好的规则应该作为驱动力，控制玩家在游戏中尽可能执行游戏动作。
- 用户哪些操作是被允许的，哪些是被约束的？
- 哪些规则应该留给玩家自己去理解，让其自然形成游戏策略，哪些又应该直接告知玩家？
步骤C：确定用户的入门等级
- 评估游戏规则，确保规则适合用户的预期发展水平。
- 如果发现规则过于简单，对用户挑战不足，则需要适当增加规则的复杂性以保证对应的趣味与学习梯度。
- 如果规则过于复杂，影响用户有效使用，则需要适当对规则进行简化。
步骤D：确定游戏决策路径
- 采用思维导图或交互图：
- 常用工具比如Mind Manager / Edraw。
- 定义好玩家需要解决的矛盾与问题，游戏过程的难点与重点在哪。
- 试着用策略驱动游戏。
- 确保游戏故事、游戏系统与玩法、游戏的反馈与结果，互相之间清晰而明了。
步骤E：设计叙事内容
- 给游戏增加一个叙事内容（故事，背景，世界观）
- 叙事内容并不是必须的，比如俄罗斯方块、麻将、2048和跳一跳都没有叙事。
- 值得注意的是，好的叙事一定能给一个新游戏在用户的吸引度上增色不少。
步骤F：设计一个游戏原型
- 利用前面步骤建立的所有元素，设计第一个游戏原型，即Demo。
- 游戏原型仅仅只需要包含20%的游戏内容，并且采用非数字化的形式。
便签-5.2：非数字化游戏原型（Non Digitalization Demo）
为什么从非数字化原型入手？
- 引自《屠龙记：创造游戏世界的艺术》——罗伯特·布莱恩特
- 作为游戏策划，非数字化Demo是最单纯的原型
- 不需要程序，不需要过于复杂的美术。
- 排除干扰因素，迅速发现游戏的美学特点与核心爽点。
- 可以即刻实现。
- Boardgame往往是Videogame的Demo，也是游戏策划用于说服他人的手段。
- 防止新手游戏策划放飞自我。
反思-5.2
关于“非数字化Demo”，笔者认为，其并不一定（甚至是多数情况下不应该）需要以桌游的形式为设计者提供其所需的论证，在这一点上，笔者与熊硕老师的意见并不一致。
传统的桌游一般会被分类为德式与美式，按照其玩法还可进一步细分种类，比如区块控制、吃墩等等。需要区别于电子游戏的非电子化原型的是，桌游是开发者最终的目的，而不是开发者实现目的的一种手段——一款真正意义上的桌游，应该能形成一个 “玩家基于某种规则下参加拥有对立性质的系统，并产生定量的某种结果的过程”（还记得游戏的定义吗？），而且这个过程应当是具有趣味的。换句话说，一款完整的桌游应该逻辑自洽且内容详实，而且最重要的是，它应该好玩。
而早期原型是开发者为实现开发目标而采用的一种手段，不是开发者的最终目的——没有人会说“我们想要开发的是一款伟大的Demo”，不是吗？原型的目的并不在于展示它有多成功，而在于展示开发者有多失败。开发者自己永远无法跳出自己的思维框架，从其视角出发对其作品的理解，注定会区别于玩家实际接触到游戏时对游戏的理解，更不要提设计者们总是更容易忽视自己的设计中存在的漏洞与缺陷。原型的意义就在于为设计者提供修正的机会。一方面，设计者将可以低成本地从自己的角度测试某一系统或某一功能运转是否如其预期或逻辑自洽；另一方面，它将能够允许设计者从受众（玩家）的角度观测其反应与行为是否符合预期，并基于结果进行分析与改进。
换句话说，能实现这两个功能的原型，就是一个好原型。但是这样一个我们眼中的的“好原型”，可能是规则随性、美术奇丑、手感糟糕的，甚至是功能缺失、流程无法闭环的——我们不会为了一个经济系统的测试原型就做出整个《伯明翰》（一款重策略的德式桌游），相反，我们做出的原型或许只针对经济系统，甚至只有经济系统的一部分——是的，参与你的原型测试的幸运儿们（恐怕包括你自己）将不得不像金融系的学生一样，拿着几张你随手撕下的纸片反复计算着经济系统的输入与输出是否维持在某个你划定的函数曲线上。笔者觉得这样的原型与桌游的关系，就像是“可执行程序”之于“电子游戏”的关系。也就是说，这样一个“好原型”，恐怕并不一定能作为一款“桌游”，而一个开发者也并不总是需要将Ta的点子落实成一个桌游（或任何类似于桌游的存在）才能实现利用原型进行可行性验证。
步骤G：自己试玩
- 游戏的第一个原型必须由自己参与试玩。
- 确保游戏的逻辑合乎常理。
- 发现游戏结构性方面的问题，并对所发现的问题进行修正，应用心流理论，评估并平衡游戏的挑战性。
步骤H：可用性测试
- 找一个或者若干个朋友对第一个原型进行测试，如果条件允许，直接寻找目标用户进行测试。
- 完整玩一次游戏，并给你对应的反馈与意见。
- 进入下一阶段前，修正对应的Bug，以及仔细评估模拟测试过程中测试者给出的反馈和意见，以确定需要迭代的内容。
步骤I：搜集并分析反馈
- 可用性测试之后，若目标项目为电子游戏，则可以开始开发已有的游戏内容的数字化版本，并进行数字化的可用性测试。但不论是电子游戏还是桌游，都需要搜集用户调研报告并作分析检讨，以此修正游戏玩法并迭代。若有需要修正的，对其进行修正。
步骤J：迭代（Spiral）
- 针对每次新增内容都需要进行循坏，直到开发者和用户基本满意为止：
- F-设计游戏原型
- G-自己试玩
- H-可用性测试
- I-搜集并分析反馈（包括修正游戏玩法）
- 迭代可以是针对游戏整体的，也可以是针对局部的，建议缩小迭代范围并减短迭代周期。
**