What was that great idea again? - Why you should document your ideas early

I know that this blog is somewhat overdue and apologies for the lack of last week’s one. Other life commitments kinda got in the way - being ill sucks!

This week we’re going to discuss the all important GDD. For those of you that are unfamiliar with this term, a GDD is a game design document, it’s the bible that we as game developers try to stick to when developing a game. It contains everything for the team to understand the game's original concept through to story and game mechanics as well as art and audio direction and will often contain information about the technical elements of the game such as the game engine, information about rendering, Ai and other complex bits of the game. It’s main purpose is to keep the team on the same page throughout development and is often a requirement when working for a publisher to get your initial round of funding. A GDD is usually at least partially written before full production on a game begins…...and that's where we kinda fucked up…

You see, when we started development of Failure, we had the clever idea that we were going to forgo documentation as much as possible - this was mainly due to the over documentation of our previous project, The Tower (Which BTW, we will return to once we find an artist capable of filling Leo’s shoes). We felt all documented out!

We had the clever idea to just go ahead and build a number of prototypes, building on the game from there, and now that we’re quite far into production (We have a working playable game) we've realised that we really should have been writing some of the design down - the issue is that we've been discussing all sorts of great ideas for Failure during our weekly meetings but haven't really been writing much of it down and because of this, several ideas have changed or been forgotten and now that we’ve realised we need a GDD its been a pain in the arse to find an easy way to put it all together.

We finally started putting the GDD together around a month and a half ago and our original idea was to document everything that we had discussed so far within a traditional Word based document, but we've been really struggling with the way that these traditional documents are laid out, and it really wasn't very nice to read. So we did some research and came up with a solution. I’ll let Leigh take over from here as he’s written most of the documentation from the start.

Leigh:

As Justin has so aptly put it, we have recently come to learn that the classic form of the almighty GDD (Game Design Document) is something that can be more cumbersome and time consuming than it can be helpful and informative.

Don’t get me wrong, throwing out the GDD as a tool is not necessarily a good idea as it is a valuable cornerstone of production, it is needed to make sure that everyone involved in development are on the same page and this becomes even more invaluable for a distributed studio but we have realised that it needs to be a lot more nimble and easy to work with.

Our current GDD is in the standard form you would expect, a long and indistinct collection of paragraphs and pages which proves difficult to digest and time consuming to update. I have found that it can difficult to be confident that everything is as it should be when updating which can lead to confusion if there are any minor discrepancies. It can also make it difficult for people to really engage with the document and therefore brings up worries that the interest and excitement the game brings can be lost.

After doing some research in to ways of improving the GDD it has become apparent that there are some out there with views that GDDs may be a thing of the past, such as James Sweatman’s Death of the Design Document and there are others that advocate their use but have come up with other ways to produce these golden documents, such as Erin Robinson’s Alternatives to a Game Design Doc.

We've decided to take a more diagrammatic approach to the GDD by turning it into a large mind-map and have found it to be very useful in breaking down a large amount information into manageable sections that are more enjoyable to peruse as well as easier to update and attain the information that would have been held within pages and pages of endless text.

We are using MindMeister, an online mind mapping tool that allows live collaboration and has a whole host of tools that make it ideal for extensive documentation such as external linking, image and file embedding and version control. (Justin: I love collaborative tools :-) )

I am much happier in the route that we are taking as it has opened up a more colourful and interesting form that has allowed for easier digestion, more productive updating and improved engagement and iteration of ideas within the document itself.

It is certainly looking like an evolution in documentation could help us all to make strides in the future of development.

in closing -
I think the lesson learnt here is that when designing and developing a game, don't forgo documenting your ideas - perhaps the traditional route is right for you and your team, but if not, find a solution that allows you to stay productive and allows you to share your vision in a manageable way.

Our ideas might sound great during a discussion, but it’s only once you've written it down and really thought about it that you can start to see whether something is plausible….oh and prototyping, don't forget about prototyping.

Anyway, until next week...hopefully

Justin and Leigh

If you would like to read more about our journey as indie developers point your browser to www.dreamharvest.co.uk - also check out our current project at www.failuregame.com