作者：Gamux

你是否曾经因为缺少计划而在游戏开发过程中不断地改变设计和玩法方向？你应该考虑使用游戏设计文件（即Game Design Document，以下简称GDD）。它是整体游戏的指导愿景，把游戏的设计、开发和商业等方面的想法和计划组织在一起。

引言

简单地说：我们都喜欢讲故事。有些人非常喜欢，有些人可能没那么喜欢。但关键是，我们都曾经花很长的时间构思故事，随着时间流逝，这些故事开始演变，变得越来越复杂，细节更加丰富，背景更加充实，剧情更加曲折。一个全新的世界就这样从无到有地在我们的头脑中成形了。

随着故事越来越复杂，构造故事世界的工具也越来越多。美术分离成若干不同的类型，音乐变得更精致，影片也进入这个世界了。技术增强带来信息共享，把艺术传播到全球。每天都在创造新的幻想世界。世界这么丰富多彩，使人们开始渴望成为它们的一部分。一个新概念就诞生了。

尽管电子游戏一开始只是关于争取最高分的娱乐活动，开发者很快就意识到游戏的无限潜力。玩电子游戏不只是简单地经历另一个故事。这是第一种在故事如何叙述自己上有发言权的媒体。玩家可以扮演角色，亲身体验旅程的艰难，探索特定的世界和精通那个世界的技能，经历主人公的胜利和失败。

游戏以前所未有的方式将玩家和故事联系起来。这种联系可以以多种方式建立，可以是故事发生的幻想世界，可以是特定角色的丰满个性。它迫使玩家努力去看到更多他们想要的东西。

不幸的是，因为游戏是由如此众多的不同元素组成的，它的制作又需要来自不同领域的不同专家的参与，使协调开发过程变成一件非常棘手的工作。为了顺利协调工作，开发者通常会使用一种叫作GDD的东西。

GDC是帮助组织游戏部件的工具。它记录游戏各个方面的总体想法，从图像设计到剧情线。总之它记录游戏概念，是对项目成品的预测和计划。

尽管编写GDD并不是制作过程的关键部分，却对开发团队有莫大的帮助，特别是当所开发的项目由大量人员参与时。另外，编写GDD的方法有很多种。事实上，不同的游戏开发公司的GDD是不同的，但一般来说，大部分游戏都是围绕这些文件展开制作的。

那么言归正传，以下是这个重要工具的几个你必须知道的要点。

概述

你所编写的游戏设计文件必须告诉阅读它的人，这款游戏是怎么样的。为此，你不仅必须解释游戏的机制，还有游戏的对象（游戏邦注：例如主角、敌人、谜题、武器、环境等）之间是如何互动的，你的游戏主题是什么，风格是什么。在GDD中，这些要点通常放在几个主要章节中阐述。

营销

营销是一个大章节，可以划分成几个章节。它主要解释游戏的商业方面，如目标受众、截止日期、竞争对手和卖点等。这个章节对商业有非常大的指导意义，因为它显示了你的游戏胜过对手的优势和如何满足消费者的需求。换句话说，它解释了你的游戏的吸引力。

高概念

在你开始告诉读者（阅读GDD的人）你的游戏如何运作以前，你必须阐明你的游戏的核心概念，即简明扼要地表述游戏的主要方面，这样读者就能预期到这份GDD要说什么以及需要注意的重点是什么。所以，GDD中有一个关于高概念的章节，这样读者不必阅读文件的所有方面就能对你的游戏有一个大致的了解。

例如：如果你告诉读者你的项目是一款未来派太空射击游戏，他就能想象到这款游戏中出现的武器、活动、敌人和其他东西应该是怎么样的。

玩法

这个章节是GDD中最重要的部分，因为它解释了如何控制游戏中的对象，如何使对象进行互动以及玩家如何执行活动等。另外，它还解释了游戏流程和各个游戏环节发生的事件。

第一分钟

这是玩法章节的一个子章节，它解释了玩家在游戏加载完后首先看到的内容。它解释了此时游戏和玩家之间的活动和反应，帮助理解游戏的进程和操作方法。这是一个重要的子章节，因为它决定了这款游戏是否有趣。

流程

这是一个比“第一分钟”更详尽的子章节。它描述了玩家在游戏时可以选择的所有选项。它是一种反映各个选项会产生的结果的流程图，显示了整个游戏的概貌。通常来说，这个流程图是由游戏截图组成的（例如，从“主菜单”到“选择关卡”），但你也可以把动作和结果放在里面（比如，如果玩家选择“法师”角色，所有背景都会变成与魔法有关）。如它的标题所示，这个子章节准确地解释了游戏的进展方法。

获胜条件

在这个子章节中，你必须告诉读者做什么怎么做才能在游戏中获胜、在什么情况下会失败。也就是说，这个子章节解释了游戏的目标。

玩家数量

指定该游戏可以由多少人一起玩是非常重要的，因为它决定了游戏的类型或游戏支持的模式——单人的还是多人的。例如：分屏、LAN连接、网络连接。注意：这个子章节对“获胜条件”有影响，因为在竞技型游戏和合作型游戏中的获胜条件是不同的。

美术

解释完如何玩你的游戏后，就可以阐释你的游戏的外观和美术风格了。这也是非常重要的章节，因为它决定了游戏世界中的元素的共存方式和影响玩家游戏的情绪。这还是游戏营销的一个关键点，因为这显示了游戏的外观和传递给玩家的感觉。

技术

GDD中必须包含的另一个章节是“技术”，因为它确定了游戏要求、运行平台、开发引擎等等。这影响营销，因为游戏所适用的硬件会影响玩家基础和目标受众——消费这款游戏的人。

有没有公式？

你必须记住，即使不同的GDD中存在若干相同的子章节，制作这种文件也不存在唯一的方法，不存在所谓的“完美公式”。每一位游戏设计师都有自己的编写方法，你必须寻找适合你自己的方法。这是很艰难的工作，但在本文中，我将提供一些解释如何编写GDD的各个子章节的技巧——然而，什么子章节是设计你的游戏所必需的，仍然取决于你自己。

