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

游戏设计文档为何不再具有可行性?

发布时间:2014-07-24 16:31:16 Tags:,,,,

作者:James Sweatman

在过去数年中,游戏设计文件有多个称谓——GDD、设计宝典、游戏概要文件等。无论是哪个名称,它们描述的都是同一件事情:电子游戏的即时设计文档。GDD已有数十年时间被视为设计方向的支柱,为无论开发者和美术人员提供了游戏的愿景。这听起来很棒吧?谁不想在同个地方存储了解一款游戏所需的一切内容呢?

我就不想。

我在2008年进入游戏行业,当时刚刚大学毕业并且胸怀抱负。我进入了一家颇具知名度的独立工作室,准备开始施展抱负。我在大学的三年时光教会我撰写最佳文档并与不同团队成员进行有效沟通,这意味着我当然会成为一名出色的游戏设计师!

我们的设计团队与EA紧密合作,后者当时需要的是严谨的设计文档,该精简的地方就精简,需要文档的地方就不能省略。太完美了!我能够驾驶这种设计方法。在一年左右的时间里,我们的方法也的确管用。我们推出了过硬而富有规划性的游戏,这达到了我们所有的要求并且没有遇到什么麻烦。但在2010年我们着手一系列新颖而更具创意的项目时,一切都变了。

我所重视和信任的旧方法开始支离破碎。为一款实际上并不存在的游戏撰写大篇幅的文字这种感觉太疯狂了,居然会让这么多未经测试的理念像纸牌一样层层叠加起来。你只需要一点点怀疑就可以将其推翻并否决整个项目。

在2010年早期,我所就职的工作室取消了一款游戏,并不完全是因为设计很糟糕,但这也的确是其中一个因素。我们开始意识到编写庞大的文档,寄希望于创意美术人员和开发者去阅读并快乐地执行,真是一个致命的错误。

GDD template(from docstoc.com)

GDD template(from docstoc.com)

为何GDD不再可行了?

1.它们有太多假设

设计文件的一个前提就是文档。它并非一个游戏零件,它无法保证某个理念很棒,它仅仅是个理念而已。这种在微软Word文档中进行的简单理念探索导致我们无法真正去证实这些理念。在这个过程中会开始出现许多假设,你的产品却要以这种相当不稳定的东西为基础。

2.它们总是容易过时

假设我们编写了很棒的文档,并且有名开发者按照要求进行执行。我们现在发现有一系列功能需要更改。此时我们不但要向开发者提供引导内容,还得扯断文档以便日后更新。

你每在游戏中做一个调整,你就得更新一次文档。这是一个无止尽的编辑和更正循环。而这些时间原本却可用于编码、创造资产或平衡内容等一切有利于团队和产品的有意义之事。我敢说如果你现在看看自己的设计文档,肯定就会发现它至少有一个地方已经过时了。

3.没人会去看GDD

经常有人告诉我们管理层需要GDD,因为这些文档可以证明我们已经吃透和仔细调查了游戏理念,并且我们在开发之前已经做足了准备。

很好,但他们究竟有几次真正看过这些文档?一直都有看吗?还是一半时候有看?也许“从来没有”看过吧。虽然它可能是上级的要求,但管理层、制作人等之类的领导几乎都没有时间去看你长达5万字的设计文档,可能也并不想(或者需要)看。

但开发者们呢?美术人员呢?他们会逐字逐句去看吗?不会。你团队的多数人都有一个很好并且想制作的游戏理念,他们并不需要你在文档中填入所有的细节。他们只想知道与自己的工作有关的要点,这就够了。他们花在看文件和重新查看说明的时间越多,就越不可能制作出有趣的游戏。

4.它们太刻板了

设计文档从定义上看并不开放,它们并非烟盒背面任人解读的涂鸦,它们是关于一个理念的详细图表和蓝图,人们必须按照这个文档的指示来执行操作,否则游戏设计就会失败。这种刻板性会扼杀团队的创意,只有设计师才能独揽创意权,排除他人的见解,会在理念和执行之间隔起一道墙。

5.它们不允许失败

以文档形式完整设计一款游戏意味着在你编写一行代码之前就必须敲定许多元素。而等到发现其中的错误或问题时,整个产品已经围绕这个愿景基本成型了,这意味着理念的任何重要调整都可能产生巨大成本。

有什么替代方法?

这里并没有什么可以替代文档的方法。你还是得将某些东西落实到纸上,否则你就只能瞎摸着开发游戏,但这并不意味着我们在执行游戏开发之前需要阅读一整本的指南。我们所需要的只是一些引导,一些给我们指路的标志而已。所以将来你撰写文档时请先考虑以下要点:

