作者：Kevin

“设计”文稿多种多样。如何撰写，包含什么细节，放置多少信息完全取决于文稿的阅读对象。就我来说，我不喜欢使用大量文稿。通常关于项目宗旨的简短备注就足以让我们瞄准正确方向。文稿若应用得当作用显著，但这完全取决于既定情境。

Design Document from shullogames.com

团队所需信息

由于我是以独立开发者身份开发我的前两款作品，因此我的设计文稿几乎就是一堆潦草的稿纸，以及1-2个于电脑编写的页面程序。这不过是帮我跟进游戏构思、条理清晰的备注。我曾担任过大公司的设计师，当时我是7-12团队的一员。你也许会认为文稿在团队合作中起着更重要的作用，但其实我们所用的文稿并不多。在项目开始前，我们会先设计所谓的游戏“话题”，细述项目宗旨、主要机制、主要功能和卖点，这也用来同其他既有产品进行比较。制作文稿还是为了说服制作人产品有利可图，从而顺利启动项目。这是整个开发过程中最主要的文稿。

这家公司有许多设计师，他们所写的文稿各不相同。但他们都主要参考“模型”。在我印象中，目前并没有任何涵盖所有项目细节的权威书籍。若我们对项目方向有所怀疑，有文稿可以参考，然后我们就可以制作大量Flash游戏和所期望的图像（游戏邦注：Gif动画很受欢迎）。我们所写的文稿非常简短（没超过5页），只是描述有待进一步商讨的琐碎、分歧内容。没有人阅读这些内容。若文稿旨在解释某游戏机制，程序员会转向影片和图像，或查看实际模型。若无法立即弄清楚，他们会让设计师做进一步解释。但文稿并不是完全没有用处。虽然没有人阅读这些内容，但它们依然能够促使设计师进行深入思考，更深刻、系统地把握游戏机制，轻松进行自信和清晰陈述。

设计工作在开发中常常发生变化，在项目开始前书写大量文稿细述项目内容非常费时。我们无法准确“想象”游戏会如何进行，只有等到自己亲身试验，所以你如何会知晓哪些内容行得通，哪些内容行不通？

那么我们该怎么做？

若你是独立开发者，你需要的是大量备注信息，协助你追踪进度，把握前进方向，以及简要但明确描述项目焦点。焦点陈述就是描述预期内容及预期风格的几段文字，这是确保你瞄准正确方向的强大工具。你可以不时浏览这些内容，重温制作此项目的初衷。文字内容也许会在开发过程中发生改变，但你需要牢牢把握项目宗旨。剩余的备注不外乎关于选择方案、游戏机制草图和数据、数据结构、屏幕信息的基本呈现方式及角色外观等（就我的文稿而言）。

建模是关键！

是的，这是把金钥匙。将想到的创意写在纸上是个好方法，但细述行为、外观和幕后故事的冗长文稿用处不大，如果这么做，游戏就会变得毫无趣味。此外，书面文稿还可能被团队成员误解，而实际模型和原型则能够直接测试构思，令大家快速、轻松地理解相关内容。这样你就能够发现主要问题，团队成员就能在创建内容前提出建设性的批评意见，从而完善构思，节约开发时间。

何时设计文稿作用最大？

我觉得文稿在组织数据方面作用突出，例如，当你需要书写故事，记录事件如何连接或对话内容，及罗列游戏武器的时候。若你的设计内容很多（不同于用户创造或程序内容），文稿能够帮你把握整体内容。文稿在充当“任务列表”方面作用突出。当我们需要记录、缩短和编辑游戏口语对话时，我们会在excel表格中使用色标追踪工作进度（游戏邦注：在各行文字中，标注红色表示已记录，标注黄色表示已缩短，绿色代表已植入游戏中。这样制作人就能够快速浏览，迅速估算剩余工作任务）。

在所有这些情况中，文稿都起着非常重要的作用。但你无需通过文稿说明角色如何移动或跳跃。借助模型或模拟动画会更好。记住完成任务过程中，所要阅读的内容越少，成员越是高兴。

总结

对我而言，设计文稿更像是工具，而不是计划。它们在追踪数据和组织想法方面作用显著，但在开发工作开始后，它们就无法说明游戏如何运作。所以我通常是一开始先书写几页有关原始构思的文稿，然后基于模型进行测试，若我就此感到满意，就罗列系列“任务列表”，组织文稿内容，确保我没有遗忘任何信息。除非你得说服他人加入或投资你的项目，否则任何其他文稿都是徒劳。

游戏邦注：原文发布于2009年4月19日，文章叙述内容以当时为背景。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