你的文本必须总是保持清楚简明，最好配合大量插图，因为它们能让读者更快地想象到游戏的最终结果，并且有助于解释谜题（如果你的游戏中有的话）以及角色、环境、怪物、武器和其他物品之间是如何运作的。

此外，你还可以在你的GDD中加入一些能够帮助理解游戏的核心的新论题。应该注意的是，你的游戏的创新和细节。例哪，如果你的游戏项目具有全新的游戏方式，或特殊的图像概念或如果它以音乐为重点（像游戏音乐），你应该在GDD中讨论佗，以便让读者理解为什么这个创意是好的。

目录

GDD最好以“营销”章节为开头，因为它是你的投资商和客户最感兴趣的部分，这样就能让他们更快对你的游戏产生兴趣。在独立游戏的GDD中可能不会出现这个章节，因为独立游戏通常没有投资商，然而，如果你认为在其他不存在商业目的的项目如苹果的免费游戏，那么就必须记录与营销方面有关的计划，因为它对发行计划具有非常重要的意义。

此外，高概念很重要，这样读者才能马上理解游戏的核心和注意它的主要方面。你会发现，在GDD中，通常以游戏的基本和总结性的定义开头， 然后再逐步深入游戏的各方面的细节。

在下一章节中，应该解释游戏的“玩法”，它包含“第一分钟”、“流程”、“获胜条件”和“玩家数量”等。

这个章节后你必须显示你的游戏的外观，也就是讨论游戏的美术方面，尽量使用图片。最后，你可以讨论“特殊性”，即解释：创新、并非所有游戏都有的方面如情节、AI、角色和其他特殊的设定。

上述提到的所有东西都显示在下面的流程图中，这只是一个供你（应该）参考的一般架构。记住：没有完美的公式。现在，你已经有了GDD的骨骼，你可以在本文的“构成”这部分找到对GDD的章节的更详细的解释。

构成

尽管编写GDD的章节没有完美的公式，但必须包含几个重要的论题和避免一些主要错误。本节主要告诉你如何细化上文“概述”中所提到的章节和子章节，并且附上正确和错误的案例。

营销章节

这个章节没有什么统一的编写方法，因为你的目标取决于你的游戏。并且它也不是必须的，你可以把它结合到其他子章节中，也可以穿插在整个文件旧城 ，因为这个论题的某些方面与其他的大有关联。无论你选择如何阐释这个论题，以下几点是必不可少的：

目标受众

谁会玩你的游戏？这不是一个普通的章节，所以不要简单地描述成“针对儿童”之类的。“分类”游戏的方法非常多，你必须好好研究。解释它将如何吸引各类玩家，他们可能与你的产品没有太多共性，但总是有一些共性的。

正确：

《Turret Defense》针对年龄介于15-25岁、经常玩FPS和RTS PC游戏的男性玩家；本作的太空冒险背景和主题尤其吸引喜爱科幻主题的游戏、电影和小说的玩家。

根据ESRB（娱乐软件分级委员会）有关暴力的内容描述，本作被评为T级（青少年），仅适合年龄在13岁及以上的玩家。为了满足发行要求，《Turret Defense》将不使用血腥或任何超过ESRB对暴力的内容描述的内容。

错误：

《Turret Defense》将吸引大量玩家。根据类似游戏的经验，它应该会在电子游戏市场上大获成功。我们计划在流量大的游戏网站上为它做大量广告。

（“大量玩家”不是有效的描述，不能解释为什么他们会喜欢你的游戏。没有提到ERSB分级或该游戏是否包括年龄限制的内容。）

另一个优秀的案例：

《OrBlitz是》的预期ERSB分级是全年龄向。本作的主要目标市场是益智游戏的粉丝，但本作的许多原创内容将吸引更广大的玩家，包括喜爱动作游戏的玩家。RTS游戏的粉丝也可能对本作感兴趣，因为它的具有某些与RTS游戏类似的玩法。因为画面不含暴力元素，且界面直观，本游戏也能吸引女性玩家。本作画面可爱、色彩丰富，既能吸引美国玩家，也能唤起日本玩家的兴趣。

注意案例中提到的分类词：性别、年龄、国家和类型。记住，取决于你的游戏，可能还要提到更多分类。预测ERSB分级也是比较好的，这样开发者就会注意到某些与暴力、性和禁忌语有关的限制需要好好处理。

平台

非常简单的章节。只要列举出你的游戏针对的平台就行了。也可以在这个部分提及系统要求。如果有必要，你还可以解释移植游戏可能遇到的困难。

竞争对手

这是GDD中的重要子章节。这里，你必须把你的游戏与市场上已经存在的其他游戏作比较。必须简要地描述游戏的竞争对手，以及你的游戏与它们的相似点。通过详尽的比较，可以让读者更清楚地看到这款游戏的真实情况。

在最后，总结你的产品的优势，使读者相信你的产品能够战胜竞争对手。这是最棘手的部分，因为你必须挑对竞争对手，读者不可能在不知道你在说什么的情况下还对你的游戏保持乐观态度。所以，文笔是很重要的。你的“自吹自擂”也能劝说读者相信你的市场有多大。

进度表

在“进度表”章节，你必须定义开发游戏的每个必要环节，也就是完成你的游戏的环节的时间线。有了这个，不只是你，包括投资商，都可以对完成项目必须的时间有一个大致的估计。

其他子章节

你可能会添加一些重商业的论题如“成本”，包括设备成本、人力成本、附加成本和预期利润等。

未来计划

有时候，可以补充到游戏中的想法太多了，但开发进度紧张，所以只能把那些想法放在一边。这个章节就是用来记录那些未能实现的想法的，这样以后你就能根据进度决定是否执行。DLC、可能的续作、玩法上的微调、图像修改等等，都可以放在这里。你还可以收集一些可能用于补充游戏成品的想法。

例子：

添加一些支线任务

使角色能够执行跳跃动作

做一段讲述开发者故事的视频

简介章节

简介章节应该首先简单地介绍游戏的高概念，然后加上“摘要”，让读者对游戏本身有一个基本的了解。你还可以在“关键特征”中强调游戏的创新方面。

