Comments on: Design Docs (Debate) There's also the "design doc" that gets sent to the publisher who wants to evaluate what game they're going to get at the end of development. It's a sales doc from the point of view of the developer, saying what'll be cool about the game and trying to show some thought-process behind the game, but it risks over-promising because you want to sound great on paper and clinch the contract. From the publisher's point of view (and I've never worked at a publisher so this may be very unfair) it's the legal promise they can hold the developer to if the dev fails to live up to what's promised. There’s also the “design doc” that gets sent to the publisher who wants to evaluate what game they’re going to get at the end of development. It’s a sales doc from the point of view of the developer, saying what’ll be cool about the game and trying to show some thought-process behind the game, but it risks over-promising because you want to sound great on paper and clinch the contract. From the publisher’s point of view (and I’ve never worked at a publisher so this may be very unfair) it’s the legal promise they can hold the developer to if the dev fails to live up to what’s promised.

]]>
By: ProbablyAnIdiot/2011/06/22/design-docs-debate/#comment-6225 ProbablyAnIdiot Wed, 22 Jun 2011 21:41:06 +0000 Ideally design docs would contain everything from art assets, code functions, dialogue line lists, a full breakdown of the game’s story/plot, testing reports, etc, etc, ad infinitum.
That seems to be impossible and impractical outside of highly digital space (a wiki setup for cross-organization, as you might need “dialog script” by itself vs. “level-by-level dialogs” depending on department). Al Lowe’s oldschool Sierra adventures game design docs ( I was just about to post the very link! I've been fascinated by the idea of Design Logs as an alternative means of accomplishing design docs in a way that works nicely with the iterative nature of game design. I'm curious if anyone has tried it on a large production project. Anyone? I was just about to post the very link! I’ve been fascinated by the idea of Design Logs as an alternative means of accomplishing design docs in a way that works nicely with the iterative nature of game design. I’m curious if anyone has tried it on a large production project. Anyone?

]]>
By: ProbablyAnIdiot/2011/06/22/design-docs-debate/#comment-6221 ProbablyAnIdiot Wed, 22 Jun 2011 20:19:13 +0000

]]>
By: Charles/2011/06/22/design-docs-debate/#comment-6185 Charles Wed, 22 Jun 2011 03:32:56 +0000 I’m in the same relative space as you are. Just graduated, working on my first project. I wrote about this myself, the post is scheduled to go up 7/11. So I am definitely interested in following this discussion. Tadhg got me thinking about it with his
post.

A good template is easy to locate on the web and it did help quite a bit. Being able to consider things up front, which wouldn’t have come to mind until much later was valuable. However, forcing a completion of the design doc seems somewhat wasteful. A mostly complete design doc is helpful but trying to force yourself to finish the doc instead of actually working on the project seems like too much.

Considering how much revision goes into a final product, there is very little chance that a complete doc will actually reflect the game as players get it. In that light polishing a doc till it shines may not be a productive use of time. Better to spend the time polishing the code or the art. So my vote goes for: have one. Use a design document as a framework to get everyone on the same page about the game. But don’t worry about making sure that its 100% completed.

Granted I’m bootstrapping. So I don’t have investors, CEO’s, or other outside stakeholders to provide documentation to… If your project has those things, detailed design documents

]]> By: Rob Braun/2011/06/22/design-docs-debate/#comment-6179 Rob Braun Wed, 22 Jun 2011 02:24:33 +0000 TLDR: The short answer is yes. Every game ever made requires design docs both large and small; they need documents, they need graphs, and they need tables. That is the short answer, and now for the long answer, which I will attempt to keep brief, as this is simply a comment and not a blog post. "Design Docs", firstly, is a horribly under qualified term, because it implies just the written word, and proper documentation is more than simply one's thoughts collected on paper. A designers job on the project goes through three major periods: figuring out what the hell you are making, getting the team on board with the initial idea, and finally managing the vision as the game progresses; similarly, your documentation, as the projects goes through these stages, serves three purposes: extrapolation, communication, and collation. <strong>Extrapolation</strong>: documentation will help you fill in the gaps of your vision. First comes the pitch document (or the bitch document as I like to call it, because it's a bitch to write). Having something figured out in your head is not good enough, as you will always forget all the tiny little subsystems that "no one really cares about". These are important, and you will discover them very quickly when you attempt to write down the "big picture". The simple act of just writing it down not only visualizes these tiny systems you forget, but also forces you to deal with them. Someone, somewhere, is going to eventually need to know how it works, so you better know how it works too. <strong>Communication</strong>: documentation will help you communicate the vision to yourself and to others Ok, onto the next phase. That giant document you just wrote? Throw it away. (Not really, but you won't really use it anymore). The next stage of the process is all about communication, and proper communication is founded on understanding your audience. You must now take all of that stuff you wrote and parse it out into smaller documents that speak directly the various parts of the team (the artist, the animators, the programmers, etc). Every team speaks a different language, and they don't talk like designers. Animators need animation lists, artists need descriptions and examples, programmers need bulleted lists of features (that's no more than 2 pages). It's all different, it's all important, and it's all documentation. But, it's not just for communicating with the rest of the team, it's for communicating with yourself and the other designers. Funny that I just today posted an article about Pacing Graphs and proper communication. Documentation is not just word documents, as it is also things like pacing graphs, which are very crucial as you begin to move through that second phase. <strong>Collation</strong>: documentation will help you remember /why/ you made the decisions you did Ok, onto the last phase. I forget stuff /constantly/, but it never prevents me from doing my job, because I have my documentation handy. You see, the Design Department (we are just seen as a group, not a person), are the great keepers of the knowledge. When someone wants to know "why the hell" we are doing something, it is up to the design department to explain the reasoning. Most times, though, the person being grilled will not be the person who designed the feature, which means that you will need ready access to clean documentation, so that you can properly answer the question. Yes, this is very difficult on a big project. Yes, the game is constantly changing. Yes, this requires that you be very vigorous. No, that does not mean you be lazy. You want to know what game design "IS"? It is the most beautifully maintained folder structure, housing crystal-clear and relevant documentation, bringing tears to the eye of whoever graces it with their presence, and if you ain't down with that, you ain't down with game design. TLDR: The short answer is yes. Every game ever made requires design docs both large and small; they need documents, they need graphs, and they need tables.

That is the short answer, and now for the long answer, which I will attempt to keep brief, as this is simply a comment and not a blog post. “Design Docs”, firstly, is a horribly under qualified term, because it implies just the written word, and proper documentation is more than simply one’s thoughts collected on paper.

A designers job on the project goes through three major periods: figuring out what the hell you are making, getting the team on board with the initial idea, and finally managing the vision as the game progresses; similarly, your documentation, as the projects goes through these stages, serves three purposes: extrapolation, communication, and collation.

Extrapolation: documentation will help you fill in the gaps of your vision.

First comes the pitch document (or the bitch document as I like to call it, because it’s a bitch to write). Having something figured out in your head is not good enough, as you will always forget all the tiny little subsystems that “no one really cares about”. These are important, and you will discover them very quickly when you attempt to write down the “big picture”. The simple act of just writing it down not only visualizes these tiny systems you forget, but also forces you to deal with them. Someone, somewhere, is going to eventually need to know how it works, so you better know how it works too.

Communication: documentation will help you communicate the vision to yourself and to others

Ok, onto the next phase. That giant document you just wrote? Throw it away. (Not really, but you won’t really use it anymore). The next stage of the process is all about communication, and proper communication is founded on understanding your audience. You must now take all of that stuff you wrote and parse it out into smaller documents that speak directly the various parts of the team (the artist, the animators, the programmers, etc). Every team speaks a different language, and they don’t talk like designers. Animators need animation lists, artists need descriptions and examples, programmers need bulleted lists of features (that’s no more than 2 pages). It’s all different, it’s all important, and it’s all documentation. But, it’s not just for communicating with the rest of the team, it’s for communicating with yourself and the other designers.

Funny that I just today posted an article about Pacing Graphs and proper communication. Documentation is not just word documents, as it is also things like pacing graphs, which are very crucial as you begin to move through that second phase.

