第一次带团队把脑子里的想法落成能跑起来的版本时我才真正明白游戏设计文档GDDGame Design Document不是写给老板看的汇报材料而是写给明天就要动手做东西的那群人看的施工图。你说做一个打击感很强的动作游戏程序听到的是要做什么动画、判定框多大、什么时候播特效美术听到的是角色有几个攻击动作、每个动作几帧音频听到的是要不要分图层、命中音效怎么叠。这句口头描述在这三类人脑子里会长出三棵完全不同的树最后拼在一起就是一场灾难。这份文档要解决的核心问题只有一个把一个人脑子里的模糊画面翻译成一群人能同时理解、能并行开工、能验证对错的结构化信息。它适合刚入行的策划、独立开发者、小团队主策也适合那些自己既写策划又写代码的全栈型选手。下面我把这几年写 GDD 的完整思路、结构、颗粒度取舍和踩过的坑尽量拆细了讲一遍你可以直接拿去当模板改。1. GDD 到底是个什么东西先把它的边界划清楚很多新人一上来就问GDD 有没有标准模板。这个问题本身就有点偏。模板是死的文档要服务的对象是活的。你团队三个人和三万人需要的 GDD 完全是两种东西。所以我更愿意先花点篇幅把它的边界讲清楚边界清楚了模板自然就长出来了。1.1 一段口头创意到可执行方案中间丢了多少信息随便举个最常见的例子。你跟团队说我们做一个横版动作游戏主角有三段连招打起来很爽。这句话在传播过程中会衰减掉 90% 以上的信息。程序会追问三段连招是固定顺序还是可以切入第一段打完多久能接第二段如果玩家在第三段中途被打了怎么办美术会追问三个动作共用一套骨骼还是三套每段的时长是多少帧音频会追问命中音效分几种材质挥空有没有音效GDD 的价值就体现在这里——它把这些追问提前问完并且把答案固化下来。一段创意在脑子里是连续的、模糊的、随时可变的一旦写成文档它就必须变成离散的、明确的、可以被他人检验的。这个从连续到离散的过程就是策划真正的工作量所在。我自己的判断标准很简单如果一份文档交给一个从没参与过讨论的程序他能在一周内做出一个能跑通核心玩法的可玩版本那这份 GDD 就及格了。如果他做出来的东西和你想的差了一大截问题一定出在文档里而不是出在他理解能力差。1.2 它和策划案、需求文档、技术方案不是一回事这四个词经常被混用其实各有分工。我梳理了一张表你可以对照着看文档类型主要读者回答的问题变更频率游戏设计文档 GDD全体开发成员这个游戏是什么、怎么玩、规则如何中随设计迭代策划案 / 设计提案主策、制作人为什么做这个、目标用户是谁、商业价值低立项阶段定需求文档 PRD程序、测试具体某功能要做什么、验收标准高随排期走技术方案 TDD程序用什么架构、什么数据结构、性能预算中随技术评审走看这张表会发现GDD 是唯一一份面向全体成员的文档。它不需要像 PRD 那样精确到每个字段的校验规则但它必须让美术知道氛围基调、让音频知道节奏密度、让程序知道核心数据流。它的定位介于愿景和规格之间是一个偏中间的、需要多方对齐的载体。注意很多团队失败的原因是让 GDD 承担了 PRD 的职责把每个功能的边界条件都写进去结果文档膨胀到几百页没人看得完最后索性不看了。GDD 应该保持够用即止细化的部分拆到单独的模块文档里。1.3 谁读这份文档决定了它该长什么样写之前先列读者清单这是我养成的一个习惯。以我最近做的项目为例读者至少包括主程、客户端程序、服务端程序、动作美术、场景美术、UI 美术、音频设计师、关卡策划、数值策划、QA、运营、本地化。这十几类人关心的东西完全不同。程序最关心的是数据结构和状态流转。你把角色可以在受击时被击退写成一句描述程序就得自己猜击退距离怎么算、和其他位移会不会冲突。但如果你写成受击时播放 hit 状态该状态持续受击硬直帧数期间每帧沿受击方向位移击退初速度 × (1 - 当前帧 / 总帧数)他就能直接落地。美术最关心的是参考和约束。光写科幻废土风没用得给出色板范围、材质倾向、参考图链接最好再标注一下角色在屏幕上的实际占比是多少像素因为这会直接决定他画多细。QA 最关心的是可验证的判定条件。所有提升了优化了更好了这类模糊表述对 QA 来说都是废的必须换成攻击间隔从 0.8 秒缩短到 0.65 秒这种可以被测试复现的句式。同一份 GDD面对这么多读者写法上就得做分层核心章节人人必读细节章节按职能拆分。这也是后面我要讲文档不是一个文件的原因。1.4 GDD 从来不是一个文件而是一组文档新人最容易踩的坑就是试图把所有东西塞进一个 Word 文档里。写到第三章数值的时候你发现几十个技能的数据用文字描述简直是在自虐写到关卡的时候你又想画个俯视图Word 里插图排版能把人逼疯。我现在的做法是主文档Wiki 形式负责叙述性的、需要连续阅读的部分比如核心体验、设计理念、系统概览数值用在线表格一行一个技能或一个敌人列是各种属性流程图、状态机、UI 层级这些用白板工具画参考图、音效样本用共享文件夹。主文档里只放大纲和链接。这样做的好处是每个文档都能用最适合它的工具承载。数值策划改平衡性时只动表格不会污染主文档程序看数据流时直接进流程图美术看参考时进素材库。变更也更容易追踪谁在哪一块动了什么一目了然。2. 动手之前先定骨架GDD 的整体结构怎么搭结构这件事我的经验是先定骨架再填血肉。很多人一上来就开始写玩法细节写了三页发现漏了叙事又回头补补完发现和玩法对不上来回折腾。骨架定好了你至少知道每一块该放什么不会跑偏。2.1 一份能落地的 GDD通常包含这些模块我把这些年的结构沉淀成一个相对通用的清单你可以按项目类型增删游戏概述一句话定位、类型、目标平台、目标时长、目标用户核心体验支柱三到五条不可动摇的设计原则核心循环玩家在 30 秒 / 5 分钟 / 1 小时 / 长期分别做什么系统与机制战斗、成长、经济、社交、任务等各系统的规则数值框架属性定义、伤害公式、成长曲线、经济平衡关卡与内容规划关卡结构、难度曲线、内容清单表现层指引美术风格、音频设计、叙事与文本UI/UX界面层级、交互流程、关键页面说明技术约束性能预算、平台限制、依赖项里程碑与范围版本划分、优先级、砍功能预案附录术语表、参考、变更记录这份清单看起来长但不是每个模块都要写得一样厚。独立小项目里社交这一章可以只有一句本作无社交系统而核心循环可能要写两三千字。厚度分配本身就是设计判断力的一部分。2.2 先写一页纸One-Pager 先行不管项目多大我都坚持先写一份一页纸的概述业内叫 One-Pager。它包含一句话定位、三到五条核心体验、核心循环的极简描述、目标平台和时长、参考作品两三个。为什么这么执着因为一页纸的修改成本极低。立项阶段你的想法每天都在变如果直接写三十页详细文档改一次要半天你反而不敢改了于是被一份过时的文档绑架。而一页纸改起来十分钟可以一天改八遍改到各方都点头再往下展开。更重要的是一页纸是绝佳的对齐工具。制作人、主程、主美坐在一起看这一页五分钟后就能吵起来——你说 8 分钟一局但核心循环里有个养成系统8 分钟根本推不动这种争吵在立项期发生是好事在开发三个月后发生就是灾难。我通常会在一页纸里放这么一段非目标明确写出我们不做开放世界我们不做多人对战我们不做长线剧情。明确不做什么往往比明确做什么更能收窄范围。这是我吃过亏之后学到的——不写非目标团队就会默认什么都可能做需求会像滚雪球一样膨胀。提示一页纸定稿后务必写明版本号和日期并且把它作为后续所有讨论的基准。后续任何偏离一页纸的设计都要在评审里说明原因否则就会慢慢跑偏。2.3 颗粒度取舍写太细和写太粗都是坑这是写 GDD 最核心的手艺没有之一。写太粗程序自由发挥做出来的东西失控写太细你替程序把代码都设计完了既浪费时间又容易出错还压制了执行者的专业判断。我总结了一条边界线写清结果和约束把实现留给执行者。举个例子。角色跳跃高度是 3 格是结果必须写跳跃时用物理引擎的初速度参数是实现不必写。每回合玩家最多行动 3 次是约束必须写用状态机还是计数器来实现是实现不必写。伤害不能因为数值溢出变成负数是约束必须写用无符号整数还是浮点是实现不必写。那什么时候必须写到实现层有两种情况。一是这个实现方式本身就是设计的一部分比如卡片拖拽必须是即时响应不能有网络延迟感这直接决定了要不要做本地预测属于设计约束。二是团队里有新人或者外包需要降维到更具体才能执行。除此之外一律不写。还有一个判断技巧如果一个细节改了会让玩家感知到变化那它是设计要写如果一个细节改了玩家完全无感那它是实现不写。玩家能感知攻速从 1.0 变到 1.2但感知不到用数组还是链表存技能。3. 核心章节逐个拆解怎么写才有人看、看了能用骨架搭好之后真正花时间的是内容章节。我把几个最关键的章节拆开讲每个都给出具体的写法和例子你能直接套用。3.1 概述与核心体验支柱先立规矩再谈细节核心体验支柱Pillars是整份文档的灵魂一般三到五条每条一到两句话。它的作用是在后续无数个设计决策里当仲裁者。拿一款横版动作 Roguelite 举例我可能写这么四根支柱每一刀都要有重量命中有停顿、有震动、有音效反馈玩家能摸到打击。失败是学习而非惩罚单局失败只损失当局进度永久成长保留玩家永远在积累。选择在 30 秒内完成所有三选一、路线选择都要在 30 秒内做完不打断节奏。一局刚好一顿饭的时长目标单局 8 到 12 分钟。有了这四条后面所有争论都有了裁判。美术说我想把命中特效做得特别华丽策划就能用第一根支柱回应华丽可以但必须能突出重量感不能糊住画面让玩家看不清判定。程序说单局时长能不能到 20 分钟内容更好排第二根和第四根支柱直接否掉。我见过太多项目因为没写支柱导致每个决策都要重新吵一遍或者由嗓门大的人拍板。支柱写得好不好直接决定了后续沟通成本。写法上每根支柱我建议配一句反面例子。比如每一刀都要有重量后面加一句反面命中只有音效、没有视觉和震动反馈打击感会像砍空气。有了反面例子执行者才知道边界在哪。这招比只写正面描述有效得多因为人更容易理解不要做什么。3.2 核心循环把时间轴切成四层来写核心循环Core Loop是 GDD 里被误解最多的章节。很多人只写一层比如打怪—掉装备—变强—打更强的怪这太浅了落地的时候完全不够用。我的做法是把循环按时间尺度切成四层每层都写清楚玩家做什么和获得什么反馈时间尺度玩家行为期望反馈设计意图30 秒一次战斗、一个房间命中反馈、掉落弹出即时爽感5 分钟打完一小段关卡结算面板、解锁提示阶段成就1 小时完成一整局永久成长、新卡解锁长期积累长期多局循环剧情推进、难度解锁留存驱动这么写的好处是你能立刻发现循环里的断点。比如30 秒层设计得很爽但5 分钟层没有任何反馈玩家打了五分钟后会觉得我图啥。很多小体量游戏就死在这里——爽点密度不够中间层是空的。我还会在核心循环下面补一段循环断裂分析写明如果某一层缺失会发生什么。比如如果 1 小时层没有永久成长玩家会认为失败没有意义重复游玩意愿下降。这种反向分析看着有点啰嗦但它是团队里最有价值的一段内容因为它把设计意图显性化了程序在做系统时会主动帮你留出成长接口。3.3 系统与机制数值、公式、状态机三件套这是 GDD 里最硬核也最容易写崩的部分。我的经验是把它拆成三样东西来处理每样用不同的表现方式。**第一样是数值表。**能用表格的绝不用文字。假设我现在定义技能一张表就够了技能 ID名称基础倍率冷却秒消耗前摇帧生效帧后摇帧备注SK_01斩击100%0.8108312可被跳跃取消SK_02挑空140%3.02010418命中浮空目标必暴SK_03突进120%5.0256620位移 4 格这张表的价值在于程序可以直接把它转成配置表美术可以按帧数排动作音频可以按帧数对音效点QA 可以按备注写测试用例。一份表服务四个职能这就是结构化的力量。**第二样是公式。**所有涉及计算的系统都要写公式而且要写清楚每个参数的含义和取值范围。以伤害为例最终伤害 基础攻击 × 技能倍率 × (1 增伤率) × 暴击系数 × 防御减免 防御减免 防御力 / (防御力 K) K 100 10 × 关卡等级 暴击系数 暴击时取 1.5非暴击取 1.0写完公式还不够我会补一段参数取值范围基础攻击 10 到 200增伤率 0 到 1.5防御力 0 到 500。这样数值策划调平衡时一眼就知道哪个参数还能加、加到多少会失衡。没有取值范围数值策划会调到填出天文数字。**第三样是状态机。**用来描述角色或系统会经历哪些状态、状态之间怎么切换。还是角色的例子当前状态触发条件目标状态附加效果待机按攻击键攻击前摇无攻击前摇到达生效帧攻击生效生成判定框攻击生效后摇结束待机清除判定框任意状态受到伤害受击硬直播放受击动画击退位移攻击后摇按跳跃键跳跃取消后摇状态机用表格写就很好不用非得画图。关键是穷举状态并且穷举切换条件。我经常发现新人漏写受击打断攻击这种切换结果程序做完发现角色被打了还能继续挥刀又得返工。提示状态机表格里所有的帧都要注明是按 60 FPS 还是 30 FPS 计的。我踩过这个坑——动作美术按 30 FPS 做了个 12 帧的后摇程序按 60 FPS 实现实际手感快了一倍整个战斗节奏全乱。3.4 关卡与内容规划把难度画成一条曲线关卡章节如果只写第一章是森林第二章是城堡那就是在写作文。真正有用的关卡规划应该包含难度曲线、内容密度和关卡结构三个维度。难度曲线我习惯用一张表来表示每五到十分钟一个检查点关卡段预计时长敌人强度新机制引入预期通关率1-1 至 1-35 分钟基础敌人移动、跳跃95%1-4 至 1-66 分钟加远程敌人闪避80%1-7 至 1-98 分钟加精英怪连招取消60%1-10 Boss4 分钟Boss综合运用40%预期通关率这一列是我强烈建议加的。它逼着你想清楚每个关卡段到底想要多少玩家通过。如果 1-4 的预期通关率你填了 80%实际测下来只有 30%那一定是难度断层了得查是不是新机制引入太陡。没有这个列你只能靠感觉说这关有点难。内容密度指的是玩家在这段时间里接触到多少新东西。我的经验是前十五分钟至少每分钟一个新鲜刺激之后可以放缓到每三分钟一个。太密会让人疲劳太疏会让人腻。关卡结构是指在空间上怎么组织。是线性一条线还是有分支路线还是有枢纽房间这直接决定了美术的资产量和程序的地图系统。我会在关卡章节里画一张极简的节点图用表格或列表描述连接关系即可标明每个区域的功能和规模。3.5 表现层指引美术、音频、叙事的不越界写法表现层最容易写成散文什么营造出孤寂而宏大的氛围执行者看完一头雾水。我给表现层定的规矩是每一项都要落到可执行的参数或清单上。美术部分至少包含色板给出具体色值范围、参考图三到五张注明参考的是构图不是风格、屏幕占比角色在 1080p 下实际占多少像素高、资产清单需要多少种敌人、多少个场景、多少套 UI。音频部分至少包含音乐风格参考、音效清单按事件分类如命中受击拾取UI 点击、混音优先级哪些声音不能被盖住比如敌人攻击预警音、动态音乐触发条件血量低于 30% 时切到紧张层。叙事部分要区分硬设定和软氛围。硬设定是会影响玩法的东西比如这个世界里角色不能飞必须写清楚软氛围是文本风格和世界观碎片可以放到单独的叙事文档里。把两者混在一起写程序读的时候会分不清哪些是约束、哪些是装饰。我踩过的一个坑是叙事里随手写了一句主角是失忆的结果程序做开场动画时真的做了个失忆剧情但玩法上设定主角一开始就拥有全部技能逻辑对不上临时改稿折腾了一周。教训是任何叙事设定只要和玩法有潜在冲突都要在 GDD 里显式标注此设定不影响玩法或此设定约束玩法 X。3.6 UI/UX把界面写成人能看懂的层级表UI 章节我建议用界面层级表来写而不是画十张线框图。线框图留给交互原型GDD 里只需要讲清楚界面之间的关系。界面层级入口出口关键信息主菜单顶层启动游戏开始、设置、退出版本号、当前存档战斗 HUD覆盖层进入关卡心算、自动隐藏血量、技能 CD、货币结算面板模态层关卡结束继续、重开本局收益、解锁提示背包二级主菜单、HUD返回物品列表、详情这张表一出来UI 美术就知道要做几个界面程序就知道界面栈怎么管理交互设计就知道哪些是模态、哪些是覆盖。比画图高效多了。交互流程再补一张关键操作路径表比如从主菜单到进入第一关需要几步点击。我给自己定的标准是核心操作不超过三步。超过一步玩家就可能在犹豫中退出。4. 实操从零写出一份能玩的 GDD前面讲了那么多结构和方法现在我把它们串起来用一个完整案例走一遍。这个案例是一款小体量横版动作 Roguelite目标单局 10 分钟适合一到两人的小团队。4.1 案例设定与目标拆解先写一页纸。定位横版动作 Roguelite目标平台 PC单局 8 到 12 分钟目标用户是下班后想快速爽一把的玩家。核心体验支柱就是我前面举的那四条。然后做目标拆解把大目标切成可验证的小目标首局体验目标玩家在 90 秒内理解移动、攻击、闪避三个操作单局目标玩家每局遇到 3 个随机房间每房间有一次三选一长期目标每局结束保留 20% 的永久成长货币手感目标每次命中有 4 帧停顿和轻微屏幕震动难度目标首次通关率控制在 40% 左右这些目标都可以被测试验证写出来之后团队心里就有数了。90 秒内理解三个操作这种目标直接可以拿去做新手测试。4.2 核心循环与数值框架搭建核心循环按四层时间尺度写前面已经给过表格这里补充数值框架。角色基础属性初始血量 100初始攻击 10初始移速 8 格/秒闪避无敌帧 12 帧冷却 0.6 秒。成长框架我设计成乘法叠加而不是加法叠加因为它更容易保持平衡最终攻击 基础攻击 × (1 所有加成之和) 所有加成包括装备加成、局内 buff、永久成长为什么用乘法因为加法叠加在多轮循环后会失控。假设每局给固定 5 攻击玩十局后攻击到 60怪物的血量没法设计了。而乘法叠加保持相对比例你只需要调整怪物的血量和防御整个系统就能稳定延展。敌人设计用威胁值来统一衡量强度。威胁值 血量 ÷ 100 每秒伤害 ÷ 10 特殊机制权重。一个房间的总威胁值控制在玩家当前战力的 0.7 到 1.1 倍之间这样既不会太难也不会太简单。这个系数范围是我实测出来的低于 0.7 玩家觉得无聊高于 1.1 玩家觉得不讲理。4.3 系统细节表格化把策划案写成可实现的说明书到了这一步就是把我前面讲的三件套填满。技能表、公式、状态机都要有。我举个具体的连招系统。三段连招每段可以取消。连招段输入窗口伤害倍率后摇帧可取消时机取消后进入第一段第 1 到 20 帧100%12第 8 帧起第二段第二段第 1 到 18 帧120%14第 10 帧起第三段第三段第 1 到 25 帧200%24第 18 帧起闪避或跳跃输入窗口和可取消时机这两列是新人和老手的最大差距。老策划会精确到帧新策划只会写连招要连贯。而连贯到底是多少帧程序不知道只能自己猜猜出来手感不对反复返工。写清楚帧数一次就过。再补一个打击感参数表事件停顿帧屏幕震动音效分层特效时长普通命中3 帧2 像素命中层0.15 秒暴击6 帧4 像素命中层 强化层0.25 秒终结击杀10 帧6 像素命中层 强化层 尾音0.4 秒这张表是整份文档里被美术和音频翻阅频率最高的一页。因为它把打击感这个玄学词拆成了可以被执行的参数。我每次做动作游戏这一页都是最先定稿的。4.4 版本迭代与变更记录GDD 是活文档必须维护变更记录。我的做法是在文档头部放一张变更表版本日期变更内容变更人影响范围0.1立项一页纸定稿主策全体0.2第二周核心循环四层定义主策程序、关卡0.3第三周连招帧数确定主策、动作程序、美术、音频0.4第五周成长改为乘法叠加数值程序、数值、QA变更记录看着琐碎但它是团队里最省事的一个设计。程序改了代码想查当初为什么这么设计翻变更记录比翻聊天记录快十倍。外包美术隔了两个月回来问参数你直接让他看变更记录不用重新解释一遍。注意变更记录里一定要写影响范围。我见过因为一次数值改动没通知音频导致音效长度和新的动作时长对不上发布前一周才发现加班重录。5. 协作与工具链让 GDD 真正活起来文档写完了不代表工作结束恰恰相反真正的挑战是让它别躺在网盘里吃灰。这一章讲协作和工具都是实操层面的干货。5.1 工具选型文档、表格、白板各司其职我现在固定用三类工具组合。文档用在线 Wiki负责叙述性内容表格用在线协作表格负责所有数值和配置白板工具负责流程图和状态机。为什么不合成一个因为它们的协作模式不同。文档要的是版本对比和历史追溯表格要的是多人同时编辑和公式白板要的是随意拖拽。强行合并每一样都用得别扭。还有一点经验能用表格的绝不用文档。数值、技能、敌人、关卡全部表格化。因为表格可以被程序直接导出成配置可以被数值策划直接用公式计算可以被 QA 直接生成测试用例。文档做不到这些。我在文档里只保留为什么这样设计的说明具体数据一律进表格。5.2 评审机制什么时候评审评审什么GDD 不能自己写完就发出去得有评审。但我反对全文档大评审一次评审三十页参与的人会走神最后变成走过场。我的做法是分模块小评审一次一到两小时只评审一到两个模块。评审节奏上我遵循先核心循环后系统细节最后表现层的顺序。因为核心循环一旦确定后面的所有细节都建立在它之上核心循环没定就评审表现层属于白费功夫。评审的产出必须落到文档里。我的规矩是评审当场记录结论会后 24 小时内更新文档并且把变更写进变更记录。否则评审完大家都记得改了但没人写下来两周后又是各说各话。提示评审时一定要拉上一个刺头。就是那个总爱挑毛病的人。他提出的问题往往是最尖锐但最有价值的。让他在评审阶段挑毛病比让他在发布后挑毛病划算得多。5.3 GDD 和原型的关系谁先谁后这个问题我纠结过很久。到底是先写文档再做原型还是先做原型再补文档我的答案是核心循环先做原型系统细节先写文档。原因很简单核心循环这种东西写再多文字都不如做出一个 30 秒的可玩片段来验证。手感、节奏、爽点这些是体验层面的只有玩到才知道对不对。你先写五千字描述打击感很强不如做个只有一刀的原型让团队上手砍两下。而系统细节比如成长曲线、经济公式、状态机这些东西做原型成本太高而且逻辑性的东西用文字和表格推演就够了。把这块先写清楚再交给程序实现效率远高于先写代码再回头补设计。所以我的流程通常是一页纸 → 核心循环原型 → 核心循环定稿进 GDD → 系统细节文档 → 系统实现 → 表现层文档 → 打磨。两条腿走路哪边效率高用哪边。6. 常见问题与排查技巧实录写了这么多年 GDD踩过的坑基本能归类。我整理成一张速查表你可以拿它当自查清单。6.1 GDD 常见问题速查表症状根本原因解决方向程序做出来的和想的不一样文档只写结果没写约束补上边界条件和判定规则文档没人看篇幅失控、重点被淹没拆分模块主文档只留大纲和链接改一处设计要改十处文档数据散落在多处所有数值收敛到单一表格美术风格反复返工表现层只有形容词没有参数补色板、占比、参考图测试用例写不出来用了更流畅更好这类模糊词全部换成可量化的描述数值调到失控缺少参数取值范围每个参数标注上下限新成员上手慢没有术语表附录加术语表并定期维护这张表里我个人觉得最值得警惕的是第一条。程序做出来的和想的不一样90% 的情况不是程序理解力问题而是文档里有一条隐含假设没写出来。比如你理所当然地认为攻击可以打断移动但没写程序就实现成移动中不能攻击。这种隐含假设是最隐蔽的 bug 源。排查方法也很简单每次发现做出来的不一样回头问自己我假设了什么没说。把这些假设逐条补进文档几轮之后文档质量会明显上一个台阶。6.2 几条踩过坑才懂的避坑心得**第一条别在文档里写参考某某游戏。**新人最爱这么写因为省事。但参考某某游戏的问题是不同人对同一个游戏的记忆是不一样的有人记得它的战斗有人记得它的美术有人记得它的付费。你写参考 A 游戏的战斗美术可能跑去参考了 A 游戏的美术。正确做法是拆解清楚战斗节奏参考 A 游戏具体是它的攻击间隔约 0.6 秒、后摇约 0.3 秒、命中停顿 3 帧。把参考拆成具体参数才叫真参考。**第二条留一页设计决策记录。**有些设计选择不是因为有数据支撑而是当时的权衡结果。比如我们没有做多角色切换因为单角色已经占满了美术资源。这类决策如果不记下来三个月后必然有人问为什么不做多角色你得重新解释一遍甚至有人会提议加多角色把范围又撑开。把决策和理由记下来能省下大量重复讨论。第三条文档的行文要用断言句不要用愿景句。我们希望玩家感到紧张是愿景句执行者不知道怎么做。当玩家血量低于 30% 时背景音乐切换为紧张层屏幕边缘出现红色渐晕且该状态持续到血量回到 50% 以上是断言句可以被实现和被测试。整份文档我都尽量用断言句写读起来可能没那么有文采但落地效率高得多。**第四条定期做一次文档体检。**我习惯每两周挑一个小时把文档从头翻一遍问三个问题有没有和当前版本对不上的地方有没有模糊词有没有没人认领的段落文档和人一样放着不管就会腐化。特别是项目做到中期变化快旧描述很容易过时而程序还在照着旧描述做等发现的时候已经晚了。**第五条给不同职能做阅读路径。**文档写好后我在开头放一张表告诉不同角色该看哪几章。程序看第 2、3、4、5 章美术看第 1、3.5、3.6 章音频看第 3.5、4.3 章QA 看第 3、4、6 章。这样每个人都不用读全文上手快也更容易形成这份文档跟我有关的认知。这套方法我是从一个老制作人那里学来的当时觉得有点小题大做后来带了一个二十多人的项目才发现没有阅读路径的文档基本等于没有文档——因为没人有耐心从头看到尾。最后再分享一个我自己的小技巧每次写 GDD 的时候我会在文档最后留一个待定问题清单把所有暂时没想清楚、但又不影响当前开发的点列在那里。这样做的好处是我不用在写文档时被这些悬而未决的问题卡住同时也不会遗忘它们。清单每周过一遍能解决的划掉解决不了的升格成需要评审的议题。写文档最怕的就是为了写完整而硬凑内容留一个诚实的待定比编一个假答案有价值得多。