作者：Leandro Gonzalez

当我们几个月前在Reddit上分享这篇文章时我们看到了一些具有有建设性且充满激情的讨论（我们也因为这些讨论而变成了更出色的游戏设计师）。

我们发现其中有些反复出现的要点，所以在你们继续阅读本文前我想先声明以下内容是错误的：

1.使用游戏设计文件（GDD）过时了。

2.当你在编写GDD时你需要直接去描述游戏机制。

之后我可能会写篇文章去讨论每个主题，不过现在我打算先讨论以下内容：

1.与其它产业一样，游戏产业也不断发展着，或许昨天还很好用的技术在今天看来就过时了。特别是在年轻的产业中，即仍在发展着过程，参数等等的产业中。这时候最重要的便是在真正投入生产前你需要使用GDD（或者Wiki，黑板等方式）等方式去描述你的游戏项目（或任何其它项目）。

以下便是我们所谓的GDD的一些使用技巧，我们同样也会使用黑板去管理任务，并尝试着将我们的项目分成两周。

我们并未使用在开发过程中不断发展的完整GDD，相反地我们使用的是能够让团队了解项目全新情况的文件。然后我们会做出一些调整去适应游戏设计阶段我们所收到的反馈内容或者团队的新想法等。

一旦开始投入生产，我们便不会再更新GDD，反而我们会将所有新理念记录在黑板上，有些理念会被优先挑选出来（即会出现优先次序1至3的内容，也就是必须做的事1，将要做的事2，以及做了也不错的事3），并将其中一些理念归到“理念”栏中留到之后再进行评估。

总之不管你使用的是GDD还是其它方式，我们都会建议游戏设计师开始考虑将自己的理念记录在某种类型的文件中让其他人能够阅读并理解这些内容。

2.如果你的游戏是像《俄罗斯方块》或《太空入侵者》或《Asteroids》那样，也就是游戏故事是科幻的并且对游戏机制不会产生任何影响，那么我便会建议你直接进入第四章节的模板中。

对于我们在这个例子中所使用的游戏，它将能够基于特定背景自然地描述角色，他们可能做的事以及这么做的原因。

不过最终这都是取决于你的游戏和游戏设计类型。你可以考虑添加一个介绍部分并在这里简短描述整体机制，而添加这部分内容的目的便是让阅读该文件的人能够马上了解你的游戏类型和游戏机制。

所以我该如何使用文件去记录我想在游戏中执行的内容？

这便是当我拥有一个能够帮我致富的优秀理念时第一个涌现出来的问题。那时候我还不知道自己想要进行游戏设计，所以我需要先创造一份游戏设计文件（简短的GDD）。

在进行一些研究后我认识了GDD，但是我却找不到其它产业标准或模板去帮助我开始执行这一过程。

在阅读了一些游戏设计书籍并浏览了网上一些相关内容后，我便开始创造自己的第一份GDD。而经过几年的迭代后它最终变成了下面的模板，这也是我们每次开始创造新游戏时所使用的模板。

以下便是关于GDD中每个部分的描述。

项目描述

总结游戏是关于什么，不要讨论过多有关游戏机制之类的内容的细节。你必须让人们在阅读了项目描述后清楚你尝试着去创造的游戏风格（游戏邦注：是社交的，休闲的，还是硬核的）和类型（是益智游戏，RPG还是FPS）。当然了你也可以添加更多与游戏相关的信息。

你最好确保这一部分只有1或2段内容。千万不要超过1页。

例如：

这一游戏设计文件描述了一款带有创新游戏机制，故事和角色的多平台触屏2D益智游戏的相关细节。

游戏玩起来像三消游戏，但同时也包含了一些创造性内容

游戏名字待定，但已经有些候选名字了。

1.角色

我们先从角色开始是因为你需要在故事前先介绍他们。如果你的游戏没有角色或故事，你便可以直接跳到游戏玩法那部分，即舍弃第1至第3部分。

角色描述例子：

Gnumies是这款游戏的主角。这些生物都很活泼且很富有，但却并不贪婪。他们之所以富有是因为他们的祖先与金钱有关，所以他们的名字才叫Gnumies。他们毛很多且具有各种颜色。

