作者：Zack Hiwiller

游戏设计文件（以下简称GDD）是设计师最有效的交流工具之一，但同时也是最容易遭到误解的对象之一。几乎每位专业的设计师都需要应对游戏设计文件。但是游戏设计文件到底是什么？为何它们如此普及？

当一个游戏开发团队只有三名成员的时候（游戏邦注：也就是只有设计师，美工以及程序员），该团队便只拥有三种交流渠道（并且需要保持开放）：设计师——美工，设计师——程序员，美工——程序员。

但是如果再添加一名程序员的话交流线就会变成4至6条：

专业游戏开发团队都拥有较大的团队规模，甚至会多达上百名成员。而如果在一个拥有100名成员的团队中每个人都需要与其他成员进行交流，那共需要建立4950条联系。就像《魔兽世界》拥有将近140名团队成员，而按照这种算法，如果每名成员都需要直接与其他成员交流，那么该团队便需要维持9730种连接关系。

这明显太过于繁琐了！现实中不管是什么团队都不需要强行维持起每个团队成员之间的关系。反倒是一些较大的团队还会根据他们所执行的专业或项目领域而分解成一些更小的小组。就像美工与美工之间进行交流并由制作人面向其它成员传达他们的想法。或者可以说所有的团队成员以多人玩家的形式共同致力于工作中，并基于单人玩家形式与自己的队友进行交流。

但这也会引起另外一个问题：团队成员之间不能自由地进行彼此间的直接交流，他们之间的沟通多了好几道门槛，如制作人或领导者。如果你玩过儿童游戏《Telephone》，你便知道经过多人转播后的内容的准确度会大大受影响：

有时候一些较为模糊的理念，如游戏设计便不能使用这种方式进行交流。团队可以通过复制设计文件去避免《Telephone》中信息遗漏的问题。而在此游戏设计文件更是解决这种问题的重要工具。

游戏设计文件是指那些提供游戏或功能设计指示内容的文件。我们还必须明确不同团队与不同工作室之间的游戏设计文件形式以及所采用的方法也有所不同。而很多人对于游戏设计文件的形式与目的也存在许多误解：

常见的误解1：游戏设计文件是关于游戏或功能等所有信息的资源库。

游戏设计文件的一个主要目的是：告知团队成员他们正在创造什么。为了实现这一目的，我们有必要提到一些利益相关者：

程序员：因为他们需要创造某些内容。

美工：因为他们需要根据环境去明确自己在创造些什么。

制作人：因为他们需要估算创建功能需要耗费多长时间。

QA：因为他们需要知道功能是怎样的以及是否合理。

授权商：因为他们需要合理使用他们的知识产权。

为了传达自己正致力于创造许多内容的信息，许多设计师都尽可能地在GDD中详细解释了系统，幕后故事，设计讨论等影响。但是这里存在着一个经验法则：除非某些内容是直接用于指示程序员或美工所需要完成的工作，否则不要将其添加到GDD中；或者你可以将这些不相关的内容添加到附录或其它文件中。

在某些情况下，创建另一份“伪GDD”也是必要的。有时候一些外部授权商或者公司高管们会想了解团队现在的工作境况，而GDD对于这些人来说又太过技术化。所以这时候“设计概述”或“执行汇总”便非常有帮助。

常见误解2：GDD中的任何内容都是不可打破的法则。

刚刚进入这一领域的设计师总是会产生这种误解。游戏设计是一种迭代过程：它要求反复的实验以及各种试错。但是很多设计文件的表达却极其强硬，就好象不管出现任何情况都不能改变其中的内容。甚至最糟糕的情况是程序员将GDD打印出来并将功能作为一种静态理念进行创造。

GDD是在特定时间内对于某一理念的构想。GDD的功能是维系起整个团队间的交流，而不是一种指令。

