The last few weeks we’ve been working on the initial version of a Game Design Document for a new project we’re working on.
We’re pretty much required to produce one for our publisher as it’s important to communicate the project as the game was signed off a higher level concept. It’s also very useful to us internally though as it helps us run through the ins and outs of the mechanics and the balancing issues that we’ll be facing on the project.
The topic of usefulness of GDDs has come up in recent weeks on a few forums, spawned by Sean Murray of Hello Games calling them insane (for their team and possibly he meant for Joe Danger) http://www.eurogamer.net/articles/2010-10-02-hello-games-design-docs-are-insane
My current opinion on GDDs would be
- It’s very useful to write down ideas, it helps identify issues before you start coding which you might have missed in your mental map / whiteboard discussions or even prototypes (depending on which way round you’re doing things). Also some people’s brains are wired so that actually writing down or voicing an idea makes them analyse it in a certain way. I certainly find this with difficult coding issues that talking it through with someone I’ll sometimes realise I’ve got an answer locked away.
- Having a GDD makes it easy to send out to contractors and to give to employees new to a project. They can quickly understand the full project, the designers intention and the planned implementation for it.
- Linked to the above point it’s vital for providing to QA teams who need to verify that things are functioning as they’re intended, especially in terms of edge cases with particular mechanics.
- And as I originally stated they’re almost required for certain projects to provide to everyone from our external producers, external marketing and business teams (who need to understand the game early in the development process to plan / look at possible opportunities) and lawyers to understand what we’re aiming to pull off with the project.
- The biggest problem with GDDs is the amount of change that occurs especially in early development and the GDD not being updated to replace it. This effectively gives GDDs a use-by date after which you need to take it with a pinch of salt. Companies tend to use wikis and other live documentation systems to counter this but unless someone is actively maintaining it things can still easily slip when more important production tasks come up.
- Even worse than not updating the GDD is people not actually reading it! The initial GDD I’ve been writing is 50 pages in total (and will get longer as information on particular items and NPCs is inserted) and more than a few read-throughs could be time consuming. Highlighting changes and structuring the document well for referencing is essential to aid with this.
- Wasted development time – writing / maintaining / reading the GDD could be spent just developing, testing and iterating on the project and for smaller teams as Sean mentioned this can be a much more efficient route.
Iteration is vital to the design process which Sean hinted towards, you can’t just write down the recipe for the game you need to actually cook it (and then experiment).
We’re fortunate in that we’ve organised our current pre-production to occur before we deliver what we deem to be ‘THE’ GDD and TDD for our project, this should hopefully get us closer to the line on the documents than we normally would be at this stage in a project.
Personally I find the writing and structure elements of GDDs the hardest. I’ve regretted going from OneNote to Word too early in the process – a few days were spent cutting + pasting parts around the document trying to get the flow of things right.
It’s also important to keep a consistent writing style to allow easy reading and also getting across the fun of what you’re describing (especially when selling the idea to marketing who may not be as invested in the project at an early stage). I’m not sure how well I’ve mastered this yet but fingers crossed 😉
Hopefully I’ll be able to talk a bit more about our pre-production process over the coming weeks.
Things we’ve been enjoying this week
- A great post by industry veteran Simeon Pashley showing the breakdown of costs involved with running a games studio. He has stolen one of my future blog post ideas but I couldn’t have done as good a job as he has
- This shows how much being a solo dev working from home / remote team can earn you extra on a title with decent sales. There are benefits to having and running a studio however which is why we still do!
- Trainyard http://struct.ca/ by Matt Rix, it’s very likely you’ve already seen this great iPhone title as it’s in the top 5 pretty much everywhere in the world!
- Countering the Minecrafts of the world this is a breakdown of financials on AI War and Tidalis and the struggles they’re facing.
- EA have open sourced their WebKit implementation which also includes some of the EA STL. I presume they are forced to due open source a lot of this due to some of the viral source licenses in there. Looks like they’ve packaged it nicely and pushed it out to the public though which could be useful for some people.