红色Gnumies充满热情且喜欢打碎各种东西。黄色Gnumies喜欢跳上跳下。绿色Gnumies很安静，毫不拘谨且很好相处。蓝色Gnumies有点阴郁且脾气较差。

Gnumies同时也拥有许多手臂，即在1至4之间，他们手臂都带有手。他们会在握手的时候结合在一起。Gnumies喜欢粗野的游戏方式，所以可能导致所有的一切变得很混乱。

你也可以在这里添加一些角色图像。

2.故事

“故事叙述的一个重要部分便是创造能够轻松将观众带入其中的角色，如果越多观众能够与角色形成共鸣，那么这些角色所参与的事件便会变得更有趣。”—-Jesse Schell

在介绍了角色后，你便可以开始阐述发生于游戏中的故事了。

例如：

Gnumies愉快地在城堡中游戏并搞了恶作剧。Butler发疯了，但所有人还是照常游玩着。

小丑在开玩笑。

德国人待在家中看电视而他的母亲不断烦他。所以他便出门去侦察Gnumies。外面在下雨而德国人羡慕地看着窗内，他已经被淋湿了。

一个奇怪的人给了他一把钥匙，他可以使用钥匙进入后门。他带着自己的军队进入了后门，绑架并监禁了女性Gnumies和小孩Gnumies，并将所有人赶出了这座岛屿。

2.1主题

“具有能够形成共鸣的主题可以将你的作品从工艺变成艺术。美术师可以将你带到你之前从未到过的地方，而主题便是他所借助的交通工具。”—-Jesse Schell

当别人在阅读你的设计时，这部分非常重要。总之主题必须能够表达出你想要讲述的故事类型：它是喜剧，还是反应真实生活的，亦或者是科幻的？

例如：

这款游戏的基调是悲伤的。这里会有动作场面和愉快的时刻，但在每个章节间故事将阐述Gnumies的悲伤，因为他们丢了钱。而这同样也带有一些幽默感。

如果你认为这与你的游戏无关便可以选择略过这一步。

3.故事进程

所以你拥有一个故事了，但游戏该如何将玩家带进故事中呢。

“你的游戏世界是一个拥有不同组成部分的内容。你的游戏是将人们带往只存在于玩家想象中的奇幻世界的大门。”—-Jesse Schell

例如：

游戏将从一个简短的介绍场景开始，在这里Gnumies将被踢出自己的家园。然后他们将来到一座岛屿，第一章节便从此拉开了序幕。

第一章节是引言。这是可以略过的内容。Butler将在这里向用户介绍游戏机制。

一旦玩家完成了教程他便可以进入第一个世界（森林世界）。

当玩家完成在森林世界的任务后他便能够获得第一把钥匙并选择去开启火山世界或冰山世界。一旦他们完成了这些世界中的任务……

创造一个能够同时出现在多个故事中的世界非常重要。这能为之后的续集和商品开发做铺垫。

4.游戏玩法

“游戏是从一个理念开始的。”—-Jesse Schell

这是GDD中最重要的部分（在99%的游戏中）。在这里你可以描述你的游戏玩法会是怎样的。

因为这部分会变得较大，所以我们将其分解成一些小节内容。当然了这也是一个非常主观的观点，即适合我们的东西不一定适合你。

4.1.目标

简而言之，为什么玩家要玩你的游戏呢？你可以添加这一信息到一个独立的部分中如此你便不需要在浏览整个GDD的时候进行猜测。

例如：

从整体来看（长期）：帮助Gnumies回家

游戏玩法（短期）：打败敌人，前进到下一个关卡等等

4.2.用户技能

这并非最直观的部分，但当你在考虑玩家需要精通怎样的技能才能玩游戏的时候这部分能够帮助你缩小范围。相信我们，编写这列内容能够帮助你找出游戏设计中的问题所在。例如你可能尝试着为孩子们创造一款游戏，而你可能会意识到你要求他们做的事太超前不符合他们的年纪，或者某些输入内容适合手机而不适合拥有操纵杆的主机。同样地，如果你的游戏将带有Custom HW，那么这列内容将帮你明确你需要执行的组件。

例如：

敲打屏幕

拖放

记忆

解决谜题

重新安排组件

管理资源

制定战略

