迭代与原型

选点子：快速决定，随时反悔（第 8 章 Choosing an Idea）

• 迟迟不决是常见陷阱。决心去做的那一刻，之前没看见的缺陷和好处会突然显现（像抛硬币时才知道自己想要什么）。
• 所以要快速决定、立刻思考后果，发现错了就立刻推翻："点子不是精美瓷器，而是纸杯——造起来便宜，漏了就换一个"。

八个过滤器（第 8 章 The Eight Filters）

设计只有一次性通过全部八个过滤器、无需再改，才算"够好"；任何改动后都要重新过一遍，因为通过一个可能导致另一个失败。

过滤器本身也可以改（例如原定 18–35 岁男性，做着做着更适合 50 岁以上女性）；教育游戏还要加"教到了该教的吗"等过滤器。

循环法则（第 8 章 The Rule of the Loop）

• 卡牌、桌游、简单电脑游戏可以直接"试一试"反复改；但需要几个月美术和程序才能试玩的电子游戏要谨慎：迭代次数无法事先计划，开发就是赌固定预算内能通过全部过滤器。
• 天真做法是"先拼起来再说"，失败时只能发售不够好的游戏或超支。
• 循环法则不是透镜而是绝对真理："这次设计太好了不用测"之类的自我安慰都会让你付出代价。电子游戏每轮测试成本远高于传统游戏，只能少循环，因而风险很高。
• 两个循环问题：如何让每次循环都有价值？如何尽快循环？

软件工程简史（第 8 章 A Short History of Software Engineering、The Agile Manifesto）

flowchart LR
  A["基本设计"] --> B["找出最大风险"]
  B --> C["做原型缓解风险"]
  C --> D["测试原型"]
  D --> E["据所学细化设计"]
  E --> B

上图是 Schell 对螺旋模型的简化：核心是风险评估、原型、循环三件事。

敏捷宣言 (Agile Manifesto，第 3 版新增一节)：2001 年一群软件工程师在犹他州 Snowbird 滑雪场发表，作者称之为"最深刻塑造现代游戏设计与开发的事件"。四条价值观：个体与互动高于流程与工具；可工作的软件高于详尽文档；客户合作高于合同谈判；响应变化高于遵循计划（右边有价值，但更重视左边）；外加 12 条原则（尽早持续交付、欢迎变更、几周到几个月一次交付、业务与开发每天协作、信任有动力的个体、面对面沟通、可工作软件是进度主要度量、可持续节奏、技术卓越、简洁即"最大化不做的工作量"、自组织团队、定期反思调整）。这些原则落地为常称作 Scrum 的实践；作者观察到超过 80% 的电子游戏开发者自称使用某种敏捷开发。

敏捷是一种哲学而非规定的方法论，各家做法不同，但都为了尽可能多循环、让每次循环有价值，核心都包含风险评估与原型（第 8 章 The Agile Manifesto）。

风险评估与缓解：Prisoners of Bubbleville 示例（第 8 章 Risk Assessment and Prototyping）

设计简报：玩家是跳伞猫 Smiley，反复伞降进城、钻烟囱拜访被邪恶巫师困住的市民；下落时抓魔法泡泡、用其能量射击秃鹫，同时导航到目标建筑；卡通风格；多平台 3D、第三方引擎。18 个月项目若直接开做，可能 6 个月后才有可玩版本，届时才完成一个循环。

十条原型技巧（第 8 章 Ten Tips for Productive Prototyping）

与引擎侧页面的对照：Schell 的"快速循环引擎"主张与 游戏脚本系统（GEA：脚本语言让策划不重新编译即可迭代）方向一致；UE5 提供的对应设施是运行中重编 C++ 的 Live Coding 实时编译，以及蓝图。第 3 版已点名 Unreal 的 Blueprints 与 C++ 配合使用，但没有讨论 C++ 的热重载（Live Coding）。

闭合循环（第 8 章 Closing the Loop）

示例：新竞速游戏

• 循环 1"新竞速游戏"→ 方案：水下潜艇竞速（带鱼雷）。原型结果：水中"发光路径"让赛道可读；潜艇要非常快且灵活（"竞速潜艇"）；能飞出水面很新颖，但空中更快，需限制滞空时间；必须支持联网多人；全屏波动特效太耗 CPU 且分散注意。
• 循环 2"会飞的竞速潜艇"→ 风格、出入水时间平衡、联网三方面原型。结果：人人喜欢"恐龙潜艇"；大多数关卡 60% 水下、20% 空中、20% 近水面（拿道具可飞行加速）；避免速射机枪会让联网简单很多。
• 循环 3"飞行恐龙"→ 问题陈述更具体：动画排期、关卡数量、道具、武器（避开速射机枪）。
• 要点：问题陈述逐轮变具体；丑陋问题很早就浮出水面；看似两轮半，借助并行其实是六个设计循环；全队参与设计，技术和美学都在影响设计。