我总是会听到一些程序员说他们从来不看游戏设计文件。我将在下文中列出引起他们产生这种错误想法的“罪状”——而其中一大“罪名”便是因为GDD未能保持按时更新。如果程序员在阅读了GDD后被告知需要执行一些与GDD上不同的任务，那么他以后就不会再相信GDD中的内容，而是坐等上级的进一步指令。而设计师的工作则是保持设计文件的即时更新——不管这一工作有多么乏味。

牢记GDD的目的：除非你想要亲自将设计改变传达给团队中的每名成员，否则你就需要根据当前的设计进程去更新GDD。

常见误解3：工作室的设计文件拥有固定模板。

通常情况下学生们总会要求能有一份简单的设计文件样本进行参考。但是我想说的是每个工作室都拥有属于自己的设计文件流程。而学生要求获得模板其实也只是为了参考格式，但格式却正好是其中最不重要的一部分！

针对于不同读者的设计文件内容也会有所不同。就像暴雪面向于大型多人在线游戏的设计文件的读者是一个拥有上百名成员的团队，所以肯定与Quantic Dream侧重于叙述的设计过程不同。这其中要考虑的内容包括谁是你们的程序员？他们知道哪些隐含式内容？等等。所以你必须针对于特定读者去撰写设计文件。

实际上有些工作室也真的拥有设计文件模板。因为模板可以帮你有效地核对哪些重要的内容被遗漏了。但是它的一大弊处在于它并不会随着团队和项目的改变而改变，因此很容易变成一份充满各种无意义内容的超负荷文件。而面对这些无意义的内容，程序员或其他利益相关者更是不得不另外寻找相关信息。所以基于形式而创造游戏设计文件是一种糟糕的选择。你应该在撰写设计文件的同时思考其它必须面对的内容，尽可能保持文件的清晰并突出最重要的目标。

GDD创造过程

接下来我将通过一个实例去分析如何创造一份简明的设计文件。假设我们只是一个小团队并致力于创造一款面向Facebook的科幻类RPG。而团队的首席设计师让你为游戏设计一个锻造系统。这时候你应该如何创造设计文件？

步骤1：明确目的，范围，定向连接系统

设计师的上头一般都有首席设计师或创意总监。而这些人就必须明确游戏设计的目标，也就是你必须明白：设计的目的，设计的范围，以及与设计相连接的系统。

设计目的：如果不清楚系统的目的，你就只能抄袭其它游戏的锻造系统。你的首席设计师将会说：“我们需要一个系统让玩家能够使用从别人身上所获取的道具（以礼物的形式）。我们希望以此鼓励创造性和社交联系。”这只是一个开始。接下来你需要通过访问，询问问题，并在真正撰写内容之前理解任务背后所存在的动机。

设计范围：设计师总是很容易踏入过度设计的误区。也就是如果你分配给设计师一个任务，他们很容易创造出一个与指令有所出入且更加复杂的系统。单独来看，这并不是什么大问题。但是如果从总体来看，任何项目都很难在维系所有复杂系统的同时按时间发行游戏并让用户理解游戏。优秀的设计师总是知道何种系统适合复杂而何种系统适合简单。通过明确功能范围，设计师便能够明确他们所创造的系统深度。

而在我们的例子中，首席设计师会说：“我们拥有许多时间，所以你可以尽可能地延伸设计范围，但是因为整款游戏必须体现出休闲性，所以你也需要尽可能地降低复杂性。”这时候我有可能会选择“市场标准”。我将在下文中详细阐述做出这一选择的原因。

连接系统：老实说，这一系统必须与赠予系统与库存系统维系在一起。也许你可能会创造出非常受欢迎的道具？或者因为设计师控制着游戏的经济运行，所以你不用担心游戏市场中是否会充斥着过多免费商品？除此之外你还需要考虑应该接触哪些人？

你必须确保这些陈述不会相互矛盾。就好比如果你的设计目的是创造一个完整的定制角色生成器，但是你的设计范围却是尽可能的简单，那你就需要寻求首席设计师给予一个合理的解释了。

步骤2：研究