4.3.游戏机制

在这里你将描述你的游戏机制。当你在向团队成员传阅GDD时，你必须尽可能避免他们对于游戏玩法的疑虑。在这部分中你可以添加一些有关游戏原型的图像或截图（我们会事先创造机制原型并在投入资源于游戏中前测试它们是否有趣）。

你可以找到许多有关如何描述游戏机制的书籍和网站，所以我们便不在这里进行详细说明了。

4.4.道具和升级道具

我们使用这一部分详细介绍了游戏机制。为了避免将所有内容集中在同一部分，我们在上部分中描述了核心机制并在这部分中讨论了为提高游戏乐趣而添加的一些内容。

如果你的游戏是一款三消游戏，那么在之前的部分中你便需要描述一款三消游戏是如何运行的。

在这部分中你则需要添加玩家可以使用/购买的每一个升级道具和道具以及它们将如何影响核心游戏玩法。

例如：

当闯完一个世界时，你可以获得与这个世界相关的升级道具。例如你战胜了火山世界，你便能够获得一个可以让红色Gnumies变得更加强大的道具。可能是一条围巾或其它他们可以穿在身上的东西，而你将在之后的游戏中看到这些道具。你可以使用游戏内部的货币去升级道具，或使用真钱去获取游戏内部的货币包。

4.5.进程和挑战

这也是一个很主观的部分，可能适合你的设计也有可能不适合。关于这一部分我们的理念是精确描述难度在游戏中是如何提升的并确保提供给玩家能够追赶难度的工具。

例如：

难度将让敌人变得更加难对付。为了应对不断提升的难度，玩家需要变得更擅长游戏，升级Gnumies并使用道具（同时也要升级道具）。

同样地我们也可以在这里谈论玩家开启全新关卡和任务的方法。

例如：

每个boss会丢下一个衔有代表所处世界颜色的宝石。玩家可以基于不同顺序去处理不同世界。当玩家战胜每个世界并获得所有钥匙后，他便可以按照自己的方式前往最后的世界。玩家可以基于不同顺序进入不同世界。最终世界的boss将丢下一把能够让玩家开启不同世界的钥匙。一旦玩家使用了某种道具，它便会永远消失。如此玩家必须在开启下一个世界前先战胜他所选择的世界。在这里世界的难度是设定好的。

4.6.失败

失败的条件是什么呢？时间，生命值，还是所有的这一切？在这部分中你可以描述玩家是因为什么才到达“游戏结束”页面。

例如：

这些都是失败的条件：耗尽了时间，耗尽了生命值，不存在可行的结合。

当玩家失败时，必须出现一个显示Gnumies受伤的图像。也许他们会掉了毛发，而你将能看到他们的皮肤。

5.美术风格

这部分是不言而喻的：在这里你可以描述游戏外观的相关想法。因为一张图可以等同于数千个单词，所以这便是你添加概念图像的地方。

例如：

这是一款2D等距游戏，具有高质量的2D精灵。角色设计就跟吉卜力工作室所设计的一样。

所有的一切都必须具有鲜艳的色彩且足够生动，并带有动画场景和分层的背景。

6.音乐和声音

“音乐是灵魂的语言，正因为如此它将从更深层面向玩家传递某种内容。”—-Jesse Schell

在这里你能够描述你的音乐和声音。基于音乐与声音对于你的游戏的重要性，你可以将其分解成一些较小的内容。

例如：

音乐应该是复古风格，能够让人回想起8位体的游戏时代，但同时也必须具有较高音质。

你必须在玩家做得不错的时候呈现出赞扬的声音。这必须是直接且正面的反馈。

当时间不够时，你可以添加一些让玩家紧张起来的声音。

悲伤的场景可以伴随着手风琴/小提琴演奏的音乐，就像悲伤的探戈那样。

对于游戏中的音乐，你也可以使用一些欢快的曲调并随着关卡的前进而加快速度。而当玩家进入山洞时声音最好显得模糊些。

7.技术说明

在这里你可以描述你将面向哪个平台发行游戏以及你将使用怎样的工具。这并不是有关技术细节的描述，毕竟那是属于技术设计文件（TDD）的范畴。在这里我们将只是传达一些表面上的内容。

例子：