多少才够？（第 8 章 How Much Is Enough?）

• 循环法则意味着多一轮总会更好——"作品从未完成，只是被放弃"。第一轮开始时无法准确估计完成时间，因为还不知道要做什么。
• Mark Cerny 的 The Method：完成两个可发布质量、功能齐全的关卡之前都是预制作 (pre-production)，之后才进入制作 (production)、可以安全排期；这个点通常在花掉约 30% 预算时到达——花 100 万到达，大约还需 230 万。
• 作者自己的两条经验法则（第 3 版新增）：
  • 计划砍半法则 (Plan-To-Cut Rule)：规划时保证即使预算被砍掉 50% 仍能做出可发售的游戏，这迫使系统保持简单，出问题砍功能时仍能交付。
  • 50% 法则 (50% Rule)：所有核心玩法元素在排期过半时都应完全可玩——一半时间让它能跑，一半时间让它出色。常见的计划是 80% 让它能跑、20% 打磨，结果 20% 被意外吃掉，游戏又晚又弱。

秘密燃料：激情（第 8 章 Your Secret Fuel、#18）

分析很重要，但别忘了当初为什么追这个点子。每个冲刺末研究原型、规划下一步时，也要做一次"激情检查 (passion check)"：激情是潜意识告诉你它对游戏兴奋的方式；激情消失说明出了问题，找不到原因的话游戏很可能"一出生就死"。激情是非理性的、有其危险，但它往往是推倒障碍、带游戏走向成功的力量。

本页透镜

版本差异：第 1 版本章三个透镜编号为 #13–#15，没有激情之镜；只有 8 条原型技巧（无"不必可交互""抓住多循环机会"），纸面原型的 FPS 例子据本库此前记录是《Doom》，第 3 版改为《Halo》；第 1 版没有敏捷宣言一节和计划砍半/50% 法则，快速循环引擎举的是 Python/Panda3D（第 1 版第 7 章）。

存疑（书内不一致，第 3 版）：过滤器 #5 的关键问题写作 "Will this game be profitable?"，透镜 #15 的问题清单却写 "Will this game sell?"；两者意思接近但措辞不一。

全部透镜见 Schell 透镜总表。

Adams & Dormans 的视角：机制在设计流程中的位置（第 1 章，印刷页约 p.12–22）

Adams & Dormans 采用 Adams 的以玩家为中心的设计 (Player-Centric Design)：玩法 (Gameplay) ＝游戏施加的挑战＋允许的动作；机制产生玩法（关卡决定峡谷的形状，物理机制决定马里奥能跳多远、能否成功）。因此一知道要提供什么玩法就开始设计机制。

三阶段流程：

设计文档是"活文档 (Living Document)"，随游戏增长；记录目标与决策能防止反复重议，也让团队目标一致。

为什么要早做机制：①玩法从机制中涌现，光看规则无法判断好不好玩，只能玩（最好让别人玩）；②机制是复杂系统，平衡很脆弱，后期加功能或改机制很容易破坏它。核心机制平衡且好玩之后，再做关卡和美术。作者赞同 Kyle Gabler 在 2009 年首届 Global Game Jam 主题演讲中的"先做玩具 (Make the Toy First)"。理论与工具不能替代真正的原型与迭代。

原型术语：

三种原型技术对比：

软件原型的关键是参数易改：重力、工厂产出率等写进启动时读取的文本文件，或在游戏里放一个现成的控制台实时修改，不要做花哨的调参界面（Spore 的原型曾公开发布）。纸面原型工具箱（Corvus Elrod 建议）：两副背面颜色不同的近似牌、小笔记本、笔、筹码、几颗骰子（用百分比设计时两颗十面骰），作者再加便利贴、空白卡片和卡套（把纸条塞进卡套，修订直接覆盖在旧卡上，保留设计历史）。

原型焦点 (Prototype Focus)：动手前先问"我想从中学到什么"，单一焦点让原型更快、反馈更准。典型焦点（大致由早到晚）：

1. 技术演示 (Tech Demo)：攻克最难最新的技术，向自己和发行商证明能做；留意其中的玩法机会。
2. 游戏经济 (Game Economy)：低保真纸面原型，越早越好。问题：平衡吗？有没有总能赢的优势策略 (Dominant Strategy)？选择有趣吗？玩家能否预见选择的后果？理想测试者是能快速掌握机制、善于找漏洞的硬核玩家，请他们尽力把游戏玩坏。
3. 界面与操控：必须软件原型；看玩家能否正确执行动作、是否得到决策所需信息、是否注意到受伤或关键状态变化。
4. 教程 (Tutorial)：开发后期才做，必须用没见过游戏的新玩家，且不要干预他们的学习；开发者已太熟练，判断不了初始难度。

