Game design document bible

So far I have produced an inception document, a conception document, and a game design document. I'm afraid I'm really clueless on how this is done.

I searched the internet for examples but haven't found anything really helpful. I suppose I could "Mickey Mouse it" and just write something, but I'd love to do this the right way. If done well, I'll have a wonderful example for future projects. I really want to wrap this up so that I can start working on the TDD and get prototyping. Thanks in advanced fellas and ladies.

Cancel Save. Tom Sloper Quote: Original post by jmau So far I have produced an inception document, a conception document, and a game design document.

Question for you: what's an "inception document"? I'm always happy to learn new things. Maybe I've already written these but never heard them called that before? Comment: all these documents fall under the category of game design documents. Although those documents are vital to a game project and although they all require writing, this topic probably belongs in Game Design.

The Writing forum typically exists as I understand it for story writing, journalism writing, that kind of writing. A list of all the graphics needed. How many 2D objects? How many 3D models? How many environments? How many animated characters? Is this to be motion-capture? For example. What file formats do the art assets have to be in?

What file-naming convention is to be used? If you are who I think you are then you have no doubt written something similiar before I'll bet identical in purpose and possibly format.

An inception document is quick one page document maybe two, but I stress the maybe containing a properties table title name, genre, target audience, ect. They can be drafted rather quickly and are meant to be a starting point in conception. I made a template for this task years ago when I was still teaching, I'd be glad to send it to you if you like. There aren't any other Tom Slopers that I know of.

What you call an inception doc, I call a concept doc. What you call a conception doc, I probably call a treatment. Mikael Segedi, a game designer and project manager has linked some intriguing game design documents from his website.

The ones from Fallout: Brotherhood of Steel 2, Tron and Silent Hill were new for me, but the other ones are also interesting to read. This is his complete list:. On this website several different kind of documents about the game can be found Docs section as well as the finished game Downloads section. It should be one page or less of bullet points about the features you will want to brag about in your game.

Emphasize the most interesting points by putting them at the top of the list, in bold print to catch the reader's eye. Part 3: The overview section is the business case for the game.

Topics that should be included:. Part 4: The last section of this document should include points about your game that the other sections did not include. Describe what else the prospective publisher needs to know to appreciate your game.

The game treatment document should be a printed version of the more developed sales pitch you make for your game in the formal meeting you have with the investor or publisher. It should be an attractive document that can be used for reference after the meeting.

Some parts are the same as in the high concept document, but they are more developed and detailed in this document. The design script is the tool that is meant to be used by your design and development team. It is not a sales tool, it is an ongoing chronicle of design decisions that must contain useful information for the people building the game. This document may be broken into component documents for different teams, but the components must coordinate to represent one vision for the game.

This is called the game bible by some, and this is meant to show that the design team views the document seriously. The document must be updated, versioned, and made available to all design staff who need to refer to it. Ideally, any new staff added to the project should read this document to become aware of the work decisions that have been made to avoid any conflict with them.