高概念

这个段落描述了你的游戏关于什么；应该写得摘要的摘要。避免谈及技术、图像或声音设计、复杂的玩法或不是非常必要的营销细节（比如，如果你做的是音乐游戏，你应该提到你使用的音乐风格；但如果你做的是益智游戏，就暂时没有必要提它的音乐；而最好描述一下谜题的类型）。关键就是，用最简洁的语句描述你的游戏，不要使用技术术语中。给你一个技巧，使用知名的游戏作为比较例子，比如“X是一款3D赛车游戏，与《马里奥赛车》类似”。

正确：

《Scavenger Hunt》是一款3D街机风格游戏，玩家的目标就是与对手竞争，看谁先收集齐任务列表上的道具。

错误：

《Scavenger Hunt》是一款3D街机游戏，背景是50年代的虚构街区，具有益智元素和卡通风格的图像和音乐，玩家的目标是和对手竞争，看谁先收集到各个阶段的任务列表上的道具。这款游戏在单人模式时，由电脑控制对手；在多人模式时对手为另一名人类玩家。

（尽量保持简洁）

摘要

这部分更加详细地描述你的游戏，限制没有高概念部分那么多。从玩法的核心方面开始，描述玩家的作用，目标、完成目标所需的行为、失败条件以及游戏的乐趣。

接着，简要介绍游戏的背景和历史（如果有的话）。最好使用图片而不是文字来说明游戏的外观如何，所以如果你没有草图或概念图，你应该贴一些风格类似的图片（比如其他游戏的截图）。

关键特征

最好用短句而不是很长的段落来组织这个章节（即小点列表）。在这部分，你应该告诉读者所有你认为会为游戏添彩的创意想法。

正确：

-简单而强大的物理学让一系列简单的规则产生惊人的结果。

-2.5D卡通风格的图像

-前所未见的绘图系统，当游戏加速到疯狂的程度时，游戏会变成色彩斑斓的世界。

-强大的陆地制作功能，允许你构建复杂的路径，如隧道和桥梁。

-丰富的游戏模式和场景，流畅的动作和反应。

错误：

本游戏有简单而强大的物理学，让一系列简单的规则产生惊人的结果，同时使用2.5D卡通风格图像和前所未有的绘图系统，当游戏加速到疯狂的程度时，游戏会变成色彩斑斓的世界；玩家可以使用其强大的陆地制作功能，构建复杂的路径；游戏有丰富的游戏模式和场景。

（一口气说了太多想法，让读者摸不着头脑）

第三方软件

简单地声明你开发游戏将使用的程序语言、库、软件以及图像与声音引擎等（游戏邦注：包括多人游戏需要的网络）。

如果你受到严格的软件/硬件限制，你应该在此说明（即如果你制作的游戏是针对苹果设备的，你必须声明你将使用iOS兼容的技术）。另外如果你的游戏是PC平台的，你应该声明最低配置要求。尽管在这个项目中不搞程序的人可能不理解什么是“NVIDIA Cg 1.2.1”，但至少应该让他们知道这么一个名称。

玩法章节

这个章节旨在描述游戏如何有效地运作、游戏的目标及其元素（菜单、获胜条件、敌人、道具、关卡……），和这些元素与玩家之间的交互作用。如果你觉得一个子章节“敌人”包含的内容太多，那么你可以把它单列成一个章节。

第一分钟

描述游戏加载后玩家的反应会是什么，这是很有趣的。比如可以描述玩家可以马上开始玩游戏，浏览菜单修改选项，通过尝错误或教程学习操作，一开始就能玩所有关卡还是需要解锁，等等。考虑到你之前已经准备好一些关卡，你可以简单地叙述一下玩家如何通关、在这个关卡中遇到的敌人和/或谜题。

正解：

标题页面后，玩家将看到一列他可加入的游戏和新建游戏的选项。选择新建游戏后，一列预设关卡将出现在屏幕的右边。（……）修改好设置后，当有三名其他玩家加入游戏，游戏就可以开始了。计时器从5秒开始倒计，这是玩家的准备时间。游戏开始后，玩家使用少量的金钱布置方块。随着轻快的背景音乐，游戏面板绕着屏幕中心旋转，逐渐展开关卡的布局。（……）玩家的目标就在游戏面板的各角。（……）计时到0时，屏幕中间出现“GO！”命令，魔法球从云中落下，沿途造成严重破坏。（……）玩家要迅速地把方块放在面析的边缘，这样魔法球就会从边缘弹开，玩家完成目标时半听到熟悉的点镖机的声音。玩家的得分和金钱变成200，他现在可以进入下一关（……）。

错误：

这款游戏一开始，玩家在相反的角落面对面。玩家1使用游戏开头赠送的钱，和布置石块挣得分，来获得。

（缺少细节）

流程

对“第一分钟”的完美补充莫过于“游戏流程”，它通常用流程图表示。与之前的子章节相反，这个部分不强调第一印象，而是显示玩家从游戏加载完毕到按下“退出键”（结束游戏回合）的过程中可以执行的活动，让读者对整个游戏的进程有一个总体认识。

正确：

错误：

（太简单了，至少应该包括玩家看到的所有页面）

获胜条件

在此声明玩家通关、获胜应该满足什么条件。比如，如果你的游戏是拼图游戏，那么玩家必须把所有拼图块以正确的方式组合起来才能进入下一关；如果你的游戏是横版射击游戏，玩家必须击败最后的BOSS才能通关……显然，这完全取决于你所设计的游戏类型。

案例：

在《太空侵略者》中，玩家扫清当前所有敌人后，游戏就会刷出新一波敌人。因为敌人是无限刷出的，所以直到玩家耗尽命值，游戏才会结束。

图像

事实上你无法向读者提供任何你还没做出来的游戏的截图，所以在这个部分，你只要描述你计划使用的图像引擎，可能再附加几张游戏的草图或你想使用的风格的原画。提前设计游戏的HUD会帮你节省大量时间。

HUD

