游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

阐述编写游戏设计文件的要点和内容

发布时间:2011-10-31 16:57:41 Tags:,,,,

作者:Pierre-Alexandre Garneau

在近期的评论中,Maxest提到很难找到如何编写优秀游戏设计文件(游戏邦注:Game Design Doc,下文简称“GDD”)的相关信息。坦诚地说,之所以信息如此之少,其原因在于多数设计文件是在项目之初临时编写的。这里没有标准的格式。但是,仍然有某些比较好的GDD,那么你要如何编写一份优秀的文件呢?

我对设计文件特别着迷。虽然有些设计师的想法是尽快投入开发工作,但是我偏爱在概念化上花费精力,寻找合适的游戏玩法,为每种元素赋予独特的个性,构建游戏的总体愿景。如果可以的话,我可以花整年的时间来做这些事情。GDD是交流上述愿景的最佳方法,随意我会努力地对自己的GDD进行改善。虽然我编写的设计文件并非趋于完美,我也很希望能够在本文的评论中看到其他设计师采用的方法,但是我坚信自己的作品应该很不错。

本文将阐述更多相关细节,包括何谓GDD、为何你应当编写GDD、应当采用何种形式,当然还有GDD应当包含的内容。

game design document(from quebarium.com)

game design document(from quebarium.com)

何谓游戏设计文件?

首先,GDD是同开发团队交流游戏愿景的工具。当某个团队成员阅读完之后(游戏邦注:理想情况下他们应当通读文件),他应该能够理解期望中的最终游戏和为何游戏可以占据市场,GDD应当能够解答该团队成员的多数问题。

GDD是游戏的愿景,但并非所有的执行细节。愿景是游戏的高层次和中层次细节,应当在文件中进行彻底的阐述。当你读完之后,你应当能够对游戏中所有内容的配合方式有准确的想法。但是,不应当让阅读者陷入毫无意义的细节泥潭之中。

这是个不断改变的参考文件。在整个项目的过程中,可能发生的改变也需要体现在设计文件中。你应当总是保证GDD能够得到更新,如果它不是份可靠的参考资料,你的团队就不会参考,开发就会失去目标,你可能需要花费一整天的时间来解释某些事情。文件也应当组织恰当,在项目开发过程中团队中每个人会参考文件的不同部分,因而他们应当能够轻易地找到文件中的所需内容。

非游戏设计文件

设计文件并非是一份供每个人阅读的包含所有内容的文件。根据不同的需要创作不同的文件,不要将用于推广的营销材料、供制作人阅读的项目计划和供程序员阅读的技术数据等内容放入同一个文件中。GDD需要解释游戏的愿景,仅此而已。如果你将所有内容放进同一个文件中,这就会变成一份难以使用和更新的巨大复杂文件。

你也不应当在文件中编写那些低层次细节。你无需在文件中具体阐述所有的菜单屏幕或敌人AI的细节算法,一旦项目进行到足够执行这些方面的时候,它们可能会发生改变。你应当等到快要执行低层次细节时再将其编成文件,因为这是你更明白如何来处理这些问题。将这些元素变成文件是个很不错的想法,但是要将它们编成独立的文件,因为它们并不属于游戏的整体愿景。

电影剧本细节化地描述了整个故事,但是它们并不包含如何架构摄像机、在何处添加光线或者角色的服装等具体信息。同样,你的设计文件应当解释游戏的整体内容,但是无需包含具体的执行信息。

GDD也不是销售参考手册或营销文件。许多开发商使用他们的设计文件来作为销售参考手册,也有开发商采用相反的方法。让他人相信你的游戏很出众与描述游戏细节内容完全不同。建筑师推广的或许是有着精美草图的建筑创意,但是在真正建设时会再制作细节化的蓝图。游戏行业也是如此。分别制作销售和设计文件,如果需要的话你可以复制粘贴两者间的部分内容,但是你应当根据这两种需求制作针对性的文件。