1.在早期时尽量保持简洁性

在得到证实之前,理念只不过是理念而已。最好将文档控制在最小篇幅内。这里我指的是一句话的概括。要确定你的需求,以便证实理念并令其生效。我发现一个有用的方法就是“用户故事”。用一个简单的故事来解释你的想法,以及它为何有趣或者好玩。要从玩家角度来考虑这一点,“作为玩家我可以用Y来做X,以便感受到Z”。

make a sentence game(from ua168.com)

make a sentence game(from ua168.com)

2.保持敏捷性

在少量或没有文档的情况下开发游戏,意味着你无需等待设计师完成其洪篇巨制的文档就可以测试理念了。直接进入纸质或简单的数字版原型,你就可以尽早从失败中汲取经验。没有什么设计文件能够一次性全部更正好。所以在数周甚至数月的文档编写和预制作阶段后才发现某个理念并不可行,这对你的项目或工作室来说可并不是件好事。

3.保持合作性

不要闭门造车地自己编写文件。应该把这种“独行侠”式的游戏开发风格抛进历史。无论你在哪个游戏团队就职,最好都要让团队中的其他人也像你一样对游戏和设计满怀激情。

不要用冗长的文档来控制游戏设计,而要和团队一起发现和解决问题。你的团队越是深入地参与设计过程,他们与产品就会越亲近,产品也会越棒。

4.调查和记录

当你制作更大的文档集时,最好是从两种形式中择一而行:调查或记录。针对特定样本的文档调查,如果足够简洁,可以成为帮助团队制定决定和引导产品更广泛设计的优质资源。记录是游戏设计的真正定义,也是设计交流或创建决定产品方向的原型的结果。这些是你在对游戏设计的一些决策上犹豫不决时可以参考的文档。

5.不要用Word写文档

如果你必须写一些设计文档时,不要用Word进行编辑。不要误解我的意思,Word是个好工具,但却并非编写游戏文档的好帮手。它刻板、封闭性的特点,以及不支持高级排版和图像功能,所以不适用于设计文件。要让你的文档具有开放性、连网、合作性,最重要的是,要视觉形象化。Wiki’s、 Prezis和Google Docs等其他在线文档更有利于制作快速、形象化的文档。

总结

虽然我的确很想给传统GDD判个死刑,但也有一些时候我们真的需要GDD。例如在外包项目、第三方或多家工作室合作开发的时候,就总会需要一些形式的中心设计文档作为参照。

寄希望于人人都能参与到合作性、无文档的开发氛围中可能有点不现实,但总有办法克服这种现状。可以尝试新的文档撰写方式,摆脱Word的桎梏,为濒临死亡的GDD理念引进新方法。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Death of the game design document

By Jagex’s James Sweatman

Jagex’s James Sweatman on why central design documents don’t always work, and the alternatives available

It has been called many things over the years – GDD, Design Bible, Game Overview Document. Regardless of title, they all describe one thing; the living design document for a video game. The GDD has been a pillar of design direction for decades, providing countless developers and artists a singular vision for a game. Sounds great right? Who wouldn’t want one place to store everything there is to know about a game?

I wouldn’t.

I joined the game industry in 2008, fresh out of university and with big dreams. Going into a well-regarded independent studio, I was ready to set the world alight. My three years at university taught me how to write the best documentation and effectively communicate with different team members, which meant I was sure to be a great game designer!

To start with I was right: Our design team worked closely with EA, who at the time wanted rigid design documentation, with briefs upon briefs and documents on documents. Perfect! I can nail this design malarkey. And for a year or so it worked. We shipped solid, formulaic games, meeting all the requirements set of us and didn’t rock the boat. That began to change as we rolled into a couple of new, more creative projects for 2010.

The old ways I’d held so dear and believed in so much had started to crumble away. The idea of writing thousands of words about a game that didn’t exist started to feel maddening, with so many untested concepts sitting on top of one another like a wobbly house of cards. It would only take a small gust of uncertainly to topple them and bring down the whole project.

In the early months of 2010 the studio I worked for had a game cancelled, not 100 per cent due to poor design, but we knew it was a factor. That hit home. It really began to sink in how our method of writing huge documents, expecting creative artists and developers to read them and happily implement our ideas, was fatally flawed.

So why don’t GDDs work?

1. They make too many assumptions

The premise of a design document is it is exactly that – a document. It isn’t a game fragment, it isn’t proof that an idea is great, it is only the idea. This simple exploration of ideas in Microsoft Word prevents them from ever being truly proven. Along the way many assumptions will begin to be made and your product is now based on some fairly shaky foundations.