你在前一个步骤中所罗列出的范围等级将有助于明确你真正需要进行多少研究，以及面向何种类型进行研究。进一步了解游戏产业中的其它游戏对你来说非常有帮助。我知道有一家专门制作同一类型游戏的公司，那里的很多设计师从来不去玩其它类型的游戏！这样他们怎么能够了解其它有趣的功能并利用到自己的游戏中？就像体育类游戏中的联盟有时候也能够有效地用于即时策略游戏。

我认为成为一名优秀设计师的最好方法便是尝试玩一些糟糕的游戏，并搞清楚这些游戏为何如此糟糕。也就是明确了一些失败的功能后你便能够在创造自己的游戏时避开它们。

当然了，你的研究并不能只局限于游戏中。

步骤3：头脑风暴

头脑风暴是一种创意会议，在此一些个人或群组将尝试着去解决任何问题。基于我们在第二个步骤中所完成的研究，你便已经做好解决问题的准备了。

步骤4：提炼

你将在头脑风暴后面临多个可能的追求方向。你最好能够挪出足够的时间去思考这些方向；然后再次回到可能的想法中。在头脑风暴中，你不能够排斥任何想法，但是在提炼步骤中你却能够这么做。

能够删除的一些理念：

*不符合所选择的范围

*难以实现的

*并不适合你的研究项目

*不能满足设计目的

*与项目中的其它设计相矛盾

步骤5：写下最好的方法

现在打开文字处理器去记录这些内容。你已经在第二步骤接触了大量的研究并在第三步骤中掌握了许多理念；所以你便能够较轻松地记录下所有的内容。但是在此之前，你需要搞清楚你的文件真正面对的是哪些人！

如果你面对的是程序员（可能你自己也是程序员），他们将会把你的文字转变成逻辑代码。如果你的文件内容越接近他们的理解，他们就能够越轻松地基于系统进行编码。一般来讲，这就像是一种等级式列表：

·玩家可以选择种族（如种族列表文件）。

如果玩家选择精灵，速度+2。

如果玩家选择小矮人，力量+2。

如果玩家选择奶牛，牛叫声+2。

·然后玩家要选择职业（参照职业列表文件）。

如果玩家选择牧师，一开始的技能是治疗（参照技能文件）

如果玩家选择骑士，一开始的技能是侵袭。但是他/她便不能在之后选择其它邪恶的角色。

如果玩家选择批评家，一开始的技能是骚扰。但是他/她便不能在之后选择其他善良的角色。

当然了，这只是一种泛化格式。程序员的类型也多种多样，所以他们也会选择自己所喜欢的类型，我只是觉得这种格式蛮有帮助的。如果你仍不确定的话，就直接问程序员他们想要看到何种内容。但是你会发现他们只会含糊地说“一些较短且容易理解的内容。”而没有人会说“请给我30页详细内容吧！”

保持简洁。是否记得我曾经说过保持设计文件的即时更新？而怎么做才能最轻松地进行更新：是使用简短的分点描述还是大篇幅的文本表达？你需要不断地问自己：我要如何做才能保持文件的清晰与简洁？

参考

就像我在上述例子中提到的“种族列表文件”便是一种参考，并且能够帮助你有效地压缩文件规模。如果你发现自己在多个设计中多次复制并粘贴同种信息，你就需要考虑是否将这些信息区分到不同参考内容中并添加超链接。就像在上述例子中，我本来可以清晰地列出了所有种族，设计以及它们在角色创造设计中的属性和定位，但是这些内容在此并不重要。

附件

我们是否需要在文件中包含一些背景信息？Jesse Schell（游戏邦注：Schell Games首席执行官和创意总监）在《全景探秘游戏设计艺术》（The Art of Game Design）中说道游戏文件能够弥补人类知识的薄弱环节。但是因为考虑到程序员不会使用背景信息去规划功能的创造，所以我们便不打算将其添加到设计文件中。因此我们将所有补充信息以脚注或“FAQ”文件链接的形式附加在文件中。附件对于简洁性没有太大的限制。你应该将任何你能够想到的内容（游戏邦注：例如设计战，做出选择的原因，不具有太多信息内容的草图等）添加到附录中。如果你觉得难以保持设计文件的精简性，那就可以在这个版块中放宽限制，在其中添加必要的内容。

步骤6：编辑并考虑边缘情况

此时你已经写下了一些最显著的功能理念并将所有理念压缩到一个逻辑列表中。很好！接下来你需要做的是将设计文件发送给其他将执行这些功能的设计师以及同事。询问他们：这些内容是否足够清晰？是否存在错误？问题出现在哪里？

边缘情况是指出现在特殊条件下的问题。当其他人在评价你的文件的同时，你也需要努力寻找自己文件中的边缘情况。并尝试着在特殊条件下测试文件。

举个例子来说：

“玩家能够跳跃的高度等同于他自身的重量除以背包中道具的重量。”

听起来是合理的。但是如果玩家背包中的道具重量为0情况又是怎样？18除以0也就意味着我们根本不能获得玩家所跳跃的明确高度！

还有另外一个例子：

“玩家可以将道具放在‘背包’里，而里面共设有20个储存空间。”

而如果玩家将背包放到另一个背包中又是什么情况？或者玩家将第21个道具放到背包中是什么情况？又或者如果玩家只想将背包卖出去那么包里的所有道具又该何去何从？这些都是我们应该努力去解答的问题。而因为这种包中包问题相对棘手，所以它便是一种边缘情况。

有时候我们很难明确游戏中的边缘情况，至少是比我所列出的例子难。而明确边缘情况的最简单方法则是面向你的玩家进行特殊的测试。思考玩家如果一无所有会是何种情况？玩家如果拥有所有东西又是何种情况？如果大多数玩家都前往同一个区域会怎样？如果玩家重复同一个操作2万次会怎样？在这一设计中玩家会采取哪种最不符合逻辑的方法去使用这些功能？

游戏邦注：原文发表于2011年7月19日，所涉事件和数据均以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Game Design Documents

By Zack Hiwiller

Posted July 19th, 2011

Oh, the Game Design Document! It is one of the most useful tools in a designer’s toolbox for communication, but also one of the most misunderstood. Nearly every professional designer deals with game design documents (or GDDs). But what are they? Why are they so ubiquitous?

When a game development team is only three people (say a designer, artist and programmer), the team only has three channels of communication they need to keep open: designer-artist, designer-programmer and artist-programmer.

Figure 4.1 – Three Members and Three Communication Channels

But add just one more programmer and the number of lines of communication jumps from four to six:

Figure 4.2 – Add One Member and Communication Lines Double

Professional game development can be a mammoth undertaking with team sizes that can top well over one hundred people. If everyone on a team of one hundred had to connect with every other team member, it would require four thousand, nine hundred and fifty connections. World of Warcraft is estimated to have over a hundred and forty people on the team.[1] If this is true, there are 9,730 connections between the team members that would need to be maintained if every team member needed to directly talk with each other.[2]

This is too unwieldy. Real-world teams are not structured where every team member needs access to every other team member. Instead, larger teams are subdivided into groups by either discipline or project area. For instance, the artists may all talk to each other but route their communication with other disciplines through a producer. Or all of the team members working on the multiplayer portion work together while the single player teammates only communicate with their own.

This causes another problem: instead of team members being able to directly communicate with each other freely, communication has to be routed through gatekeepers such as producers or leads. If you ever played the childhood game Telephone, you know how multiple rebroadcasts can add noise to a channel:

Figure 4.3 – The Telephone Game

A fluid and, at times, highly vague concept like a game design can’t be faithfully communicated in such a manner. Teams devise artifacts that can be digitally replicated to eliminate the signal loss of the “telephone” method above. The game design document (or documents) is a tool to solve this problem.