最初游戏将是跨平台手机游戏，即面向以下平台发行：

iOS

Android

Windows Phone

紧跟着将发行PC单机版和Facebook版本。

在未来也有可能添加Mac或主机支持。

我们所考虑的引擎包括：Marmalade，Unity 3D，Unreal Engine 4.

对于项目管理我们会使用JIRA。并使用Perforce去储存代码和资产。

TBD非常适合技术设计文件。

8.市场营销和融资

这是一个可选择的部分，但你最好在当下记下自己的想法以防之后忘记。你必须考虑如何去营销自己的游戏—-甚至是在投入开发之前。你必须清楚该从哪里筹集制作游戏的经费。

“计划是货真价实的。”—-Jesse Schell

例如：

创建第一个关卡的原型，然后进行Kickstarter活动去呈现该原型

尝试着达成一个发行协议。

寻找是否存在可申请的政府资助。

创造一份新闻稿并将其发送到游戏新闻网站。

创建YouTube Channel并在上面发布开发日记视频。

等等。

8.1.目标用户群体

你必须清楚你将面向哪些用户群体，这将被融入到游戏设计中。如果你瞄准的是15至25岁的男性，你的主角就不应该是一只粉色小马。

例如：

年龄：12至50岁

性别：所有人

主要是休闲玩家

8.2.平台和盈利

你可以添加更多有关如何面向不同平台发行游戏的细节。

例如：

最初：作为一款带有游戏内部广告的免费Android应用，以及没有广告的付费版本。

带有广告的免费iOS应用。没有广告的付费iOS版本。

游戏内部购买。

考虑：Windows 8，Windows Phone 8，XBOX live和任天堂e-shop。

8.3.本土化

考虑你将支持的语言。添加任何你所想到的内容，这可能会是你到后来才考虑的内容。

例如：

最初是英语/西班牙语。

之后更新：意大利语，法语，德语等等。

考虑和亚洲发行商合作向亚洲市扩展，他们将帮助你进行本土化。

9.其它想法

这也是一个可选择的部分。如果你拥有一个你不确定是否适合游戏的想法，你可以将其添加到这里以防自己忘记。

例如：

关卡设计师

能够为其他用户所创造的关卡评级

成就

排行榜

游戏是否应该拥有多人模式？

“通常情况下，比起单人游戏，创造多人在线游戏所需要的精力和经费将增加4倍。”

“通常情况下当你完成一个可行的版本后你将需要花费6个月的时间去平衡游戏。”—-Jesse Schell

结论

我们真心希望这一模板也能够帮到其他游戏开发者。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

How to Write a Game Design Document

by Leandro Gonzalez

Some clarifications before diving in

When we first shared this post (a few months ago in Reddit), some really constructive and passionate discussions emerged (and we all became better Game Designers because of it).

There were a few points that kept showing up the most and I’d like to clarify some stuff that will make sense once you’ve been able to read the whole thing:

Using a GDD is a thing of the past.
When you write a GDD you need to jump right into describing the Game Mechanics.

I’ll probably write a full post discussing each topic in the future, but for now:

1.- Like every other industry, the game industry evolves, and the techniques that are used one day quickly become a thing of the past. Specially on a young industry that is still developing it’s processes, metrics, etc…. Whatever you like to call it (GDD, Wiki, Board,…), the important thing is to have something that describes your game project (or any other project for that matter) before jumping into production.

Here at Trick we name them GDDs and we also use boards (Trello) for managing tasks, and try to divide our project in two week milestones (somewhat resembling Scrum).

We don’t use a monolithic GDD that evolves during development, but rather a document that can be used by the team to get up to speed. Then, a few corrections are made to reflect the feedback or ideas of the team during the Game Design phase.

Once production has started, we no longer update the GDD, all new ideas go straight into the board, some of them prioritized (Priority 1 to 3, being 1 a Must do, 2 a Will do, and 3 a nice to have) and some of them into an “Ideas” column to be evaluated at a later time.

In summary, whether you use a GDD or something else, we recommend Game Designers that are just starting to please, please, please, consider writing down your ideas into some type of document that other people can read and understand.

