如何编写一份最有效的游戏设计文件

Admin

作者：Ella Romanos

最近我阅读了来自Jagex的James Sweatman的一篇优秀的文章《Death of the game design document》，这让我开始思考自己的游戏设计文件经验以及我是如何处理它们的。

我非常同意James所说的，即这非常符合我自己的经验以及我们最终所编写的文件类型。经过几年的时间我们创造了编写自己的文件的过程，这同时也是一个不断发展与完善的过程，并提供给我们一个可遵循的标准模式。

game design document(from tuicool)

James清楚地解释了传统游戏设计文件未能发挥作用，所以我并不打算在此详细说明，但总的来说，传统游戏设计文件的问题在于它们尝试着去解释游戏的每一个细节。我们都知道这几乎是不可能做到的事，因为这需要花费许多时间去更新内容，并且因为太过死板而难以支持一个创造性且迭代的开发过程。

我将在此讨论的是为何你需要使用一个更加与时俱进的游戏设计文件；就像James所提到的，这样的文件具有实用性，非常清楚且具有协同性。

这一过程与我和Martin Darby在年初于Develop大会上所讨论的用户体验设计过程具有密切的联系。

我认为拥有的游戏设计文件（GDD）必须具备三个要素：

1.定义你的游戏目标，即你希望玩家所拥有的体验。实际上，这意味着你的GDD应该规划出游戏的整体流程以及用户该做些什么。你不需要规划的内容是一些较小的细节。只要你知道自己想要实现怎样的目标以及游戏中的每个元素和功能是什么，你便能够在之后罗列出细节，而无需遭遇功能变化或违背游戏流程或目标的风险。

2.任何阅读你的GDD的人都应该能够快速且轻松地理解游戏是关于什么以及用户该做些什么。

3.你应该创造一份拥有足够可以完善，调整甚至是改变细节的空间，而无需重写整份文件，改变用户流程或整个游戏目标。

游戏概述

这就像是你心目中的概念文件或产品介绍书。大概有2页内容，其中应该包含执行概要，简短的介绍，关于背景的简要说明，以及最重要的关键功能的项目符号列表。我经常会包含一些设计核心，并使用图像帮助解释。

核心的游戏描述

这一部分是基于游戏的核心循环图，即呈现了游戏的关键功能以及用户经历它们的流程。

遵循这样的图表，你将获得一份说明书能够解释每个核心循环功能以及它们的作用。每一个描述只需要不到半页纸的内容。你还应该包含进一步的循环图表去分解每一个元素，因为这能比任何文本更清楚地解释你的理念。

在这一部分包含游戏画面模型很有用，因为这让人们能够想象出玩家将会看到什么以及如何在游戏中进行互动。

游戏元素

这一部分将进一步解释游戏的重要功能，在这里你将开始添加更多细节。

你可能需要包含一些表格去分解功能并解释游戏模式，进程，控制，盈利，可更新内容，社交功能，游戏世界，菜单页面流程图表以及任何未被作为重要功能的次要功能等等元素。

在这里，如果你是致力于创造最小可行产品的话，你便可以忽视其中的某些元素，但是你也可以添加人们所期待的功能，或者在游戏发行后再进行添加。

这一部分更像是传统的GDD，一开始较为简单，然后会随着开发过程而不断扩展。在创造性过程中，我们将会看到这一部分的改变，并且这样的改变是合理的。我们必须清楚，游戏概述和核心游戏描述部分应该始终保持不断，因为这里的改变将会从根本上改变你的游戏设计，所以你需要在做出改变前进行更慎重的考虑。你可能不想提供给这个第三部分额外的利益相关者；这一部分更适合内部使用，因为它准确解释了如何创造游戏。

结论

我们通过这种方式分解设计文件是为了是扩展之前的每一部分。任何阅读文件的人都能够快速且轻松地理解内容，随后才会沉浸于一些详细的信息中。当你进一步阅读文件时，你便能够获得更加详细的信息，因此你能够在开发过程中轻松地扩展文件，既不会失去它的易读性，同时也不会迷失整体目标和用户流程。

一份GDD必须使你确保自己能够实现之前所设定的目标，即用户能够获得你希望带给他们的体验。

