Game Design Documentation and the System of Record

If you are familiar with game development and programming, the concept of a Game Design Document (GDD) should not be unfamiliar to you. The GDD's main purpose is to provide a full-scale description and specifications for a game concept or idea. This kind of document or something like it is crucial for the planning and design phase of game development. Without it, there is no way to solidify a concept and take it from conception to completion.

But it tends to happen that the GDD is written once, abandoned and other documents are used in its stead. I've been a part of teams where a GDD is devised, "completed", and then a similar document with more technical specs is built in its place. It is the recommended practice to keep a GDD as the living document of the project, but this tends to be the case less and less.

And I understand that it's hard, at the conceptual phase to build structure, content and features that make sense for the scope of the game. But just because the GDD is the starting point of most games does not mean it is a stepping stone! It is my belief that the initial GDD should be the system of record, or the most up-to-date source of information regarding a project.

Here is a copy of a GDD provided on google drive. You will find that only around half of the document surrounds gameplay (Sections 1, 2, 4, 6, 7). The rest involve UI, technical specifications, art, content and GTM plan. This document is more than just a starting point, it's main purpose is to take you through the pipeline to near completion. Surely other documents will come into play, but to recreate what is already encapulated in this document would otherwise be a waste of time.

I do not think I can do this concept more justice than is done here on Gamasutra, a post called "The Anatomy of a Design Document" by Tim Ryan. The document serves a multitude of purposes none of which is more important than the other. Some examples being:
  • Elimininating the hype* - setting a clear scope and direction for the grandiose ideas
  • Detailing things clearly* - making what seems abstract in concept more clear from a development standpoint
  • Testing against a rubric - what caused this game's conception? 
I hope that I've pushed the point enough - the GDD needs be a part of the development process from start to finish. Keep it up to date. Refer to it regularly. Add bookmarks for clear delineation. 

Now that that's out of the way, I am excited to inspect the non-dev related segments of the GDD in a following post (legal considerations, cost analysis, go to market strategy, art and content).

-stencil chris

You may also like

No comments :

Powered by Blogger.