参考游戏 (Reference Games)：免费的原型：借鉴现有游戏，尤其是界面、操控与基础物理这些玩家要求一致性的部分（没必要把 WASD 改成 ESDF）；不要抄袭；选与自己项目规模、质量相近的参考作。

与 Schell 第 8 章对照：两者都强调"先做玩具"、快速迭代与原型要回答具体问题；Schell 以风险清单驱动原型（每个原型回答一个风险问题），Adams & Dormans 以"原型焦点"按开发阶段排序，并按机制的离散/连续性质选择原型媒介。

Rogers 的视角："不好玩"理论（Level Up! 第 3 版 Level 2，第 38–41 页）

Rogers 最怕的问题是"好玩吗？"。他的唯一真理是你无法保证游戏点子会好玩；照搬已验证的玩法能提高胜算，"抄是完全可以的起点"，但不要做成彻头彻尾的克隆品——评测者一比较就致命。由于开发者会把同一关玩上百遍、必然失去客观性，加上"熵"让问题不断混入，他提出**"不好玩"理论 (Theory of Un-Fun)**：从一个好玩的点子开始；开发中去掉不好玩的东西；剩下的就是好玩。

• 必须从好玩的点子出发，否则去完不好玩就什么也不剩。
• 要在开发中反复执行：停下来，列出所有让游戏不好玩的东西，然后修掉——发飘的延迟操控、按键后播放太久而影响攻击时机的动画、太晦涩或太难的谜题、太容易打的敌人或 Boss。
• 许多团队留着坏机制、丑美术和坏镜头，只是因为看惯了（"本来就这样"不是好回答）或没认出这是问题；有时要改掉花了不少工夫的东西。
• "别太珍惜" (Don't be too dear)：敢于杀掉坏点子，甚至杀掉几个好点子；点子很便宜，关键在怎么用。

分歧并列：Schell 的迭代循环是"提问—原型—测试—再提问"，以风险为驱动、主动加入新东西；Rogers 的"不好玩"理论是减法，只从已有内容里去掉问题。两者可以结合：Schell 的循环负责找出新的可能，Rogers 的清单负责定期做减法。

版本差异（第 1 版内容据早前收录记录）：理论本身未变；第 3 版把不好玩的例子具体化（发飘操控、动画拖慢攻击时机），并补充"可以从抄已验证的玩法起步，但别做成克隆"。

Rogers 的视角：制作中的难题（Level Up! 第 3 版 Level 20，第 507–513 页；第 1 版 Level 17，PDF 页 604–607）

"电子游戏是个很难的行业"：好游戏也可能评价差、卖得差，发行商可能无力充分宣传，销量预期可能定得太高；团队成员也会因家庭和健康问题分心，甚至主设计师在开发中生病或去世。游戏是人做的 (Video games are made by people)——多数失败源于计划不周。排障清单：

• 别过度承诺内容，别贪多嚼不烂。
• 提前计划：为病假、休假、硬件故障、停电等预留余地。
• 尽早锁定设计与内容：为追求完美不断改动会拖垮团队，甚至毁掉游戏。
• 玩家总会找到弄坏游戏的方法，所以要像玩家一样玩——做奇怪的事，敲打游戏直到它坏掉，修好再继续；设法弄坏游戏，换位思考。
• 国际版要考虑文化敏感性：Titan Studios 的《Fat Princess》(2009) 为日本发行把四根手指的卡通角色改为五根（Rogers 的注释列出原因：黑帮断指谢罪、"四"与"死"同音、对部落民的歧视手势）。
• 当心"设计师眼罩"（离游戏太近，觉得太简单或半成品"够好了"）；想象自己是"第一个玩家"——反馈够不够、刺激和乐趣够不够；保持客观，用"一万英尺视角"和节拍表、大纲找出设计弱点（见 游戏设计文档）。
• 和其他游戏比较：你的游戏给人的感觉和别的游戏一样吗？别的游戏有什么你喜欢而你的没有？讲出游戏的故事：玩的过程就在创造叙事，它与你希望玩家的玩法一致吗？
• 在制作的所有阶段迭代——"像武士刀一样，反复折断再锻打，直到它强韧"。
• 收集反馈：从四类试玩者那里都要（见 游戏测试），别因为听到不爱听的话就生气，强烈抱怨通常有正当理由；也让家人玩——他们最会夸你，也最能判断好不好玩。
• 焦点小组：按特定条件（爱玩动作游戏、每周游戏时长、年龄或性别）挑选、常付费请来的人。小心"领头者"左右全组意见、其他人不敢开口——确保每个人都被提问；拿钱的人可能觉得要说好话，你要的是诚实不是奉承；付了钱也不等于他们是对的，对结论要有保留（Schell 对焦点小组的看法见 游戏测试）。
• 不行就扔掉：别把点子当宝贝，它们一文不值；但扔之前要有备用方案，别让扔掉成为习惯——浪费工作就是浪费时间和钱；扔掉好点子说明好点子太多，可以"留给续作"(S.I.F.S.)。前期砍得越多，制作中砍得越少；砍内容要有正确理由，别砍那些牵动多个系统的内容。
• 当心骄傲：设计师常对自己的设计有占有欲，为不好玩的玩法、不好用的操作争执；早期决定可能日后要改或删。指出别人的问题要讲究方式，最好引导对方自己想出办法；对方坚持不让，有时只能放手、承担后果。"游戏开发最重要的是把游戏做完。"

两种制作方式：

赶工有害 (CRUNCH TIME IS BAD!)（第 3 版新增）：任何计划不周的制作都会导致赶工，无论做垂直切片还是直接做整个游戏；需要赶工说明开发出了问题。许多年轻设计师以为熬夜加班是在乎游戏的高尚表现——"你是在做游戏，不是在拯救世界"，别牺牲健康、理智和生活。避免赶工的九个办法：

1. 排期：列出做游戏所需的全部工作，GDD 就是估算工作量的工具。
2. 先做难的：棘手的镜头、复杂的碰撞或设计最容易出问题，早做；擅长的放到后面。
3. 为修改留余地：保持 GDD 更新，免得有人做了不需要的东西。
4. 拿定主意：他参与的一个游戏把一个敌人重新设计了十次；决定了就坚持并承担后果。
5. 沟通：自负、分歧、粗心乃至怕做错都会阻碍沟通；表明你愿意谈，更要愿意听，出了问题尽早告诉团队。
6. 别推迟会议：准时、限时、少议题、别变成闲聊、吵架或长篇辩论；备零食和纸笔；没有议程就别开会。
7. 预期延误：生病、休假、蜜月、生子、亲人和宠物离世——体谅队友，"做个好人 (be a mensch)"。
8. 为学习留时间：美术学新插件、程序学新写法，设计师更要不断学新工具、玩游戏。
9. 为犯错留余地：覆盖了几天的文档、给美术错误的参考图、改错文件提交——立刻告诉队友，别隐瞒；用版本控制等保险措施，尽快恢复。

游戏设计师的日常（第 3 版新增）取决于所处阶段（概念、前期、制作、后期、发售）与排期，Rogers 做过的工作包括：构思并写下基本点子；做提案并在行业活动或会议上讲；协作设计并审阅其他设计师的工作；编写故事；设计角色动作；设计关卡、机制和敌人；与队友讨论设计；画关卡地图并在引擎中搭灰盒；试玩关卡与玩法；在关卡中编写机制和镜头脚本；写对白并指导配音；为官网、新闻稿或包装写营销文案。他的建议：做那个在会议室里举手说"我来！"的人——这是积累经验、让自己更有价值的最好方式。

Rogers 的普遍真理是"二选一然后开干"，并用负责任的设计目标和详细的制作计划避免赶工。灰盒的关卡层面做法见 关卡设计流程。

版本差异：第 3 版（p.507–513）在第 1 版清单基础上新增"第一个玩家""和其他游戏比较""讲出游戏的故事""收集反馈（含家人）"、焦点小组的三条注意事项、"当心骄傲"与"把游戏做完"，以及整节"赶工有害"九条和"游戏设计师的日常"；删去"发行商擅长提供一万英尺视角"，改为自己用节拍表和大纲保持客观；《Fat Princess》补注开发商 Titan Studios 与年份。

Totten 的视角：关卡尺度的非数字原型与灰盒（第 3 章，p.124–126）

• 过去开发者常到 Beta（素材已基本完成）才开始测试，如今业界认为这太晚，要在各阶段测试。
• 多数原型文献把非数字原型用于整款游戏，Totten 强调关卡也能用：Fullerton《Game Design Workshop》记载 EA 用塑料树、玩具兵和战场模型的实体沙盘为《荣誉勋章》起草户外关卡，也有用六角格、玩具兵和火柴棍（当墙，便于挪动）做的第一人称射击桌游原型。
• 非数字原型可以是宏观的（学生把骑士救公主的 RPG 做成类似 Candy Land 的线性棋盘——这块棋盘就是整款游戏的"可交互 parti"，表明设计意图是按故事节拍线性推进而不是让玩家选择）或微观的（越狱潜行游戏只在一个无墙房间里定义守卫与角色的移动规则，以后再加走廊和牢房）。
• 进入数字阶段用灰盒：早期还可以用灰盒来确定角色度量本身，详见 关卡设计流程 中 Totten 的灰盒与模块化部分。

对照：Schell 的原型技巧和 Adams & Dormans 的纸面原型都以整款游戏或机制为对象；Totten 的贡献是把同样的手段落到一间房、一张地图上，并区分宏观与微观两个尺度。