游戏设计艺术 摘抄/笔记
第八章 游戏通过迭代提高
选择创意
一个平淡的创意根本不算创意。——艾尔伯特·哈伯德
面对一堆想法，迅速做出设计决定，坚持下去，然后立刻想一想这个决定的后果。
而当做出决策后意识到错误时，准备好推翻之前的决策。
创意不是一个完好的瓷器，而是一次性纸杯——它很廉价，能够大量生产。如果有人得到了一个纸杯，去拿另一个就好了。
尽快确定一个创意比拖延更好——你将可能更快地做出好决定，而不是花费时间考虑潜在选择。不要沉迷于你的决定，当它并没有效果时，准备好推翻它。
怎样选择？猜！
八项测试
你完成的设计方案必须通过八项测试或是过滤器。只有所有测试都通过，设计方案才算得上优秀。
- 测试一：艺术冲动。
作为设计师，是否觉得这个游戏“感觉不错”。自己的直觉和团队直觉都很重要。
关键问题：这个游戏看起来不错吗？ - 测试二：人群特征
你的游戏有一群特定受众。需要考虑设计是否适合目标受众。
关键问题：我们的目标受众很喜欢这个游戏吗？ - 测试三：体验设计
为通过这项测试，需要尽一切努力创造良好体验，包括美学、兴趣曲线、共鸣主题和游戏平衡。游戏必须经得起书中的透镜的检验
关键问题：这个游戏设计得不错吗 - 革新
一个新游戏按理说需要包含一些玩家从未见到过的新内容
关键问题：这个游戏是否与众不同？ - 商业和市场
想要卖出游戏的设计师必须考虑商业现实，并将其融入游戏设计中。这带来了很多问题。
游戏主题和故事对玩家们具有吸引力吗？
游戏是否通俗易懂，一个玩家能否仅仅通过观看概述就能明白这个游戏的内容？
消费者对这种题材的游戏有怎样的期待？
市场上，这个游戏与相似游戏比有哪些特点？
是否开发成本过高导致无法盈利？
关键问题：这个问题能够盈利吗？ - 工程
即技术可行性。
关键问题：这个游戏在技术上是否具备可行性？ - 社交/社区
有时候，一个好玩的游戏可能并不足够。一些设计目标可能需要很强的社交元素，迅速蔓延的病毒式传播，或者围绕游戏形成社区。
关键问题：这个游戏完成我们的社交或社区目标了吗？ - 玩法测试
当游戏开发到可玩程度，必须通过玩法测试。必须尽可能把游戏开发到可玩程度，只有实际看到游戏表现，才知道需要做出哪些重大改变。随着对游戏机制和目标受众的心理感受的了解加深，这个过程中测试目标与游戏都会不断迭代。
关键问题：游戏测试者是否享受这个游戏？
测试过程中对某些测试预期的调整是允许的，如改变目标受众。关键是要想办法通过所有测试。
当你选择一个初始创意时，重要的是选择创意中最容易被修改和塑造的那个，这样它更容易在测试中存活。
15 号透镜：八项测试
要使用这个透镜，你的设计必须满足许多约束条件。只有当它通过了八项测试而不需要修改时，你的设计才算完成。
问你自己八个关键问题：
- 这个游戏看起来不错吗?
- 我们的目标受众喜欢这个游戏吗?
- 这个游戏设计得不错吗?
- 这个游戏是否与众不同?
- 这个游戏能够盈利吗?
- 这个游戏在技术上是否具备可行性?
- 这个游戏完成我们的社交或者社区目标了吗?
- 游戏测试者是否享受这个游戏?
在某些情况下，还需要考虑一些其他的测试。
如一个教育游戏必须回答“这个游戏达到了它的教育目标了吗?”。如果你的设计需要更多的测试，不要遗漏它们。
迭代规则
思考并选择创意后，下一步是尝试将其实现。
对于简单游戏，可以快速构建原型，并进行玩法测试。
但若是无法在一两小时内构建可玩原型，要谨慎。游戏设计和开发过程必须是迭代/循环的。
期待游戏做完时就是最好的状态是一种天真想法。
迭代规则：你的游戏测试和改进的次数越多，就会越出色。
如果会经历长期测试与改进，需要回答以下问题：
- 迭代问题 1：怎样才能让每一次迭代都有意义？
- 迭代问题 2：怎样才能尽可能快地进行迭代？
软件工程师在过去 40 年中已经对这两个问题进行了深刻思考，他们想出了一些有用技巧。
软件工程的简短历史
危险-瀑布-保留
瀑布模型中，只需要不断向前，没有迭代，因为瀑布不会回头。
- 优点
鼓励开发者在编写代码前花费更多时间进行规划和设计 - 缺点
违背了迭代规则
瀑布模型符合项目认知，但却缺少工程认知，对于一个复杂系统而言，瀑布模型的推进是完全不可控的，也不太可能如此顺利
巴里·伯姆爱你
螺旋模型中，开发从最中间开始，顺时针旋转，依次通过四个象限。
里面包含了最棒的三个理念：风险评估、原型和迭代。
螺旋模型建议你做以下几件事：
- 想出一个基础设计
- 找出设计中最大的风险
- 建立原型消除这些风险
- 测试原型
- 基于从原型中得出的结论作更详细的设计
- 回到 2
它运用了迭代规则击败了瀑布模型的递进关系，它也回答了之前描述的问题：
- 迭代问题 1：怎样让每次迭代都有意义
- 螺旋模型的答案：评估并消除风险
- 迭代问题 2：怎样尽可能快速进行迭代
- 螺旋模型答案：构建许多粗糙模型
螺旋模型有很多衍生，目前为止，最成功的的是敏捷开发的传播。
敏捷宣言
2001 年，由工程师提出的敏捷宣言：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值
我们更重视左项的价值
原则：争分夺秒！
- 最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化
- 经常交付可工作的软件，间隔几星期或一两个月，倾向于采取较短周期
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外
- 激发个体斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈
- 可工作的软件是进度的首要度量标准
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
- 坚持不懈追求技术卓越和良好设计，敏捷能力由此增强
- 以简洁为本，它是极力减少不必要工作量的艺术
- 最好的架构、需求和设计出自自组织团队
- 团队定期反思如何能提高成效，并依此调整自身行为
被大多数开发者使用的核心元素：
- 灵活的目标：无法恰好得知计划所需的时间。围绕更加灵活的目标组制定计划，而不是忍受对计划做出改变，有计划地改变计划。开发过程中，团队能够迅速适应新创意和信息。
- 优先级列表：任何时候有人为一个特性想到了一个新的创意，他就能将其加入到列表中。每次迭代时，团队就查看列表，重新设定特性优先级——重要的评分高。接下来的工作只需要看看列表顶端就好。没有人能保证列表上的所有特性都会被完成——这样能保证大多重要特性能在时间允许范围内完成。
- 冲刺：相较于制定长期目标，敏捷开发者们用一系列冲刺工作，每一个冲刺持续一段较短时间，并在最后能传递一个坚实的工作结果。更多的 ddl 意味着更多工作被完成了！
- 争分夺秒会议：10~15 分钟，站着开会以表明会议简短的本质。每个成员解释三件事：昨天完成了什么，今天计划完成什么，面临的问题。会议结束后，通过与团队成员一对一接触来一个个找到问题解决方案。每个团队成员明确知道他们要做的事，且能够被其他团队成员帮助。
- 演示日：每个冲刺阶段最后，大家聚集在一起，面对面观看和测试工作结果。从新基准开始工作。团队开始分析风险，并一起确定下一阶段的冲刺计划。
- 回顾：每个冲刺阶段最后，团队有一个回顾会议。不是关于产品，而是关于工作进度。这给了团队机会来讨论什么是正确的，什么是错误的，怎样在下一冲刺阶段调整工作。
敏捷是一种哲学，不是一种规定方法。不同开发者有不同方法，但都致力于创造更多次迭代，且让每次迭代都有意义。
所有特性的风险评估和原型设计都是他们的核心。
风险评估与原型设计
案例：气泡城的囚徒
假设要制作一款城市跳伞的电子游戏。
气泡城的囚徒：设计概况
- 剧情：你是一只叫作“微笑”的跳伞猫。气泡城的市民们都被一个邪恶的巫师困在他们的房间中。你只有通过跳伞进入城市，从烟肉中滑下来找到市民，寻找阻止巫师的方法。
- 机制：在向城市中跳伞时，你可以试着抓住从城市中升起的魔法气泡。你能使用气泡的能量向邪恶的秃鸷发出射线，防止他们戳破气泡或者撕碎你的降落伞。同时你必须使降落伞正好落到城市中的目标建筑之上。
- 艺术：卡通风格的外观和游戏体验。
- 技术：使用第三方引擎的、多平台的三维主机游戏。
可以马上开始制作，深入细节，但很可能在玩法测试之前已经过去了很长时间。
正确的做法：和团队一起坐下，做一个风险评估，这意味着列出一个会危害到项目的所有风险的列表。可能示例：
风险 1：收集泡泡/射击秃鹫的机制不如想象中有趣
风险 2：游戏引擎无法同时完成绘制整个城市、所有气泡和秃鹫的任务
风险 3：目前的想法是需要 30 种不同房子来构成完整游戏——可能没有足够时间完成所有室内设计和动画角色
风险 4：不确定人们是否喜欢角色和剧情
风险 5：可能要改变游戏主题，以夏季新上映的电影作为跳伞噱头
可以通过构建小型原型，尽快减少或消除风险。
风险 1：收集泡泡/射击秃鹫的机制不如想象中有趣
可以将游戏机制抽象出来，比如方块版本。这样可以立即回答游戏机制是否好玩的问题，若是不好玩，对着简单模型迅速做出改变，直到好玩，然后就可以开始制作精细化版本。
明智的做法是利用迭代规则的优势。风险 2：游戏引擎无法同时完成绘制整个城市、所有气泡和秃鹫的任务
立刻做出快速原型。原型没有其他功能，只是单纯在屏幕上展示预估数量的相同物品，看引擎能否处理。这个引擎没有玩法，只是单纯测试技术可行性。如果能处理，很好，若是不能，在艺术品完成前，赶紧想解决方案！风险 3：目前的想法是需要 30 种不同房子来构成完整游戏——可能没有足够时间完成所有室内设计和动画角色
让艺术家先做一间房屋和一个角色，评估时间。如果达不到预期，想办法——用更少房屋或复用角色。风险 4：不确定人们是否喜欢角色和剧情
构建能够快速展示角色的艺术原型和故事版，将其展现给（最好是目标人群）玩家，评估他们的反映，整理出他们喜欢什么，不喜欢什么，为什么。充分利用这些信息进行迭代！风险 5：可能要改变游戏主题，以夏季新上映的电影作为跳伞噱头
要消除这个风险，可以寄希望于管理层尽快作出决定，或者可以决定制作一款能够更容易偏向电影主题的游戏，甚至可能想出一个制作两款不同游戏的计划——关键是立即考虑风险，并做出行动以保证它不会危及项目。
这可太可怕了 2333
16 号透镜：风险消除
是以圣人犹难之，故终无难矣。 —— 道德经
有道的圣人总是看重困难，所以就终于没有困难了。
没想到这里能看到哈哈。
要使用这个透镜，停止积极地思考，然后开始认真考虑那些会危及游戏的风险。
问你自己这些问题：
- 是什么让这个游戏变得平庸?
- 我们怎样防止这样的风险发生?
风险管理很难。这意味着你必须面对那些不想碰到和立刻解决的问题。但是如果训练自己这么做，你就能进行更多次有效的迭代，获得一个更优秀的游戏。忽视潜在的问题，只专注于游戏中你最有信心的部分是一种诱惑。你必须抵抗这种诱惑，专注于游戏中的风险。
制作有效原型的 10 个技巧
- 原型设计技巧 1：回答问题
每个圆形都应该设计为回答一个或多个问题。应该能清楚地描述问题，如果不能很可能会浪费时间。一些原型应该要回答的问题示例：
- 我们的技术能够在一个场景中支持多少个动画角色？
- 核心玩法有趣吗？趣味能持续较长时间吗？
- 角色和设定在艺术上能融合吗？
- 游戏关卡应该有多大？
避免过度构建原型，专注于让原型回答关键问题。
- 原型设计技巧 2：忘记质量
制作原型，唯一要关心的是其能否解决问题。其解决的越快，这个原型就越好——即使这个原型只能勉强使用而且只有粗糙外观。
目标是尽快找到问题，从而尽早解决。精致的原型会隐藏真正问题，带来错误安全感。
不要逃避迭代规则。需要尽快构建能回答疑问的原型，别管它有多难看！
想起自己在做 Yin Yang Messenger demo 的时候，一开始不敢动手，然后想了半天，做了个简易的 cube 版本出来，让朋友玩了之后收集了反馈立马迭代了新版本出来，一下子好了不少。
- 原型设计技巧 3：不要太过留恋
计划好扔掉当前的产品——你总会这样。 —— 《人月神话》（The Mythical Man Month）， Fred Brooks
要带着一切都是临时的心态开始原型工作——唯一要关心的是这个原型是否能回答问题。
把每个原型都当做学习机会——这是制作真正系统的练习。
- 原型制作技巧 4：区分原型的优先级
若是有多个风险需要消除，为风险也列出优先级，这样才能解决最大风险。特别是当一些风险因为其他风险而存在，那么解决源头，后续风险自然不再存在。
- 原型设计技巧 5：有效的并行原则
巧妙进行更多次迭代的方法是同时制作几个原型。
系统工程师构建回答技术问题的原型，艺术家构建艺术原型，设计师构建玩法原型
多个小型独立原型可以帮助你更快回答更多问题
- 原型设计技巧 6：并不总需要数字化
简单的桌上游戏原型——纸上原型，也能很好回答问题！
这样能迅速制作出桌面游戏，而且实现相同玩法。这能让你更快定位问题。
回合制游戏的数值可以通过纸上原型来打磨
实时游戏也能将行为转换为回合制模式
案例：
- 原型设计技巧 7：无须交互
简单的草图和动画能够对回答关于游戏玩法的问题大有帮助
《波斯王子：时之沙》有一套新奇的跳跃和时间回溯机制，最初的原型就来自无交互动画，描绘了设计师想象中难以置信的巧妙杂技，所以团队能够更容易看到思考和讨论怎样创造一个交互系统能够完成这个愿景。
- 原型设计技巧 8：选择一个“快速迭代”的游戏引擎
传统软件开发像烤面包：
1.编写代码。
2.编译和链接。
3.运行你的游戏。
4.操纵你的游戏到你想要测试的部分。
5.测试并验证。
6.回到步骤1。
如果对结果不满意，只能从头再来。
选择一个能快速迭代的引擎像是捏黏土——可以一直改变：
1.运行你的游戏。
2.操纵你的游戏到你想要测试的部分。
3.测试并验证。
4.编写代码。
5.回到步骤3。
- 原型设计技巧 9：先构建玩具
通过先制作一个玩具再想出游戏，可能从根本上提高了游戏质量，因为这在两个层次上都会很有趣。更深远的是，当你创造的玩法是基于一个很有趣的玩具的一部分，两个层级就能够通过最强有力的方式互相支持。
17 号透镜：玩具
要使用这个透镜，不要思考你的游戏是否好玩，要思考参与这个游戏是否有趣。
问你自己这些问题：
- 如果我的游戏没有目标，它会有趣吗？如果不是，我怎样才能改进它？
- 当人们看到我的游戏时，他们想要与它产生互动吗，甚至在它们知道应该怎样玩之前？如果不是，我怎样才能改进它？
有两种方式可以使用玩具透镜。
第一种方式是将其运用在一个现存游戏上，想出怎样为它添加一些玩具类的特质——怎样让它变得更亲切，操作更有趣。
第二种方式更加大胆，即在你还没有任何游戏创意之前运用它制作一个玩具。如果你在计划中做这件事就会有风险——但如果不是这样，这就是一个伟大的魔杖，可以帮助你找到你还没发现的绝妙游戏。
- 原型设计技巧 10：抓住更多迭代的机会
在游戏开发过程中会对游戏做出一些改变，这需要更多时间。
《光环》（Halo）就是这样，它原本作为一款苹果电脑游戏而被开发。与微软交涉时，他们为个人电脑做了改变，团队利用这个机会进行了更多次迭代。第二个意外是微软请他们将这个游戏从个人电脑转移到新发布的 Xbox 平台！团队需要更多时间改变技术，他们也再次拥有了提高和迭代游戏核心玩法的时间。
完成迭代
- 非正式迭代
- 想出一个创意
- 试验它
- 测试和改进，直到其足够好
- 正式迭代：
- 描述一个问题（利用机制、技术、美学、故事作为限定）
- 用头脑风暴的方式找到几种可能的解决方案
- 选择一个解决方案
- 列出使用这种解决方案的风险
- 构建原型来消除这些风险
- 测试原型，直到足够好为止
- 描述一个新的想要解决的问题，回到第 2 步
每次原型设计迭代中，都能更加详细地描述问题。
迭代的例子：
多少次才足够
现在我明白了，尽管太晚了。在我们计算费用之前，在我们评价自己是否有能力完成它之前就开始工作是很荒谬的。 —— 鲁滨逊·克鲁索（Robinson Crusoe）
更多的迭代总会让你的游戏变得更好。但是“工作永远不会终结——只会被放弃。”
需要确定在用尽开发预算之前，进行足够的迭代次数。
马克·塞尔尼（Mark Cerny）的观点：在你完成两个可发布的游戏版本并完成所有必要特性之前，你都处于试验产品阶段。换言之，除非有两个完全完整的关卡，你仍在进行游戏基本设计。
这个点通常在花费 30% 必要预算之后。
如果到达该点花费了 100w，那么可能还需要花费额外 230w。
作者有自己的 50% 法则：
- 50 % 法则前半部分：当计划游戏时，确定用这种方式构建它。如果 50 % 的预算被削减了，你依然能够有一个可玩的游戏。这条规则要求保持系统简单，也保证当出现糟糕的事情（很可能）迫使你放弃一些特性时，依然能够得到一个可玩游戏。
- 50 % 法则后半部分：所有核心玩法元素应该在规划中前半部分完成。即用一半时间让游戏变得可玩，用一半时间让游戏变得更好。
你的秘密燃料
18 号透镜：激情
在每个原型的结尾，当你小心地消除风险并计划下一步时，别忘了用这些重要问题检验你对游戏的感受：
- 我对这款游戏的成功是否抱有极大激情？
- 如果失去了激情，怎样才能找回？
- 如果激情没有回来，是否应该做一些其他事？
在每次冲刺的末尾，当你在研究原型和准备接下来的计划时，一定要记住做一个“激情检验”。激情就是潜意识与你交流的方式，它告诉你这个游戏是否令人兴奋。失去激情就说明一些地方出了问题——如果不能找到问题所在，游戏很可能会死去。激情也有危险性——毕竟这是一种不合理的情感。
必须小心对待激情，因为它往往能够击倒障碍并带领游戏走向成功。
拓展阅读
第八章 游戏通过迭代提高
- 比尔·巴克斯顿撰写的《用户体验草图设计》 (Sketching User Experiencesby Bill Buxton)。这本书通过多元化的原理和令人嘱目的结果向我们展示了草图的概念(提示:原型就是一种草图)
- 比尔·卢卡斯撰写的《用纸设计原型》 (Have Paper, Will Prototype by BillLucas) 。这本书是一系列案例研究,关于怎样成功创造计算机界面的纸上原型。麦克·塞林格撰写的《狗头人指南之桌面游戏设计》 (The Kobold Guide to Board Game Design by Mike Selinker) 。这本非常棒的书讲述了如何制作伟大的桌面游戏。
- 超级兄弟撰写的《少说话,多做事》 (Less Talk, More Rock by Superbrothers)这篇文章认为游戏是行动的媒介,而不是语言的媒介,并坚定的认为太多的设计讨论将会是毁灭性的。
- 《敏捷软件开发》 (Agile Software Development) 。维基百科中关于敏捷软件开发的条目编写地很不错,如果你想要更多地学习敏捷,它可以提供很多参考。
- 杰森·范登博格撰写的《游戏设计的四个F:快速失败与跟随快乐》(The 4Fs of Game Design: Fail Faster, and Follow the Fun by Jason Vandenberghe)这篇文章(基于马克,勒布朗的一个理念)将伟大游戏设计过程的关键方面总结为清晰的基础元素
