Design documents

At the moment, I'm working on a design document for my platform game, Tar!. It's getting some shape by now, as the general look, feel and storyline are described, and I'm working on character descriptions (as in, enemies, friends, their behaviour, etc.).

So, I'd like to ask for some feedback. I'm not asking to read the doc, instead I'd like to know what you would want to see in a design doc if you had to create a level or art for it. What information is a must-have and what information would be helpfull on top of it? What degree of freedom would you, personally, like to be given?

Also, what format do you think is usefull? At the moment, I'm using a wiki for it, instead of a .doc or .pdf. The reason is, that a recent version is always accessible for a team and can be modified by anyone - and revision history can be tracked as well. .pfd's seem to be favored by many, but I find them slow to work with. Anyway, if you've worked with them, could you share your experience of what worked in your situation? :smile:

Thanks beforehand. :smile:

---

Create-ivity - a game development blog

You usually don't ask what people want to see in a design document. Generally, the consumer should be ignorant of that part. You ask them the requirements for the product. Then translate that for the engineers. You don't make design documents for art, since that's a little more free-flowing than anything else. That's what concept art is for. Seeing what works and what doesn't.

It'd be best to map out levels (draw them) and work the kinks out that way before you start mapping. The entire point of the design document is to be fast, accurate, and detailed so someone who has NO previous knowledge of the project could pick up the document and create the game.

There's plenty of stuff online on how to contruct a good document. Take a look around.

---

Blame it on Microsoft, God does.

I think you're mixing 'concept document' with 'design document'. Concept docs are used to get people (publishers) interested. Design docs are the games description, the guidelines, describing how the game should be.
So artists and others won't take it the way they envision the game, but get a feel for the intended vision - building on top of it, fleshing it out, giving it their personal touch. It's a way to get the team on one line. I'm aware it doesn't substitute team meetings and such, but it should be there as a guideline, a reference chart. Programmers often get a technical document, though personally I find reading about the game design too helpfull for my programming job as well.

Anyway, good thing mentioning concept art, I'm sure to add art to the document for reference purposes. It'll help people envision the idea better. However, sketching out levels is a level-designers job - the design doc describes what items are unlocked in a specific level, it's theme, available enemies, specific events, and so on. That's where I wonder, how much freedom would you wish, and what things would you want to see described there?

I know there's various articles on this subject, and I've read quite some so far, but this is more of a question aimed at artists to see what information they think is usefull when creating art or levels for a game idea they didn't design themselves.

---

Create-ivity - a game development blog

I just found what seems to be an official design doc to MGS III. I never played and just found the PDF but heared it's a good read.

http://www.mgstus.org/downloads/misc/MGS2_orginal_gameplan/metal_gear_solid_2_grand_game_plan.pdf

I'm not mixing anything up. A "Design Document" doesn't apply to art. For art there's more or less a guideline or style that needs to be followed. A design document is created so two different teams, for example, could follow it and create the same product. That doesn't happen with art, nor do I think you'd want it to.

In addition to that, you should have separate "documents", all of which have different styles. The art one should be the most loose and general of them all. You have concept art, the most strict you can be is "make this into a model with x max poly count" or whatever.
For a level, I think the requirements are similar.

---

Blame it on Microsoft, God does.

Hmm, I think I get the point. A design documents purpose isn't to tell artists how every single piece of art should be done, but it's there to tell them what the game should be. It's there to get the idea across. I guess I'm mixing things up then, a design doc isn't an art asset list. Or whatever the name is - if that matters at all.

So an art document would describe what art needs to be created, a list of characters and texture sets for example. I believe some artists can work from descriptions, others need concept art to get the correct idea across, so that's probably going to be settled individually.
Anyway, I do think it's necessary to put up a list of requirements for certain items. If character A needs to be bold because it's part of an important plot-twist, then the artist needs to know. If a level takes place before the player learns trick B, then the level designer should know about it.

In other words, a description list, backed up with concept art, would be sufficient for you to create the levels and art the designer envisioned?

@reaper47: interesting read indeed. Thanks for linking. It enforces the idea that a design doc should focus on the design + design decisions, not specific art or tech info.

---

Create-ivity - a game development blog

From my personal and detailed experience, a design doc is that thing which nobody reads until they've implemented said design and something doesn't work.

Generally though, it's a blueprint of game mechanics, asthetics, vision, which can reach into all aspects of art/programming/gameplay. There's very much an art to creating good design docs. One of the things I've found is the value of good reference images. A picture really is worth a thousand words.

So you'd say team meetings are far more important to get the game idea across and a design doc is merely a reference chart for troubled times, or at least used by the designer to order his or her thoughts?

I must say, that's recognizable. At the place I work at, we don't even have a design doc for the game I'm working on - although it's a pretty small mobile game, so the alread-done art and the tech doc are sufficient for me to work with, and otherwise I ask the one who's in charge of the game for details and let them know my suggestions.

Well then, I'll keep my design doc short, detailing the game mechanics and feeling/style, and I'm going to draw some concept sketches. The actual levels and art will need some planning too, of course, but I guess they're not directly the game design part of this. :smile:

Thanks for your comments people. :smile:

---

Create-ivity - a game development blog

Captain P said:
Thanks for your comments people. :smile:

What about us little folk who wanted to say something but all the ideal replies were taken already?

---

The best things in life, aren't things.

Uhm... you can't shoot what you can't see, so... :razz:

---

Create-ivity - a game development blog

Captain P said:
Uhm... you can't shoot what you can't see, so...

Gods if that were only true during deer season around here.

---

The best things in life, aren't things.