HUD是指玩家在游戏过程中使用的内置界面。与游戏菜单如设置或目录面板不同，这是特指通常不游戏本身互动而只具有提供信息作用的浮动窗口和数值条，比如命值条、小地图、计时器、装备栏、钱袋等。尽管HUD的大小因游戏类型而异（MMORPG和RTS通常有很大的HUD，而横版游戏和益智游戏的HUD通常很小），记住，HUD不应该占据屏幕太多空间。

案例：

声音

另一方面，你也无法描述声音，所以你只要声明你将使用的声音引擎和（也许）歌曲风格。尽管对于大部分游戏，你只要简单地声明不同场景将有不同的背景音乐，但毫无疑问，这个部分对音乐游戏来说是最重要的。

操作

用文字介绍按钮/键盘的对应功能，可能有一点麻烦，特别是当按键对应的功能不止一个时（比如《塞尔达传说》的“A”键）。用简单的控制器或键盘图示来解释各个按键的功能更合理。此外，如果你的游戏有高级的连击或类似的东西，你要详细地解释它们，声明在什么情况下会“激活”什么操作组合。

案例：

游戏特定的子章节

拼图游戏可能有“拼图块”章节，横版游戏可能有“关卡设计”章节，太空射击也许有“敌人”章节等等。正如标题所暗示的，每一种游戏都有它们自己的特定的子章节，因为我们列举一个GDD可能有的所有子章节，所以下面我只举三个例子。

拼图块

假设你的游戏是拼图游戏，玩家的目标是通过把相同的图像拼成一行，以获得积分。最好能在这个部分展示不同类型的拼图块的草图，以及解释它们的旋转方式、分值和布局。如果能配合图片就太好了！

案例：

关卡设计

假设我们的游戏是2D平台游戏。这款游戏的核心元素之一是玩家必经的台面。必须让各个台面显得独一无二，否则玩家就会觉得自己只是在重复玩某个关卡。另一方面，玩家应该仍然熟悉流程，即如果关卡中间总有一个保存点或可收集道具，那么其他关卡也应该如此。

不同类型的敌人、地形、道具等是怎么样的？关卡设计师是否可以根据它们设计出不同的台面？你可以展示一些测试版台面的图解。

案例：

敌人

太空射击游戏往往有许多不同类型的敌人，每一种都有不同的进攻招式、移动模式、命值、速度和攻击范围。因此，你当然需要再写一个章节专门介绍游戏中的敌人和它们的属性。另外，你可以陈述一些他们的模糊行为，比如当它们命值过低时会发射额外的光波。

案例：

情节

许多游戏都发幻想世界为背景，各有自己的地理、历史和角色，玩家可以扮演的主角当然很多。如果你的游戏有特别有趣的背景，那么最好能加入游戏的故事板，描述主角在冒险过程中遇到的主要事件和传说。

角色

玩家在游戏中通常不会只遇到敌人。可能有主角和同伴来帮助他打败敌人。例如，甚至在无玩家控制角色的塔防游戏中，在开头部分仍然可能有像向导NPC这样的辅助角色来指点你如何克服某个挑战。如果你的游戏确实有玩家操作的角色，那么他是怎么样的？他是否有什么技能和专长？记住，不要把这部分写得像“怎么玩”。

AI

所有游戏都需要一个恒定的世界来处理所有的玩家行为和其他活动。这包括敌人移动、玩家操作、碰撞、计时、随机数生成和许多其他东西。尽管没学过程序的人也许不能完全理解这个章节，但他们至少应该知道基本知识。最重要的是，不要在这里出现代码，简单地描述敌人的移动模式、拼图块下落的算法，用流程图来解释战斗系统。

案例：

面板上的角色通过简单的寻径/集群算法来躲避魔法球。每一个关卡会使用三个不同的脚本文件来向动画化的角色发布指令。（……）玩家角色将用于模拟真实的玩家。由AI系统将决定的是：

-是否放新方块？如果是：

-在哪里放新方块？

-这个方块是什么类型/材料？

技术章节

组成一系列游戏数据技术，如系统要求、开发工具、算法以、屏幕上可出现的元素的最大数目。图像技术方面包括软件、建模类型、美术风格和其他与此有关的东西。

所谓的系统要求是指电脑运行游戏必须达到的配置，如游戏占用的硬盘空间、需要多少RAM。

另一个重要的技术方面是，不要忘记ESRB评级，之前已经解释过了。评级例子如下所示：

要不要包含？什么时候？为什么？

负责推广该游戏的公司或将使用该技术开发游戏的人会对技术方面感兴趣，所以当你把这个GDD拿给审查这款游戏的人时，总是保证介绍它的技术方面。你可能会写出一些错误的论题，比如，把平台和推广游戏模式放在营销章节中，而不是技术部分。

更多案例

至于提供专业的GDD的网站，我推荐Shred Nebula、Play With Fire、Grim Fandango Puzzle Document等，当然在gamepitches.com上也有许多。

如果想进一步学习GDD的结构和组成，可以看Gamasutra上的文章《 The Anatomy of a Design Document》的第一和第二部分、《Creating a Great Design Document》和《How to write an effective Design Document》（它与游戏开发无关，但关于软件开发）。

《Game Design: The Two C’s of Video Game Design》也值得一看。

另外，游戏圈对如何编写游戏设计文件有不同的观点。虽然看似与本文所说的有矛盾，但这是因为分析的案例不同，而且还要考虑到团队规模、预算和截止日期。

总结

对于需要投资商批准的设计师，你必须首先吸引他的注意力，为此，你的文件必须做到：

高概念：你永远没有机会给别人留下第二个第一印象。你已经知道怎么写这个章节了，现在只要记住，首先写好这个部分，点出所有你认为可以让游戏更吸引人的东西。

图片：不要以这读者会老老实实地把整个GDD看完，更别说有些文件还超过一千页（真的有这种事！）。但读者肯定会好好地看吸引他眼球的东西，所以还有什么比图片更有效的？毕竟，图片胜过千言万语。

不用说，你的文件必须有好的外观。花点时间把文本排列成方便阅读的格式。另外，不要忘记本文只是告诉你一般的GDD的结构是怎么样的，你必须根据自己的游戏做修改！（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Effectively Organize Your Game’s Development With a Game Design Document

