如果你必须写一些设计文档时，不要用Word进行编辑。不要误解我的意思，Word是个好工具，但却并非编写游戏文档的好帮手。它刻板、封闭性的特点，以及不支持高级排版和图像功能，所以不适用于设计文件。要让你的文档具有开放性、连网、合作性，最重要的是，要视觉形象化。Wiki’s、 Prezis和Google Docs等其他在线文档更有利于制作快速、形象化的文档。
作者：Richard Rouse III
本篇文章是摘自Richard Rouse III的著作《游戏设计：原理与实践》的修订版。这本书覆盖了所有游戏设计的相关内容，包括想出一个可靠的理念，执行游戏玩法，以及测试最终版本的游戏。在设计师真正开始进行游戏编码前，他们必须先将游戏设计呈现在设计文件上。而就像Rouse在书中所提到的，并非所有设计文件的创造都是相同的。
——《The Elements of Style》William Strunk
另外一个关于省略符号文件的例子是：“玩家将能从一些很厉害的武器中做出选择。例如比起玩家的其它武器‘Gargantuan Kaboom’拥有双倍的破坏力以及特殊的影响力。而‘Barboon Harpoon’则带有很好的摄像机效果让玩家能够在远处杀死敌人。而其它武器也都拥有各种有趣且强大的功能……”这一省略符号文件的作者未能详细描写游戏每个关卡所出现的武器，并且也只罗列出两种武器，从而让读者不得不自行想象其它武器。虽然文件告知了玩家其它武器也是“非常有趣且强大”，但是省略符号文件的作者却错误地认为开发一款游戏并不需要完整的描述。
另外一个例子便是我所说的“平衡数据”。这是一些关于游戏中的武器，道具和角色的真实统计。而设计文件则应该罗列出武器和角色所拥有的不同属性，例如一种武器拥有准确的射击率和极快的发射速度。除此之外设计文件也有可能会描写一种特定武器的特性，如“Double Barreled Shotgun虽然射程较短且不够精确，但是在较大范围内它却能够造成巨大的破坏力。”但是事实上，罗列出武器的这些属性对于设计文件来说并没有多大用处。就像是“Shotgun的精确度为2”这一描述并不存在任何特殊目的，因为在这里数字“2”并没有任何可供参考的环境，所以不具备任何意义。只有在游戏真正开始运转，也就是设计师能够根据玩家使用武器的情况平衡武器，并通过在不同设置中进行实验而达到预期效果时，这些价值标准才会真正实现。所以在我们真正能够测试信息之前创造大量的信息便只能说是一种浪费时间的表现。将内容以表格的形式表达出来虽然能够帮助设计师更好地阐述一些未经加工的想法，但是这种表格却只能呈现出最初形式，在游戏真正发行之前设计师还需要对此做出多次调整。
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 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.
篇目2，Design Docs: Barf
I hate design docs.
I’ve been co-hosting a radio show recently on GameDevRadio.net, where we talk about game develoment topics on a weekly basis. A few weeks back we discussed design docs, and I think I did a good job of denoting when a design doc is good or useful, and when it is bad and just a detriment to your team. Go take a listen! I’ll sit here and wait patiently, but you don’t have to listen if you don’t want to. After all, I have it.
My biggest problem with design docs is that you can end up spending more time editing the design doc than anything else.
In my little world of game development, a core mechanic should be built in a day. A polished prototype should take you a weekend. If you spent all weekend working on a design doc, and I spent all weekend actually making mechanics, who’s in a better spot? You have a bunch of papers with theories on what is fun, and I have hard evidence.
That said, I have a small team (of one, usually!), and I hold a lot of things in my head. I use a few tools to hold data externally, like white boards and to-do lists, and one could argue that the collection of those things is a strange type of “design doc” I am referring to as I work. Fair enough! You might be right there.
Sometimes you have to make a design doc, because some suit somewhere (publisher maybe? investors?) demand it. Sometimes you need one for government grants. If that is the path game dev is taking you, I am sorry for your lots. But sometimes you just have a large team, and you have to make sure everyone is on the same page. Cool! I get it, and I also think that right there (the inability to effectively communicate across your large team) is one of the reasons why bigger studios take so long to make games in the first place. But I digress.
I mentioned I sometimes use a whiteboard. It’s the closest I come to “design doc” in my mind, and I wanted to share it with you!
Again, with pictures!
So let’s take a look at my word game as an example; it’s fresh and still sitting on my whiteboard. Back on the Sunday that was January 22nd, I started working on the game. I got up relatively early that morning, and while my head was still mostly in the clouds, I went to my desk.
Just to the left of my desk, facing me, is a whiteboard. Before I opened the code IDE, I picked up a marker and started sketching. In about ten minutes, with only minor amounts of erasing, this is what I came up with:
I might have tweaked some of the written details in the bottom left corner throughout the day, but this whiteboard has not changed since day one of my game design journey.
Here’s my notes on the image as I am seeing it now:
This is mostly a mind-map of ideas, trying to get the key elements of the game out of my head and down on a hardcopy somewhere. I find it really helps to do this, as often some keystone element I once thought of is lost to the mists of my memory. This is also why I always carry around a moleskine everywhere I go.
The left half of the board is a simple flow chart of the game screens. One of the goals of this game was to be very, very simple and uncomplex; you can see me questioning things like the pause screen (“need this?”) right on the document. I find doodling the UI really quickly definitely helps me form data structures in my head, and helps me properly organize my thoughts. If I can compartmentalize “gameplay” to a single function on the whiteboard, I know I have a system that’s easy to build.
I sketched out what I thought the basic gameplay mechanic was going to be, in text on the bottom right. When I thought of the gameplay in my head, it was more of an image; breaking it down into these component pieces was an exercise in trying to boil the mechanic down to its bare elements.
The top right I sketched – in red – the key questions I’d have to answer before I could have a working prototype. Questions like “how big should the grid be?” and “what if your leftover letters suck?” Identifying where your problem areas might be early keeps your mind constantly checking for these cropping up (and searching for solutions). Sometimes it’s good to put a problem on a slow boil in the back of your mind.
Here’s where this might deviate from a standard design doc:
I spent a maximum of 30 minutes creating this.
I always kept it next to my desk, staring me in the face, every time I worked on the game.
I never altered it, even when gameplay significantly shifted.
Alteration of the Core Mechanic
The entire premise of the gameplay was that you were playing Boggle, but sort of in a first-person fashion. Your character would move around on the tiles, and you could only start spelling from where you were currently standing.
If you take a look at my last two gameplay elements – in green in the bottom right of the above image – you’ll notice two entries that describe the danger element of this gameplay:
No valid move -1 life
Certain tiles give +1 life
That is to say, if you walk into a corner and can’t spell your way out, you lose a life – and the game would use a standard “three lives, how long can you last” model. Sounds good on paper, right?
Well, it turns out that – even with tiny board sizes – the player almost never got stuck. There was always some obscure word to spell. With the occasional 1up laying around, everyone could eventual get 99 lives an the game would never end.
It turns out that English is entirely too flexible and my game mechanic broke. Very early on I had to switch to a timer based system – remove the lives, add a countdown clock, have it work that way. This in turn shifted many of the mechanics and balance mechanisms I had in the game.
And this is why prototyping is so important: you can’t know from a document what will work, and what won’t. You have to make it. And you have to make it as soon as possible.
I could have spent another week detailing all the different ways you could get 1ups, and sketching out death animations, and ordering death-music-samples from musicians – and wasted all of that effort on something that could never work.
I left the original idea on the board though – to remind me of the core simplicity of the game. To remind me what it was at first, to remind me how straightforward the game could be. If I start altering my whiteboard, I quickly get into feature-creep territory. Besides, keeping my errors up there, constantly glaring at me – keeps my game design skills humbled. If I just erase it, will I learn the lesson for next time?
Visual style remained solid
When I doodled out the interfaces, it wasn’t just drawing some placeholder logic boxes. I drew little penguin doodles in there, placed some UI elements in positions I thought would be good, and had a distinctive “style map” in place. Here’s how the game ended up looking:
Check it out. Same tile layout, same penguin theme, even the pause button and timers still in their original positions. About the only thing that changed here is the level of talent doing the doodling (Thanks, Sven!)
Having a consistent driving style is important to the games I make. It helps focus development down the same path, and sometimes things just “make sense” in the context given.
I didn’t have to beg Sven to keep penguins as part of the game. He looked at my initial sketches and just ran with it.
I think design docs suck for my purposes. This is how I do it instead. How do you keep yourself organized?
篇目3，Game Design: Theory & Practice Second Edition: ‘Not All Game Design Documents Are Created Equal’
by Richard Rouse III
The following excerpt comes from Richard Rouse III’s book Game Design: Theory & Practice, which has just been released in a revised and expanded second edition. The book covers all aspects of game design, from coming up with a solid idea, through implementing the gameplay, to playtesting the final game. Along the way, before coding begins, a game’s design typically takes the form of the infamous design document. But, as Rouse discusses in this excerpt from ‘Chapter 19: The Design Document’, not all game design documents were created equal.
“Omit needless words. Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word should tell.”
- William Strunk in his book The Elements of Style
Inauspicious Design Documents
As I previously recommended, it may be useful to try to get your hands on some professional game design documents in order to give you an idea of what the industry expects in such specifications.
However, you must be careful. It is likely that the document you obtain will not be any good. Many of the documents that have been used for published games and that were written by experienced professionals are truly terrible. By way of example, and in order to best teach you what to avoid, I will explore a few of the different types of horrible design documents, and why they fail so miserably at what they are supposed to accomplish.
The Wafer-Thin or Ellipsis Special Document
These thin little volumes, certainly none longer than thirty pages, startle and amaze the experienced game designer with their total and complete lack of any useful content whatsoever. They use meaningless descriptions like “gameplay will be fun” and “responsiveness will be sharp.” In these documents, many comparisons to other games are made: “This plays like Super Mario 64” or “The game has a control scheme similar to Quake.” While such comparisons can be slightly useful, as I have discussed, the writer of the Wafer-Thin Document almost always fails to explain the control scheme of Super Mario 64 or Quake in any detail, let alone the scheme to be used by the game in question.
Often these documents spend a lot of time, maybe half their pages, talking about back-story. Usually this back-story is very weak and poorly developed and is only tangentially related to the game being developed. The Wafer-Thin Document also spends a lot of time talking about how the menus will work. Not the in-game menus, but the system menus where users select what type of game they want to play, set their options, and so forth. Many mock-ups are made and options are carefully listed. What exactly the options will affect in the game is seldom described in any detail, since the game itself is barely defined. Figuring out the menu system is something best pursued once the game is working, when the designer knows what sort of options might be important and what different gameplay choices players will have; it is certainly far from the most difficult part of game design, nor the most important system to nail down first.
Wafer-Thin Documents are often constructed by managers who like to think they are game designers. The reason these can also be called Ellipsis Special Documents is that they are often littered with ellipses. For example, the worlds players will encounter in the game will be described in the following manner: “Jungle World is a very hot and sticky place where the Garguflax Monkeys swing around and torment the player…” And that will be all the document provides in way of description for the world, ending at an ellipsis, as if to say “insert game design here.” It is unclear whether the writers of these documents plan to come back and fill in at the ellipsis later or that perhaps they do not deem it worthy of their valuable time to actually explain how their game works. They just assume someone somewhere will fill it in and make them look good.
Another example of the content found in Ellipsis Special Documents might be: “Players will be given an option of many cool weapons. For example, the Gargantuan Kaboom does twice the damage of the players’ other weapons and has a special effect. The Barboon Harpoon will allow users to kill enemies at a distance with a nice camera effect. Other weapons will be just as fun and cool…” Here the writer of the Ellipsis Special fails to describe the weapons the game will have to any useful level of detail, and then, having listed two weapons, decides to leave the rest up to the imagination of the reader. Of course, readers are very usefully told that the other weapons will be “fun and cool.” The writers of the Ellipsis Special mistakenly think that is all the description necessary to develop a game.
The only upside to the Wafer-Thin or Ellipsis Special Document is that it allows whoever gets to implement the design to pretty much take over the project and turn it into her own. I say this is an advantage, since usually the ideas the manager included in the Wafer-Thin Document are beyond ridiculous and do not make for viable gameplay. But one must be wary. Problems arise when the manager shows up six months later and complains: “But that’s not what I wrote!”
The Back-Story Tome
Unlike writers of Ellipsis Special Documents, the designer who writes the Back-Story Tome spends a lot of time working on her document. These books (it is hard to call them merely documents) usually stretch into the hundreds of pages — 300-, 400-, even 500-page documents are not out of the question. There’s a lot of information in there.
The first mistake these documents make is usually a poor table of contents and the lack of an index. In a design document, well-ordered information and a good table of contents can replace an index, but the absence of both is a huge error. The problems are compounded when the document is as long as War and Peace. The primary reason for the existence of game design documents is to allow team members to quickly look up information about a section of the game they are working on. If a programmer wants to know how the AI for a particular enemy is going to work, she needs to find that information quickly and easily. If she cannot find it, she may just make something up. Similarly, when an artist wants an idea of the textures that will be needed for a given area in the game, she wants to be able to find where that area is described as quickly as possible. Design documents are not read like novels. No one starts at the beginning and comes out at the end. Primarily, design documents are reference materials, and if team members cannot easily retrieve the data they are seeking, they are liable to give up.
However, once one starts hunting through one of these Back-Story Tomes, one is startled to find that, indeed, there is no information about the gameplay in there. It is all back-story. And at 500 pages, it is far more back-story than most computer games will ever use. The history of all the characters in the game, the friends of those characters, and all the relevant parents and siblings are all described in minute detail. It may be very interesting stuff (though usually it is a disorganized mess), but in the end the reader is left with very little idea of how the game is supposed to function. These documents are often the sign of the frustrated novelist or a writer from a non-interactive medium who does not truly understand game development. A lot of games make storytelling one of their central concerns, and a story bible can be quite useful to game creation. In such a case, it makes sense to discuss the game’s story in the design document to some extent. But first and foremost, a design document is supposed to contain the game’s design, which is very different from a game’s story. Remember, your most important consideration when writing a design document must be, “what can the player do?” Though these tomes are very significant in terms of weight and will probably impress the venture capitalists, the programmer who has to work with such a document as her only guidance is going to end up designing the game herself.
The Overkill Document
Some designers think they can describe every last aspect of a game in the design document. It is certainly true that many design documents lack the necessary detail to be useful, as we found in the Ellipsis Special Document discussed above, but at the same time, going to an excessive level of detail can be a waste of the designer’s time as well as that of the person who has to sift through all of that excess information. Furthermore, excessive documentation can lead to the illusion that the designer has created a complete, thorough document, when in fact she has gone into far too much detail about certain subjects while skipping other areas that need to be addressed.
For example, suppose that the game being documented has a number of characters that perform certain actions in the game-world. Say the game has townspeople, and they need to walk around, sit down and stand up, talk to each other, and sleep. The document should describe these behaviors in the AI section. A truly thorough document might break this down into separate animations: stand from sitting, sit from standing, idle sitting, idle standing, walk, converse with hand gestures, and so on. Probably this is not necessary, since good animators and artists will be able to break this down better than a designer can. But some designers may go overboard and actually sketch or list the individual animation frames. This is absurd. There is no way to know in the design document stage how many animation frames will be required for a given animation. This sort of decision can only be made and adjusted during the game’s production. Not to mention that listing animation frames is insulting to the animator who will only feel demoralized by this degree of micro-management. Furthermore, the design document should stick to gameplay design, and not veer into the territory of the art bible or other art documentation.
Another example might be what I call “balancing data.” These are the actual statistics for the weapons, items, and characters found in the game. The design document should probably list what different attributes weapons and characters will have. For instance, a weapon might have a range, accuracy, number of shots, and rate of fire. Furthermore, the design document might want to describe the qualities of a given weapon: “The Double Barreled Shotgun has a short range and a low accuracy, but does a large amount of damage in a large area.” However, actually listing the values for a weapon’s attributes is not very useful in the design document. Saying “Shotgun Accuracy: 2” does not really serve any purpose since the number “2” does not have any context and therefore no meaning. These values are best determined when the game is actually functioning, when a designer can balance the weapons as they will be used by the players and thus the designer can experiment with different settings to achieve the desired effects. Creating large tables full of data before this information is actually testable is by and large a waste of time. Filling in a chart quickly may be a way to convey some raw ideas that were hard to describe through words alone, but at best such a table is a first pass that will no doubt change many times before the game
As with animation minutia and precise balancing data, source code also does not belong in the document. Designers who start writing out algorithms in their design documents are going too far. It does not matter if the designer is also a programmer. There should be no code, not even pseudocode, in the design document. Including code will only serve to bloat the document and distract from omitted information that needs to be covered. Some simple if-then-else type logical explanations may be useful and are completely appropriate. Such examples may help communicate all the contingencies to the person actually writing the code, and if nothing else force the designer writing the document to consider all the possible cases and outcomes that the game will need to support. But by the time the examples start looking like compilable C++ code, you know your document is overdoing it.
If there is any useful information in the Overkill Document, it is so hidden in the river of useless data that team members will be too intimidated to look for it. The author thinks that she can preplan everything, and that she is far more talented than any member of her team. While such excessive attention to detail can be impressive to those who do not really know what they are doing, a design document that goes too far will only infuriate the team that has to work with it.
The Pie-in-the-Sky Document
These design documents often have noble intentions with grand ideas for truly magnificent gameplay. Sadly, the writers of them typically lack any technical grasp of what the computer is capable of or what a team of twenty people is likely to accomplish in a year and a half. As a result, these overly ambitious documents put forth fancy ideas with no basis in reality or feasibility and end up frustrating and infuriating the teams assigned to “make them happen.”
Pie-in-the-Sky Documents include ideas such as “a fully modeled replica of Manhattan will be the players’ primary game-world, complete with AI agents representing all of the city’s seven million inhabitants in real-time.” The authors of Pie-in-the-Sky Documents do not want to be bothered with messy details such as the reality that no existing computer system can simulate seven million humans in any sort of reasonable time frame (let alone real-time). Another feature suggested might be “a natural language parser will be included that allows users to type in full, complex English sentences, which the characters will respond to with their own dynamically generated dialog.” The guilty designer does not want to hear that research institutions have been working for decades on natural language processors that still have trouble with short, simple sentences. When confronted with a Pie-in-the-Sky Document that you must work with, the first thing to do is call a reality check meeting involving key programmers and artists as well as the management who want this document implemented. With them all in the same room, some simple and quick calculations on a piece of paper or white board will often reveal how fundamentally impractical the game proposed is, and if the management still refuses to accept the reality of the situation, it might be time to start looking for a new job. Pie-in-the-Sky Documents are often combined with Ellipsis Specials to create truly wretched design documents, where the guilty designer outlines a completely impractical project without bothering to go into much detail about it.
The Fossilized Document
Any of the above flawed design documents can also be a Fossilized Document. Indeed, a design document that does not necessarily suffer from any of the above problems and was once a fine reference tool will become a Fossilized Document over the course of a project if the designer is not diligent in her efforts to keep the document up to date. I know of no original game project whose design has not changed significantly during the course of its development, and when the design changes but the design document does not, that document starts to become fossilized.
Suppose a programmer on the development team looks something up in the Fossilized Document and the information she finds is out of date. She may start implementing the old, long-since-modified functionality. At some point, a designer or producer who is aware of the changes that have taken place in the design will notice that the programmer is creating a system that is no longer appropriate, and will chastise the programmer for doing so. This creates frustration for both parties, not to mention wasting the programmer’s time. Furthermore, whenever the programmer needs to know something about the design in the future, she will not trust the design document, and instead will go hunt down a designer or producer to find out how a given system is supposed to function.
Of course, this defeats the purpose of the document, as the designer must stop whatever she is working on to explain the system to the programmer. This new system may be described correctly in the document, but the programmer is not going to get burned again by using the Fossilized Document. When the designer fails to update the document when design changes occur, the entire document becomes useless. No one can trust it, and as a result no one will bother to read it.
Wiki systems can be great for more easily keeping a document or collection of documents up to date. With Wiki, any member of the team can update a section of the document through their web browser, and full version control and history is supported to prevent the accidental loss of data. So, for example, the programmer who is implementing a particular feature can slightly modify the text of the design document to match how the feature actually ended up working, to add more information, or to link to the newly created technical design document for that particular feature. On a large enough project, keeping the design document completely up to date can be a full-time job.
A Matter of Weight
It is often joked that design documents are not read, they are weighed. This is not surprising given the heft of many design documents and the lack of desire among team members to read them.
Shockingly, this statement is often true. I once heard an ex-producer from a major gaming publisher talk about her experience with design documents and the project approval process. She said that the “decision–makers” would bring a scale to their “green-light” meetings. When it came down to two similar projects that were both relatively worthy of funding, they would take the design document for each project and place it on the scale. Whichever one weighed more would get accepted, the other rejected. Much as it pains me to tell you, if you are in the commercial gaming business and groveling for dollars at publishers, you need to make your document hefty. You need it to be impressive to pick up and flip through. Many will never read it at all. Others will read only the Overview and Table of Contents at the beginning. But everyone will pick it up and remark on its weight.
Of course, many of these super-thick documents contain a lot of information of negligible value toward the actual development of the project. They may be stellar examples of one of the failed types of documents I discussed earlier, such as a Back-Story Tome or an Overkill Document. It is your challenge as the game designer to make the document as practical as possible by providing only useful information in the document, while making it hefty enough to impress the suits. One might want to include a large number of flowcharts or concept sketches or choose to use a bigger font, all while not being too obvious. Indeed, a great game (though a simplistic one) can have a perfect design document only ten pages long. One wonders how many great, simple games have been cast aside by publishers who were unimpressed with the mass of their design documents.
Thankfully, over the last few years many publishers and developers seem to be wising up to the unwieldiness of massive design documents. Design consultant Mark Cerny has been preaching the concept of starting development with only a simple “macro” design document of perhaps ten pages in length that can be expanded on as needed over the course of development. As I have discussed, others are starting to use Wiki as a means of organizing and interlinking a lot of design information contained in many smaller documents. And fewer and fewer publishers are funding development based on a phone book-like design document alone, with prototypes and high-level, graphical pitch documents becoming increasingly important. The days of padding out the design document just for the sake of it seem to be thankfully drawing to a close.
Getting It Read
Once your design document is written, one of your biggest challenges may be getting anyone on the development team to read it. Often, many programmers, artists, or even other designers will not want to put the time into a careful reading of your document. Others may have been burned by bad design documents in the past and will jump to the conclusion that yours is of similarly poor quality. Keeping your document up to date, including only useful information, providing a detailed table of contents, and limiting yourself to practical, accomplishable gameplay elements will help.
Including numerous short, high-level summaries before each section of the document can also help team members get high-level information for aspects of the game they don’t need to know so much about. At the same time, such summaries can give readers a big-picture vision before they dive into the gritty details of the document. If your team members sample your document and find it to be of superior quality, they are more likely to return to it for reference when they are actually implementing a given system or working on a particular piece of art. As with any written document, you need to earn the trust of your readers if you hope to keep them reading.
Another key method of getting your design document read is to make it easily available to anyone who wants to read it. Keep it in the same source-control system that your team uses for asset management. You want your team members to be able to get the latest version of the design document as easily as they get the latest build of the game. Since you will be constantly revising and updating your document to keep it up to date with the project (and to prevent it from becoming a Fossilized Document), source control will be a valuable tool for keeping track of the previous revisions. Not to beat a dead horse, but a Wiki system run over a company intranet can also be great for distributing the document to the team, with developers at any time being able to easily read the very latest version of the document through their web browsers.
When you check in the latest version of the document, send your team an e-mail telling them that it is available and explaining what has changed. That way, people can easily skim over the changes.
If one of the changes is relevant to their work, then they can get the latest version of the document off the network and read over the relevant updates. Updating your document does not do any good if no one knows you have updated it or if people are still reading old revisions. It is probably a good idea to use a version number with your document, such as 1.3 or 2.7. Include this version number, along with the date, in a header on every page. Often people will print out a design document and not realize how old or fossilized it is. If they can quickly compare a date and a version number, they will know which version of the document they have and whether they need to get a new one.
Documentation Is Only the Beginning
Some designers or aspiring designers seem to think that a thorough design document is, by itself, enough to build a game. Indeed, some companies have had designers write design documents, only to then have those designers move on to write other design documents while a separate team actually executes their design. At its best, a design document is a rough outline, more the suggestion of a game than anything else, and without being involved in a game’s creation until it goes gold master, one cannot truly be considered to have designed the game. A designer who takes any pride in her work will want to be there throughout the project, ready to change the design as necessary to make it the most compelling game possible and updating the document as the design is changed and revised (and rest assured it will be continuously changed and revised). A committed game designer will want to be there to balance the weapons, the AI, the controls, and certainly the levels. She will want to make sure the game follows the focus through and that the initial vision is realized.
If a designer writes a design document and then passes it on to others to actually build, the people who do the actual creation will change the design to match their own interests and artistic drives. The design document will be a springboard for their own acts of creation, not the original designer’s. The design document is an integral part of the game’s creation, perhaps, but a design document is not all that is required. To claim any sort of meaningful authorship on the project, a designer needs to be involved for the duration. In a way, writing the design document is the easy part of computer game design. Actually taking the document and creating a compelling gaming experience is much, much harder.
篇目4，Design tutorial – how to write a feature brief
by Ethan Levy
The simple truth of game development is that a finished game will never be all that you imagine it to be. Even the best managed game development processes result in a game that represents 5 to 10 percent of the initial ambition. Ideas are cheap, implementation is expensive and at a certain point games must be shipped. For instance, even if my team’s current game Enhanced Wars is a runaway success and we continuously improve it for the 3 years after launching, it will never be all that we want it to be.
Once upon a time, when I set out to design a game I would start by writing a lengthy document detailing every aspect of the game. Eventually I learned that these documents are largely a waste of effort. No one else would ever read a 75 to 100 page document and most of the initial concepts get changed dramatically in implementation. Nowadays when working on a game, I prescribe a method of managing the design process for all these features that is lightweight and flexible.
The process revolves around writing out short documents called feature briefs. In this tutorial, I will walk you through the process of writing a brief. You can access a downloadable template of a feature brief at this link.
Step 1 – fill your backlog
Before writing a single brief, you should start by setting up and populating a backlog of proposed features. This will be a place where every member of the team can and should submit ideas to add to the game.
A screenshot of the feature backlog for Enhanced Wars
I highly suggest using a Google spreadsheet for this backlog. Your format will be your own, but I suggest each feature have a name, KPI, estimated implementation effort, 3 sentence description and comments section. As briefs are written, the name of each feature is turned into a hyperlink to the document. This list can then be prioritized by the team and sorted on the key axis of design intention and development effort when choosing which features to add to the game.
KPI stands for key performance indicator. In the instance of a live game, this correlates to specific metrics that the game team wishes to focus on. The standard KPIs are Retention (keeping players in the game over a series of days), Engagement (length of play time per day), Virality (number of new players an existing player attracts to a game), Monetization (if free to play, the amount of money spent in game) and Quality (will improve the game’s critical rating/user reviews but will not have a direct impact on measured metrics). Depending on your game and business model, your team will determine the appropriate KPIs to obsess over.
Step 2 – write the high concept
Even if your process focuses on minimal documentation, it is important to recognize that people will generally read as little as necessary. Therefore, I recommend starting feature briefs with a short, high concept section that another person can quickly digest to understand the feature.
High concept section from an Enhanced Wars feature brief
As you can see, this information is just a slight expansion on what was found in the backlog.
Step 3 – visualize your feature
Once it is time to write a detailed feature treatment for implementation, you will need to spec out the user interface and flow fully. But at this early stage, I recommend making a single mock up of the feature to help solidify the design and make it clearer for more visually oriented team members.
Mock up of the Single Player challenge levels dialog box for Enhanced Wars
A feature brief should include at least one image. This can be a mock of the interface the feature will require, a storyboard to show how the player will use the feature in the game or some other form of visualization.
In a single image, paint a clear picture of how the feature will manifest for the player.
Step 4 – flesh out details
Finally, you should list out all the major sections of the feature and write a one to two paragraph description of each. Again these are not full implementation details; they are just enough information to get the feature out of your head and onto paper in a way that you can evaluate with your team.
Detailing the progression system for Enhanced Wars’ challenge levels
Brevity is key at this stage. If you find that your feature brief is going beyond 2 or 3 pages, it is probably an indicator that you should split your concept into multiple features. Your goal is to write just enough information to communicate the design intentions to your team.
The purpose of process
Feature briefs are quick to write. Instead of spending two full weeks speccing out every detail of Enhanced Wars, I can populate a backlog and write briefs for two years worth of development work in a few days. By following this process, you can get ideas out of your mind and onto paper in a format that your team evaluate it for implementation. Now that you have the briefs, you can decide which features will be developed and write more detailed treatments as they are required.