Game design document? How about ‘game bible’?

When you’re working with 4 coders,  an artist, a couple musicians, a writer, and a project manager how do you keep everyone on the same page about what the game is and what the game is not?  The Creative Lead or the Project Manager must be the arbiter of the contents of the game.  They must have a method for making sure that everyone on the project has a way of understanding that vision.  What is ‘canon’ and what is ‘not canon’, to borrow the terminology use by Star Wars (one of the most curated intellectual properties in existence). had a post recently about Game Design Documents.  Tadhg was commenting on a problem that all project managers have whether they are in game design or not.  It a bit like ‘scope creep’.  As a project moves forward stakeholders start to ask for new features.  Changes and additions start to creep in and your scope and project can veer wildly off course without careful curation.  A good Project Management Professor will warn about scope creep.  It sounds like in the Game Industry the GDD suffers from the same problem.

A game design document should not contain information about the overall project.  The game design document should be subordinate to the project document.  The project document should consider aspects of the project outside of the game itself.  There shall be no marketing information in a good GDD.

Game Design documents are not bad, and you should work with one.  Especially when you are new to this  field you can learn a lot from a good GDD template.  They are immensely useful for filling in the gaps of what you have and have not yet thought about.  They force you to consider aspects of the game which haven’t immediately jumped to mind.

The ZoRTS Project uses a great game design document.  It was made a number of years ago by Chris Tayor.  The document is linked to by wikipedia and hosted by Runaway Studios.  You can download a copy here.  If you are experience or running a game design company it may be a good idea to create your own format.  But if your an amateur use someone else’s document as a place to start.

If you have any doubts or internal conflict about what a game design document should be take a look at the Battlestar Galatica Series Bible.  The game design document should define the setting of the game, and how the game is played.  The UI and the HUD.  Get the flavor of the game into the document.  Record your ideas about the game and what it should be.  Make the GDD a repository for your games canon.  Make it a bible that explains the universe you want to play in!

Failure is always an option.

The Zorts Project is most likely going to fail.  TapDave asked me a direct question about the future of the project, and point blank the answer was “I am planning on the project failing”.   The reason behind that is the project may come to a point where we stop working on it.  That does not mean that we have failed.  Quit the opposite actually.  Learning something is never a true failure.

What are we learning from the ZoRTS Project?

There is, of course, another school of thought that only when you embrace that something could fail are you actually prepared from something great to happen.  Failure could even be the very thing that drives the economy!  What are your stories of success through failure?  Share in the comments!