In the comments for my last post (about how game ideas are not very valuable), some readers pointed out that not all ideas are low in value -- design documents by experienced designers can be quite valuable for some projects. That's definitely true! However, ideas are different from design docs in the same way that an architect's sketch is different from a finished set of blueprints. Ideas tend to be vague and fleeting, while design docs flesh out all the details of the game and clearly communicate them to the team.
"A great idea is meaningless. A great idea that leverages your existing technology, gets the team excited, is feasible to do on time and budget, is commercially competitive, and, last but not least, floats the boat of a major publisher... Now you have something." - Ken Levine
Fleshing out details
The basic idea for Grim Fandango is something like, "A point-and-click adventure game in which the player is entangled in a film-noir murder mystery in the afterlife". From this idea, the design team wrote hundreds of pages of documentation, with design sheets for each character and setting, and detailed descriptions and flow charts for every puzzle in the game. Here's a picture of part of the puzzle chart for chapter one, from the 72-page Grim Fandango puzzle document.
Different games and teams need widely-varying levels of detail in the design doc. For example, a game with a really large team will likely need a more detailed design doc. Communication becomes difficult with so many people, and it can become more efficient to have a central document to fall back on that clearly defines every detail. However, for Overgrowth, we have a very small team, so we need very little documentation -- especially since we already have Lugaru as a prototype (which also never had a design doc). Also, since the lead designer and programmer are the same person, spending a month writing an in-depth design doc would mean a month without writing a line of code.
Communicating with the team
As with any kind of writing, it's vital that the designer consider the target audience for the design doc, and the intended effect of reading it. In this case, the audience consists of artists, programmers, and other developers, and the intended effect is to inform them exactly what they should be doing. Good design documents usually have a funnel effect to direct readers to the relevant parts -- a level designer might start by reading the overview, then the level design overview, then the specific level overview, and finally the minor details of the level implementation. They also use very precise language -- instead of "The Desert Eagle .50 does a lot of damage," they would say "The Desert Eagle does 65 points of damage to unarmored targets, and 40 points to armored targets."
Here's an excerpt from a design document for Fallout: Brotherhood of Steel 2. This particular document looks like its intended audience was marketers and publishers, since it is fluffy and vague to the point of uselessness -- for example, it says "10 new guns will be introduced," on page 15, but never even lists them.
When to use design docs?
Design documents are definitely useful tools, and essential for projects with large teams in which designers and developers are separate. However, I'm not sure how useful they are for small indie teams like ours, because they can waste development time and prematurely crystallize the design. What do you think? Should we take the time to write up detailed design documents? Do any of you have experience working with them? (permalink)
Track us on ModDB (visit our page)
Please join us here too:
Design documents are only useful when the game's details are not known by everyone.
With a team of 5, or so your Wikipedia page says, most of your "details" would be shared much easier. Why create a document including all of them, when most of you have them stored in your head. ;)
Oh god, thats a terrible idea. You should NEVER be a game developer. It's ALWAYS important to outline your game in a game document! I would never be a part of your development team, that would make me cry. You remind me of the pointy haired boss I have at work. It's the same thing with software development.
That was rather uncalled for.
Of all the game designs to pick on you pick on Brotherhood of Steel 2, considered the worst Fallout game ever. It's game design was the most stupidest thing ever- who ever wrote it or even allowed the game to ship should be shot- the game was just that bad and even from the game design you could see "Yes this game will FAIL.. FAIL HARD DAMN IT!".
It also doesn't help if the game is based on an IP that is stereotypically an RPG and here you are producing a POS team based arcade shooter.
From Fallout.wikia.com : "In March 2009, the design document for the game, written by Brian Freyermuth (one of the designers of the original Fallout), was leaked."
The best part of a design documents, are the tangible goals that are set on it. You will know, how far and or close you are to accomplish the project.
Great article, bring more.
I'm a modder, been going on for a year with the same mod, things are still going well, development is flexible simply because we do NOT have a design document.
So yeah I'd say it could "crystallize" development by setting too many things in stone, for commercial developers that have publishers that may need to be important but with indie or modding I'm not so sure, I suppose it depends on the game ofcourse, if it's a game where stats, characters, story and more are very important then having a design document to keep things on track would be good, if it's like a fun game that the player can simply "play" without digging into the story or something such as a stats system then I'd say a design document isn't important.
In such case rather focus on getting community feedback and if it will make the game more fun, listen to that feedback, be flexible and do it.
For my own mod, someone I invited over for just one playtest suggested walljumping, it's been implemented and like someone else just said to me yesterday: "Walljumping makes the mod 100% more fun".
If I were to have had a design document, I'd have to stick to it and walljumping would never have been implemented.
I would say for such a small team you don't need a fully fledged, 500 page design doc, although you do need some way of recording development, tasks and deadlines as well the in game content you are going to create.
Using something like google docs or a wiki would make more sense than uploading a heavy .doc file to an ftp or svn. With a google file or wiki your team can access it from anywhere with an internet connection and edit their own sections without any fuss. Allowing this kind of open access can become confusing if people start changing things without notification, but as this is a small project it would be perfect for you to implement as you can just chat amongst yourselves about what you think would be a cool idea to try out.
It would act as a referance for the team and essentially become a giant "To Do" list to keep everyone on track.
Thanks for writing this article, I enjoyed reading it!
I recognize you from interlopers, your the one doing the 8bit stuff right?
Lobstar here ;)
Yeah, although I'm back to the more high poly stuff now haha.
I'd say writing a design document is just as important [if not moreso] as the process of actually following it. It allows the designer to lay things out in a logical order, uncovering potential compatibility issues between various game mechanics before the team's wasted any time implementing stuff that might just need to be trashed in the future.
Whenever I embark upon building a new map or model I will prepare concepts [both visual and textual] to help me keep focus on what I want the finished project to achieve otherwise I'll invariably end up going off on some wild, off-the-cuff tangent. That's not to say a design document is unchangeable, but it certainly helps me to keep things in perspective, and sometimes even makes it EASIER to make changes, as I can better consider the potential repercussions.
I'd say it's also important to have a design document if you're implementing some original/rare game-play mechanic, just to make sure everybody on the team [no-matter how small or large] is working towards the same goal and can remind themselves of it whenever they need to.
Ultimately I guess it just comes down to personal preference and that can be decided upon by the team, but its important not to rule out the possibility that a team will change over the course of a project.
A design document is always important for so many reasons it's not even funny. Not only does it act as a method of measuring progress, but also as a way to keep the team organized. Design documents change and that's an acceptable fact but to not design one just because you design document may change is unprofessional and silly. Creating a design document is a good habit to get into and an extremely good practice. It will help you succeed more than you ever realize. As the leader of PO, my design document has kept me on track so many times. Even though my game is designed off of Pokemon it's still easy to get off track. Design documents are a huge solution to this.
If you ever went to a game or software development company and said, "I'm going to start our new software or game and not have a design document!" then you would probably be fired, and for a good reason too. It doesn't matter if you have 5 developers, 1 developer, or 100 developers. A design document will keep you and your team on goal and knowing what is done, and what needs to be done.
Excellent article!
I, as a dev of the game Solitude can say that design docs, although in many cases useful, are not always needed. So yes, I agree with the article :) I haven't seen anything resembling a design doc in my team so I assume (being one of the earliest members) that one doesn't exist, and if it does, only the leader saw it so it wouldn't have any real purpose. My point is that even without it, we seem to be doing fine. Using common sense (like no, you can't have Masterchief shooting rays from his eyes/nose/butt) allows us to be very flexible and all 'ideas' are submitted to a category on our forum to be reviewed by the rest of the team. In my opinion, unless you're doing something really original (that is not a straight FPS/RTS/RPG/etc.) or have a really huge team, you don't need a design doc. Why? Because you can tell your 'idea' to the team yourself and without a design doc you're not limiting your team's global imagination which can lead to some cool ideas :)
I think all games/mods should use design documents. All the big companys use them and i personally think they make the communication more fluent as you can just give team documents and they can easily see what's done and what needs to be done. I have used them every project and it definitely showed.
Design docs might be usefull for modders.