本文由 Paolo Gambardella 以意大利语撰写，由 AI 智能体翻译，可能含有不准确之处。
游戏设计师最核心的职责之一，就是撰写设计文档。任何人都能写文件，但设计师要做的是文档——这两者有本质区别。
文件里装的是想法、思路，随便什么都行。而文档是针对某个具体事物的特定类型文件：对竞品游戏的研究报告、一次游戏测试的结果、我们已经搭建并亲眼观察过的某个功能、回答了某个明确问题的原型。
要理解为什么这条规则总是被打破，不妨想想游戏开发过程中知识是如何积累的。
概念文件（Concept DOCUMENTS）
项目启动之初，几乎一切都是未知数。
- 已知条件（Constraints）：有些事我们已经清楚：目标平台、游戏类型，也许还有预算。
- 待解问题（Frontiers）：有些问题我们知道必须回答：核心循环怎么运转，一次典型游戏时长是多少。
- 未知的未知（Risks）：有些东西我们根本不知道自己还不知道。那些只有玩家拿起手柄才会暴露的设计问题。那些在纸面上看似显而易见、实际运行起来却一塌糊涂的系统交互。那些从未有人质疑过的假设，因为它们看起来太理所当然，根本不值得多想。
概念文件几乎完全活在第三个层面里。它不是文档，而是团队在某个特定时刻的想象力快照。
游戏设计文档（Game Design DOCUMENTATION）
真正的文档是在之后才浮现的。在我们搭建了原型、发现那个看似绝妙的机制根本没法按预想运作之后。在我们分析了其他游戏如何解决同一个问题之后。在我们测试并亲眼观察之后。到了那时，我们才真正有东西可以记录。
文件与文档
文件服务于临时目标。会议记录是文件，概念文档是文件，头脑风暴前随手列的想法清单也是文件。它们是有效的、必要的工作工具，有着自然的生命周期：现在用得上，之后就成了历史。
文档则是为了长期存在而设计的。
- 它必须清晰，让没参加那次会议的人也能看懂。
- 它必须实用，是能真正拿来用的参考，而不只是拿来读的。
- 它必须能激励那些六个月后翻开它的人——那时候最初的热情早已冷却，人们需要实实在在的抓手。
- 它还必须好看：不是为了美观而美观，而是因为如果没人打开一份文件，那份文件就等于不存在。我遵循这个公式：60%的篇幅留给视觉元素（图表、图片、视频……），30%留给数据和表格，10%才是文字。文档不是论文，不是让人从头读到尾的小说！
不是所有文件都是文档，项目过程中会需要各种各样的文件。但你的团队真正需要的，是文档。
真正的文档长什么样
一份好的设计文档要能够明确无误地回答几个问题：这是什么游戏？它有什么意思？它给玩家的幻想感、情感承诺是什么？核心功能有哪些——不是所有功能，只是那些定义产品身份的功能？这个系统到底是怎么运作的？以及足够的产品背景，让这份文档真正可以落地执行。
有一个原则我觉得特别有用：如果一个团队无法清晰简洁地说明自己的游戏，那这个设计很可能还不够清晰。文档的清晰度映照的是思维的清晰度。一份密密麻麻、塞满章节和子章节、试图覆盖所有可能情况的文件，往往恰恰说明我们还没掌握足够的东西来写文档。
这就把我们带回到第一条规则。如果你还没有具体的东西可以记录，也许现在还不是写文档的时候。现在该做的是研究，是搭原型，是测试，是回答那些你还不知道自己需要回答的问题，是学习，是探索。
这份东西记录的是已经存在的事物，还是我们想要构建的事物？