# 游戏设计文档模板

九份相互关联的文档，覆盖一款游戏从提案到决策日志的方方面面，每份都写明该写什么，并附一个简短示例。以 Markdown 文件下载：任何编辑器都能打开，在 GitHub 和 Obsidian 中会显示图表，导入 Nodary 后则成为一张地图。

免费，无需账户，无需邮箱。随意使用、修改和分享。

[下载模板 (.zip)](https://nodary.ai/downloads/game-design-document-template-zh.zip)

## 下载之前，先逐页看一遍

总览一屏就能看完，并链接到八个部分，每个职能一份：每个部分都有负责人，每次改动也都很小。斜体行告诉你该写什么；示例来自 Saltmarrow，也就是本站处处使用的示例游戏。

- 游戏设计文档: 所有人最先读的一页：提案、设计支柱、受众、范围，以及通往每个部分的链接。
- 游戏玩法: 玩家每分每秒在做什么，以及他们为什么会一直玩下去。
- 系统与经济: 每个系统、它遵循的规则、它流转的资源，以及背后的数值。
- 世界观、故事与角色: 背景设定及其规则、玩家亲历的故事，以及其中的人物。
- 关卡与内容: 玩家会去的每个地方、最初一小时的体验，以及首发需要多少内容。
- 美术与音频指导: 游戏的画面与声音，写得足够精确，让两位各自工作的美术做出的东西依然统一。
- 界面与无障碍: 界面、HUD 和输入，以及游戏如何适应每一位玩家。
- 技术设计: 引擎、性能目标、架构与管线，以及它们给设计带来的限制。
- 制作计划: 里程碑、团队、风险，以及每个改变了设计的决定的日志。

### 游戏设计文档

_使用说明：斜体行是写作指引。用你自己的话替换它们，然后删掉。方括号里的值由你来填。这一页尽量控制在一屏左右：它是所有人最先读的一页，设计的其他每个部分都只隔一个链接。_

#### 速览

| 条目 | 你的游戏 |
| --- | --- |
| 暂定名 | [名称] |
| 一句话介绍 | [一句陌生人也能复述的话] |
| 类型 | [类型与子类型] |
| 玩家 | [单人、2 至 4 人合作、竞技对抗] |
| 平台 | [PC、主机、移动端] |
| 单局时长 | [一局典型游戏的分钟数] |
| 引擎 | [引擎及版本] |
| 团队 | [目前规模与最大规模] |
| 商业模式 | [买断定价、免费游玩、订阅] |
| 下一个里程碑 | [名称与日期] |

#### 提案

_两三句话：玩家是谁，做什么，这款游戏有什么不同。写到可以直接放上商店页面的程度。_

_示例（取自示例游戏 Saltmarrow）： 耙盐，潜水寻回记忆，赶在涨潮之前回家。一款最多四人的合作探索与制作游戏，舞台是潮汐盐滩，一座沉没的档案之城每天两次浮出水面。_

[你的提案]

#### 设计支柱

_三到五条规则，每个功能都必须服务于它们。像“战斗爽快”这种放在任何游戏上都成立的话，不算设计支柱。不服务于任何支柱的功能要砍掉；违背某条支柱的功能要重新设计。_

1. **[支柱一]**：[一句话说明它的含义]
2. **[支柱二]**：[一句话说明它的含义]
3. **[支柱三]**：[一句话说明它的含义]

_示例（取自示例游戏 Saltmarrow）： 潮汐就是时钟。时间是唯一永不增长的资源：每个系统都读取潮汐，任何东西都无法让它暂停。_

#### 目标受众

_游戏为谁而做，他们现在玩什么，什么时候会流失。写出真实的游戏和真实的习惯，而不只是一个年龄段。_

- 核心玩家：[他们是谁，怎么玩]
- 他们现在玩的游戏：[三四款游戏]
- 他们在这种时候流失：[...]
- 次要玩家：[...]

#### 对标游戏

_三四款你的团队和玩家都熟悉的游戏。写明从每款中借鉴什么，以及同样有用的一点：舍弃什么。_

| 游戏 | 借鉴什么 | 舍弃什么 |
| --- | --- | --- |
| [游戏] | [...] | [...] |
| [游戏] | [...] | [...] |
| [游戏] | [...] | [...] |

#### 范围

_首个版本包含什么，以及明确不包含什么。防止范围悄悄膨胀的，正是第二份清单。_

- 首个版本包含：[...]
- 首个版本不包含：[...]
- 以后再定：[...]

#### 设计的其余部分

_每个部分都是一份独立文档。链接过去，而不是复制内容，这样每个事实只存在于一处，也只在一处修改。_

- [游戏玩法](https://nodary.ai/zh/templates/game-design-document#gdd-gameplay)：核心循环、机制、操作与成长
- [系统与经济](https://nodary.ai/zh/templates/game-design-document#gdd-systems)：每个系统、它的规则和数值
- [世界观、故事与角色](https://nodary.ai/zh/templates/game-design-document#gdd-world)：背景设定、故事以及其中的人物
- [关卡与内容](https://nodary.ai/zh/templates/game-design-document#gdd-levels)：每个地点、最初一小时和内容预算
- [美术与音频指导](https://nodary.ai/zh/templates/game-design-document#gdd-art)：游戏的画面与声音
- [界面与无障碍](https://nodary.ai/zh/templates/game-design-document#gdd-interface)：界面、HUD、输入与无障碍
- [技术设计](https://nodary.ai/zh/templates/game-design-document#gdd-technical)：引擎、性能目标、架构与管线
- [制作计划](https://nodary.ai/zh/templates/game-design-document#gdd-production)：里程碑、团队、风险与决策日志

_本模板可免费使用、修改和分享。它来自_ [Nodary](https://nodary.ai/zh)_，这些文件在那里可以导入为一张由相互关联的文档组成的地图。_

### 游戏玩法

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_玩家每分每秒在做什么，以及为什么会一直玩下去。从循环写起：本文档的其他内容都挂在它上面。_

#### 核心循环

_玩家重复最多的那个循环，用四到六个动词表达。如果团队画不出来，说明它还没定下来。_

```mermaid
flowchart LR
  n0["规划"]
  n1["探索"]
  n2["采集"]
  n3["制作"]
  n4["升级"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
```
_核心循环，每轮约 [n] 分钟_

| 环节 | 典型时长 | 玩家面对的问题 |
| --- | --- | --- |
| [规划] | [2 分钟] | [这次定什么目标，带什么出门？] |
| [探索] | [...] | [...] |
| [采集] | [...] | [...] |

_示例（取自示例游戏 Saltmarrow）： 采收还是潜水，8 到 14 分钟：稳稳地耙盐，还是潜下去找可能更值钱的水晶？每个环节都应该向玩家抛出一个问题。没有问题的环节，就是苦差事。_

#### 机制

_每个机制一行。“服务的支柱”一列让每个机制都站得住脚：不服务于任何支柱的机制，列入待砍清单。_

| 机制 | 玩家做什么 | 服务的支柱 | 状态 |
| --- | --- | --- | --- |
| [机制] | [...] | [...] | [构想、已做原型、已锁定] |
| [机制] | [...] | [...] | [...] |

#### 操作

_玩家的动词，以及每个动作应有的手感。各设备的按键映射见_ [界面与无障碍](https://nodary.ai/zh/templates/game-design-document#gdd-interface)。

- [动词]：[如何操作，应该是什么手感]
- [动词]：[...]

#### 成长

_在一局之内和整个游戏过程中，什么在成长，玩家如何看到它成长。写明长期目标。_

- 单局之内：[...]
- 跨局：[...]
- 长期目标：[...]

#### 挑战与失败

_难度如何提升，失败的代价是什么，玩家如何重新投入。只让玩家损失时间的失败，不如让玩家失去一个选择的失败更有教益。_

- 难度提升方式：[...]
- 失败的代价：[...]
- 重新投入的方式：[...]

_示例（取自示例游戏 Saltmarrow）： 号角响起时仍在档案馆里的潜水者，会失去背包里的水晶，并在最近的塔楼浮出水面，但保留身上的盐。_

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [游戏设计文档](https://nodary.ai/zh/templates/game-design-document#gdd-overview) · [系统与经济](https://nodary.ai/zh/templates/game-design-document#gdd-systems) · [关卡与内容](https://nodary.ai/zh/templates/game-design-document#gdd-levels)

### 系统与经济

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_游戏中的每个系统、它遵循的规则和背后的数值。数值每周都在变：把它们放在表格或电子表格里，把思路留在这里。_

#### 系统

_每个系统一行。不为任何东西提供输入的系统只是摆设。所有东西都汇入的系统是游戏的脊梁，值得单独写一份文档。_

| 系统 | 作用 | 读取自 | 输出到 | 负责人 |
| --- | --- | --- | --- | --- |
| [制作] | [...] | [背包] | [升级] | [姓名] |
| [系统] | [...] | [...] | [...] | [...] |

_示例（取自示例游戏 Saltmarrow）： 每个系统都读取潮汐：采收产量、风暴概率、村里的物价，甚至角色愿意和你聊多久。_

#### 资源与货币

_每种资源从哪里来（产出），到哪里去（消耗）。产出多于消耗的经济会通胀：调任何数值之前，先把这两列填上。_

| 资源 | 产出 | 消耗 | 上限 |
| --- | --- | --- | --- |
| [金币] | [...] | [...] | [无，或一个数值] |
| [资源] | [...] | [...] | [...] |

#### 奖励与掉落率

_掉落表、奖励概率以及保底规则（如有）。写明玩家应有的预期：半数玩家拿到某件物品需要尝试多少次，九成玩家又需要多少次。免费的_[掉落率计算器](https://nodary.ai/zh/tools/drop-rate-calculator)_可以根据一张权重表算出这些数字。_

| 奖励 | 权重 | 单次概率 | 保底 |
| --- | --- | --- | --- |
| [物品] | [...] | [...] | [无，或第 n 次] |
| [物品] | [...] | [...] | [...] |

#### 调节参数

_策划用来让游戏更简单、更快或更慷慨的少数几个数值，附当前值和已经测试过的范围。某个值改动时，在_[制作计划](https://nodary.ai/zh/templates/game-design-document#gdd-production)_的决策日志里记下原因。_

| 参数 | 当前值 | 已测试范围 | 影响 |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [游戏玩法](https://nodary.ai/zh/templates/game-design-document#gdd-gameplay) · [关卡与内容](https://nodary.ai/zh/templates/game-design-document#gdd-levels) · [制作计划](https://nodary.ai/zh/templates/game-design-document#gdd-production)

### 世界观、故事与角色

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_世界的规则、玩家亲历的故事，以及其中的人物。永远不会传达给玩家的设定资料，应该放在单独的文档里，从这里链接过去。_

#### 背景设定

_何时何地，用三句话说清，再加上这个世界中玩家在游玩时能切身感受到的那条规则。_

_示例（取自示例游戏 Saltmarrow）： 一座图书馆之城，曾想靠种盐熬过大海。它成功了：盐保住了书，却淹死了读书的人。潮水每天两次退去，让它重见天日。_

[你的背景设定]

#### 基调

_三个词，每个词配一款立下标杆的游戏、电影或书。然后写基调不是什么：这比写它是什么更能平息争论。_

- 基调：[...]
- 参考：[...]
- 绝不：[...]

#### 故事大纲

_按玩家经历的顺序，逐个节点写故事，而不是写前史。注明每个节点如何传达给玩家：过场动画、一句台词、一件找到的物品，还是关卡本身。_

| 节点 | 发生了什么 | 玩家如何得知 |
| --- | --- | --- |
| [开场] | [...] | [...] |
| [转折点] | [...] | [...] |
| [结局] | [...] | [...] |

#### 角色

| 角色 | 玩法中的定位 | 想要什么 | 一句代表性台词 |
| --- | --- | --- | --- |
| [名字] | [向导、商人、对手] | [...] | [...] |
| [名字] | [...] | [...] | [...] |

_一个角色的台词一旦超过几句，就给他单独写一份文档（人设、参考、台词样例），并从这张表链接过去。_

#### 写作规范

_每位文案都要遵守的约定：名称与写法、这个世界绝不使用的词、屏幕上放得下的最长台词。尽早写好，能为本地化团队省下好几周。_

- [规范]
- [规范]

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [游戏设计文档](https://nodary.ai/zh/templates/game-design-document#gdd-overview) · [关卡与内容](https://nodary.ai/zh/templates/game-design-document#gdd-levels) · [美术与音频指导](https://nodary.ai/zh/templates/game-design-document#gdd-art)

### 关卡与内容

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_玩家会去的每个地方，以及游戏需要的每一项内容和各自的数量。这份清单会变成制作待办，所以数量要实事求是。_

#### 地点与关卡

| 地点或关卡 | 在游戏中的作用 | 主要机制 | 时长 | 状态 |
| --- | --- | --- | --- | --- |
| [新手教学区] | [教会移动和核心循环] | [...] | [10 分钟] | [白盒、美术细化、完成] |
| [地点] | [...] | [...] | [...] | [...] |

#### 关卡设计规则

_在每个关卡都成立的规则：如何引导玩家，检查点之间隔多远，如何提示隐藏要素。在这里写一次，而不是在每个关卡里各写一遍。_

- [规则]
- [规则]

#### 最初一小时

_玩家最初一小时的逐步体验：做什么，学到什么，以及第一个会让他想讲给朋友听的时刻。大多数流失的玩家，都是在这里流失的。_

| 分钟 | 玩家做什么 | 学到什么 |
| --- | --- | --- |
| 0 至 5 | [...] | [...] |
| 5 至 15 | [...] | [...] |
| 15 至 60 | [...] | [...] |

#### 内容预算

_首发需要每类内容各多少，由谁制作。在任何人开工之前，先对照_[制作计划](https://nodary.ai/zh/templates/game-design-document#gdd-production)_核对一遍。_

| 内容 | 数量 | 制作者 | 备注 |
| --- | --- | --- | --- |
| [关卡或区域] | [...] | [...] | [...] |
| [角色与生物] | [...] | [...] | [...] |
| [物品] | [...] | [...] | [...] |
| [对话台词] | [...] | [...] | [...] |
| [音乐曲目] | [...] | [...] | [...] |

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [游戏玩法](https://nodary.ai/zh/templates/game-design-document#gdd-gameplay) · [世界观、故事与角色](https://nodary.ai/zh/templates/game-design-document#gdd-world) · [制作计划](https://nodary.ai/zh/templates/game-design-document#gdd-production)

### 美术与音频指导

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_游戏看起来、听起来是什么样，要写得足够精确，让两位各自工作的美术做出的东西放在一起也能统一。_

#### 视觉规则

_三到五条关于形状、色彩、光照和细节的规则。“风格化”不是规则；“每个剪影在三十米外都能辨认”才是。_

- [规则]
- [规则]
- [规则]

#### 参考

_在每条规则下加入参考图，并写明从每张图里取什么：配色、光照还是形状。绝不是“全部”。_

| 参考 | 借鉴什么 | 避免什么 |
| --- | --- | --- |
| [图片或游戏] | [...] | [...] |
| [图片或游戏] | [...] | [...] |

#### 调色板

| 用途 | 颜色 | 备注 |
| --- | --- | --- |
| [背景] | [#hex] | [...] |
| [危险] | [#hex] | [绝不作为提示危险的唯一方式] |

#### 资源类别

_每类资源的共同点、它的预算（面数、贴图尺寸、帧数）以及由谁审批。_

| 类别 | 风格说明 | 预算 | 审批人 |
| --- | --- | --- | --- |
| [角色] | [...] | [...] | [...] |
| [场景] | [...] | [...] | [...] |
| [道具] | [...] | [...] | [...] |
| [特效] | [...] | [...] | [...] |

#### 音频

_音乐、音效和配音的情绪，以及由声音传达的游戏信息：警告、奖励、时间的流逝。_

- 音乐：[...]
- 音效：[...]
- 配音：[语言与台词数量，或无]
- 由声音传达的信息：[...]

_示例（取自示例游戏 Saltmarrow）： 潮水转向前两分钟，号角声响彻盐滩。潮汐在屏幕上看得见，在混音里听得见，在手柄上也感受得到。_

#### 评审

_美术和音频由谁审批、何时审批。把反馈直接留在图上，钉在它所指的位置：能省掉一轮“哪一个？左边那个？”_

- 美术审批人：[...]
- 音频审批人：[...]

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [世界观、故事与角色](https://nodary.ai/zh/templates/game-design-document#gdd-world) · [界面与无障碍](https://nodary.ai/zh/templates/game-design-document#gdd-interface)

### 界面与无障碍

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_玩家阅读、按下和浏览的一切，以及游戏如何适应在视觉、听觉或行动上有差异的玩家。_

#### 界面与流程

_每个界面，以及玩家从启动到退出如何在它们之间切换。一张图能在开发之前就找出死胡同。_

```mermaid
flowchart LR
  n0["标题画面"]
  n1["主菜单"]
  n2["游戏中"]
  n3["设置"]
  n4["暂停"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1
```
_界面流程_

#### HUD

_游玩时一直留在屏幕上的内容，以及每个元素凭什么占有一席之地。玩家每分钟看不到一次的内容，都可以放进菜单。_

| 元素 | 显示内容 | 何时可见 | 优先级 |
| --- | --- | --- | --- |
| [生命值] | [...] | [始终、战斗中、按需] | [高、中、低] |
| [元素] | [...] | [...] | [...] |

#### 输入

| 操作 | 键盘与鼠标 | 手柄 | 触屏 |
| --- | --- | --- | --- |
| [移动] | [WASD] | [左摇杆] | [...] |
| [互动] | [E] | [A / 叉键] | [...] |
| [暂停] | [Esc] | [Start / Options] | [...] |

#### 无障碍

_逐项勾选，或写明为什么不适用。尽早决定，大多数成本很低；后期再加，代价很高。_

- [ ] 所有输入都可以重新映射
- [ ] 按住类操作可以改为切换
- [ ] 字幕会显示说话者，字号可以调整
- [ ] 重要的声音同时有视觉提示
- [ ] 任何信息都不只靠颜色传达
- [ ] 文字可以放大
- [ ] 计时器可以放慢或关闭
- [ ] 镜头晃动和闪光可以减弱

#### 文本与语言

_首发支持的语言，以及让翻译始终可行的规则：不把文字烘焙进图片，为比英文长三分之一的译文留出空间，字体覆盖所有发行语言的文字。_

- 首发语言：[...]
- 后续语言：[...]
- 字体：[...]

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [游戏玩法](https://nodary.ai/zh/templates/game-design-document#gdd-gameplay) · [美术与音频指导](https://nodary.ai/zh/templates/game-design-document#gdd-art) · [技术设计](https://nodary.ai/zh/templates/game-design-document#gdd-technical)

### 技术设计

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_影响设计的技术选择，以及设计必须遵守的限制。详细架构可以放在工程文档里，从这里链接过去。_

#### 引擎与工具

| 选项 | 决定 | 原因 |
| --- | --- | --- |
| 引擎 | [引擎及版本] | [...] |
| 编程语言 | [...] | [...] |
| 版本控制 | [...] | [...] |
| 构建与分发 | [...] | [...] |

#### 性能目标与预算

_每个部门都要据此开发的数字。没有它们，性能问题要到最后才会暴露。_

| 平台 | 帧率 | 分辨率 | 内存 | 加载时间 | 安装包大小 |
| --- | --- | --- | --- | --- | --- |
| [PC，最低配置] | [...] | [...] | [...] | [...] | [...] |
| [主机] | [...] | [...] | [...] | [...] | [...] |

#### 架构

_游戏代码的主要部分，以及它们之间如何通信。五个方框的图，胜过五页文字。_

```mermaid
flowchart TD
  n0["输入"]
  n1["游戏状态"]
  n2["渲染"]
  n3["音频"]
  n4["存档"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4
```
_主要系统_

#### 存档与联网

- 存档：[存什么、何时存、存在哪里]
- 联网：[无、点对点、专用服务器]
- 玩家数据：[收集什么，保存在哪里]

#### 管线

_一个资源或一行文本从作者手里到可玩版本要经过哪些环节，耗时多久。缓慢的管线会悄悄减少团队能做的迭代次数。_

[你的管线]

#### 技术风险

| 风险 | 影响 | 应对措施 | 负责人 |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [界面与无障碍](https://nodary.ai/zh/templates/game-design-document#gdd-interface) · [制作计划](https://nodary.ai/zh/templates/game-design-document#gdd-production)

### 制作计划

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_游戏何时上线，由谁制作，什么可能让它停下，以及一路上做出的每个决定。_

#### 里程碑

| 里程碑 | 日期 | 目标 | 完成标准 |
| --- | --- | --- | --- |
| [原型] | [...] | [核心循环好玩] | [...] |
| [垂直切片] | [...] | [一个关卡达到最终品质] | [...] |
| [Alpha] | [...] | [所有功能都已加入，粗糙也行] | [...] |
| [Beta] | [...] | [所有内容就位，只修 bug] | [...] |
| [发布] | [...] | [...] | [...] |

_“完成标准”是大家最容易跳过的一列。没有它，里程碑只是一个日期。_

#### 团队

| 职位 | 成员 | 负责的文档 |
| --- | --- | --- |
| [创意总监] | [姓名] | [游戏设计文档、游戏玩法] |
| [职位] | [姓名] | [...] |

#### 风险

| 风险 | 可能性 | 影响 | 应对措施 | 负责人 |
| --- | --- | --- | --- | --- |
| [...] | [低、中、高] | [低、中、高] | [...] | [...] |

#### 决策日志

_每个改变设计的决定：决定了什么，谁决定的，为什么，改了哪份文档。六个月后有人问“为什么是这样”时，这张表会给出答案。_

| 日期 | 决定 | 决策人 | 原因 | 修改的文档 |
| --- | --- | --- | --- | --- |
| [日期] | [...] | [...] | [...] | [...] |

_示例（取自示例游戏 Saltmarrow）： 9 月 12 日：取消战斗，威胁只来自潮汐和风暴。由创意总监和系统策划共同决定，为了让游戏保持平静，也为了守住工期。修改的文档：设计支柱。_

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [游戏设计文档](https://nodary.ai/zh/templates/game-design-document#gdd-overview) · [关卡与内容](https://nodary.ai/zh/templates/game-design-document#gdd-levels) · [技术设计](https://nodary.ai/zh/templates/game-design-document#gdd-technical)

## 使用方法

### 一口气写完总览

先和真正要做这款游戏的人一起，花一小时左右填好表格、提案和设计支柱。其余每一页都以它们为准绳。

### 边做决定边填写各部分

宁可让一节空着，也不要凭空编造。空着的一节是一个坦诚的未决问题；编出来的一节，最后会被真的做出来。

### 记录每一个决定

某个决定改变了设计时，在制作计划的决策日志里加一行，并更新受影响的那一页。日志记录原因，页面记录现状。

### 每一页都要有负责人

每个部分都写明负责人和上次审阅的日期。没人负责的页面，最先过时。

## 导入 Nodary，变成一张地图

Nodary 是为游戏团队打造的工作区，文档像地图上的星星一样相互关联。导入这个 .zip，总览会连同归在它下面的八个部分一起出现，页面之间的链接保持不变，图表也会画好。之后你的团队可以评论具体段落、请求审阅，并查看自上次查看以来改了什么；通过 MCP 连接的 AI 智能体会先读设计，再动笔写。

1. 打开一个项目的地图，点击“导入”。
2. 选择“文件夹或 ZIP”标签页，再点击“选择 ZIP 文件”。
3. 选中下载的文件，检查目录结构，然后导入。

免费版每个工作区可容纳十份文档，项目本身的页面也计算在内：模板的九份文档正好装进一个新工作区，并将它填满。付费方案容量更大。

## 写一份真正有人读的 GDD

游戏设计文档的失败只有两种：没人读，或者人人读的都是旧版本。下面这些习惯能同时避免这两种情况。

### 每个部分一页

一份六十页的文件，只会在项目开头被读一次。简短且相互链接的页面会在需要时被读到，一处改动只涉及一页，而不是五页。

### 写决定，不写愿望

“战斗要有爽快感”什么也没决定。“按下按键后 100 毫秒内完成命中判定”才可以实现，也可以测试。

### 写明哪些还没定

把没有答案的问题标为未决，写明由谁回答、何时之前回答。把猜测写成事实，两个部门最后就会做出两款不同的游戏。

### 链接，而不是复制

经济页面需要潮汐时间表时，就链接过去。同一个事实写在两处，很快就会变成两种说法。

### 保留原因

决策日志记录事情为什么是现在这样，免得新同事推翻团队已经付出代价才换来的选择。

### 删掉没人读的内容

如果一节内容写完后再没人打开过，就合并或删除它。一份简短而真实的文档，胜过一份曾经真实的长文档。

## 关于游戏设计文档的常见问题

### 什么是游戏设计文档？

游戏设计文档（GDD，中文团队也常称之为策划案）描述团队正在制作的游戏：提案、设计支柱、机制、系统、世界观、关卡、美术与声音，以及制作计划。策划、美术、程序、制作人，以及越来越多的 AI 智能体都要读它，所以它必须随着游戏的变化保持更新。

### 游戏设计文档应该包含哪些内容？

至少包括：一页总览，写明提案、设计支柱、受众和范围；游戏玩法与核心循环；各个系统及其数值；世界观与故事；关卡与内容；美术与音频指导；界面与无障碍；技术限制；以及附带决策日志的制作计划。本模板为每一项各准备了一份文档。

### GDD 应该写多长？

在能回答团队问题的前提下，越短越好。总览应该一屏放得下。每个部分随已经做出的决定增长，而不是随愿望增长：一页已经定下的规则，胜过十页的可能性。

### 独立团队和敏捷团队还需要 GDD 吗？

他们需要把决定写下来，而不是预先写好一本大而全的“设计圣经”。快速迭代的团队把 GDD 当作游戏当下状态的记录：页面简短，试玩改变了什么就随时更新，原因则留在决策日志里。

### 模板是什么格式？

Markdown：任何编辑器都能打开的纯文本文件。文档之间是相对链接，表格是 Markdown 表格，图表是 Mermaid，GitHub、Obsidian 和 Nodary 都能把它画出来。不依赖任何特定工具。

### 能在 Obsidian、GitHub 或其他编辑器里使用吗？

可以。Obsidian 会把解压后的文件夹作为库打开，所有链接都能用；GitHub 会显示文件及其中的链接和图表。逐个导入 Markdown 文件的工具会保留文字和表格；文件之间的链接如何处理，请先确认。

### 如何把模板导入 Nodary？

打开一个项目的地图，点击“导入”，再选择“文件夹或 ZIP”标签页，然后选中下载的 .zip。Nodary 会先显示目录结构，再创建九份文档，以总览作为它们的父文档，保留它们之间的链接并画出图表。任何不超过 200 个 Markdown 文件的文件夹或 .zip 都可以用同样的方式导入。

### 可以把模板用于商业游戏吗？

可以。无论是不是商业游戏、有没有 Nodary 账户，你都可以使用、修改和分享它。欢迎注明出处，但绝非必须。

本页地址: https://nodary.ai/zh/templates/game-design-document