A game design document is any method of documentation that gives instructions for building a game or feature. It is important to note that from team to team and studio to studio, game design documents can take wildly different forms and be constructed from wildly different methods. There are also common misconceptions about the form and purpose of a game design document.

Common Misconception #1: The Game Design Document is a repository of all information about a game or feature.

Game design documents are there to serve a primary purpose: to inform team members as to what they are to build. To this end, there are a number of stakeholders:

Programmers. Because they need to build the thing.

Artists. Because they need context to know what they are creating.

Producers. Because they need to be able to gauge how long a feature will take.

QA. Because they need to know what a feature looks like when it is working.

Other designers. Because their systems need to work with the feature.

Licensors. Because they need to ok use of their intellectual property.

To look like they are producing a lot of content, many designers fill a GDD with explanations of all of influences behind a system, backstory, design discussions or other ephemera. Here’s the rule of thumb: Unless it directly instructs a programmer or artist what exactly to make, leave it out of the GDD proper. You may relegate it to an appendix (see below) or to another document.

In some cases, it is necessary to keep a second pseudo-GDD. In cases where you have external licensors or overly involved executives, they will want to get their hands in what the team is making. In these cases, the GDD will likely be too technical for what they need. For these situations, “Design Overviews” or “Executive Summaries” are sometimes useful and are covered at the end of Part Four.

Common Misconception #2: The word in the GDD is law.

Aspiring designers who are just entering the field often hold this misconception. Game design is an iterative process: it requires experimentation and often-copious trial-and-error. Yet many game design documents are written and attitudes are hardened as if the game design document will never change. In the worst-case scenarios, programmers will print out the GDDs and build from a static conception of what the feature is.

The GDD is the formulation of an idea at a given time. The GDD’s function is to foster communication throughout a team, not to be a dictate.

Often I have heard from programmers that they don’t read game design documents. We will get into the cardinal sins that cause this attitude below but one of the reasons for this attitude is that GDDs are not kept up-to-date. If a programmer reads a GDD and then is told to make something contrary to what he or she read, she will wait to be told in the future instead of trusting that what the GDDs say. It is the designer’s job to keep documents as up-to-date as possible, no matter how tedious a job that may be.

Remember the purpose of the GDD: Unless you personally want to communicate a change in design to every member of the team, you must keep the GDD aligned to the most current design.

Common Misconception #3: There is a template to how studios create design documentation.

Often students will ask to see sample design documentation. I will show some made-up examples later in this book. Why I am hesitant to show anything at all is that every studio has its own documentation processes. The purpose of a student asking me for a sample is to copy formatting. The formatting is the least important part!

The design documentation is written specific to a particular audience. Blizzard’s design documentation for MMOs on hundred person teams is going to look quite different from Quantic Dream’s narrative-heavy design process. Who are your programmers? What do they know implicitly[3]? You are going to write your documentation for a particular audience.

Some studios do, in fact, have massive templates for game design documentation. This can be a useful practice if there are needed sections that are commonly left out. The danger with templates, however, is that they are not updated as the team and the project change and are thus prone to overloading documentation with wasteful, empty categories. Empty sections that have to be scrolled through make it more difficult for programmers and other stakeholders to find the information they need. That is anathema to having formal game design documentation at all. Given all the other things you have to deal with when writing your design document, keep clarity as the most important goal.

GDD Creation Process

Now we will go through an example together of creating a short, concise design document. Assume we are on a small team putting together a Fantasy RPG for Facebook. The lead designer comes to you and says you need to design a crafting system for the game. How would you go about creating the documentation?

Step One – Determine Purpose, Desired Scope, Locate Connected Systems

Designers usually have lead designers or creative directors above them. From one of these folks, you must clearly determine the goals of the designs. You must find out: the purpose of the design, the scope of the design and the systems that will necessarily connect with the design.

The purpose of the design: Without knowing the purpose of the system, all you can do is copy a similar crafting system from another game. Your lead designer says: “We need a system to use the items that players receive via gifts from other players. We want it to encourage creativity and social connections.” That is a start. Interview. Ask probing questions. Really understand the motivations behind the assignment before you begin writing or prototyping.