When do you need a game design document?

By Kevin

There is different kind of “design” documents. How you write it, which details and how much informations you put into it really depends on who it is adressed to. Personally I don’t like using a lot of documentation. Often short notes on your intentions are enough to get you started in the right direction. Documents can be useful when used well but it really depends on the given situation.

What’s necessary for the team

Since I’ve been working alone on my two first games as an independent game developer, my design documents mostly look like a pile of paper with scribbles and a one or two pagers written on the computer. Really just some notes to keep track of my ideas and put a bit of structure in it. I’ve also worked as a designer for a big company in which I was part of teams of 7 to 12 peoples. You might think that the documents are more important when working with a team, but we did not work so much with docs. Before the project started we initially developped what we called a “pitch” for the game, detailing the intentions of the project, the main mechanics, the main features and selling points and was also used to compare other existing products. This document was aimed to get the project started by convincing lead producers that it would be profitable. This was the biggest document written during development.

There were a dozen designers in this company and most of them wrote their designs differently. However, all of them relied heavily on “mock-ups”. I don’t remember seeing any huge bible describing all the details of a project. The pitch was there if we ever doubted the direction and then we mostly did a bunch of Flash demos, still images or animated gifs depicting what we wanted (yes, the animated gifs were very popular). When we DID write documents, they were short (never more than 5 pages) and detailing only small, ambiguous parts of the project that needed more thought. And nobody read them. If it was explaining a game mechanic, the programmers would jump to the pictures and graphs or look at the mock-up. If they could not figure it out instantly they would come to the designers for explanations. The documents were not totally useless though. Even if nobody read them, they still allowed the designers to deepen their reflexion and have a better, more structured vision of the mechanics, making them easier to explain with confidence and clarity.

The design changed so often during development that writing a huge design document detailing the project in it’s entirety before the project started would have been a tremendous waste of precious time. It’s impossible to accurately “imagine” how the game will play until you’ve tried it yourself, so how could you know what would work and what would not?

So what should we do??

If you work alone, all you need is a pile of notes to keep track of where you are, where you’re going and a short but strong description of your focus. The focus statement, a few paragraphs about what you want and how you want it to feel like, is a strong tool to keep you on track. You can come back to it once in a while to take you back to the initial spark of interest that triggered the project. It might change during development but you should still keep that initial spark somewhere handy. The rest of the notes (mine anyway) really are just random schemas, sketches and datas about the mechanics of the game, the structure of the data, the basic display of informations in the screen, the look of the characters, etc.. Here is the main “design document” I’ve used before starting HyperSpace Shooter. I have a few other pages of notes but the single page you see here is the initial spark. Note that almost nothing from these notes made it into the game (mostly because it was too ambitious for the time constraint).

Prototyping is the key!

Yes, this is the golden key. It’s good to pin down your ideas on paper as they come, but writing long and detailed documentations about behaviors, look and backstory will prove useless if, once done, the game is uninteresting. (As an example, building a prototype allowed me test and redirect my focus for HyperSpace Shooter.) Also, written documentation always bear the risk of being wrongly interpreted by the various team members while mock-ups and prototypes allow direct testing of the ideas, making them quick to assimilate and easy to understand. With it you can easily find the most important problems and team members are able to make constructive criticism before anything is built, thus improving on the ideas and saving development time.

When is a design document really useful?

I found that documents have a lot of value to structure datas. For example, when you need to write the story, keep track of how the events are linked together or what are the dialogs, make a list of the available weapons in the game, etc.. If you have a lot of designed content (as opposed to user created or procedural content) it allows you to have a whole view of it. Documents are also very useful as a “to do” list. When we had to record, cut and edit spoken dialogs of a game I worked on, we applied color codes to the excel sheet to keep track of the work (for every line of text, we marked them as red when they were recorded, yellow for cut and green once integrated in the game. The producer could take a quick look at it and estimate the remaining work load in seconds).

In all these cases, and many more, documents are invaluable tools. But you don’t need no stinking document to explain how the character moves or jump. You are waaaay better off with a prototype or mocked-up animation. Remember that when people are asked to perform a task, the less they have to read, the more they’re happy.

Conclusion

To me, design documents are more like a tool than a plan. They are invaluable to keep track of datas and structure ideas but as soon as development starts, they are useless in explaining how the game works. So my own way of working is to start by writing a few pages about my initial ideas, work on a prototype to test them and, once I’m happy with the direction, write a few “to do” lists and structure documents to make sure I’m not forgetting anything. Unless you need to convince someone to join in or invest in your project, any other documentation is futile. （Source：gamesandmen）