By Gamux

Have you ever dived right in to developing a game, but found yourself having to constantly change aspects of the design or the gameplay due to a lack of planning? You should consider using a game design document: a guiding vision of the game as a whole, pulling together ideas and plans for the design, development, and business sides of your game.
Introduction

To put it simply: we like to tell stories. Some true, some not so much. But the point is that we have been crafting tales for a very long time, and as time went by these tales began to evolve, becoming more complex, with richer details, with more and more fantastic backgrounds and appealing plots. Whole new worlds were born from thin air, hammered into shape in the anvils of the human brain.

And as the stories grew in complexity, so did the tools used in their making. Art diverged into several different categories, music became more elaborated and movies found their way into the world. Technological enhancements allowed sharing of information, spreading art all around the globe. New fantasy worlds were created each day. Worlds so rich made people began to desire becoming a part of them. A new concept was being brought to life.

Although video games were first just about getting the highest score possible when faced with a determined task, developers soon realized the endless possibilities laying ahead of them. Playing a video game is more than simply sitting through another story. For the first time one could have a say in how the tale told itself. Players could take hold of characters and live the hardships of the journey themselves, diving into that particular world and mastering it, making theirs the protagonist’s conquests and failures.

A game has the potential to bond player and story in a way never seen before. This connection can be established in a variety of ways. Be it the fantastic landscapes in which the story unravels, the soundtracks or the well-constructed personality of a particular character. It forces the player to thrive in order to see more of what he wants.

Unfortunately, since a game is composed of so many different elements, different experts from different areas are required in its creation, making the coordination of the development process a rather tricky job. In order to help developers do their job, a document known as a GDD, or Game Design Document, is often employed.

A GDD is a tool that helps merging the components of a game together. It registers the general ideas of every aspect of it, from graphics design to story line. In short it registers the game concept, creating the closer feeling of the finished product.

Although the writing of a GDD is not a vital part of the creation process, it is of major help to the team of developers, especially when in major projects, involving large amounts of personnel. Also, there is not only one way of writing a GDD. In fact, GDDs differ vastly among game development companies, but as a general rule, most games are built around these documents.

So without further ado, here is what you need to know about this important tool.

Overview

A Game Design Document must teach everyone who reads it how the game that you’re talking about works. In order to do this, you need to explain not just the mechanics, but also how the game’s objects (characters, enemies, puzzles, weapons, environment, and so on) interact with each other, what your game is about, and how it looks. In a GDD, these points are discussed in some general sections.

Marketing

Marketing is a big section subdivided in many subsections that explain the major commercial aspects of the game, like public target, deadlines, competitors and selling points. This section is very helpful for business, since it shows what your game has in advantage over others and how it meets the consumer demand. In others words, it shows the game’s appeal.

High Concept

Before you start to tell the reader how your game works, you must clarify the core concept of your game, i.e., you must talk about the major aspects of your game in a very short way, so that the reader can anticipate what will be said in the GDD and pay attention to what is important to the game. For this, there is the High Concept section, which explains all of it, so that the reader won’t have to read many pages of the document just to know what your game is about.

For example: if you tell the reader that your project is a futuristic space shooter game, he will be able to imagine what kind of weapons, movements, enemies and others things will be used in the game.

Gameplay

This section is one of the most important in the GDD, because it explains how to control the objects in the game and how to make them interact with the other parts. Also, it explains how the player will execute the possible moves. Moreover, it’s interesting to comment the way that the game flows and what happens during the course of the game.

First Minutes

This is a subsection of the Gameplay section, and it exposes what the player will see in the game when it has just finished loading. It exposes the actions and reactions between the game and the players during this interval, helping understand the game’s progress throughout the gameplay and give a better idea of how to play it. It’s also an important subsection, since it will determine whether or not the game is fun.

Gameflow

This is a more detailed subsection of the Gameplay than the First Minutes. It describes all the options that the player can choose while he is playing. It’s a kind of flowchart that shows which reaction each option has, giving a picture of the game as a whole. Generally it shows a flow of screens (e.g. from the “Main menu” screen it goes to the “Select level” screen), but you can also put actions and consequences in it (e.g. if the player chooses the “Mage” character, all the backgrounds will have a “magical” feeling). It literally explains the way that the game flows, as the name suggests.

Victory Conditions

You also need to teach the reader in the Victory Conditions subsection, what must be done to win, when the player loses and under which conditions this happens. In other words, this section explains the goals of the game.

Number of Players

It’s important to specify how many people can play, because this implies the type of multiplayer – where applicable – that the game will support; for example: split-screen, LAN connections, Internet connections. Note: this section has influence over the Victory Conditions, since the players will need to do different things to win in a competition than in a cooperative game.

Art

Once you explained how to play your game, it’s import to show how your game will look like and which kind of art is behind it, since it’ll influence how the elements of your game’s universe will coexist, mixing the emotions of who is playing. This is a crucial point in the game’s marketing, because it shows the appearance of the game and the feelings it will pass to the player.

Technical Aspects

Another section that must be put in a GDD is the Technical aspects, since it defines the physical game requirements needed to play and specifies on which platforms the game will be developed, which engines will be used, and more. This affects the Marketing, as the kind of hardware used affects both the fanbase and the public target, i.e., the people who consume the game.

Is There a Formula?

All things said, you need to keep in mind that even if some general subsections are common between the GDDs, there is no static form to make this kind of document, and no such thing as a perfect formula. Every game designer has his own way to do this and you must discover yours. This is a hard job, but in this article we’ll give some tips explaining how to create each subsection of the GDD – however, it’s up to you to decide which of them are necessary to design your game.

Always be clear and concise in your text and use a lot of images, because they give the reader a faster and more real view about the game’s final result and they also ease the explanation about puzzles (if your game has them) and how characters, environment, monsters, screens, weapons and other objects from the game will work.