The scope of the design: Designers have an awful tendency to over-design. What this means is that given an assignment, designers will come up with nuanced, complex systems. In isolation this is not a problem. But in aggregate, no project can sustain complexity in every system and still expect to ship on time and be understood by users. Great designers know which systems benefit from complexity and which benefit from simplicity. By identifying the scope of the feature, designers get an idea as to the depth of the system to create.

Possible Scope Levels of a Design:

Present(Level 4)

The design is as bare bones as it can be while still satisfying the purpose of the design.

Example:Driving in Alan Wake

Market-Standard(Level 3)

The design is at the level that is expected from other titles in the market.

Example:Multiplayer Ranking in Uncharted 2

Market-Leading(Level 2)

The design is at the level of the top example of other titles of the market.

Example:Cover in Gears of War

Innovative(Level 1)

The design is beyond the level of other titles in the market and is something that has never been tried before.

Example:Creature Creator in Spore

In our example, the lead designer says: “We have a lot of art time for this, so you can make it broad, but the entire game is pretty casual so keep the complexity low.” In this instance, I would probably choose to go with the “Market Standard” complexity. We will deal with the implications of this choice below.

The systems that will connect: Clearly, from the original proposal, this system will be interacting with the gifting system. In addition there may be an inventory system. Perhaps you will make salable items? What designer is in charge of the economy so you don’t flood your game’s market with free goods? Who do you need to contact?

Assure that none of these statements are contradictory. For instance, if the purpose of the design is to have a fully customizable character generator while the scope of the design is to be simple, then you will need to meet with your lead designer to find out what must give.

Step Two: Research

The scope level you come to in the previous step will help you to decide how much and what type of research you need to do. Having a wide breadth of exposure to other titles in the industry helps here. I remember working in a studio that only produced one genre of game. Many of the designers there never played games from other genres! How will you know about features that may eventually creep into your genre without exposure? What is going on in matchmaking for leagues in sports games may become relevant for real-time-strategy games.

I have often said that the best examples for growth in being a designer is to play bad games and endeavor to understand why they are bad. By identifying features that were unsuccessful, you can design around the pitfalls and mistakes of your industry brethren.

Of course, your research is not just limited to games.

Research Techniques Based On Scope

Present(Level 4)

Play games that implement similar features and try to find what is common between all of them. Can anything else be taken away while still preserving the purpose of the feature? This requires design by subtraction.

Market-Standard(Level 3)

Play games that implement similar features. Which are the worst implementations? What can we do to avoid their pitfalls?

Market-Leading(Level 2)

Play games that implement similar features. Which are the best implementations? Why are they the best? How can we adapt their system to our game’s requirements?

Innovative(Level 1)

Since, by definition, you are attempting to create something that has never been done before, you cannot take features from other games and apply them to yours. However, you do still need to know the best practices for that feature to determine whether yours exceeds the quality of the market leader.This step requires influences from beyond the world of games. You do read outside your design work, correct? From what fiction and nonfiction can you pull inspiration? From what non-game interactive systems (ATMs, Toys, Events) can you draw inspiration? Be thorough.

Step Three: Brainstorm

We are going to discuss brainstorming and its uses in a later chapter in depth. A brainstorm is a creative meeting where an individual or a group tries to create a quantity of solutions to a problem. Based on the research you completed in Step Two, you should be well equipped to envision a number of possible solutions. See the Idea Generation chapter for the how-to of using this technique.

Step Four: Reduction

You will have a lot of possible directions to pursue after your brainstorming. It is best to sleep on them to have adequate time to think them over. When this is done, come back to the list of possible ideas. In Brainstorming, you don’t discriminate against ideas. In the Reduction step, discrimination is all you do.

Eliminate ideas that are:

Not in line with the chosen scope

Impossible to create

Not effective in researched titles

