本文系用户投稿，不代表机核网观点
⚠️ 未经作者授权 禁止转载
译文仅供参考，仅用于学习交流，请勿转载，谢谢！
作者： Leandro Gonzalez
原文标题 ： How to Write a Game Design Document
原文链接：点击跳转
译注： 本文写于2016年，距今也已有7年之久，一些观点可能跟不上如今的发展，请仅供参考。 翻译完成与2023.05.15，本来计划在赶在BOOOM暴造开始之前翻译完，但因为诸多原因进度缓慢……希望对大家有所帮助。
深入探讨之前我想先解释几个观点
深入探讨之前我想先解释几个观点
我第一次分享这篇文章的时候（几个月前的Reddit上），出现了很多非常有积极而热烈的讨论（因此我们都在游戏设计师这条路上共同进步）。
其中有几个比较重要的观点我想在这里解释一下，如果你能阅读全文，那么就更容易理解这些内容：
- GDD（Game Design Document）的使用已经是过去式。
- 撰写GDD时，需要直奔游戏机制。
之后我可能会写一篇完整的文章来讨论每个观点，不过现在：
译注： 作者在这里使用对应编号，对上述两个观点分开进行详细的解释说明。
1.——
跟其他行业相似，游戏行业也在不断发展，使用的技术在不久的将来就会被淘汰，更何况它还是一个仍在发展其流程、指标的新兴行业……所以不管想如何称呼游戏设计文档（GDD、Wiki、Board……），更重要的是在全力开发之前，一定拥有了能够描述游戏项目（或任何其他项目）的东西。
译注： Board：意为看板，可按自定义的顺序放置各种内容的卡片。常见于软件Trello，可用于项目管理等。
在Trick任职时我称其为GDD，不过我们还用看板（Trello）组织任务，尝试每两周设立一个项目里程碑。（有点像Scrum）
我们不使用随开发过程推进而修改的单一GDD，而是使用加快团队开发速度的文档。然后，在游戏设计阶段，按照团队的反馈和想法，做出修正。
一旦开始开发，我们就不再更新这份GDD。所有新想法都放在看板上，一些需要优先处理（权重1到3，1是一定做，2是可以做，3是还不错），另一些放在“想法”栏，留着之后评估。
总之，无论是想用GDD还是别的什么，我们一定会建议那些刚起步的游戏设计师们——把想法写进各式各样文档的时候，请，请，请让其他人能看、能懂。
2.——
我的回答是“视情况而定”，这会在本文中详细说明。如果你的游戏像《俄罗斯方块》（Teris）、《太空侵略者》（Space Invaders）或《爆破彗星》（Asteroids）一样......（译注：那你就可以在GDD直奔游戏机制来描述）换句话说，游戏中剧情如果不是特别的存在，那就对机制毫无影响，那你完全可以直接跳到第4章的模板。
刚才所举例的这个游戏，可以很自然地结合上下文描绘出角色、行为、动机（纽米（The Gnumies）可以转化成特定的游戏的机制，也可以衍生出游戏中交战的敌人——“细菌人”（German）“细菌先生”（The Germ））。
译注： Gnumies，结合后文，应该是Numismatic（与钱币相关的）与Gnome（侏儒）结合而成的词。
说到底，一切都取决于游戏和游戏设计风格。可以考虑设置一个介绍部分，简短地（一到两段话）描述整个机制。这样不管你是直接跳到游戏的完整介绍，还是转而先解释背景故事，都能让大家立刻理解游戏的类型和核心机制。
所以，我该如何围绕我想在游戏中做的内容撰写文档呢？
所以，我该如何围绕我想在游戏中做的内容撰写文档呢？
这是我每次有个能一夜暴富的绝妙想法时，脑子里蹦出来的第一个问题（开个玩笑，我还是很穷）。当时我甚至不知道我在做游戏设计，也不知道我需要写创建一份游戏设计文档（简称GDD）。
调查一番之后，我发现了这个术语，但似乎没有让我起步的一个行业标准或模板。
我找到很多游戏设计书籍（我非常推荐Jesse Schell的一本关于透镜的书），尽可能地在线阅读之后，觉得是时候创建我的第一份GDD了。经过多年的迭代，它已演化成接下来的这个模板。我们在Trick每次制作新游戏的时候都会使用。
本文是对这份GDD（你可以在这里下载到后缀名为doc的模板文件=>Trick's GDD Template）中每个章节的描述。
译注： Jesse Schell：《游戏设计艺术：一本关于透镜的书》（The Art of Game Design: A Book of Lenses）的作者。这本书确实非常推荐，即使不从事游戏行业，也可以从这本书中得到创意上的启发。 一本关于透镜的书：《游戏设计艺术》的副标题，本文作者都用副标题在称呼这本书。 透镜：《游戏设计艺术》中一种分析游戏、理解游戏的视角。书中有一百多个透镜（第一版有100个，第二版增加到了113个）。
GDD
GDD
项目说明
项目说明
总结游戏内容，不详述游戏机制，不漫谈其它细节。项目描述要能够让人明白你想做的游戏风格（大众，休闲，硬核等）和游戏类型（益智（Puzzle），角色扮演（RPG），第一人称射击（FPS）等）。当然，你可以增加任何与你游戏相关的内容。
这一章节最好只写1-2段，一定不能超过1页。
例：
这份游戏设计文档详细说明了一款跨平台触控的2D益智游戏，以及其独特机制、原创故事、原创角色。 该游戏类似其他三消游戏，但做出了一些创新。 名称暂未定论，候选有……
1. 角色（Characters）
1. 角色（Characters）
之所以从角色开始说明，是因为需要在剧情前介绍他们。假如你的游戏没有角色和/或剧情，可以直接跳到玩法章节并移去章节1-3（或留空）
角色说明的例子：
纽米（Gnumies）们是游戏中的主要角色。这些生物开心而富有，却毫不贪婪。他们之所以富有，是因为他们的祖先与金钱或钱币（Numismatic）有关，他们因此得名：纽米（Gnumies）。 红纽米（Red Gnumies）容易激动，有破坏冲动。黄纽米十分好动，常上蹿下跳。绿纽米儒雅随和，一颗平常心。蓝纽米常感悲伤，有躁郁倾向。 纽米们有很多只手臂，从1到4只不等，而且都长有手。他们抓握有力，可以靠牵手连接成一体。纽米们行为粗暴，总会把一切回归混乱。
你可以把角色设定图也放在这。
2. 剧情（Story）
2. 剧情（Story）
“讲故事艺术其中重要的一环，就是创造听者容易共情的角色。因为角色让听者共情的点越多，角色身上发生的故事也就显得越有趣。” ——Jesse Schell，一本关于透镜的书
在介绍完角色之后，是时候讲述事件是如何贯穿游戏始终了。
例：
纽米们在城堡中愉快地玩耍，互相恶作剧。管家常常头疼，不过大家还是其乐融融。乐子人造乐子。 细菌人正在家看电视，妈妈却来打扰他。于是他来到外面，窥视纽米们。外面下着雨，细菌人透过窗户露出羡慕的神情，全身却被淋湿。 一位陌生的神秘人给了他一把钥匙，可以用它打开后门。他带着军队闯入，绑架并监禁了纽米们中的的女性和孩子，并把其他纽米都驱逐出了这个岛屿。
译注： ……这个故事不知从何吐槽。
2.1. 主题（Theme）
2.1. 主题（Theme）
“共鸣主题能把你的作品升华为艺术。艺术家会引领你进入无法独自到达的领域，而主题就是让你前行的工具。” ——Jesse Schell，一本关于透镜的书
别人看你的设计时，主题很重要。一般来说，主题说明了你想要讲述什么样的故事：是喜剧，是现实生活，还是只是幻想…… :）
例：
这是一个有关悲伤与困境的游戏。游戏中会有激动、快乐的时刻，但每一章剧情都在以确定的基调来推进，即纽米们因失去了家园而悲伤。 游戏也必须存在幽默感，必须有趣。
如果你觉得这和你的游戏不相关，你可以跳过这一章。
3. 剧情流程（Story Progression）
3. 剧情流程（Story Progression）
所以，你有了剧情，但游戏该怎么把玩家带入剧情呢？
“游戏世界是独立存在的。你的游戏是通往这个神奇之地的大门，是独属于你的玩家们的天马行空。” ——Jesse Schell，一本关于透镜的书
例：
游戏开始于一个简单介绍场景，纽米们在这被驱逐出了家园。随后他们来到一座岛上，第一章开始。 第一章是教程，可以跳过。关卡比较少，管家会给玩家介绍游戏机制。 玩家通关教程时，就可以进入第一个世界森林世界。 玩家通关森林世界时，会得到一把钥匙，可以选择进入火山世界还是冰山世界。然后玩家通关这些世界时…… 最好不要让这个世界只能容纳一个剧情，而是能同时发生多线剧情。这会为续作、周边提供空间。
4. 玩法（Gameplay）
4. 玩法（Gameplay）
“游戏始于一个创意” ——Jesse Schell，一本关于透镜的书
这是（可能对99%的游戏来说）GDD中最重要的章节。在这里需要说明你的游戏玩法（没错，加粗了）会是什么样。
译者注： 原文是将Gameplay的G大写，表示非常重要。考虑到中文没有大写一说，所以加粗表示。
考虑到这章内容比较多，我们选择了一些我们觉得有意义的部分作为子章节。当然，我们选择的内容非常主观，效果可能因人而异。
4.1. 目标（Goals）
4.1. 目标（Goals）
很简单，玩家为什么要玩你的游戏？最好的办法就是把这部分内容单独列成一章，不然你还得通读整个GDD。
例：
总体（长期）：帮助纽米们重返家园 游戏玩法（短期）：打败敌人，提升等级，等等……
4.2. 玩家配置（User Skills）
4.2. 玩家配置（User Skills）
这一章不太直观，不过如果你需要考虑你的玩家应该掌握什么样的技能才能够游玩你的游戏，你可以聚焦于此。相信我们，列出这份表能帮你发现游戏设计中的问题。比如，你可能想开发一款面向儿童的游戏，但你意识到他们可能需要做出超出年龄认知的操作，有些操作可能适合手机但并不适合带摇杆的控制器。再者，如果你想为游戏自研硬件（Custom HW），列个表能搞清楚开发需要哪些功能。
例：
* 点按屏幕 * 拖放 * 记忆力 * 解谜 * 重组碎片 * 管理资源 * 制定策略
4.3. 游戏机制（Game Mechanics）
4.3. 游戏机制（Game Mechanics）
这才是你该说明游戏机制的地方。毋庸置疑，你的团队在传阅GDD的时候，应该保持对游戏玩法的合理质疑。这是非常重要的一个部分，可以插入原画、原型截图（我们倾向于在投入资源之前制作原型，以测试游戏玩法是否有趣）。
已经有完整的书籍、网站包含如何描述游戏机制的资料，我们就不再举例赘述。相关资源附在文章最后。
4.4. 道具、强化（Items and power-ups）
4.4. 道具、强化（Items and power-ups）
这一章用来阐述游戏机制。为了避免脑子里的想法塞爆了这一章，我们用上面那章描述核心机制，而这里可以讲讲用来提高趣味、强化玩家的游戏附加玩法。
所以，假如你的游戏是三消类，那在上一章准确描述三消的机制原理（并在公式中增加变量）。
而在这一章，把玩家可使用/获取/购买的每个强化、道具加进来，并介绍它们会如何影响核心玩法。
例：
每当通关一个世界，可以获得该世界相关的强化。比如，通关火山世界后，可以获得强化红纽米力量的道具。它可以是围巾或其它可穿戴的物品，而这些道具在之后的游戏都会看到。可以使用游戏货币升级道具，也可以氪金购买游戏货币礼包……
4.5. 流程、挑战（Progression and challenge）
4.5. 流程、挑战（Progression and challenge）
这也是非常主观的一章内容，可能因设计而异。我们想用这一章阐述游戏难度是如何随着游戏流程上升的，好保证玩家跟得上步伐。
例：
难度以增强敌人的方式提高。 为了降低难度，玩家需要提高游戏技艺、升级纽米、使用道具（也可以升级道具）。
对了，这里我们要说玩家怎么解锁新关卡或新任务。
例：
每个BOSS会掉落一把钥匙，颜色对应着当前世界。可以按任意顺序通关世界。通关所有世界、拥有所有钥匙之后，就可以冲击最终世界。玩家可以自由选择每个世界的通关顺序，世界的最终BOSS会掉落钥匙，可以解锁其他世界。这样一来，玩家必须在选择下一个世界之前，通关当前的世界，同时难度也将随之设定。
4.6. 失败（Losing）
4.6. 失败（Losing）
没错，失败！失败条件是什么？时间，生命，还是都有？在这里说明玩家怎么样才会看到“游戏失败”界面。
例：
失败条件：超时、超步数、无可用连接（译注：三消游戏背景）。 玩家失败时，需要展示纽米受伤/擦伤的图像。可以是掉了些毛发，露出了其下的皮肤。
5. 美术风格
5. 美术风格
这一章不用多说：介绍你的游戏想要展现什么模样。一图胜千言，快把概念图放在这吧。
例：
这是一个2D等距（isometric）游戏，使用高质量2D精灵（Sprites）。角色设计参考吉卜力工作室（Studio Ghibli）作品。 通过高度动画化的场景和分层背景，将世界表现得多彩、生动。
译注： 等距：指等距视角风格，也称等轴测图。该视角下，正方体的每边长度相同、对边平行，透视没有视平线、灭点，且摄像机方向固定。使用等距视角的游戏例有暗黑破坏神、纪念碑谷、陷阵之志等。 精灵：指游戏引擎中的可展示图片的一种游戏元素。（并不是一种生物）。
6. 音乐、音效（Music and Sounds）
6. 音乐、音效（Music and Sounds）
“音乐是灵魂的语言，正因如此它是在一个深层次对玩家倾诉。” ——Jesse Schell，一本关于透镜的书
在这里说明音乐和音效。如果你的游戏音乐音效很重要的话，你可以把这章再分成若干个子章节。
例：
音乐是复古风（Retro），最好是高质量的8bit怀旧风。 当玩家表现活跃时，奖励音效一定要给足，且拥有即时、积极的反馈。 时间不够的时候，需要制造紧张感的音效。 悲伤的场景应该配有手风琴或小提琴的音乐伴奏，听起来像是一曲悲伤的探戈。 至于游戏内的音乐，用轻松的旋律，欢快的曲调，并随着关卡推进提升节奏。山洞里的音乐则需要压低一些。
7. 技术说明（Technical Description）
7. 技术说明（Technical Description）
在这里说明你想运行的平台、将在开发中使用或考虑使用的开发工具。这并不该是一份详细的技术说明，你可能需要另起一份技术设计文档（Technical Design Document、TDD）。这里只涉及最表层的信息。
例：
最初，游戏将会是跨平台移动端： iOS 安卓（Android） Windows Phone后续会有PC独占和支持Facebook Canvas。 可能会增加Mac和/或控制器支持（通过e-stores） 考虑使用以下引擎：Marmalade，Unity 3D，虚幻4（Unreal Engine 4）。 用JIRA进行项目管理。用Perforce存储代码和资源。 待定于技术设计文档。
8. 市场、资金（Marketing & Funding）
8. 市场、资金（Marketing & Funding）
这是一个全部可选的章节，但现在你得写下你的想法，以免之后忘记。即使在正式开发之前，也要考虑如何推销你的游戏，还要想好开发游戏的资金从何获取，这很重要。
“计划是件现实的事。” ——Jesse Schell，一本关于透镜的书
例：
将第一关原型化，然后启动一个Kickstater（译注：一个众筹网站）项目展示这个关卡。 尝试达成出版协议。 有任何我们可以申请的政府资金吗？ 撰写新闻材料，发布到游戏新闻网站。 开启一个YouTube频道，上传开发日记视频。 等等……
8.1. 人口统计数据（Demographics）
8.1. 人口统计数据（Demographics）
了解你的目标用户群体是很重要的，应该贯穿游戏设计过程始终。如果你的目标是15到25岁的男性，那你的主角不该是一只粉红小马（并不是说这有什么问题）。
例：
年龄：12到50岁 性别：所有 休闲玩家为主
8.2. 发布平台、变现
8.2. 发布平台、变现
可以增加一些细节，关于每个平台上该如何发布。
例：
最初：安卓app，免费版内置广告，付费版无广告。 iOS，免费版内置广告，付费版无广告。 游戏内购。 待考虑：Windows 8，Windows Phone 8，XBOX live和Nintendo e-shop。
8.3. 本地化
8.3. 本地化
你支持的语言。加你想做的就好，前期优先级并不高。
例：
最初英语和西班牙语。 之后更新：意大利语、法语、德语等。 考虑与亚洲的发行商合作，发展到亚洲市场，需要帮忙做本地化的人员。
9. 其他创意
9. 其他创意
这也是一个全部可选的章节。如果你有些拿不定的创意，考虑要不要加入游戏，那就把他们都放在这当作备忘。
例：
* 关卡设计师 * 能够为其他用户创建的关卡评分 * 成就 * 排行榜 * 这游戏应该有多人模式吗？
“一般来说，制作一个多人在线游戏花费的时间精力和金钱是制作一个类似的单人游戏的4倍是比较合理的。” “有一个古老的经验法则，即在你有一个完全可行的版本后，需要六个月的时间来平衡你的游戏” ——Jesse Schell，一本关于透镜的书
结语
结语
我们希望其他游戏开发者能认为这个模版有用。欢迎来讨论这份文档该如何修改和改进。
欢迎与我们联系：play@trickgs.com。如果想跟进我们正在进行的工作，可以再Twitter或Facebook上关注我们。感谢！
这里有一些纽米，请收下！
模板链接：Trick's GDD Template
评论区
共 条评论热门最新