2. They are always out of date

Let’s say that we’ve written our wonderful document and a developer has implemented it. We now find that a collection of features need to change. At this point not only do we have to provide guidance to our developer but also begin pulling apart our document in order to update it for future reference.

Every time you make a change in the game you have to update your documentation. An unending circle of edits and corrections. All time that could be spent helping with code, creating assets or balancing. Useful things to help the team and the product. I can guarantee that if you look at your design document right now it will be out of date in at least one major place.

3. No one reads them

We are always told that management need a GDD. They are proof that the game idea is thought out and well researched, and that there is evidence of all the preparation before development (preparation that we usually have to rewrite).

Great, but how many times are they actually read? All the time? 50 per cent of the time? Probably ‘never’ is the answer. While it may be a requirement, executives, producers, or leads of any kind almost certainly don’t have the time to read your 50,000 word document and probably don’t want (or need) to.

But what about the developers? The artists? They read every word right? Nope. Most of your team have a good idea of the game you’re all trying to make and won’t need all of the detail you’ve stuffed into your document. They want the points that are important to their work and that is all. Time spent reading and rereading is time not spent on making a fun game.

4. They are too rigid

Design documents by definition aren’t open to interpretation. They aren’t doodles on the back of a cigarette packet for someone to interpret. They are detailed diagrams and blueprints for an idea that have to be implemented by the numbers otherwise that design falls apart. This rigidity kills creativity in the team, saves it all for the designer, removes by-in, and builds a wall between the ideas and implementation.

5. It doesn’t allow for failure

Fully designing a game in document form means so many elements have to be decided before you have even written a single line of code. By the time development begins to reveal errors or problems an entire production has formed around this singular vision, meaning a huge cost for any core changes to the concept.

What’s the alternative?

There is no escaping documentation in some form. You have to get something on paper otherwise you’re developing in the dark, but that doesn’t mean we need a bible to guide us before we start on our path to game development glory. All we need is some guidance, a few signs to help us on our way. So when putting finger to keyboard think about these points for your future documentation.

1. Keep it light early on

An idea is still an idea until it is proven. Keep documentation to an absolute minimum. By minimum I’m talking a single sentence. Define what you need in order to prove the idea and make it happen. A way I find useful is the ‘user story’. A simple story that explains your idea and why it’ll be fun or interesting. Keep it in the guise of a player. “As a player I can do x with y in order to feel z”.

2. Keep it agile

Working with little or no documentation means you aren’t waiting for your designer to finish their epic tome before you can test out the idea. Jump into paper or simple digital prototyping so you can fail early and fail often. No design document has ever been correct first time. So waiting to find out an idea doesn’t work after weeks or months of documentation and preproduction isn’t good for your project or your studio.

3. Keep it collaborative

Don’t sit in a corner for weeks writing your finest works. This kind of “lone creative” style of game development should be and hopefully will be consigned to the history books. If you work in any kind of team in the game industry then anyone in that team should and will be as passionate about games and design as you are.

Instead of controlling the design with sprawling documents, work to discover and solve issues together. The deeper your team’s involvement in the design process the closer they’ll feel to the product and the better that product will be.

4. Research and record

Once you do produce larger sets of documentation they should come in one of two forms: research or recordings. Documenting research on a particular subject, if kept light enough, can be a great resource for aiding decisions as a group and guide the wider design of the product. Recordings are the real definitions of the game’s design, and are the results of design conversations or prototyping that fully define the direction of your product. These are documents you can refer to when being questioned on decisions made around the design of the game.

5. Don’t do it in Word

If you must write a design document of some kind, do not craft it in Word. Don’t get me wrong, Word is a good tool (I’m using it right now) but it isn’t a tool for documenting a game. Its rigidity, closed nature and poor support of advanced layouts and imagery makes it unsuitable for design documentation. Keep your documents open, online, collaborate and most importantly – visual. Wiki’s, Prezis, Google Docs and other great forms of live documents are far better for rapid, visual documentation for all to see.

There is no design utopia

While I’d love to really put the nail in the coffin of the traditional GDD for good, there will be occasions where something like it may still be required. Outsourcing, third-party or multi-studio development will always need some form of central design documentation for reference.

Expecting everyone to join the collaborative, document free commune may not be realistic but there are always ways to challenge the status-quo. Try new ways of documenting, break free of the shackles of Word and bring a fresh approach to the dying concept of the GDD.(source:develop-online


上一篇:

下一篇: