Game Design Docs

Posted on October 16, 2010

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

  • Positives
    • 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.
  • Negatives
    • 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.

Thanks!

Things we’ve been enjoying this week

  • http://game-linchpin.com/2010/10/where-the-money-goes.html
    • 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!
  • http://gpl.ea.com/skate3.html
    • 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.
Be Sociable, Share!

Tags:

5 Responses

  1. AyreGuitar
    October 16, 2010

    Interesting article. I’ve found storyboards work better than Game Design Documents. Once you have to visualize the game on screen a lot of potential issues are exposed. Plus there’s more chance that people will actually ‘read’ your document and understand it (50 pages of a game design ‘comic’ are much easier to digest than 50 pages of dense game design copy). I’ve had much success with this at Sony/Psygnosis for Assault Rigs (for game power-ups) & G-Police (for the weapon types and visual effects) and more recently with Mario Pinball Land (for general gameplay). Of course it needs somebody who can communicate the ideas in Storyboards.


  2. admin
    October 16, 2010

    Hi thanks for the comment.

    I completely agree – storyboards are brilliant especially for playthrough descriptions, my art skills aren’t too hot unfortunately!

    Also I enjoyed Stone Librandes talk about One Page Designs as a way to think more about condensing design specifications
    http://www.stonetronix.com/gdc-2010/

    Simon


  3. the Jack
    October 17, 2010

    I find that for our purposes, creating a document that goes as far as needed to “prove out” the game on paper is a necessary part of development.

    Seeing how different planned mechanics will work together can help avoid a lot of heartache and lost development time later when faced with sticky questions like “how does action A work on result B” or “what’s this reward system supposed to do again”?

    Using the GDD as the main arena for throwing stuff against the wall and getting really crazy with ideas is fundamental, too. It’s here that the real scope of a project can be decided.

    Having said that it’s important to create a document that serves as a guide and framework, but not something that needs to be slavishly followed. It should be flexible enough to allow for the inevitable changes that come up in iteration, but also protect as much as possible against resource-killing feature creep.

    Going without this level of planning is fine if you’re a hobbyist working without deadlines and limitless resources, but for someone interested in getting a product to market at least the very bare-bones of an outline will work wonders for producing a shippable game.


  4. Simeon
    October 19, 2010

    I’ve witnessed occasions where the motivation for requesting wasn’t that the publisher was ever going to read them in detail, I’d guess that some Producers wouldn’t even understand what the hell you were talking about.

    It was partly to force us to *really* think about what we were doing and how were going to do it and therefore put some get a level of confidence that the schedules & costs were in the right ballpark. They also serve the purpose of making sure expectations on both sides are the same.

    I’ve certainly worked on teams from 5 people to 80 people with massive sets of documentation/wikis/intranets that never gets read by anyone actually making the game, much to the chagrin of the designers.

    I think it’s true to say that everyone recognises they’re going to change anyway as you can never anticipate everything and even the smallest change can have dramatic effects on the whole of the game design.

    Would you really throw away a truly brilliant idea 1/2 way through development because it wasn’t written up in a document? I doubt it.

    GDD’s are obviously largely irrelevant if you’re just making the game for yourself or with a small team as there’s no real external stake holders you need to keep happy. It really depends on what you feel you need to make the game.

    When I make my own games I like to go ‘commando’ and just let the breeze take me. πŸ™‚


  5. […] Game Design Docs – pros and cons (Four Door Lemon) […]


Leave a Reply