Moreover, you can also find new topics to add in your GDD, as long as it’s necessary to the understanding of the game’s core. Some things that deserve attention are the innovations and the particularities of your game. For example, if your game project brings up a new way of playing, or a specific graphic concept or if it’s focused in music (like a music game), you should discuss it in the document, to convince everyone why this innovation is a good idea.

Guidelines

A good way to start your Game Design Document is with the Marketing section, because it will be the section that your investor or client is interested in, thus allowing them to gain interest in your game faster. In indie game development, it is not a common section due to the common lack of investors, however, if you think in other projects not related to commercial purposes, such as a free game on App Store of Apple to help a charity institution, it’s important to keep track of plans related to the marketing aspect, since it will be really important to have a publishing plan.

After this, it’s important to put the High Concept, so the reader immediately will understand the core of the game and pay attention in the major aspects. You will figure out that in GDDs it’s common to always start with a basic and summarized definition of the game, and go on to present every detail step-by-step.

In the next section you should write about the Gameplay, which should include, as sub-sections, the First Minutes, the Game Flow, the Victory Conditions and Number of Players.

After that, you need to show how your game will look, so talk about the Art, using as many images as you can. In the end, you can talk about the Specific Sections, which should bring topics that explain: the innovations, the aspects that not necessarily all games have, like story, artificial intelligence, characters and others particulars things.

All the things said above are represented in the flowchart bellow, but it’s just a general schema and you can (and should) adapt to your game. Remember: there isn’t a perfect formula. Now that you have a kind of skeleton of the GDD, you will find in the Composition topic of this tutorial a more detailed explanation about what which section of a GDD holds.

Composition

Although there isn’t such a thing as a perfect formula for composing your GDD sections, it’s important for you to include some crucial topics in it, as well as avoid some major mistakes. This section teaches you how to detail the sections presented in the Overview topic, while showing examples of how it’s done and some common mistakes.

The Marketing Section

There is no correct way of dealing with this subject, since your objectives for it will depend on your game. It’s also not really needed; you can either concatenate it all in a major subsection or spread it across the document, as some of the topics discussed here have much in common with others elsewhere. Despite the way you choose to do it, some topics should always be addressed:

Target Audience

Who will play it? This is no ordinary section, so don’t settle for a simple “for children” description, for example. There are endless ways to “classify” gamers, and you must explore this. Comment on how it will appeal to each category and try not to leave anyone out; they might share little in common with your product, but they still share something.

Right:

Turret Defense will appeal to male gamers of ages 15 – 25 who typically play FPS and RTS PC titles. In particular, fans of Sci-Fi themed games, movies, and books will be immediately attracted to Turret Defense’s space adventure setting and theme.

Turret Defense will have an ESRB rating of T (Teen) for ESRB Content Descriptor of Violence, suitable for ages 13 or older. To conform to the wishes of the publisher, Turret Defense will not use blood or any other content that would lead to further ESRB Content Descriptors related to violence.

Wrong:

Turret Defense will appeal to a large audience. Based on the experience of similar games, it should be a huge financial success in the video games market. We plan to advertise it heavily with ads on games-related websites with huge traffic.

(“A large audience” isn’t a valid fanbase, and it doesn’t explain why they would enjoy it. No mention of the ERSB rating or whether the game has any age-restricted material.)

Another good example:

OrBlitz is expected to receive an ESRB rating of Everyone. The main target market will be puzzle games fans, but the game’s many original aspects will attract a wider audience, including people that prefer to buy action-based games. Real time strategy games fans could also be interested in the game for its tweakability and other similarities with RTS games. Because of the lack of graphic violence and the intuitive interfaces, this game can target women as well as men. The game is relatively cute and colorful, and is expected to appeal to both American and Japanese audiences due to the content in it.

Notice all the classifications in the example: gender, age, nationality and genre. Keep in mind that many more categories may arise depending on your game. Predictions on the ESRB rating are also welcomed, therefore some restrictions regarding violence, sexual content and language should be addressed if needed.

Platform

Extremely straight-forward section. Just enumerate the platforms that your game is being designed for. An estimate of the system requirements are also a good call. If needed, you can comment on porting the game and the difficulties involved.

Competitors

This is a key subsection of your document. In here you must compare your game to others already developed. It is important to give a small description of the game being compared to, and point the similarities between both. This is an excellent opportunity to expand the comparisons that were already made across the GDD and give the reader a better picture of what the game will actually be.

At the end summarise your product’s strong points and convince the reader why would your product sell despite its competitors. This is the trickiest part, because you must pick good opponents, otherwise the reader just won’t know what you are talking about, and still keep your game’s image shining; therefore a good writing is crucial. Your ‘adversaries’ also help on the notion of how big your market can be.

Milestone Schedule

The Milestone Schedule subsection is where you must define each necessary steps in order to develop the game, which is basically a timeline of the intended completion of phases of your game. Through that, not only you, but also the investors, can have a very rough estimate of the interval of time needed to complete the project.

Other Subsections

You may choose to add some heavy market-related topics such as Costs Overview, that can comprehend equipment costs, people costs, additional costs and expected profit.

Future Plans

Sometimes there are so many ideas to complement a game that some of it must be put aside in order to meet the tight schedule of development. This section is specifically made to store those ideas, so that you can work on it later depending on how things work out. DLCs, possible sequels, minor improvements to gameplay, graphics and so on, all comes in here. You can also gather some ideas of what to do with the game once it is finished.

Example:

Add some side quests.

Enable the character to jump.

Make a movie telling your story as a developer.

The Introduction Section

The introduction section should provide the reader with a basic overview of the game itself, first with a light approach with the High Concept subsection and then with a broader one within the Summary subsection. You can also highlight the more innovative aspects of your game in a Key Features subsection.

High Concept

A one paragraph description of what your game is about. This should sound like the summary of a summary. Avoid any technical aspects, graphic or sound designs, complex gameplay features, or marketing details that aren’t strictly required (for example, if you’re making a rhythm game you should mention what kind of music style you will be using, whereas if your game is a puzzle you can just forget about music for now; it’s better to describe what type of puzzle the player will have to solve instead). The idea is to describe your game in the most non-technical and shortest way. A good tip is to use well-known games as examples for comparison, such as “X is a three-dimensional racing game with power-ups like Mario Kart”.