最后,GDD不是你陈述游戏周围小层面的地方,比如英雄的背景故事、游戏世界的历史、外星侵略者的政治结构等。将这些内容编成文件是个很不错的想法,但是如果这些信息没有具体使用到游戏中,那么就不用出现在GDD中。这会让设计文件更难阅读和参考,是种得不偿失的做法。但是,一定要把这些内容编入某些其他文件中,这些信息或许往后将变得非常重要。

为何要编写GDD?

编写游戏设计文件需要大量的工作,所以你或许想知道是否值得花费如此精力。其作用在于:使你可以避开代价惨重的错误,使团队专注于游戏愿景之上。

重新改变团队可能会付出沉重的代价:因为你的关卡缺乏令人记忆深刻的事件,因而你浪费了3个月的时间,而且失去了假期和数十万的销售量。细心地构建初始设计有助于避开这些问题。我并不是说这样做就可以不出现任何问题,不过认真的规划确实会有所帮助。

GDD也会使得团队成员更加专注:如果所有人都采用同样的指导而且知道自己的前进方向,工作会更有效率。我曾经见过有些团队几乎停滞不前,因为他们不理解游戏的愿景究竟是什么。在这种情况下,优秀的设计文件可以让他们重新定位。

你应当在设计上花多少时间呢?事实上,这个时间越多越好。设计对游戏价值的提升要高于成本。理论上存在停止设计并开始制作的时刻,但是事实上我从未见过设计过度的项目。

格式

组织和参考的简易性对游戏设计文件来说至关重要。它应当能够被人所通读,但是也应当能够轻易地从中找到具体的信息。

保持以往的改变记录是个不错的想法。这样如果你之前摒弃的某个功能需要重新添加回游戏中,你可以从以往的文件中找出相关信息并加以更新。使用程序员所用的版本系统(游戏邦注:SVN或CVS)可以实现这个目标,或者可以使用有版本保留功能的程序(游戏邦注:比如Word可以让你在文件本身中保留历史版本)。

就编写的方法来说,有些人喜欢用文字的形式来解释所有的内容,有些人喜欢使用大量的图片。我认为每种方法都是平等的,使用你自己觉得顺手的方法就可以了。(游戏邦注:如果需要制作图片的话,作者推荐使用SmartDraw之类的工具。)

最普遍的形式是Word,或者其他的文字处理器,但是所有能够制作出很容易阅读、参考和更新的文件的方法都是可行的。比如,可以使用Vi来编写然后导出成PDF文件。我在当前项目中开始使用Wiki,到目前为止,我对结果感到很满意:编辑简单,在线化可以让你很简便地传送给团队中的每个人,支持链接和评论而且能够保留每次更改历史。

内容

在这个层面中,或许你希望我能够给你个小模板,包含需要在设计文件中提及的所有东西及编写顺序。很遗憾,我不能这么做,每款游戏都各不相同,所以每个设计文件也都不同。《侠盗猎车手》的设计文件与《宝石迷阵》不同。游戏续作所需的信息与原创游戏不同。你需要自己弄清楚文件中所需包含的内容以及如何来表述。

grand-theft-auto-harbour-city-design-document(from xbox360.ign.com)

grand-theft-auto-harbour-city-design-document(from xbox360.ign.com)

但是,多数GDD都需要如下内容:

1、游戏概述:首先简短概述游戏的内容,勾勒出一个大体的画面。

2、游戏规则:描述游戏玩法的机制。

3、游戏模式:如果你的游戏包含多种模式(游戏邦注:比如单人游戏和多人游戏),分别解释这些模式。

4、玩家角色:玩家角色能够做什么?他要如何移动?他的生命值是否随时间逐渐恢复或减少?解释所有主角的相关信息。

5、敌人、武器、可收集物品、强化物品等:你需要具体描述所有在游戏过程中可能遭遇的互动。

6、每个关卡的描述:关卡的位置在哪里?发生的令人印象深刻的事件是什么?是否有过场动画或特别事件?

7、控制:对控制进行完全的描述。

8、故事:阐述玩家将看到的整个故事。如果你的游戏有大量对话的话,可以考虑将这个内容制作成独立的文件。

