游戏设计文档（GDD）

本页导读：这一页教你写游戏设计文档（Game Design Document，简称 GDD）——不是官僚表格，而是替你记住想法、说服合作者、拦住范围膨胀的三合一工具。学完你能写出一页纸 GDD 快速立项，也知道完整版该包含哪些模块、用什么工具维护最省事。

做游戏的第一杀手不是技术不行，而是想法在开发途中悄悄变形：上周说好的"极简肉鸽"，三个月后变成了四不像。

GDD 就是用来对付这个的。先说清楚，它不是什么关于"文档规范"的形式主义，而是三件很实际的事。

一、为什么需要设计文档：三个理由

理由一：记忆外化。

你对游戏的想象是模糊的画面和感觉，而人的记忆会悄悄篡改它。

三周前你觉得"核心乐趣是紧张感"，三周后开发卡壳时，你可能已经默默把它改成了"轻松休闲"，自己都察觉不到。

写下来的设计是锚点：要改可以，但要有意识地改，并知道自己改掉了什么。

理由二：沟通工具。

哪怕你是一个人开发，也有需要说服的对象——试玩的朋友、合作的美术、未来的发行商、三个月后忘光了细节的自己。

"我做的是一个很爽的游戏"说服不了任何人；一页写清核心循环和卖点的文档，五分钟就能让对方明白你要做什么。

理由三：拦截范围膨胀（Scope Creep）。

这是对独立开发者最致命的一条。开发途中每天都有新点子冒出来："要不要加个宠物系统""这个地图是不是再大一点"。

每一个单看都有道理，加起来就是做不完。GDD 里的范围边界就是闸门：新点子先记录，定期评估，值得加就正式修订文档再动工——让"加功能"变成决策，而不是习惯。

一句话总结：GDD 不是写给游戏的，是写给做游戏的你的。

顺带拆掉三个最常见的借口：

• "我是单人开发，不用文档"——单人更需要，因为你同时是那个三个月后会忘掉设计初衷的人。
• "点子都在我脑子里，很清晰"——清晰到能一口气写出一页纸吗？写不出来就是还不清晰。
• "写文档不如多做十分钟开发"——没有文档的开发，后期的每一分钟都在为返工买单。

二、一页纸 GDD：先把想法压成一页

新人最常见的错误是把 GDD 写成几百页的宏伟蓝图，然后从未开工。正确的顺序反过来：先写一页纸版本，写不满一页或超过两页，都说明你还没想清楚。

一页纸 GDD 只回答六个问题，用这张表对照着填：

字段	回答的问题	示例（虚构游戏《星港杂货店》）
概念一句话	这是个什么游戏？	在太空站经营杂货店，一边补货一边应对奇葩外星顾客
玩家是谁	给谁玩的？玩多久？	喜欢轻松经营的玩家，单局 10～15 分钟
核心体验	玩家全程反复做的那件事	排列货架、接待顾客、赚币升级店面
核心循环	一个回合内行为→反馈→奖励	补货→顾客购买→赚币→解锁新商品→吸引更多顾客
特色卖点	和同类游戏不一样在哪	顾客的奇葩需求驱动的轻叙事 + 单局制经营
范围边界	明确不做什么？	不做剧情主线、不做多人、不做开放地图

填表的两个要点：

• "范围边界"是最重要的一栏，也是新人最容易跳过的。写清楚"不做"，比写清楚"做什么"更难也更有用。
• 示例里故意选了一个小体量游戏。练习时也请选小体量的——一页纸 GDD 如果装不下你的点子，先砍点子，不是加页数。

写好一页纸之后，先别急着开发。放两天再读一遍，拿给一个朋友看，问一句："你觉得这游戏好玩吗？"如果对方一脸茫然，说明你的概念一句话还没磨到位。

另外用三个问题自检一遍：

• 核心体验那栏，是不是一个具体的"动作"而不是一个抽象的"感觉"？（"排列货架接待顾客"合格，"治愈与温惐"不合格）
• 范围边界那栏，是不是至少写出了两条"不做"？
• 六栏加起来，别人读完能不能复述出这是个什么游戏？

三、完整 GDD 的模板结构

一页纸 GDD 用于立项决策；项目真正开动后，再逐步长出完整版。完整 GDD 常见包含六个模块，按需取用，不要求全：

**1. 概念一句话。**放最顶部，永远可见。整个文档的其他部分都是给这句话打工的，任何模块和它冲突了，以它为准或正式修订它。

**2. 核心玩法。**写清楚玩家反复执行的行为、操作方式、胜负或结算条件。这是文档的心脏，建议配一张核心循环图（下一页核心玩法循环会教你怎么画）。

**3. 进度与成长。**玩家玩 10 分钟、1 小时、10 小时时分别在体验什么？解锁节奏怎么排？成长感来自数值变强、内容解锁还是技巧提升？

**4. 经济系统。**游戏里有几种资源？怎么获得、怎么消耗？产出和消耗的量级关系是什么？哪怕是小游戏也常有意外的经济设计——货币、体力、时间都是资源。

**5. UI 与交互。**屏幕上常驻显示什么信息？玩家最重要的操作映射在哪个键位？菜单层级有多深？UI 是玩法的一部分，别留到最后一刻。

**6. 风险清单。**列出三到五个最可能杀死这个项目的问题，每个附上你的应对预案。比如"货架摆放玩法可能不够爽 → 第三周做纸面原型验证，不爽就砍"。这份清单会在开发途中反复救你的命。

写作格式建议：每个模块用小标题加短段落和列表，配图（循环图、界面草图）比长文字有效十倍。

完整 GDD 的长度以"十页以内"为宜——它不是写作比赛，能指导开发就够了。

写作顺序也有讲究：先写核心玩法，再写进度与成长，然后是经济和 UI，最后补风险清单。

概念一句话虽然放在最顶上，但往往要等核心玩法写完才磨得准——允许自己最后再回头修改它。

每个模块写到什么程度算合格？给一个自查清单：

• 核心玩法：没玩过的人读完能描述出"玩家大部分时间在干什么"。
• 进度与成长：能回答"玩家第 10 分钟和第 1 小时玩到的内容有什么不同"。
• 经济系统：每种资源都有明确的来源和去向，没有只出不进或只进不出的孤儿资源。
• UI：拿一张草图就能指出"玩家视线焦点应该落在哪"。
• 风险清单：每条风险都附了可执行的验证动作和验证时间点。
• 全文：任何人能在一刻钟内读完，并且读完知道下一步该做什么。

四、轻量工具推荐

GDD 工具的选择原则只有一条：打开成本足够低，你才愿意天天更新它。

工具	适合场景	优点	注意点
Notion	个人或小团队在线协作	数据库、模板、多视图切换方便	依赖网络，离线不可用
飞书文档	国内小团队协作	表格与评论强大，上手零门槛	深度依赖飞书生态
本地 Markdown	单人开发者	纯文本、好备份、跟代码仓库放一起	排版和插图要自己打理
在线表格	数值和经济系统	公式随改随算，适合调参	不适合写长文字描述

几个实战建议：

• 单人开发，推荐"本地 Markdown 为主 + 一张在线表格管数值"的组合：设计文档跟项目代码放在同一个仓库里，版本历史自动保存。
• 有合作者，用 Notion 或飞书文档，对方不用装任何东西，发个链接就能评论。
• 无论用什么工具，在文档顶部放"最后更新时间"和"当前版本号"，这行小字后面会救命（见下一节）。

不要在工具选择上花超过十分钟。GDD 的价值在内容，不在载体。

五、GDD 是活文档，不是墓碑

最后一个观念修正：很多人写完 GDD 就再也没打开过，文档迅速变成与现实不符的"墓碑"。

GDD 应该是活文档——开发过程中不断修订，让它始终描述"当前的游戏"，而不是"立项时的幻想"。

维护节奏可以很简单：

• 开发中每次大改动（新增/砍掉一个系统、改变核心循环），当天更新对应模块，并在文档末尾加一行变更记录：日期 + 改了什么 + 为什么。
• 每个开发阶段结束（如完成一个可玩版本），通读一遍全文，删掉过时内容。删文档比写文档更难，但对活文档是必须的。
• 发售前，GDD 会自然演变成一份"游戏说明"，可以从中直接摘出商店页文案和教程文案——这是它给你的最后一笔回报。

变更记录是活文档的灵魂。半年后你纠结"当初为什么把体力系统砍了"，翻记录就能找回当时的决策理由，避免来回摇摆。

警惕两个反面模式：

• 墓碑文档：立项时写得漂漂亮亮，开发后再也没更新过。它不但没用，还会误导后来的合作者。
• 日记文档：事无巨细全部往里塞，文档比游戏还庞大，更新成本高到无人维护。GDD 记决策，不记流水账。

记住：文档跟不上现实，改文档；现实跟不下文档，改的通常也应该是文档先想清楚。

---

本页小结

• GDD 的三个作用：记忆外化、沟通工具、拦截范围膨胀——都是为开发者自己服务的。
• 立项先写一页纸 GDD：概念一句话、玩家、核心体验、核心循环、特色卖点、范围边界，其中"不做"最重要。
• 完整 GDD 六模块：概念、核心玩法、进度与成长、经济系统、UI、风险清单，十页以内够用。
• 工具按打开成本选：单人用 Markdown 加表格，协作用 Notion 或飞书文档。
• GDD 是活文档：大改动当天更新、记录变更理由，让它始终描述当前的游戏。

下一页：核心玩法循环，GDD 里最重要的"核心循环"到底怎么设计？我们从"玩家 30 秒内做了什么"讲起。