Right:

Scavenger Hunt is a three-dimensional arcade-style game where players race to collect items from a list before their opponents do.

Wrong:

Scavenger Hunt is a three-dimensional arcade game with puzzle elements set in a fictional neighborhood in the 50′s with cartoony graphics and music, where the player races to collect various home-related items from a given list in each stage, while using gags as powerups, before his opponents, which can be either CPU-controlled when in singleplayer mode or human-controlled players in multiplayer mode.

(Keep it short and simple)

Summary Overview

A more detailed description of your game, with less restrictions than the High Concept subsection. Start with the core aspects of the gameplay, describing what role the player will take, what’s his goal, what he will have to do in order to accomplish it, what will hold him back and why the game will be entertaining.

Next, do a quick introduction to the game’s setting and a brief description of the history (if any). It’s always nice to use an image instead of describing what the graphics will look like, so if you don’t have any sketches or conceptual art you should just paste pictures with similar art to what you will be using (that includes screenshots of other games as well!).

Key Features

The best way to compose this is using short topics (i.e. bullet lists) instead of long paragraphs. Basically you should tell the reader right away about all of the creative ideas you had which you thought would make your game a great game.

Right:

- Simple yet powerful physics that provides surprising results from a set of simple rules.

- Amazing Hatched and Cel-Shaded graphics.

- Never seen before paint system where color spreads out to the world as the gameplay picks up speed to a frantic pace.

- Powerful land crafting abilities that allow you to build complex paths the orbs can take, like tunnels and bridges.

- Various game modes and scenarios to choose from, each of which feels like a totally different game, favoring action or reflection.

Wrong:

The game will have simple yet powerful physics that provides surprising results from a set of simple rules, while using amazing Hatched and Cel-Shaded graphics and a never seen before paint system where color spreads out to the world as the gameplay picks up speed to a frantic pace, when players build complex paths by using powerful land crafting abilities which the orbs can take, in various game modes and scenarios.

(Too many ideas at once makes the reader lose the train of thought.)

Third-Party Software Used

A little explanation of the programming languages, libraries and software you will be using to create your game, as well as the programs you will use to adjust your graphics and sound engines and any other engines your game may need (like a networking one for multiplayer games).

If you’re under some heavy software/hardware restrictions, you should specify that in here (i.e. if you’re making a game for Apple devices, you have to tell you’ll be using iOS-compatible technology). Also if your game is aimed at PCs and you have an idea what the minimum requirements will be you should note them here. Although the non-programming people of the project probably won’t understand what the heck a “NVIDIA Cg 1.2.1” is, they’ll have to know it by name since that’s what the game will run on.

The Gameplay Section

This section is designed to describe how the game will effectively work, describing the game’s objective as well as its elements (menus, victory conditions, enemies, powerups, stages, …), and the interaction between each one of these elements with the player. If you feel like one subsection, such as “Enemies”, has too much content to be just a subsection you may promote it to a section of its own.

First Minute

It’s interesting for you to describe what the player’s reaction is going to be like as soon as the game loads, such as describing whether he can start playing right away or if he can navigate through menus to change some options beforehand, whether the player will have to learn the controls by trial and error or a tutorial will be presented to him, whether all stages will be available at the get-go or if he will have to unlock them in progression, and so on. Given you have already planned some stages ahead, you could narrate a short run of the player clearing a stage, describing the enemies and/or puzzles he had to go through in said stage.

Right:

After the title screen the player is presented with a list of games he can join and an option to create a new one. After selecting the option to create a new game a list of predefined levels appears on the right of the screen. (…) After the settings are adjusted three other players join and the game begins. A timer counts down from five while the players get ready, using the small amount of money they start with to place a few blocks. As a simple beat plays in the background, the board rotates around the middle of the screen, revealing the layout of the level. (…) The player’s goals are on each corner of the board. (…) As soon as the count down reaches zero, ‘Go!’ is displayed in the middle of the screen and the orbs start falling from the cloud, creating havoc on their path. (…) The player quickly places a stone corner block on the edge of the level and the orb bounces off it, only to end up in the player’s goal followed by a familiar cashier sound. The player’s score and cash are updated to 200, and he starts going through the blocks he can now place (…).

Wrong:

The game begins with the players facing each other in opposite corners. Player 1 decides to use all his money from the get-go and wins the game by using well-placed stone blocks to earn points.

(Although being essentially how the game will run, it needs more details.)

Gameflow

A nice complement to the “First minute” would be the “Game Flow”, which is usually represented as a flowchart. In contrast to the previous subsection, this one won’t focus on the first impression but rather give an overview of the whole picture, showing step-by-step which actions the player can take from the moment the game is loaded to when the player hits the “exit button” – i.e., ends his gaming session – including the gameplay itself in a somewhat high concept.

Right:

Wrong:

(Nothing THIS simple. Include, at least, all the screens that the player will run through!)

Victory Conditions

Here you state what is required for the player to clear a stage, win a match, or advance another level, whether your game is a puzzle, where the player advances to the next level when all pieces are combined in a certain way, or a sidescrolling shooter where the player advances a stage when he defeats the boss at the end, or whatever. Obviously, this depends entirely on what kind of game you’re designing.

Example:

In Space Invaders, the player advances to a new wave each time he destroys all enemies from the current wave. Since the waves are endless, the game will keep going until the player runs out of lives.

Graphics

You can’t really provide the reader with screenshots or video footage of something you may haven’t even designed yet, so in this subsection you should simply describe how do you plan to handle your graphical engine and maybe show some sketches of your game or a few drawings in the art style you intend to use. Planning the game HUD from the beginning will save you a lot of time later on, for example.

HUDs

The head-up-display is the in-game interface the player will have when playing the game. Rather than in-game menus like settings or inventory screens, this refers specifically to the floating windows and bars which don’t normally interact with the game and serve a information-only purpose. This includes health bars, mini-maps, time counters, equipped items and their amounts, money and etc. Although the size of the HUD will vary according to the game type (MMORPGs and RTSs will have big HUDs while sidescrollers and puzzles will have very small ones) keep in mind that a HUD shouldn’t occupy too much of the screen.

