做游戏这行十多年我见过最离谱的一种场面项目复盘会上每个人都坚称自己看过设计文档可美术画出来的角色和策划脑子里想的完全不是一个人程序写出来的战斗节奏跟文档上写的差了两倍测试同学拿着一份三页纸的文档试图验证一百多项功能。回头翻出那份文档上面写着打击感要强玩法要有趣经济系统要平衡。这不是设计文档这是许愿池。游戏设计文档也就是圈内常说的 GDDGame Design Document本质上不是一份给老板看的汇报材料而是团队成员之间关于这个游戏到底怎么运转的一份共识契约。它要解决的核心问题只有一个当策划、程序、美术、音频、QA 五拨人各自坐在工位上干活的时候凭什么大家做出来的东西最后能拼成一个完整的游戏而不是五个平行宇宙。这篇内容适合三类人看。第一类是刚入行、被要求写一份 GDD但完全不知道从哪下笔的新人策划第二类是独立开发者和小团队没有专职文档岗需要自己一边做一边写第三类是从程序或美术转过来做设计的朋友技术能力很强但不知道该怎么把自己的想法翻译成别人能执行的文字。全文我会从为什么这么写讲到具体怎么写中间夹大量实操细节和我自己踩过的坑尽量做到看完就能上手改自己那份文档。1. GDD 到底是什么先把概念和使用场景说透1.1 一句话定义以及它和另外几份文档的分工我给 GDD 的定义是用可验证、可执行的方式描述游戏在运行时如何响应玩家行为的一份动态说明书。这句话里有两个关键词值得掰开说。可执行意味着文档里的每一条描述理论上都能被转成代码、模型、音频文件或者测试用例。如果你写角色跳跃手感要舒服程序没法执行但如果你写起跳速度 12 单位/秒重力加速度 -30 单位/秒平方下落时重力系数乘以 1.6落地后 0.1 秒内禁用再次起跳程序立刻就能做出第一版然后你们再一起调手感。动态意味着 GDD 不是一次写完就封存的合同而是随项目推进不断收敛的文档。这点和很多新人想象的不一样——他们以为文档是先想清楚再开工实际上更多时候是先写清楚假设再用手感去验证假设。这里必须区分几份经常被混为一谈的文档。GDD 管的是游戏本身怎么运转技术设计文档TDD管的是这套运转逻辑用什么架构实现关注模块划分、数据结构、性能预算制作排期表管的是谁在什么时候交付什么关注人力、里程碑、风险。我见过新手把三者揉成一份文档结果策划不想看架构图程序不想看玩法故事两边都痛苦。分文档不是为了形式主义是因为三份文档的读者和更新频率完全不同GDD 随设计迭代改TDD 随技术方案改排期表每周都在改。1.2 谁在读你的 GDD读者视角决定写法判断一份 GDD 写得好不好有个很土但很有效的办法把它丢给三个不同岗位的人让他们各自说出我这周要做什么。如果三个人说出来的东西能拼到一起这份文档就算及格。程序读 GDD找的是边界条件和状态变化。他会盯着玩家在什么条件下能触发这个技能这个状态持续多久两个效果同时触发时谁优先这类问题。所以涉及逻辑的部分状态机、优先级、异常分支必须写清楚不能只写happy path。美术读 GDD找的是视觉锚点和参考。他要的不是一只很酷的怪物而是体型比例、材质倾向、配色范围、动作节奏、参考图链接。我通常会在美术需求里放三张图一张主参考、一张反面参考明确不要什么风格、一张细节参考。音频读 GDD找的是情绪曲线和触发时机。战斗音乐什么时候切入、Boss 进入第二阶段音效怎么变、UI 点击音的一致性规则这些都要在文档里提前定调否则最后就是十几个人各发一批素材拼在一起风格打架。QA 读 GDD找的是可验证的验收条件。所以数值部分尽量写成预期值 容差范围比如跳跃最高点约为 3.2 米允许 ±0.2 米误差而不是跳得高一点。这一点在早期就能省下大量扯皮。1.3 项目规模决定文档粒度不是所有项目都需要一份上百页的 GDD。文档粒度应该跟着团队规模和项目复杂度走这里给一个我实际用过的对照表。项目类型团队规模建议文档形态大致篇幅玩法原型1-2 人一页纸 数值表1-3 页小型独立游戏3-8 人模块化文档 表格15-40 页中型商业项目15-40 人分册 GDD 工单系统80-200 页大型长期运营50 人以上文档库 单一数据源无固定上限关键判断标准是沟通成本。两个人的时候你扭头喊一声比写文档快得多这时候写详细文档反而是浪费。一旦超过八个人信息传递开始出现衰减这时候文档的边际价值就急剧上升。我踩过的一个坑是在四个人团队里坚持写正规文档结果两周里文档改了六版程序每次都要重新看效率反而更低。后来改成只维护一份数值表和一份核心循环说明团队节奏立刻就顺了。1.4 GDD 的三种生命周期形态同一个项目在不同阶段GDD 承担的职责是不一样的。概念期它的核心任务是说服和收敛篇幅短、形容词少、图示多重点是把这游戏好玩在哪用一页纸说清楚。这个阶段的文档允许大量待定但每个待定项都要写明负责人和截止时间。预生产期它的核心任务是验证。文档要围绕一个垂直切片展开把所有关键系统的最小可用版本描述完整包括数值、交互、资源需求。这个阶段的文档密度最高也最容易写废——因为很多设计在这个阶段会被证伪。生产期它的核心任务是拆解和跟进。这时候文档本身不再是主体工单系统变成了主体GDD 退化成权威参考源。任何一条工单都应该能回溯到 GDD 的某个小节编号否则就会出现这个功能是谁让加的这种经典悬案。2. 动笔之前把骨架搭对后面少改一半2.1 一份能用的 GDD 目录长什么样我用的目录结构大致如下模块顺序不是随便排的基本遵循从玩家看到什么到系统怎么算到内容怎么排的认知顺序。概述一句话定位、目标平台、目标玩家、核心体验目标、参考作品核心循环玩家在 30 秒、5 分钟、1 小时、10 小时四个尺度上分别做什么系统清单每个系统的职责、输入、输出、与其他系统的依赖关系数值设计属性定义、公式、成长曲线、经济产出与消耗内容规划关卡/章节数量、节奏曲线、内容解锁顺序交互与界面操作映射、界面结构、状态流转美术需求风格定义、资源清单、命名规范音频需求音乐层次、音效清单、触发规则本地化与可访问性文本量预估、字号与色盲适配附录术语表、参考链接、变更记录这里有个经验目录里必须有依赖关系和变更记录这两块。前者防止你设计出一个自相矛盾的系统后者防止三个月后没人记得某条规则为什么是现在这样。2.2 信息分层把已定和待定物理隔开新人写文档最常见的结构问题是把确定的和不确定的混在一段话里。三个月后回看根本分不清哪句是定论、哪句是当时的猜想。我的做法是给每条信息打状态标签用统一的写法[已定]已经通过验证改动需要走评审[暂定]当前采用预期会调整附上调整触发条件[待定]尚未决策附负责人和截止时间[废弃]曾经的方案保留是为了记录决策路径这套标签看着啰嗦实际用起来非常省事。当程序问这条到底是最终版吗你直接搜标签就能回答不用凭记忆。2.3 版本、状态与变更记录变更记录不是应付流程的装饰。我要求每条记录至少包含四项日期、改动内容、改动原因、影响范围。其中改动原因最重要因为它是唯一能防止团队重复踩同一个坑的东西。举个真实例子。我们曾经把技能冷却从固定值改成随等级递减两周后又改回固定值。如果变更记录里只写冷却机制调整第三周新来的策划很可能又提一次递减方案。但如果记录里写着递减导致低等级段技能空窗过短战斗节奏碎片化实测后回退这个决策路径就被封存了。3. 核心模块逐条拆解从概念到可执行数值3.1 核心循环别写形容词写动词和资源核心循环是 GDD 里最容易被写空的部分。典型的失败写法是玩家探索地图击败敌人获得奖励变得更强。这句话没错但没有任何执行价值。我会用动词 资源 反馈三件套来拆。以上面这句话为例展开后大概是这样的玩家进入一张关卡动词进入→ 消耗时间与生命值资源资源时间、HP→ 通过战斗行为击败敌人动词击败→ 获得经验、掉落物、解锁进度资源经验、道具、进度点→ 属性提升或内容解锁反馈数值成长、新区域可达→ 促使玩家进入更高难度的关卡回到起点这样拆完之后每个环节都能派生出具体设计问题一场战斗预期消耗多少 HP掉落率怎么定进度点需要多少个才能解锁下一个区域这些问题一旦有了答案文档就从描述变成了规格。我还会额外做一件事把核心循环按时间尺度分段写。30 秒尺度是单次操作反馈5 分钟尺度是一次战斗或一个关卡1 小时尺度是一个章节10 小时尺度是整体进度。四个尺度都要有明确的玩家此刻在追求什么这样节奏设计才有依据。3.2 数值设计公式、曲线与推导过程数值部分最忌讳只写结果不写推导。我要求任何一条数值都必须能回答这个数字是怎么来的。先看伤害公式。一个最常见的结构是最终伤害 基础攻击力 × 技能倍率 × (1 增伤加成) × 防御减免系数 × 暴击系数 防御减免系数 防御力 / (防御力 常数 K)选择这种除法减免而不是减法减免原因是它天然不会出现负伤害和无敌堆防的问题。减法减免在高防御时会直接归零除法减免则是渐近趋近于 0曲线更平滑也更容易做平衡。常数 K 的取值通常等于设计上希望达到 50% 减伤时对应的防御力数值这个数值直接决定了防御属性的收益拐点。再看成长曲线。经验需求常用的是幂函数升级所需经验 基础值 × 等级 ^ 指数指数取 1.5 时前期升级快、后期逐渐拉长但不会像指数函数那样炸掉。取 2.0 则后期非常陡适合强调长期投入的项目。这个指数不是拍脑袋定的它要和内容量对齐如果你总共设计了 40 小时的游玩内容希望玩家在 30 小时左右满级那就用内容时长反推每一级应该停留多久再反推经验需求。我习惯在文档里放一张期望进度表把每个等级段的预期游玩时长、预期战斗场次、预期资源产出全部列出来然后逐个核对总和是否和内容规划对得上。这一步能提前发现大量数值和内容不匹配的问题。注意所有公式在文档里必须写清楚变量的定义域和优先级。比如增伤加成是否和其他加成加法叠加、是否有上限、多个来源同时生效时的计算顺序这些不写清楚程序只能自己猜最后一定是各处实现不一致。3.3 关卡节奏用表格描述体验曲线关卡设计如果只写文字描述几乎必然出现理解偏差。我推荐用表格来固定节奏。关卡段落目标时长主要玩法强度指数情绪设计开场引导2 分钟基础操作教学1好奇、安全首次遭遇3 分钟单一敌人类型3紧张感建立机制引入5 分钟新增环境互动4学习与掌握组合考验6 分钟双机制叠加6压力上升短暂喘息2 分钟资源补给、无战斗2释放收尾战斗7 分钟精英敌人8高峰体验强度指数是我自己用的一个 1 到 10 的粗略标尺用来观察关卡的强度是否单调、是否有张弛。很多新手设计的问题就是强度一路从 3 涨到 8中间没有波谷玩家玩下来只会觉得累。注意短暂喘息这一段。它不是可有可无的填充而是让高峰体验成立的必要条件。没有低谷高峰就不存在。3.4 交互与界面状态机加低保真线框交互部分我会写两类内容。第一类是操作映射表。每个平台上的每个输入对应什么行为长按和短按是否区分组合输入是否有优先级全部列清楚。这张表同时也是本地化和手柄适配的依据。第二类是界面状态流转。用文字描述状态机就行比如主界面 → 进入关卡选择 → 选择关卡 → 加载界面 → 战斗界面战斗界面可在正常暂停结算三个状态间切换暂停状态只能回到战斗或退出到主界面不能直接进入结算写完状态流转后我会画低保真线框用方块和文字标出每个界面的信息层级和按钮位置不做视觉设计只定结构。这一步能提前暴露大量这个按钮放不下这个信息玩家看不到的问题成本极低。3.5 美术与音频需求写成外包能接的清单美术需求部分我坚持一个标准把它写成一份可以直接发给外部供应商的清单。如果外包看完还得回来问三轮说明清单没写清楚。清单字段大致包括资源名称、用途、尺寸与格式、面数或分辨率上限、风格参考、是否需要多状态默认/悬停/禁用、交付格式与命名规则。命名规则一定要提前定比如ui_icon_skill_fire_01.png这种前缀加分类加序号的结构后期资源上千个的时候命名混乱会让人崩溃。音频需求同理但要多一项触发规则。同一个音效在不同情境下是否需要不同版本比如敌人近处和远处的攻击音是否允许被截断是否优先级高于背景音乐这些都要写明。4. 从零到可执行一份 GDD 的三轮迭代实操4.1 第一轮一页纸先把核心体验钉死一页纸文档的目标不是描述完整的游戏而是回答一个问题这个游戏的核心体验是什么凭什么它值得被做出来。我写一页纸的时候固定包含五块内容。第一块是定位句格式是这是一个面向某类玩家的某类型游戏核心体验是某某。第二块是核心循环的四个时间尺度。第三块是三条差异化设计也就是和同类作品比我们的不同点在哪。第四块是一个关键场景描述用第一人称写玩家在游戏里最精彩的那三分钟。第五块是风险和未解问题坦白列出你现在还不知道答案的东西。这份文档原则上不超过两页写完之后我会拿给团队里完全不了解项目的人看让他们复述一遍核心体验。如果复述不出来就是一页纸没写好回去改。4.2 第二轮垂直切片文档把所有系统压到最小可用垂直切片的意思是不做完整游戏但把每个关键系统都做出一个能跑通的最小版本从头到尾串成一条完整的体验线。这个阶段的文档要做的核心工作是裁剪。比如完整的装备系统包含 200 件装备、6 个稀有度、强化、附魔、套装效果切片版本只保留 5 件装备、2 个稀有度、无强化。文档里要明确写出切片版本包含什么、不包含什么、不包含的部分预计何时补充。我踩过的坑是切片做太大。曾经有个项目切片阶段就想把装备系统做全结果三周过去核心战斗还没验证完等到发现战斗手感不对的时候装备系统已经做了一半推翻成本极高。后来我定了个规矩切片阶段任何单个系统的内容量不超过完整版本的 10%超了就砍。4.3 第三轮生产期拆分与工单化进入生产期文档的角色从主要工作物变成参考源。这时候要做的是把文档拆成工单。我的拆分方式是每个工单必须包含四项——功能描述、验收标准、依赖项、文档锚点。其中文档锚点就是 GDD 里的章节编号比如GDD 3.2.1。这样任何人都能顺着工单回溯到设计原文避免口头传达造成的偏差。拆分粒度上有个经验值单个工单的预期完成时间控制在半天到三天之间。超过三天的工单往往意味着它其实包含多个独立功能应该继续拆低于半天的工单管理成本会超过收益。4.4 工具链怎么选够用就好工具选择上我没什么执念几家都用过关键看团队现状。工具类型常用选择适合场景主要缺点在线文档飞书文档、Notion、腾讯文档小团队协作、需要多人同时编辑结构化查询弱数据分散表格工具Excel、Google Sheets数值配置、批量数据版本管理容易乱原型工具Figma、Axure界面线框、交互演示与文档容易脱节项目管理Jira、TAPD、GitHub Issues工单流转、进度跟踪灵活度依赖配置版本控制Git、SVN数值文件、配置表需要一点技术习惯我个人的组合是正文用在线文档、数值用表格、工单用项目管理工具、配置表进版本控制。四者之间靠命名规范和小节编号串起来。工具越少越好多一个工具就多一份同步成本。见过不少团队为了管理规范上了五六个平台最后没人愿意维护。5. 常见问题与排查最容易翻车的八个地方5.1 内容层面的四个高频问题问题一形容词替代规格。文档里出现流畅爽快有深度这类词基本等于没写。排查方法是全文搜索这类形容词每出现一次就追问具体表现是什么。替代方案是把形容词翻译成可测量的指标比如流畅可以翻译成输入到反馈的延迟低于 80 毫秒。问题二只写正常流程不写异常分支。玩家在加载中掉线、技能释放瞬间角色死亡、背包满时拾取道具这些情况永远会发生。我的做法是在每个系统后面强制加一节异常情况至少列出五条边界条件。这个习惯让我们的 bug 数量在测试期明显下降。问题三数值之间互相矛盾。单看每条公式都对合在一起就出问题。比如掉落率设计成 5%但玩家每小时需要 20 个材料而每小时只能打 30 场战斗算下来期望产出只有 1.5 个完全对不上。解决方法就是前面提到的期望进度表把所有数值放在同一张表里做总量核对。问题四内容量与工期不匹配。文档里规划了 60 个关卡但按团队产能算下来需要 20 个月而项目周期只有 12 个月。这类问题在文档阶段发现成本最低进入制作就是灾难。我习惯在文档里加一节内容产能测算把每个内容的预估工时列出来求和。5.2 协作层面的四个高频问题问题五文档只在策划内部流转。程序、美术靠口头传达获取信息导致实现和设计脱节。解决方法是在需求确认环节要求每个岗位的人回复我理解的是这样对吗形成书面确认。问题六没有单一数据源。同一个数值在文档、表格、代码里各有一份改了一处忘了另外两处。我的做法是明确声明数值以配置表为唯一标准文档中的数值仅供参考并在文档对应位置标注配置表路径。问题七文档更新滞后于实现。做出来的东西和文档不一样久而久之没人再信文档。这个问题的根源是流程里没有实现后回写文档这一步。我把它加进了验收检查项功能验收通过后必须有人回写文档并更新状态标签。问题八术语不统一。同一个东西在不同文档里叫不同名字沟通时各说各话。解决方法是在附录里维护一份术语表规定每个概念的唯一中文名和英文名所有文档统一使用。这份表看起来不起眼但在跨部门沟通时价值极高。5.3 一份问题速查表现象可能原因排查动作各岗位理解不一致缺少书面确认环节检查是否有需求回执记录数值实现和文档不符存在多份数据源确认唯一标准来源并标注文档半年没更新流程中缺少回写步骤把回写加进验收清单需求反复变更早期验证不充分检查切片阶段是否覆盖核心系统讨论时各说各话术语不统一建立并强制使用术语表工期总是不够内容量未做产能测算补充工时估算表测试用例难以编写缺可验证的验收条件把描述改成数值加容差外包返工率高资源清单信息不全补全尺寸、格式、命名规则最后分享一个我自己用了很多年的小习惯每份 GDD 的最后一页我都会留一块未解问题清单把所有当前没有答案的设计问题列在上面标注负责人和截止日期。项目推进过程中这块清单会不断缩短又不断新增它其实是整份文档里最有信息量的部分——因为它记录的是一个项目真实的思考进度而不只是已经想清楚的东西。等到某天你发现这块清单连续两周没有新条目而且旧条目全部清空那大概就是这份文档真正成熟的时候了。
