本文原作者：Dylan Moran 本文译者：Ciel Chen

一个概念性游戏设计文案，其理想状态是能够在着手开发前概括出整个游戏的开发过程。

一旦这个游戏项目被通过，开发者就会为开发团队把这个概括文案具体化。因为游戏开发是一个非常动态的过程，有时一个游戏设计文案会在开发过程中被反复多次地修订更改而变得更加完善，同时项目范围和方向也会不时地变化。

正因为游戏设计文案有这个会不断变化的性质，它常常又被称作动态文案。刚开始它可能只是一个很基础的大纲，然后慢慢地变成了一个对整个游戏开发过程的每个阶段都有详尽描述的框架。

successful Game Design Document（from gamasutra）

格式确切、对所有不同类型游戏都适用的游戏设计文案终稿是不存在的。每份游戏设计文案终稿所涵盖的信息量都是独一无二的，因为这取决于不同的公司目标，项目规模，团队技术以及作者认知。但相同的是，在初期，一份好的游戏设计文案会包含所有的游戏组成部分和游戏机制，也就是以下部分：

项目说明

一份游戏设计说明必须有一个简洁的关于游戏的说明。没必要把游戏机制和技术方面的内容一一列出。只要把这个说明把控在两三段左右，应提到的有游戏性质（社交、冒险等），游戏类型（益智类、设计类、战斗类）还有你所知道的任何游戏参考。

角色、故事、时间、主题

在一开始把游戏的角色、故事、时间和主题介绍出来很重要。如果你的游戏没有任何特定的角色或故事，你可以简单地描述游戏的主题进入下一步就好。因为就像简单的射击游戏未必需要像拯救平民的士兵这样的角色。它可以仅仅是让两个玩家切磋射击技巧的简易游戏。

游戏可玩性

在这部分，你必须特别指出玩家会选择玩这款游戏的理由以及他们会怎么玩。比如可以提到游戏设计的目标、角色/玩家在玩这个游戏需要用到的技巧、游戏的机制、可强化的选项（为了让游戏更有趣好玩）、游戏难度以及玩家怎样算输。

美术风格

就像标题说的那样，美术风格的定位决定了整个游戏的画风。游戏画风也就是说这款游戏看上去会是什么样。举个例子，像《精灵宝可梦》(Pokemon Go)、《糖果粉碎传奇》（Candy Crush）和《愤怒的小鸟》（Angry Bird）就有非常吸引人的美术风格。独一无二的画风元素在这些游戏的成功道路中功不可没。富有创造性的色彩融合、设计、主题加上有新意的角色让这些游戏脱颖而出流行起来，而且还为游戏增添了自然/免费的营销渠道。比如不同的制造商发行的各种周边，就像愤怒的小鸟腕表/文具；还有以游戏相同名字注册的不同服务，比如Rebel Penguin网络服务，精灵宝可梦儿童日托服务。

技术说明

在这个部分，你必须明确游戏发行所面向的平台，比如是手游平台（安卓系统或者苹果系统）、单机、联网/Facebook平台或其他更多。还有就是这个新游戏所用到的工具、软件或者游戏引擎，比如说虚幻引擎4（Unreal 4）、Unity 3D等。因为详细的技术细节会在技术设计文案中一一例举出来（TTD），所以在这里你只要把最基本的细节明确下来就好。

营销与资金

此处应列举出你对于这款游戏的所有营销想法，比如游戏所面向的目标用户或者目标地区，要从哪里弄来资金等等内容。在动手开始设计游戏之前，把这些细节搞定是非常重要的。比如说，如果你的目标用户是年轻男性（15到25岁），那比起粉嫩的洋娃娃或者小兔子，把主要角色设定成士兵、赛车或者足球运动员总要合适得多吧。还有如果了解游戏面向的地区你就知道游戏要采用那里的语言，比如法语，西班牙语，英语，意大利语等等。还有最重要的是，你必须明确你打算怎么通过这款游戏赚钱，是通过植入游戏的广告还是通过卖出该游戏的完整版。