Don’t meet the purpose of the design

Conflicts with another design in the project

Step Five: Write the Best Method Down

Now fire up a word processor and get this idea down on (digital) paper. You’ve been exposed to a large amount of research in Step Two and a large amount of ideas in Step Three. It would be easy to put your voluminous knowledge down to paper. Stop!

Remember your audience.

If you are writing for programmers (and it is likely that you are), remember that programmers will change your words into logical code. The closer the form your document is to how they think, the easier it will be for them to translate it into code that works for their system. Generally, they will like hierarchically formatted lists like:

Player chooses a race (See RaceList.doc).

If player chooses elf, +2 speed.

If player chooses dwarf, + 2 strength.

If player chooses cow, +2 mooing.

Player then chooses a class (See ClassList.doc).

If player chooses priest, starting skill is heal (see Skills.doc)

If player chooses paladin, starting skill is smite. If player chooses paladin, he/she cannot choose evil alignment later.

If player chooses critic, starting skill is annoy. If player chooses critic, he/she cannot choose good alignment later.

This, of course, is a generalization. There are many types of programmers and each like different styles, but I have found it to be helpful. When in doubt, ask the programmers what they like to see. They are just as afraid of you as you are of them. Generally they will tell you, “Something short and easy to read.” No one has ever said “Something thirty pages long with lots of details.”

Err on the side of brevity. Remember how I have told you that it is your duty to keep the design documents up-to-date? Which do you think is easier to update: short hierarchical bulleted-lists or vast walls of text? Always ask yourself: what can I do to make this document clearer and shorter?

References

Did you see the “See RaceList.doc” mentions in the above example? Those are references and are the most helpful technique to keep your document size small. If you find yourself copy and pasting information into multiple designs, consider separating that information out into a reference and add a hyperlink. In the above example, I could have spelled out all the races, their designs, attributes and locations in the character creation design, but is it relevant?

Appendices

What if there is some background information that is necessary or helpful to include? We don’t just throw that out, right? Absolutely not. Jesse Schell points out in The Art of Game Design that game documentation is a cure for the frailty of human knowledge. But since the programmers won’t be using that background information in scheming up how to create the feature, we don’t want it cluttering up the design document proper. Therefore, all the “bonus” material should be put at the end of the document in a footnote section or in a linked “FAQ” document. Here you have little restrictions on brevity. Anything that needs to be remembered (design battles, reasoning for certain choices, sketches that aren’t particularly informative, etc.) can be added to the appendix section/document. If you find it painful to be brief in the design document, you can let loose in this section.

Step Six: Edit and Find Edge Cases

You’ve written down the most salient feature idea and condensed that idea down to a logical list form. Great! Now there are two things you must do and it helps to do them simultaneously. Send the design out to your fellow designers and folks implementing the feature. Ask them: is this clear? Are there mistakes? Where does it break down?

An edge case is a problem that occurs only under extreme conditions. While others are reviewing your documentation, try to find edge cases in your own design. Test the extremes to see if it breaks down.

For instance, here’s a simple design:

“The player’s jumping height is equal to his strength divided by the weight of items in his/her backpack.”

Sounds reasonable. What if the weight of items in his/her backpack is zero? 18/0 means the player can jump an undefined height!

Here’s another:

“Players can put items in the “bag” item, which has twenty storage slots.”

Neat. What happens if a player puts a bag in a bag? What happens when a player tries to put a 21st item in a bag? What happens to the in-bag items when the player tries to sell the bag itself? These are all questions that will need to be answered. Since the bag-in-a-bag question is a little awkward, it would be an edge case. The others should have been thought out in the draft.

It is difficult to identify edge cases sometimes, at least more difficult than my simple examples above. The easiest way to check for edge cases is to make extreme examples of your players. What if a player has zero of something? What if he has everything? What if the maximum number of players all tried to stand on the same spot? What if a player did this action 20,000 times? What is the most illogical way the player could access the features in this design?(source:hiwiller)