2.- I think the answer to this is one is that “It depends”, which should have been made clear in the post. If your game is something like Tetris or Space Invaders or Asteroids… in other words, games where the Story is practically non-existent and they won’t have any effect on the game mechanics, I agree it’s the right thing to jump right into Chapter 4 of the template.

For a game like the one we used in this example, it felt natural to describe the characters, what they could do and why, in order to give some context. (The Gnumies can merge, which translates into a certain game mechanic, and they are fighting German the Germ, which explains the game enemies).

Ultimately, it all depends on your game and your Game Design style. Just take into account that there is an Intro section where you can briefly describe (in one or two paragraphs) the overall mechanics, and the intention is that whoever reads the document can immediately understand your game’s genre and high level mechanics, regardless of if you jump straight into a full fledged description or take a detour explaining some backstory first.

So, how do I go around documenting what I want to do with my game?

That was the first question that came up when I had the great idea that would make me rich (JK of course, I’m still poor). At that point, I didn’t even know that I wanted to write a Game Design, and for that I needed to create a Game Design Document (GDD for short).

Doing some research I came across the term, but couldn’t seem to find an industry standard or template to help me get started.

After going through a few Game Design books (I highly recommend Jesse Schell’s Book of Lenses), and reading all I could online, it was time to create my first GDD. Through the years and iterations it has evolved into the following template, which we use every time we start a new game here at Trick.

Here’s a description of each section in the GDD (you can download the template in *.doc format here => Trick’s GDD Template)

Project Description

A summary of what this game is about, without going into much detail about game mechanics or anything else. After reading the Project Description, it should be clear what type of game you are trying to make (Social, Casual, Hardcore, etc.) and the genre (Puzzle, RPG, FPS, etc.). Of course, you can add more information that feels relevant to your game.

This section would ideally be one or two paragraphs long. No more than a page for sure.

For example:

This game design document describes the details for a
multi-platform touch based 2D puzzle game with novel
mechanics and an original story and characters.

The game plays like other match-3 games but introduces
some innovations.

The name is to be defined but candidates are…

1. Characters

The reason we start with characters is because you need to introduce them before the Story. If your game doesn’t have Characters and/or Story, you can just jump to the Gameplay section and remove Sections 1 to 3 (or leave them empty).

An example of character descriptions:

Gnumies are the main characters
in this game. These creatures are happy and wealthy, but not
greedy. They are wealthy because their ancestry is related
to money, or Numismatic, thus their name: Gnumies.
They’re hairy and come in a variety of colors.

Red Gnumies are passionate and break stuff. Yellow Gnumies
are electric and jump up and down. Green Gnumies
are tranquil, relaxed and easy going. Blue Gnumies
are a little sad and grumpy.

Gnumies also have a lot of arms, anywhere from 1 up to 4, and
their arms have hands. They have a firm handshake and can
combine when holding hands. Gnumies like rough play and
leave everything messy…

You can also add some character artwork here.

2. Story

“An important part of the art of storytelling is to create characters that the guests can empathize with easily, for the more the guests can empathize with the characters, the more interesting the events become that happen to those characters.” – Jesse Schell, Book of Lenses

Having introduced the characters, it’s a good time to talk about the events that will happen throughout the game.

For example:

Gnumies are happily playing inside their castle and causing
mischief. The Butler is going insane, but everybody is enjoying.
Joker makes jokes.

German is home watching TV and his mother bothers him. So he
goes out to spy on the Gnumies. Outside it’s raining and German
is looking envious through the window, getting all wet.

A strange mysterious person-something gives him a key that he
can use to enter through a backdoor. He goes in with his army,
kidnaps and jails female and baby Gnumies, and kicks everybody
else out of the island…

2.1.Theme

“Resonant themes elevate your work from craft to art. An artist is someone who takes you where you could never go alone, and theme is the vehicle for getting there.” – Jesse Schell, Book of Lenses

This is important for when other people read your design. Overall, the theme speaks about what kind of story you want to tell: is it comedy, is it the real life or is it just fantasyyy…

For example:

This is a game about sadness and hardships. There is
action and happy moments but between each chapter
the story must progress in a way that clearly states that
the Gnumies are sad because they lost their home.
It must also have a sense of humor and be funny.

You can skip this section if you think it’s irrelevant for your game.

3.Story Progression