总而言之，一份游戏设计文案不用把你游戏每个技术部分都描述得非常详细。它只需要概括出你对这个游戏的设计计划，这个计划得让人读得下去，看得明白。 拥有一份详细的游戏设计文档肯定不是件坏事，因为它能让开发团队在回顾分析一些小细节时，能预判到潜在问题，这些都是那些过于简短的文案办不到的。

本文由游戏邦编译，译者为Ciel Chen 转载请注明来源，或咨询游戏邦，微信zhengjintiao

How to write a successful Game Design Document

by Dylan Moran on 02/21/17 09:08:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

A conceptual Game Design Document (GDD) is ideally created before a pitch, which outlines the complete game development process.

Once the project is approved, the document is then expanded by the developer into a detailed guide for the development team. And because the game development is so dynamic, sometimes a GDD is revised and changed multiple times during the development phase. It is continuously improved upon as the development processes. Project scope and direction is also changed at times.

For this frequently changing nature of a game design document, it is also often referred to as a living document. It may start with only a basic outline and become a detailed framework for each phase of the complete game development process.

There is no definite format of a final Game Design Document that suits all different variations of games. The amount of information contained in the final GDD is always unique, depending on the company goals, project size, skills of the team and knowledge of the author. However, to begin with, a good GDD contains a description of all the components of the game and the game mechanics as below:

Project Description

A GDD must start with a brief description of what the game is about. Not necessarily listing the game mechanics or other technical aspects. Just keep it to 2-3 paragraphs and mention the nature of game (like, social, adventure), genre of game (like, puzzle, shooter, combat) and any reference games you know of.

Characters, Story, Events and Theme

It is important to introduce the characters, story and theme of the game at the beginning. In case your game does not have any particular characters or a story, you may simply describe the theme of the game and move ahead. Like a simple shooting game may not necessarily have a character like a soldier rescuing civilians. It can be simply game where two players compete for better shooting skills.

Gameplay

In this section, you must specify why the player would be playing the game and how he would play. For example, mention the goals of the game, skills needed by the character/player to play the game, the mechanics of the game, power up options (to make the game more fun), game difficulties/challenges and how a player loses.

Art Style

As the name suggests, defining an art style means deciding on the visuals of the game. How the game would look like. For example, games like pokemon go, candy crush and angry birds, had very attractive art style. Their unique visual elements were equally responsible for the success of these games. Their creative blend of colors, design, theme along with innovative characters makes these games highly popular among masses and increase the natural/free marketing channels. Like, various accessories are launched by different manufacturers with the game theme, like angry birds wrist watches/stationeries, and different sort of services being registered under same title name like Rebel Penguin web services, pokemon go day care for kids.

Technical Description

In this section, you must specify the platforms on which you would launch the game, like Mobile Phones (android, iOS), PC, Social Networks/Facebook or more. The tools, softwares or game engines you would employ to create your new game, like Unreal Engine 4, Unity 3D and more. The detailed technicalities would need to be listed in a Technical Design Document (TDD), so here you just need to specify only most basic details.

Marketing and Funding

Here you need to list all your ideas about how you intend to market your game, which is the targeted user or location, where to get funds from and more. It is important to have all these details in hand before starting to design a game. For example, if you are targeting young adult men (from 15-25 years), it might not be appropriate to have the main character as a pink colored doll/bunny, rather a soldier, a racer, a football player could make a better choice. Knowing the location of the game would allow you to use regional language within the game, like, French, Spanish, English, Italian and more. And most importantly, you must specify how you plan to monetize on the game, whether it is through in-game ads, or by offering a paid full version of the game.

In short, a GDD does not need to be a detailed document that specifies each technical aspect of your game. It simply needs to outline your plan for the game design, which is readable and easily comprehensible by anyone who reads the document. Having a detailed GDD can never be a bad thing either, as it would allow the development team to review several smaller points analyse them and address potential problems in advance which could not be possible through a very brief document. (source:gamasutra.com )