Example:

Sounds

On the other hand, one cannot sketch sounds, so you’ll just have to detail your sound engine here, and maybe the style of songs your game will use. Although for most games you will simply state that there will be different background music for different situations, it goes without saying that this subsection is most important for a rhythm game.

Controls

Stating which buttons/keys do what can be troublesome in the case where a single button does more than one action (i.e. The ‘A’ button in any 3D Zelda). Start by putting a simple picture of a controller or a keyboard with each button highlighted with their function in a more general sense. After that, if your game has advanced combos or something similar to that, explain them carefully, stating under which conditions each combo is “activated”.

Example:

Game-Specific Subsections

Puzzles could have a “Pieces” subsection, sidescrollers will probably have a “Level Design” one, space shooters may have “Enemies” and so on. As the title in bold above says, each game will have their own specific subsections, and since we can’t compose a subsection for all the possible ones that one GDD can have, we will provide you with the three bold subsections presented here as examples.

Pieces

Suppose we have a puzzle game, where the player rotates different pieces in order to create a line of matching pieces to gain points. This would be a nice subsection to show some sketches of the many different types of pieces, as well as explaining their rotation pattern, stating their points value, and maybe describe their positioning placement. Pictures are welcome as always!

Example:

Level Design

Now let’s pretend we have a typical 2D platformer. One of the core elements of the game is the stages the player has to go through. It’s important that each stage feels unique so the player won’t feel like he’s just repeating the same thing over and over again. On the other hand, the player should still be familiar with the flow of the stage, i.e. if there’s always a checkpoint somewhere halfway through it, or some collectible items along the way.

What are the different types of enemies, terrains, doodads and power ups and do they allow the level designers to come with many different stages? You could present some beta stage diagrams to illustrate how will they be carried out.

Example:

Enemies

It’s very popular for space shooters to have many kinds of enemies, each one with different attacks and movement patterns, as well as different values for health, speed and targetable area. As such, it’s no surprise you would need an extra section to present all the game’s foes and their stats. Also, you could state some of their more obscure behaviour like shooting an extra beam when their health is low and so on.

Example:

Plot

Many games are set in fictional worlds, each with their own geography, history and characters, in which the player will undoubtedly play a large role as the protagonist. If your game has a particularly interesting setting, it would be interesting to include a little insight on the game’s storyboard, describing the protagonist’s main events during his adventures and details about the lore.

Characters

Lots of games aren’t made of enemies alone. There may be a protagonist and allies to help him overcome his foes. For example, even a tower-defense game without a controlled character can still have side-characters like a tutorial-NPC giving you tips on how to overcome certain challenges at the beginning of each stage. If you do have a protagonist that the player controls, then what’s he like? Does he have any abilities and powers? Keep in mind that this shouldn’t feel like a “How to Play” subsection.

Artificial Intelligence

Any game will need a persisting world to handle all the player’s actions to the game and the other way around. That includes enemy movements, player controls, collision handling, time counting, random number generators and many other things one could need in a game. Although people not directly related to the programming may not understand this subsection entirely, they should at least grasp the basic of it. Most of all, keep the coding out of here and simply state the enemies’ moving patterns, the chain puzzle piece falling algorithm, maybe illustrate the combat system with a flowchart and so on.

Example:

The characters on the board will escape the orbs using simple pathfinding / flocking algorithms. Every level will use up to three different script files to issue commands to the animated characters. (…) Player bots will be used to simulate real players. This will allow any level to be played even if there are more goals than players. The decision process that the A.I. system is trying to solve is this:

– Should I place a new block? If so:

– Where do I place the block?

– What type / material should the block be?

Technical Aspects Section

The technical aspects consist of a series of game data, such as the system requirements on which it will play and the framework in which it was developed, the method or algorithm it was based on, and the maximum number of elements that can be rendered on screen. The graphical technical aspects consists of software used, modeling type, art style and others according to these topics.

The system requirements are the necessary computer settings for the game to be played, like the size it occupies on the computer’s HD and how much RAM is needed.

Another important technical aspect not to forget is the ESRB (Entertainment Software Rating Board) rating (or similar), already explained earlier. Some of the ratings are shown below.

To Include or Not to Include? When? Why?

Technical aspects interest the companies that will distribute it or that will use the technology developed in the game, so always add something in it if you’re showing this to someone that will approve or disapprove the game. There has to be some care when writing technical aspects. You can write something in the wrong subject. For example: limiting the platform and distribution game mode belongs to Marketing Aspects, not to Technical Aspects.

More Examples

For professional examples of Design Documents provided by the developers, we have: Shred Nebula, Play With Fire, Grim Fandango Puzzle Document, and many more avaliable at gamepitches.com.

For more material about the structure and composition of a GDD, one could try the featured Gamasutra article The Anatomy of a Design Document, Part 1 and Part 2; the self explanatory Creating a Great Design Document; and a more general How to write an effective Design Document, which isn’t about GDD, but about software development.

More on Game Design: The Two C’s of Video Game Design.

Moreover, there are other visions of how should documentation be done in the Game Industry, as seen in Game Design Logs and Return of the GDD. Although they seem to contradict what had been told here, this should fall in a case-by-case analysis considering team size, budget and deadlines.

Conclusion

For designers who need the approval of an investor: truth be told, before you can make any progress with an investor, you must first get his attention, and to do so, the following key points of your document must be in excellent shape.

High concept: you never get a second chance to make a first impression, and here is where you will make it. We have already given you the tools to make this section, now just remember to give its construction a high priority and point everything that makes your game more appealing here.

Pictures: do not be fooled that the reader will always go through your entire GDD, there are some documents that surpass a thousand pages (yes, this is true!). But he will surely take a better look if something catches his attention, and what better way of doing so than with pictures? After all, one image is worth a thousand words.

It goes without saying that your document must have a great appearance. Take your time to make everything readable and nice. Also, don’t forget that this article only presented a skeleton structure of a GDD for you; you will have to adapt it to your own game!(source:tutsplus)