为了做到这点，你并不需要直接呈现每一个细节，你需要清楚游戏是从哪里开始，并能够引导用户去实现目标。你需要清楚自己能够通过游戏去调动用户的兴趣，并且你也能够面向内部和外部利益相关者去宣传游戏。基于这种自上而下的方式定义游戏将帮助你做到这点，并且你还可以摆脱累赘的文件的束缚。专注于你尝试着实现的目标而不是在所有小细节中迷失方向才是关键。

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

How to write a useful game design documentHow to write a useful game design document

By Ella Romanos

I recently read James Sweatman from Jagex’s great article ‘Death of the game design document’ and this got me thinking about my experience of game design documents, and how I approach them.

I agree largely with what James has said, it fits with my experience and type of documentation we ended up writing. Over the years we have developed a process for writing our documents, which whilst it is an ever evolving and improving process, has given us a standard format to work from.

James explained very clearly that traditional game design documents don’t work, so I’m not going to go over that in detail, but to summarise, the problem with traditional game design documents is that they try to explain every detail of the game. We all know that this is nearly impossible upfront, simply because they then take a lot of time to keep updated and are too rigid to support a creative and iterative development process.

What I’m going to talk about is how I think you can adopt a more up to date game design document; a document that is both useful and practical, and as James suggested, is light early on, visual heavy and collaborative.

This process very much relates to the user experience design process that myself and Martin Darby spoke about during our talk at the Develop conference earlier this year, and which I published on my blog recently.

I believe the key to a useful game design document is three fold:

1. Define your goals for the game, and the experience that you want people to have. In practice this means that your GDD should map out the overall flow of the game and what the user can do. What you don’t need to map out, at least initially, are all the little details of that. As long as you know what you are trying to achieve and how each element and feature fits within the game, you can map out the detail later without too much risk of feature creep, or losing the flow or goals of the game.

2. Someone reading your GDD should very quickly and easily be able to understand what the game is about, and what the user has to do.

3. Have a document where there is enough room for those details to be refined, tweaked and even changed if necessary, without being forced to rewrite the entire document, change the user flow or overall goals of the game.

On that basis, the first iteration of your GDD should include the following:

Game overview

This should be what you often think of as a concept document or sellsheet. Around 2 pages, it should include the executive summary, a short synopsis, potentially a very short description of the back-story and most importantly a bullet point list of key features. I often include design pillars and always use a lot of images that help explain your points.

Core game description

This section is framed by a core game loop diagram, which shows the key features of the game and the flow that users go through them. (I covered how to define key features and create game loop diagrams in a previous article.)

Following the diagram, you should have a description explaining each of those core loop features and what they do. These need only be a short description using no more than half a page for each. You should probably include further loop diagrams breaking down each element because these explain your ideas much more clearly than any text can.

It’s often useful in this section to include a game screen mockup because this allows people to picture the viewpoint and how the player will see and interact within the game.

Game elements

This is a section that further explains the key features, and this is where you will start to add more detail.

You will probably include tables to break down features and will explain other elements such as game modes, progression, controls, monetization, updateable content, social features, the game world, diagrams of the menu screen flow, and any secondary features that weren’t defined as key features.

Some elements in here may be ones that are not definitely to be included if you are working towards a Minimum Viable Product, but you can include features that are desired, or may be added post-release.

This section is much more like a traditional GDD, it’s initially quite light, then expanded and edited as you go through development. Changes within this section are expected throughout the creative process and are healthy. It’s important to note that the game overview and core game description sections should remain largely untouched once defined, changes here are fundamental changes to your game design and require much more serious consideration before being altered. You may not want to give this third section to external stakeholders; this section is more useful for internal use, because it explains exactly how to make the game.

CONCLUSION

Essentially what we are doing by splitting the design document up in this fashion is expanding each section from the previous one. Anyone reading the document can then easily understand the game very quickly, before getting inundated with detailed information. The further into the document you read, the more detailed information becomes and therefore you can easily expand the document as you go through development, without losing its readability and also without losing track of your overall goals and user flow.

A GDD should be there to keep you on track, to make sure that you achieve the goals you set out to achieve, and that users get the experience you set out to give them.

To do that you don’t need every little detail immediately, you need to know where the game starts and the flow users go through to get to their goal. You need to know that you can excite users about the game to be able to market it, as well as being able to pitch it to internal and external stakeholders. Defining the game in this top down way will allow you to do this, without stifling you with cumbersome documentation. Focusing on what you are trying to achieve, rather than getting lost in all the little details of how you are going to achieve it is the key.(source:develop-online)