Even with all the research I’ve done, I still can’t really find a good, simple and straightforward explanation of the differences between a vision document, a design document and a technical document for a game. I’ve seen examples where people create each one individually, where they roll all 3 into one document, and others where they only combine certain elements of each into a single document, and leave the rest for other documents. I know there’s no “right way” to put together those documents, but there’s at least got to be something like a list of essential dos and don’ts for things to include or leave out of each type of document.
Anyone have any advice, suggestions, template or examples of each that I could refer to to help get myself on track with putting those documents together for my own project, without tearing my hair out over what I should and shouldn’t include in each?
While it varies on each studio, generally a technical document has ideas on how to implement features, a vision document is how the game should look, and a game design document covers how the game functions.
A Vision Document is a very high level design document. You don’t go into and specifics. Its the document that you usually make your pitch with. You highlight the overall concept of the game, any cool features it will have and how the players will generally feel and interact with the game. Consider this a broad outline of the GDD.
A Technical Design Document is exactly what it sounds like. It covers the technical aspects of development. That will be things like how the networking is done, asset formats, where files are stored and how things are saved, etc. This will often also contain things like the screen flowchart and detail how and when menus are accessed.
The Game Design Document is the detailed bible that exists (and changes) throughout the development. It describes all of the aspects of gameplay, explains each level, character dialogue, etc. It will detail every item that the player can have in their inventory, when each weapon does, etc, etc, etc. This will typically contain everything except specific math (leave that up to the programmer to decide) and the specific technical stuff (such as how things will be saved, peer 2 peer vs. dedicated server, etc. Pu that in the TDD).
So, I figure I’ll just continue working on the vision document for my project for now, and then move on to the design document and finish up with the technical document, if I feel there’s enough reason to put one together for an already-well-documented set of programs I’d be using.
If stuff is already documented then don’t bother re-documenting it. Just stick in a reference to what’s already there.
The job of these documents is to a) make sure you’ve thought things through (internal inconsistencies, holes, etc. are much easier to find when you’re organising things on paper) and b) help you communicate it to others (ie: if you were to bring someone onto your team tomorrow, what is the complete se of knowledge they need to know in order to sit down and start work?). You’re not writing for the sake of writing. If any given thing you write doesn’t help to achieve one of the above goals then there’s a good chance you can drop it.
Yes. Also, try not to overlap/repeat things across the the GDD and the TDD. It will confuse things, especially if you make changes (and you will make changes).
Each one does it in a way that works for him. I do not use separate documents. I put it in different sections of the GDD. It is easier for me to manage, and avoid contradictory statements between documents.
For specific softwares to do the GDD, I use Microsoft Word in the Outline View (the view that lets you do sections that you can expand and contract with plus and minus signs).
Yes, everybody does it differently. I admit, I don’t often use a TDD and, like you, just create a separate section in the GDD. Usually, the TDD is a pretty short document anyway.
Sometimes I’ll use Word, since its easy and straightforward (and easy to make edits). However, for the Vision Document (and sometimes the GDD) I use Publisher, adding in lots images, concepts, a background, etc. Some may consider it a waste of time, but I think it helps project the mood of the game to the developers.
NOTE: I ALWAYS spruce up the vision document that way. It helps get people excited about the game.
Using Word’s outline view sounds like a good idea. Certainly keeps things more compact. I’ll probably want to start doing that, myself.
I agree- using fancy text and images to convey the tone and mood of the game in the vision document is always worth it. Of course, all have right now to stick in the vision document for this project is textual stuff from the game: dialogue scenes I’ve written, decent-quality Photoshop mock-ups of in-game books and their contents (part of how the player learns about the game’s story and the lore of its multiverse) and some of the ideograms I’ve created for the language and writing system I’m building as an aspect of the story/lore and some of the gameplay.
If I could draw or model competently enough, I’d be doing those for the concept art, and throw that in there; but as it stands, all I’ve got are the words I can put down and the graphics I can create in Photoshop.
Keep in mind that this document is only for in-house use. While its preferable to use custom art, its perfectly acceptable to use images you find on the web that convey the same look and feel as your game. As long as your team gets a sense of the project, then the document has done its job.