Collation: documentation will help you remember /why/ you made the decisions you did

Ok, onto the last phase. I forget stuff /constantly/, but it never prevents me from doing my job, because I have my documentation handy. You see, the Design Department (we are just seen as a group, not a person), are the great keepers of the knowledge. When someone wants to know “why the hell” we are doing something, it is up to the design department to explain the reasoning. Most times, though, the person being grilled will not be the person who designed the feature, which means that you will need ready access to clean documentation, so that you can properly answer the question. Yes, this is very difficult on a big project. Yes, the game is constantly changing. Yes, this requires that you be very vigorous. No, that does not mean you be lazy.

You want to know what game design “IS”?

It is the most beautifully maintained folder structure, housing crystal-clear and relevant documentation, bringing tears to the eye of whoever graces it with their presence, and if you ain’t down with that, you ain’t down with game design.

]]>
By: Kevin Daley/2011/06/22/design-docs-debate/#comment-6173 Kevin Daley Wed, 22 Jun 2011 01:49:31 +0000 In my experience, formal design docs work wonders early on in development. They provide a good springboard from which to start working by providing context, fleshing out the needs, and spurring on discussion. In order for a design document to be relevant, though, it has to be continuously updated. As the project goes on and people get busier and busier, it becomes more and more likely that the design doc is out of date. Information starts to get passed in more and more informal ways--emails, stopping by someone's desk, an off-hand comment in the hallway. This is where OneNote has been extremely helpful for us. We do a pass over a given gameplay element, take notes, and start a short period of work (3 to 5 days), checking things off as we get them done. On the next iteration, we re-evaluate what didn't get done, carry over what we still want to get done, and add to it according to a new play-though. The downside of this is that it can make some managers uncomfortable because it's often difficult to itemize, prioritize, and schedule such things. In my experience, formal design docs work wonders early on in development. They provide a good springboard from which to start working by providing context, fleshing out the needs, and spurring on discussion. In order for a design document to be relevant, though, it has to be continuously updated. As the project goes on and people get busier and busier, it becomes more and more likely that the design doc is out of date. Information starts to get passed in more and more informal ways–emails, stopping by someone’s desk, an off-hand comment in the hallway.

This is where OneNote has been extremely helpful for us. We do a pass over a given gameplay element, take notes, and start a short period of work (3 to 5 days), checking things off as we get them done. On the next iteration, we re-evaluate what didn’t get done, carry over what we still want to get done, and add to it according to a new play-though. The downside of this is that it can make some managers uncomfortable because it’s often difficult to itemize, prioritize, and schedule such things.

]]>
By: Rob Braun/2011/06/22/design-docs-debate/#comment-6163 Rob Braun Wed, 22 Jun 2011 01:11:08 +0000 It's vague enough to give creative freedom when implementing the system, but specific enough to outline the needs and mechanics. The document grows as more specification is needed, I haven't done enough to say how they scale in size. Hope that helps :] It’s vague enough to give creative freedom when implementing the system, but specific enough to outline the needs and mechanics. The document grows as more specification is needed, I haven’t done enough to say how they scale in size. Hope that helps :]

]]>
By: Rob Braun/2011/06/22/design-docs-debate/#comment-6159 Rob Braun Wed, 22 Jun 2011 01:00:08 +0000 From the perspective of a programmer on a small indie team, a design document is crucial. We only meet once a week and I find myself often refering to the design document for direction. It's a great way to flush out the core ideas of a game, and how to go about acheiving them. From the perspective of a programmer on a small indie team, a design document is crucial. We only meet once a week and I find myself often refering to the design document for direction. It’s a great way to flush out the core ideas of a game, and how to go about acheiving them.

]]>
By: Rob Braun/2011/06/22/design-docs-debate/#comment-6150 Rob Braun Wed, 22 Jun 2011 00:08:16 +0000 Heh. I’m not going to comment on Overstrike. But I’ll point out this post written by our Design Director (Mike Ellis) as reference for the general discussion: Guidelines for Creating Good Design Materials

]]>