游戏设计文档模板

文件 游戏设计文档模板/游戏设计文档.md

游戏设计文档

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

速览

提案

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

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

[你的提案]

设计支柱

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

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

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

目标受众

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

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

对标游戏

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

范围

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

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

设计的其余部分

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

• 游戏玩法：核心循环、机制、操作与成长
• 系统与经济：每个系统、它的规则和数值
• 世界观、故事与角色：背景设定、故事以及其中的人物
• 关卡与内容：每个地点、最初一小时和内容预算
• 美术与音频指导：游戏的画面与声音
• 界面与无障碍：界面、HUD、输入与无障碍
• 技术设计：引擎、性能目标、架构与管线
• 制作计划：里程碑、团队、风险与决策日志

本模板可免费使用、修改和分享。它来自 Nodary，这些文件在那里可以导入为一张由相互关联的文档组成的地图。

文件 游戏设计文档模板/游戏设计文档/01 游戏玩法.md

游戏玩法

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

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

核心循环

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

flowchart LR
  n0["规划"]
  n1["探索"]
  n2["采集"]
  n3["制作"]
  n4["升级"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0

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

机制

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

操作

玩家的动词，以及每个动作应有的手感。各设备的按键映射见 界面与无障碍。

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

成长

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

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

挑战与失败

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

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

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

未决问题

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

相关文档： 游戏设计文档 · 系统与经济 · 关卡与内容

文件 游戏设计文档模板/游戏设计文档/02 系统与经济.md

系统与经济

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

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

系统

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

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

资源与货币

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

奖励与掉落率

掉落表、奖励概率以及保底规则（如有）。写明玩家应有的预期：半数玩家拿到某件物品需要尝试多少次，九成玩家又需要多少次。免费的掉落率计算器可以根据一张权重表算出这些数字。

调节参数

策划用来让游戏更简单、更快或更慷慨的少数几个数值，附当前值和已经测试过的范围。某个值改动时，在制作计划的决策日志里记下原因。

未决问题

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

相关文档： 游戏玩法 · 关卡与内容 · 制作计划

文件 游戏设计文档模板/游戏设计文档/03 世界观、故事与角色.md

世界观、故事与角色

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

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

背景设定

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

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

[你的背景设定]

基调

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

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

故事大纲

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

角色

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

写作规范

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

• [规范]
• [规范]

未决问题

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

相关文档： 游戏设计文档 · 关卡与内容 · 美术与音频指导

文件 游戏设计文档模板/游戏设计文档/04 关卡与内容.md

关卡与内容

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

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

地点与关卡

关卡设计规则

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

• [规则]
• [规则]

最初一小时

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

内容预算

首发需要每类内容各多少，由谁制作。在任何人开工之前，先对照制作计划核对一遍。

未决问题

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

相关文档： 游戏玩法 · 世界观、故事与角色 · 制作计划

文件 游戏设计文档模板/游戏设计文档/05 美术与音频指导.md

美术与音频指导

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

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

视觉规则

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

• [规则]
• [规则]
• [规则]

参考

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

调色板

资源类别

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

音频

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

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

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

评审

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

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

未决问题

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

相关文档： 世界观、故事与角色 · 界面与无障碍

文件 游戏设计文档模板/游戏设计文档/06 界面与无障碍.md

界面与无障碍

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

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

界面与流程

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

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

HUD

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

输入

无障碍

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

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

文本与语言

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

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

未决问题

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

相关文档： 游戏玩法 · 美术与音频指导 · 技术设计

文件 游戏设计文档模板/游戏设计文档/07 技术设计.md

技术设计

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

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

引擎与工具

性能目标与预算

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

架构

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

flowchart TD
  n0["输入"]
  n1["游戏状态"]
  n2["渲染"]
  n3["音频"]
  n4["存档"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4

存档与联网

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

管线

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

[你的管线]

技术风险

未决问题

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

相关文档： 界面与无障碍 · 制作计划

文件 游戏设计文档模板/游戏设计文档/08 制作计划.md

制作计划

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

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

里程碑

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

团队

风险

决策日志

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

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

未决问题

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

相关文档： 游戏设计文档 · 关卡与内容 · 技术设计