9、教程:如何将玩家引入游戏中?

10、菜单链接:就菜单页面间的联系绘制出相关图表。

11、游戏玩法流程:展示游戏中的每个部分如何引向其他部分。如果你的游戏并非线性,编写这部分内容很有必要。

12、存档读档机制:游戏如何存档和读档?自动还是手动?

结语

无论你如何编写游戏设计文件,它都应该能够清晰地向读者表达游戏愿景。这是它存在的目的。保持文件简单和切入重点,你的团队才可以真正阅读和使用它,每个人都会对你想要实现的目标有更好的了解,文件的更新也将会更加简单。

游戏邦注:本文发稿于2006年7月5日,所涉时间、事件和数据均以此为准。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

How to Write a Game Design Doc

Pierre-Alexandre Garneau

In a recent comment, Maxest mentioned how hard it was to find information on how to write a good game design document (to sound like a pro, call it a GDD, pronounced Gee-Dee-Dee). Honestly, the reason there’s so little info is that it’s mostly improvisation at the start of every project. There’s nothing near a standard format. Still, some GDDs are better than others, so how can you write good one?

I have a strange fascination with design docs. While some designers want to get to development proper as fast as possible, I just love to work on conceptualization — finding the right gameplay, giving each element a unique personality, coming up with the overall vision of the game. I’d do that all year long if I could. The GDD is the best way to communicate that vision, so I’ve worked very hard on improving mine. While the design docs I write are nowhere near perfect — I’d love to hear from other designer’s approaches in the comments — I do believe they’re pretty good.

Read on for more details on what a GDD is, what it’s not, why you should write one, what format it should be in and, of course, what it should contain.

What’s a Game Design Doc?

Above all else, a GDD is a tool for communicating the vision of the game to the development team. When a member of the team finishes reading it — ideally they should all read it through — he should understand what the game is supposed to be, why it’s going to kick ass and most of his questions should be answered.

The GDD is about the vision of the game, but not about all of its implementation details. The vision — the high and medium level details about the game — should be thoroughly explained. When you finish reading it, you should have a precise idea of how everything fits together. However, the reader shouldn’t be bogged down in pointless details.

It’s an ever-evolving reference document. Throughout the project, changes will happen which will need to be reflected in the design doc. You should always keep the GDD up to date — if it’s not a reliable reference, your team will stop referring to it, development will lose focus and you’ll spend your whole day explaining things that are already in it. It should also be very well organized: everybody on your team will refer to different parts of it throughout the project, so they should be able to find their way around the document easily.

What it’s not

A design doc isn’t a catchall document for everything and everyone. Create separate documents for separate needs, don’t throw in sales point for marketing, planning for the producer, technical specs for the programmers, etc. The GDD is the document that explains the vision of the game, no more, no less. If you throw everything and the kitchen sink in there, it becomes a huge, messy document that’s hard to use and update.

It’s also not where you’ll write details about low-level issues. You don’t need to give specifics about each menu screen or detailed algorithms for enemy AI — they’re going to change once the project is advanced enough to implement them anyway. You’re better to hold off until you’re closer to implementing low-level items before you document them because you’ll have a better idea of how to approach them. It’s a good idea to document those elements, but keep them in separate files since they’re not part of the overall vision of the game.

Movie scripts describe the overall story in details, but they don’t contain specific info on how to frame shots, where to put lights or the specifics of the costumes of the characters. Likewise, your design doc should explain what your game is all about, but leave out information that’s specific to implementation.

A GDD is also not a sales pitch or a marketing document. Many developers use their design docs as sales pitches or vice-versa. They end up with a pitch that’s as convincing as a design doc, or a design doc that’s as thorough as an advertisement. Convincing somebody that your game is going to rock is entirely different from describing in details what’s in the game. An architect may sell a building with nice little sketches, but he makes a detailed blue print for actual construction. The same holds true here. Make separate pitches and design documents, copy and paste parts between them if you have to, but make specialized documents for each specific need.

