团队协作与设计文档

爱是团队协作的秘密（第 26 章）

全队真心热爱游戏和受众时，一切分歧都会为让游戏变好而搁置；成员想到游戏完成时就像孩子盼圣诞节。这不是手拉手唱歌，也不要求你喜欢每个队友。三种"爱的缺失"：

不能爱游戏，就爱受众（让别人爱上游戏是设计师的责任；自己不爱时作品顶多平庸，因为不真诚会透出来）：

1. 努力找出一处你真正喜欢的地方——一个瞬间、一个巧妙机制、一个流畅界面——有时一处就足以让整个项目值得投入。
2. 若你不是目标受众，就把它当作送给受众的礼物：像精心为所爱之人准备礼物、期待对方拆开时的表情；让对方开心的不只是礼物，而是你如此在乎。这种爱会透过游戏照进受众心里。无法假装——魔术师 Thurston（书中作 "Henry Thurston"）："你能骗过观众的眼睛和头脑，却骗不了他们的心。"
3. 若连受众也不爱，只剩假装：大家都怕的春季大扫除，有人半开玩笑说"这会超棒！"，大家带着假装的态度去做，活动真的开始有趣。问问自己真正热爱这款游戏的人会说什么、做什么，然后照做，你可能会惊讶于自己内心的转变。Schell 强调：团队对游戏的爱是决定成败的最重要因素，爱不是奢侈品而是必需品。

原书问题（第 3 版仍未改）：书中把魔术师写作 "Henry Thurston"。引文出自美国魔术师 Howard Thurston（1869–1936），他以上台前默念"我爱我的观众"闻名；不存在名为 Henry Thurston 的知名魔术师。

共同设计（"我是游戏设计师"的另一种变体：人人都是）

有些设计师觉得队友提设计意见威胁自己的地位，于是退出团队、独自设计——结果众人的好点子被压碎、热爱枯竭，设计师抱怨团队实现不了他的愿景，游戏谁都不满意。更好的是放下自我、尽可能让全队参与：多数人并不想劫持设计，只想被听见。好处：更多可选想法；快速剔除有缺陷的想法；被迫多角度看游戏；每个人都觉得拥有设计。而且设计决策并非全部事先做出——成百上千的小决定由程序、美术、管理者随时做出，若都对设计有坚实共识，这些小决定都会强化设计。

• 许多人都觉得自己的贡献最重要，这很健康。放大这种感觉的好办法是不要把设计写得过满：在不确定的地方留些模糊，迫使负责该部分的开发者思考并补足细节——他们离那部分最近，直觉常常很好，被采纳后会有真正的主人翁自豪感。
• 并非人人有耐力花三小时争论物品栏布局；细节讨论由感兴趣且高效的人组成核心设计组，达成共识后尽快告知全队。典型流程：初始头脑风暴（尽可能全员）→ 独立设计（核心组成员各自思考）→ 设计讨论（汇总并争取共识）→ 设计展示（向全队展示、收集意见批评，常演变为下一轮头脑风暴，开启下一轮迭代）。

团队沟通十要素（题记：Patrick Lencioni"团队合作不是美德，是选择"）

人比点子更重要——皮克斯 Ed Catmull："把好点子交给平庸团队，他们会搞砸；把平庸点子交给好团队，他们会修好。" 每个接触游戏的人都会影响设计，所以团队协作与设计息息相关。

版本差异：第 1 版为"九要素"，第 3 版加入第十要素"爱"与 Intel 的 "disagree and commit"；透镜编号由 #88–#90 变为 #100–#102。第 3 版延伸阅读推荐 Lencioni《The Advantage》、Ken Birdwell "The Cabal: Valve's Process for Creating Half-Life"，以及 Schell 2011 年 IGDA Leadership Summit 主题演讲 "Information Flow: The Secret to Studio Structure"。

设计文档：没有神奇模板（第 27 章）

新手常幻想天才设计师独自写出完美的 GDD，交给团队照做即可，"只要找到正确的 GDD 格式我也能成为职业设计师"。Schell 用超大字号强调：神奇模板不存在，过去没有，将来也不会有。文档很重要，但每个游戏、每个团队都不同。第 3 版新增设计师 Jason VandenBerghe 的观点：GDD 写完那一刻就过时了，它表达的是"什么能让游戏好玩"的当前理论，而人们本能地把正式文档当作规格、剧本或蓝图；有人当计划、有人当理论、有人当蓝图时就会出乱子，小团队靠大量当面沟通弥补，大团队难得多。

• 记忆：设计包含成千上万重要决定，两周、两百个决定之后最妙的方案也会忘；记录决定可免于重复解决同一问题；把设计从有限的工作记忆搬到纸上或屏幕上也有助思考。
• 沟通：决定要传达给许多人，而且是对话——一落到纸上就有人发现问题或改进方法，文档让更多头脑更快参与，发现并修正弱点；正因许多人要查看和编辑，Google Docs 已成为编写和更新游戏文档的标准方式。

六个群体、十五种文档（书中图 27.2 以箭头表示各群体之间的记忆与沟通路径，每条箭头可以是一份或多份文档）：

原书问题（第 3 版新发现）：第 27 章说团队沟通"as we discussed in Chapter 25: Team"，但第 3 版团队一章是第 26 章（The Designer Usually Works with a Team），第 25 章是社区；应是章节重新编号时遗留的交叉引用错误（第 3 版新增了场所、玩家动机、临场感等章），可对照本书目录核实。

从哪里开始：像开始设计时一样从简单开始——一份粗略的要点清单。清单增长时脑中会冒出问题，这些问题至关重要，记下来；"做设计"主要就是回答这些问题。每回答一个，就记下决定和原因。想法、计划、问题、答案逐渐自然分节——你就有了一份围绕独特游戏有机生长出来的设计文档。第 3 版延伸阅读另荐 Daniel Cook 的 "Game Design Logs"（解决设计文档过时问题）。

与引擎侧页面的对照：第 5、6 类文档（管线概览、系统限制）在本库工程页面中有具体对应：资产管线与工具链 讲资产如何被处理入库，正是"管线概览"要向美术说明的内容背后的实现；性能预算类页面则对应"系统限制"。Schell 强调的是它们的沟通功能——越简单越好、写给美术看——而工程页侧重机制本身。

本页透镜

全部透镜见 Schell 透镜总表。

Rogers 的视角：谁在做游戏（Level Up! 第 3 版 Level 1，第 14–25 页）

早期游戏几乎由一人完成（Jordan Mechner 独自编程、设计、动画、作曲做出 1989 年的《波斯王子》），后来画面能力提升、内容变多，程序员先与美术合作，再分化出专职设计岗位；Rogers 与宫本茂都是由美术转做设计。如今只有最大的 3A 才有数百人的团队，多数开发由小型独立团队完成——《我的世界》初版、《传说之下》、《星露谷物语》都出自一人之手（第 14 页）。

开发团队 (developer) 的岗位（第 15–23 页）：

发行商 (publisher) 负责资金、制作管理、法务与 IP、实体介质、展会、公关营销与发行（第 23–25 页），岗位有产品经理（排期、里程碑审批与付款、对接授权方、ESRB 分级）、创意经理（Rogers 本人在 THQ 的职位，提供"千尺视角"的无偏反馈，还写包装盒背面文案）、美术总监、技术总监（工具建议、尽职调查）、市场团队（Rogers 提醒：务必让市场团队真的玩过你的游戏）、商务拓展、法务、品牌经理、公关经理、QA 经理，以及猎头、评测与网红、授权方。这与 Schell 第 26 章"爱是团队协作的秘密"互补：Schell 谈团队如何相处，Rogers 列出团队由谁组成。

版本差异（第 1 版内容据早前收录记录）：第 1 版本章开头的两条"粗体真理"（"游戏设计师更好玩""团队里没有人想读你的设计文档"）在第 3 版 Level 1 中已不出现；编剧一栏从"后期请来重写剧情、写提示和说明书"扩写为"叙事设计/编剧"；新增社区经理、市场团队两栏；新增"一人做出的独立游戏"与"3A/2A/独立"的区分（见 游戏的定义）。

Rogers 的视角：设计文档（Level Up! 第 3 版 Level 4，第 71–102 页）

Rogers 的四份前期文档（一页纸、十页纸、节拍表、GDD）、好 GDD 的四个特征、各类型 GDD 要点与负责任设计师的习惯，详见 游戏设计文档。与 Schell 一样，他认为 GDD 没有官方格式，目的是沟通；不同的是他给出了逐页模板，并在第 3 版鼓励先问队友喜欢怎样工作，必要时"抛掉 GDD"，改用一页纸、分镜、动态分镜、白板软件或 wiki。

版本差异（第 1 版内容据早前收录记录）：第 1 版此处强调"没人想读 GDD"和"设定圣经 (bible) 与玩法无关、应在 GDD 之后写"，第 3 版 Level 4 已不再讨论设定圣经，改为"抛掉 GDD"一节。