![Blog-[x]cube LABS](https://d6fiz9tmzg8gn.cloudfront.net/wp-content/uploads/2016/06/blog_banner.jpg)
BLOG
No One Reads My GDD?
-
By [x]cube LABS
Published: Jul 01 2013
The problem with writing a well-defined and articulate game design document is that the only one who ends up reading it is the one who wrote the document to begin with – the game designer!
Being repeatedly questioned and asked about game features clearly outlined in the GDD is not exactly a great way to jump start development, if not downright irritating and many times, wildly infuriating.
Since people aren’t going to start behaving according to our game rules (i.e. read the GDD!) any time soon, it is up to us to design creative alternatives to cross this particularly hard level. Here are some pointers that effectively communicate game design and ensure relevant teams are on the same page even if they scored an F on the GDD.
Get a mood board
Put up a mood board and start pinning images. Since pictures speak louder than words, make use of pictures to communicate your design; tag them correctly and structure it in a manner that the viewers can form the relationship between images and understand the game. Let those involved with the game pitch in too with their images, making the entire exercise symbiotic. But ensure it is about the game as it is or is being designed.
Use a mind map
Use a mind map to share the structure of your design. Let the elements and sub-elements be structured according to the parent-child-sibling models. This provides at a quick glance what the design is and how the different components relate to one another. Keep it at just a one pager, as more people will end-up reading this than the GDD. Don’t leave out any thing important.
Call in a design meeting post submission
After the straight-off-the-press GDD has been submitted, call for an all team meeting to explain the design and all questions. This doesn’t solve all problems but is much better than assuming that the participants will read the GDD and understand the game (which they won’t, sooner or later this becomes evident).
In this one-time meeting, clearly state the game first (all of it), including dependencies and what needs to happen to complete the game design e.g. proto/tools needed to finish the game, the design elements that will come later, etc.
Obviously, these won’t solve everything but it is a start. Use what works with your team! The GDD is a means to an end and not the end in itself.