Finally, the GDD isn’t where you keep every little aspect surrounding the game: the back story of the hero, the history of the realm, the political structure of the alien invaders, etc. It’s a very good idea to document all these things, but if that information isn’t specifically used in the game, don’t put it in the GDD. It would make the design doc harder to read and to refer to, without real benefits. Do write it down elsewhere however, that information may very well become important later on.

Why Write One?

Writing a game design doc is a lot of work, so you may be wondering if it’s worth the effort. It is: it allows you to avoid costly mistakes and it focuses the team on the vision of the game.

Redoing a part of your game can be very costly: your schedule slips 3 months because your levels lack memorable events and you’ve just missed the holidays and a hundred thousand sales. Creating the initial design carefully can help avoid that kind of problems. I’m not claiming it’s the silver bullet that will slay the werewolf of schedule slips, but careful planning certainly helps.

The GDD also helps focus the team: if everybody’s on the same page and know where they’re going, work is going to be much more efficient. I’ve seen teams almost at standstill because they didn’t understand what the game was supposed to be. In each case, a good design put them back on track with renewed interest and focus.

How much time should you spend on design? As much as you can, really. Design adds value faster than it adds cost. In theory there’s a point where it’s better economically to stop designing and start producing, but in practice I’ve yet to see an over-designed project.

Format

Organisation and ease of reference are crucial for a good design doc. It should be readable enough to be read from cover to cover, but it should also be easy to find specific information.

It’s a good idea to keep an history of past changes. That way if a feature you had to cut is put back in the game, you can fish it back from the distant past and put it into the new version. This can be achieved using a versioning system like the one your programmers are using (SVN or CVS probably), or use a program that features versioning (Word, for example, lets you keep the history of your document inside the document itself).

As for the way to write, some people like to explain everything in text, some people like to put lots of pictures and graphs. I don’t think any method is superior; just use what’s more natural for you. (You’ll probably make graphs one way or another, I highly recommend using something like SmartDraw. Anything but Visio, really)

The most popular format is Word, or some other word processor, but anything that produces a document that’s easy to read, refer to and update is fine. If Latex written with Vi and exported in PDF works for you, go for it. I’ve started using a Wiki for my current project and so far I’m very happy with the result: editing is easy, it’s online so it’s simple to send to everyone on the team, it supports links and comments, and it keeps an history of every changes.

Contents

At this point, you’re probably hoping I’ll give you a nice little template with everything you should cover in your design doc and in what order. Sadly, I can’t — every game is different, so every design doc is unique. Grand Theft Auto requires a different document than Bejewelled. A sequel requires different information than an original title. You’ll have to figure out by yourself what is needed exactly and how to present it.

Still, a number of items need to be in most GDDs (mention in the comments anything important you think I’m missing):

Overview of the game: Give a short overview of what the game’s all about at first, to give a glimpse of the big picture without reading everything.

Complete rules of the game: Describe the mechanics of the gameplay.

Game modes: If your game has multiple modes (single player and multiplayer for example, or Career and Quick Play) explain their unique characteristics.

The player characters: What can the player character do? How do he move? Does his health restore or drop over time? Explain everything needed about the main protagonist.

Enemies, weapons, collectables, power-ups, etc.: You need to describe pretty much everything interactive that will be encountered during gameplay.

Description of each level: Where is it located? What are the memorable events that occur? Any cutscenes or special events?

Controls: Give complete mappings of the controls.

Story: Put in the whole story, as seen by the player. It may be a good idea to give this its own document if your game has lots of dialog.

Tutorial: How is the player introduced to the game?

Menu flow: Draw a flow-chart of how each menu page leads to each other.

Gameplay flow: Show how each part of the game leads to each other. Especially necessary if your game isn’t linear.

Saving & loading scheme: How does your game save and loads progress? Automatically? Manually?

Conclusion

No matter how you write your game design doc, it should express clearly the vision of the game to whoever reads it. That’s its goal. Keep it simple and focused and your team will actually read and use it, everybody (including you!) will have better idea what you’re trying to do and you’ll have an easier time keeping it up to date. (Source: Page on Games)


上一篇:

下一篇: