作者：Mike Birkhead

在过去6年的时间里，我共参与5款游戏的开发。在此期间，我编写过无数的word文件，建立过无数的excel文件、模型关卡和代码文件，甚至还绘制过一些地图。

尽管我乐于谈论游戏设计中的抽象概念，但是我觉得并没有很多人知道系统设计师的生活究竟如何。对系统设计师而言，其真正的工作是编写文件。

我是个坚持编写文件的人，不仅仅是编写文件，而是编写能够发挥作用的文件。我乐在其中，而且做得越来越好。我不看好那些无法清晰组织文件的设计师。

简单地说，这就是我的所做所想。团队越大，有效组织文件就变得愈发重要，我也时常想知道其他人怎么做。我的风格是以同我工作过的设计师的优秀想法为基础来构建文件，而这些同我工作过的设计师采用的也是这种方法。

近期，AltDevBlog上发表了大量优秀的文章，对还在学校中或刚刚开始从事工作的设计师不无裨益，这让我略有所思。我想要将自己的做法与他人分享，这样他们也能够有所成长。我也希望其他人也能说说他们的做法，这样我也能够得到提高。但是，要如何实现这个目标呢？我觉得只有从头开始设计一款游戏方能将这些内容阐述清楚。

writing(from listverse.com)

Game: the Verbing Noun

过去三周来，我利用自己的业余时间编写某款虚构游戏的文件。以下是我所编写的内容：

什么是Game: the Verbing Noun？

”Game: the Verbing Noun“是某个设置在（某著名场景）中的单人动作冒险游戏。游戏核心的动作部分来源于（某款动作游戏），将其与（其他动作游戏）中的风格相结合，再利用热门游戏的宣传手法。所有这些内容构建成有着世界级艺术和技术的既野蛮又漂亮的游戏。

阐述过这些内容之后，我便可以为你提供某个链接，让你自己看看我所编写的文件。这似乎看起来很不错，但我不想做这种马虎的事情。我想先解释下这些基本内容，然后再提供文件的链接。

首先，让我先声明下，这并非完整性文件。我尽自己全力将内容表述清楚，我也只能做到这么多了。这份文件中有三个内容：概念文件、内容表格和关于Thrall的信息。

概念设计文件

许多人将此称为“游戏设计文件”或简称为GDD。但是，我的说法是“概念设计文件”，因为这份文件的内容并不完整。这种文件罗列出了整个游戏的框架。如果你从头到尾阅读了整个CDD，那么你应该就对游戏的概念有很深的理解。

我的想法是，文件越详尽，其中所包含的信息就应该越具体。我开始编写这份文件时发现很难做到，我多次重新编写。开始时游戏与Conan有关，场景在Hyboria，战斗中包含大量的武器。当我开始创造敌人时，我发现自己的想法无法同游戏风格相符，因而我回到前面更改内容。这种事情在文件编写中多次重复。

概念设计文件(from gamasutra)

你阅读完CDD后，应该对游戏中的四个元素有所了解：玩家、场景、其他角色和世界。玩家在游戏中能做什么，事情发生的地点，他能遇见何人，他如何到达那个地方，当他做某些事情时发生了什么。但是，如果想要更细节的信息，应该怎么办呢？

内容表格

我的风格的首个技巧便是与CDD主标题相配和内容表格（游戏邦注：包括其中的文件夹结构）。如果你已经阅读过CDD，那么你就知道整个游戏中的内容会如何组织起来。我尽全力展示拥有更多文件完成后的游戏面貌。

内容表格(from gamasutra)

关于Thrall的信息

文件越具体，我就更能够为目标用户量身打造游戏。就玩家所要面对的战斗对象Thrall而言，就有许多内容。他有着自己的身世，大量的动画描述、所需的特征以及配合音效。我甚至还为故事线路设计了ppt幻灯片。需要注意的是，当动画师寻找自己所需动画效果，Thrall的站姿对他来说才是有意义的信息。我们需要为文件使用者提供合适的信息。

其他事物中也采用了这种做法。但是诸如阐述Spawning的其他文件就不需要有如此深度。必须再次强调的是，你需要尝试站在阅读者的角度来思考。

HTML格式

除了我将在web上展示这些东西之外，还有其他原因让我采用HTML格式。我的文件撰写风格就是将大量小文件制成动态HTML格式。

那么那些Excel文件呢？首先，你或许会注意到，在某些页面中，有些文件有“Excel”字样。如果你点击这些内容，就会下载该页面信息的Excel文件。那么，如果都采用DHTML格式呢？这样，我或许可以完全不使用Excel。我确信web是有绝佳的方法！

这是原因之一，第二个原因是格式问题。信息呈现方式同信息本身同样重要。我时常觉得标题1并不清晰，而且你根本无法区分标题2和标题3。使用HTML和CSS后，我能让每个文件的呈现方式符合我的要求，而且保证每个文件都是如此。

总结

以下是文件的相关内容：

1、内容表格——链接至所有内容的链接页面

2、概念文件——统揽整个项目

3、Thrall——举例说明如何描述和记录角色。分为以下三部分：描述；动画；特征。

游戏是虚构的，但文件却是真实的。这便是我如何完成游戏文件编撰任务的示例：从大到小，从普遍到细节，从程序员到动画师，从Word文件到Excel文件。

休息一段时间后，我计划回去对文件进行修改并添加内容。我还需要添加如何平衡经济的内容，而且关卡设计方面都还未提到。

这便是我如何编写文件的方式，但你不一定要这么做。每个游戏都是不同的，而且每个游戏的题材也各不相同。我只是希望这种结构和某些想法能够对其他人有启发作用，我还希望能够有人指出其中的不足之处。只有这样，全世界的游戏设计师才能得到成长。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Opinion: How I Document A Game

Mike Birkhead

I have worked on five games in the past six years. I have written countless word documents, set up countless excel files, modeled levels, written code, and even drawn a few maps; but I cannot show you any of this.

This has been bothering me for a long time. Of all the things I set out to do when I started writing, my first and greatest goal was to get down and dirty. I was going to “keep it real”. Much as I love talking about abstract concepts like fun, play, and other great game design concepts, I felt there were not enough people really showing what the system designers life is like. The REAL work. You know, documentation.

I have always been a stickler for documentation. And not just documentation, but efficient documentation. I enjoy it, and I like doing it better and better each time.

I look down on designers that can’t organize their files cleanly, that can’t set up a list in Excel.

In short, I’m that guy. But dammit, it’s important! The larger the team gets, the more important it becomes to be efficiently organized, and I often wonder how others do it. My style is built up from the great ideas of the designers I have worked with, which I’m sure was built upon the great ideas from designers they worked with.

Lately there have been a lot of great posts on AltDevBlog talking to designers in school, or people first starting out, and it got me thinking. I wanted to share my style with others, so that they too can grow; and then hopefully others would talk about how they do things so that I can improve. But how? In exasperation I thought, “Well, gee. I’d have to design a whole game from scratch in order to talk about it.”

So that’s what I did.

Game: the Verbing Noun

For the past three weeks, I have spent my free time writing documentation for a fake game. I am now going to post the entire thing online. Some might call me crazy. Maybe I am.

So what is Game: the Verbing Noun?

{Game: the Verbing Noun} is a single player action adventure game set in {FamousSetting}. The game takes the visceral action of games such as {Some Action Game}, mixes it with style switching from games such as {Some Other Action Game}, and finishes it with {buzzword} from modern games such as {Popular Franchise}. All of this is mixed with both world class art and tech to create a game that is as brutal as it is beautiful.

Now, I could follow this with a link to the docs, and just unceremoniously dump you into the deep end, which is fairly tempting, but I would be remiss. I shall start by explaining some of the basics of what is there, and then, at the end, dump links all over your face (and maybe a surprise).

First let me state that this is not comprehensive, not in the slightest. I have written as much as my little wrists could handle, but there was only so much I could do. Of what made it, there are three major topics to cover: the concept document, the table of contents, and the many views of the Thrall.

Conceptual Design Document

Most people call this the “Game Design Document” or, more informally, the GDD. I call it the Concept Design Document, because mine are less all encompassing. It lays out the entire game in broad strokes. If you read the CDD from cover to cover, you should have a firm grasp of the concept (get it) of the game.

I follow the philosophy that the more specific the document, the more specific the information contained with it. I write this first, and it is hard. It gets rewritten like a million times. When I first started out, the game was basically about Conan, set in Hyboria, and the combat involved lots of weapons. When I went to create enemies, however, the ideas I had didn’t fit with that style of game, so I went back and things changed. Repeat.

Once you have finished reading CDD you will have a broad grasp of four major categories: player, setting, cast, and world. What can the player do, where does it all take place, who does he meet, how can he get there, and what happens when he does. But what happens when we want more detailed information?

Table of Contents

The first trick to my style is that the table of contents (and even the folder structure it is all contained within) matches the major headings for the CDD. If you have read the CDD, then you have learned how everything for the entire game is going to be organized. I did my best, despite many missing docs, to show how it would look once more documentation was written.

But what does it look like when you click on the Thrall?

Many Views Of The Thrall

The more specific the document, the more I begin to tailor it specifically to its intended audience. In the case of something that the player is going to be fighting, the Thrall, there are several views of the same guy. He has his description, a list of his animations, his required features, and stuff for effects and sounds; sometimes, I even do power point slides as a story board. Point being, when an animator is looking up needed animations, he doesn’t need to know that the Thrall can only be thrown when he gets to 20 percent health, but what he does need to know is that the Thrall’s idle stance is to be hunched over. The right info for the right audience.

This same process is done for other things, such as the Lever, when necessary. But other features, such as the document dealing with Spawning, do not require such fine tuned depth. Again, it’s about trying to understand your audience.

Wait, Why Is Everything HTML

Despite the obvious fact that I’m trying to showcase all of this on the web, I had other reasons for doing everything in HTML. My style of documentation, which is to say lots of small files, lends itself very well to dynamic HTML. Though this particular instance is not dynamic, it could be; and allowing for a dynamic quality makes things like “change the Thrall’s health” not the complete nightmare it normally would be.

What about Excel files, and hey, while we’re on it, where are your Excel files? First, you might have noticed, on some pages, there was a little bit of text that said, “(Excel)”. If you click on that, it will actually download an excel file for the information on the page. (See, not forgotten, and in fact very much a part of my docs.) But what happens when you try and go all DHTML? Well, in that case, I would probably do the work to drop Excel completely. I firmly believe that web is the way!

So, that was one reason, and the other was formatting. How you display your information is just as important as the information itself. I constantly fret that Heading 1 isn’t clean enough, and that you can’t tell the difference between Heading 2 and Heading 3. Yeah – totally that guy. By doing this all in HTML, and by using CSS, I can make every file look exactly how I want, and guarantee it is the same for all of them.

Conclusion

Time to unceremoniously dump links on you!

Table of Contents – a jump off page that links to almost everything

Concept Document – the major overview of the entire project

Thrall – an example of how I go about describing and documenting a character. Has three parts: Description; Animations – Note: if you change the url to .xls, it will download the excel file; Features.

The game may be fake, but the documentation is real. This is a reasonable facsimile of how I approach the task of designing a game’s many layers of documentation.

From the large to the small; from the general to the specific; from the programmers to the animators; from the Word documents to the Excel files.

Once I have given my wrists a rest, I plan to go back and keep adding. I still need to add an example of how to balance the economy, and I haven’t even touched on level design at all.

This is the form and structure of how I do things, but it does not and should not necessarily be how you do things. Every game is different, and every genre of game is different. My hope is that this structure and some of its ideas, maybe a lot the ideas, will be enlightening; but I also hope that some of it will not and, in fact, you will look at it and say that it can be done better; that you have seen it done better. I hope that you will join the conversation and share how it was done better. In this way, and only in this way, will the game designers of the world truly grow.

Speaking of sharing and growing – I told you I had a nice little surprise at the end – this entire process (how I set this up) was done and stored on GitHub. And here it is if you would like to download it as a zip.

The major benefit of the GitHub package is that it includes the “helpers” folder, which contains templates for all the documents I write. It makes my life easier, and I assume it will make your lives easier too. So, please, feel free to use it. Or fork it and make it better.

But most of all, enjoy. (Source: Gamasutra)