So, you have a Story, but how will the game take your players through that story.

“The world of your game is a thing that exists apart. Your game is a doorway to this magic place that exists only in the imagination of your players” – Jesse Schell, Book of Lenses

For example:

The game starts with a short intro scene where the Gnumies
are getting kicked out of their homes. Then they land in an
island and the first chapter begins.

The first chapter is the Tutorial. This can be skipped. Here
the levels are few and the Butler introduces the user to
the mechanics.

Once the player beats the tutorial he can advance into the
First World Forest World.

When the player beats the Forest World, he gets the First Key
and then can choose to open the Volcano World or
Icy Mountain World. Once he defeats one of these worlds….

It’s very important to develop the world like a place were
not only this story, but multiple stories could be happening
at the same time. This opens the door for sequels and
merchandise.

4. Gameplay

“The game begins with an idea.” – Jesse Schell, Book of Lenses

This is (probably in 99% of games) the most important section of the GDD. It’s where you describe what your Gameplay (yes, with capital G), will be like.

Since this section can become humongous, we went ahead and divided it in sub-sections that made sense to us. Of course, this is a very subjective topic and what works for us may not work for you.

4.1.Goals

In short, why is the player playing your game? It’s good to add this information to a separate section so you don’t have to guess while reading through the whole GDD.

For example:

Overall (long term): Help Gnumies return home

Gameplay (short term): Defeat the enemies,
advance to the next level, etc…

4.2.User Skills

This is not the most intuitive section, but it really helps to narrow down your scope if you think about what are the skills your player needs to master in order to play your game. Believe us, writing this list will help you find problems in your Game Design. For example, you may be trying to develop a game for kids but realize you require them to do something that is too advanced for their age, or some inputs may be good for Mobile but not for a Console with a Joystick. Also, if your game is going to have Custom HW built around it, then this list will allow you to figure out what components you’ll need to make it work.

For example:

Tap on the screen
Drag and drop
Memory
Puzzle solving
Rearranging pieces
Manage resources
Strategize

4.3.Game Mechanics

This is where you describe your proper game mechanics. Spare no words, when you circulate this GDD around your team, there has to be the least reasonable amount of doubt about what the gameplay should be like. This is a very good section to add some Artwork or Screenshots of your prototype (we prefer to prototype the mechanics and figure out if they are fun before committing resources to a game).

There are complete books and sites with materials about how to describe game mechanics, so we’ll not elaborate with examples here. Linked resources at the bottom.

4.4.Items and power-ups

We use this section to elaborate on the Game Mechanics. In order to avoid having a single section with everything in our brains poured into it, we use the section above to describe the core mechanics, and this section to talk about things that can be added to the game in order to improve the fun and empower the player.

So, if your game is a match-3 game, then in the previous section you’d go and describe exactly how a match-3 game would work (and adding your variations to the formula).

In this section you’d add every power up and item the player can use/encounter/buy and how they would affect the core gameplay.

For example:

When finishing a world, you could get a power up
related to that world. For example, finishing the
volcano world, can give you an item that makes
red Gnumies more powerful. It could be a scarf,
or something they can wear, and those items could be
seen in-game later. You can level up items using
in-game currency, or use real money to acquire
in-game currency packs….

4.5.Progression and challenge

This is also a very subjective section that may or may not work in your design. Our idea behind this section is to elaborate on how the difficulty will increase throughout the game, and making sure we give the player the tools to catch up to it.

For example:

Difficulty will advance by making the enemies harder.
To mitigate difficulty, the user will have to play better,
level up Gnumies and use items (also level up the items).

Also, here we can talk about the way players will unlock new levels or missions.

For example:

Each boss drops a key with a jewel of that world’s color.
Worlds can be tackled in any order. When the user beats
every world and has every key, then he can go and work
his way through the last world. The order in which a user
tackles each world can be chosen by him. The boss at the
end of a world drops a key that can be used to open a
different world. Once the item is used, it is lost forever.
That way, the user must complete the world he selected
before opening the next. At that point the difficulty for
that world is set

4.6.Losing

Yes, losing! What are the losing conditions? Time, health, all of them? This is the section where you describe how the player gets to see your “Game Over” screen.

For example:

These are the losing conditions: losing by running out
of time, losing by running out of moves, losing when
there are no available combinations.

When the player loses, there must be an image showing
the Gnumies wounded/scratched. Maybe they can lose
some hair and you can see the skin under the hair.

5. Art Style

This section is self-explanatory: here’s where you describe your ideas about what the game should look like. Since a picture is worth a thousand words, this is a great place to add some concept art.

For example:

This is a 2D isometric game, with high quality 2D sprites.
The character design should resemble that of Studio Ghibli.

Everything should be very colorful and feel alive, with
highly animated scenarios and layered backgrounds….

6. Music and Sounds

“Music is the language of the soul, and as such, it speaks to players on a deep level.” – Jesse Schell, Book of Lenses

Here is where you describe your Music and Sound FX. Depending on how important this is in your game, then you can split this section in different sub-sections.

For example:

The music should have a Retro style, appealing to 8 bit
nostalgia but high quality.

It’s important that a lot of sound effects praise the user
when he does something good. There should be immediate
and positive feedback.

When time is running low, add a sound that makes the
user nervous.

The sad scenes should be accompanied by Accordion/Violin
music and sound like a sorrowful Tango.

For In-Game music, use a more relaxed approach with
happy tunes and going up on tempo as the level progresses.
When in caves the music should sound muffled.

7. Technical Description

Here’s where you describe the platforms you’d be launching for and tools you’ll be using or are considering to use throughout your development. This should not be a detailed technical description, for that you have the Technical Design Document (TDD). Here we are just scratching the surface.

Example:

Initially, the game will be Mobile Cross-platform:

iOS
Android
Windows Phone

Follow with PC standalone version and Facebook Canvas.

Could add Mac and/or console support (through e-stores)
in a future.

Consider the following engines: Marmalade, Unity 3D,
Unreal Engine 4.

For project management use JIRA. Use Perforce for
storing code and assets.

TBD properly in Technical Design Document.

8. Marketing & Funding

A completely optional section, but write your ideas now so you don’t forget them later. It’s important to think about how you are going to market your game, even before starting your development. It’s also important to know where the money to make the game is coming from.

“A plan is a real thing.” – Jesse Schell, Book of Lenses

For example:

Prototype the first level, and launch a Kickstarter campaign
where we show that level.

Try to land a publishing deal.

Is there any Government funding we can apply to?

Create a press kit and send to gaming news websites.

Start a YouTube Channel and post development diary
videos.

Etc.…

8.1. Demographics

It’s important to know who you’ll be targeting, this should spill into the game design. If you are targeting 15 to 25 year old males, then your main character probably shouldn’t be a pink pony (not that there’s anything wrong with that).

Not that there’s anything wrong with that
Example:

Age: 12 to 50

Sex: Everyone

Casual players mostly

8.2.Platforms & Monetization

You can add a little more detail about how you are going to approach the release on each platform.

For example:

Initially: Free android app with in-game ads, and paid
version without ads.

Free iOS with ads. Paid iOS version without ads.

In game purchases.

Consider: Windows 8, Windows Phone 8, XBOX live
and Nintendo e-shop.

8.3.Localization

Your supported languages. Just add whatever you have in mind, this is something that probably won’t be a priority until later.

Example:

Initially English/Spanish.
Later update with: Italian, French, German, etc.

Consider getting an Asian publisher for expanding
to Asia, someone that can help with localization.

9. Other Ideas

Another completely optional section. If you have ideas that you are not sure if they should go in the game or not, just add them here so you don’t forget them.

For example:

Level designer
Be able to rate levels created by other users
Achievements
Leaderboards
Should the game have a Multiplayer mode?

“Generally, it is safe to assume that a multiplayer online game will take four times the effort and expense to create compared to a similar single-player game.”

“There is an old rule of thumb that it takes six months to balance your game after you have a completely working version” – Jesse Schell, Book of Lenses

Closing comments

We hope other game developers can find this template useful. Looking forward to starting the conversation about how this document can be changed or improved.

Please, leave your comment below or reach out to us at play@trickgs.com and if you want to see updates of what we are working on, we’d love it if you can follow us on Twitter or Facebook. Thanks!

Here’s are some Gnumies, please take them!(source:gamasutra)