Game Design Documents

I'm not much of a game dev yet, I've only gone through some tuts for Unity. I'd just like to make sure I'm on the 'right' path from the beginning and won't have to unlearn bad habits later on.<br><br>One of the things I learnt about game development is a game <i>must </i>have a Game Design Document. I had a friend who went to Digipen who drummed this home. What I was wondering is how important that is for indie games. I would guess Digipen etc. train you for "big" projects, where you might have to communicate ideas to a team of upwards of 10 people over a long time.<br><br>Of course, there are advantages to documenting goals and ensuring you're on track with the game you intended to make. What I was wondering is how you structure a GDD in an indie environment, where your advantage is being loose and free. Evan's talk last night highlighted the importance of iterating ideas and scrapping bad ones early, but if you have a rigid design document how do you plan that?<br>

Comments

  • A GDD is a gigantic waste of time in my opinion, especially for small indie studios where keeping the document up to date will take more time and effort than actually making the game!<br><br>In any case, if someone thinks that they can plot every fine detail of every game mechanic in advance, without playtesting and iterating along the way, the game is either a blatant clone of something already out there, or the final product is destined to suck.<br>
  • edited
    <p>So, I wasn't at Evan's talk, and I'm not much of a game designer, but... :P</p><p>From my meagre understanding, you want to write the GDD once you're pretty sure you know what you're doing. So you've already written a whole bunch of prototypes for this game, experimenting with a bunch of different game mechanics, discarded prototypes that just aren't fun, and you've narrowed things down to something that you're confident is worth spending months, years, taking to completion. Only then do you write the GDD. Writing it before then is setting yourself for failure, because you're spending a lot of time writing something up in theory, instead of testing whether the idea has any practical value.</p><p>A GDD is supposedly useful because (1) it forces you to think about a lot of stuff that you might put off otherwise, and therefore build yourself a more solid understanding of how much this game's going to cost to make, and (2) it serves as something your team can refer to as they work on the project.</p><p>I only have experience with the latter, and while I find that a GDD (and prototype) is quite useful for getting people up-to-speed with what the game is, and how you expect things to work, their usefulness diminishes a lot as the project continues. As the GDD gets revised, and people are busy with their own work, having to keep up to date with revisions of your doc is a horrible use of time. While they should have access to the GDD and be able to refer to it whenever they need to, keeping it up to date is a big hassle, and getting people to read it is just as big a hassle. (To the point where you might as well not have one.)</p><p>It's definitely useful to keep records of stuff while you work, and perhaps be writing smaller "GDD-like" documents for people to focus on, as well as to prevent yourself from forgetting about some great idea (because there are often many of those flying around, and it's easy to lose track of them), but having a giant tome of all the stuff... isn't useful in my experience in smaller teams. And while I can see how it may be valuable in a larger team, it feels like a patch that works around communication problems, rather than being a proper solution.</p>
  • <font face="Arial, Verdana" size="2">All it takes is one document out of date, and then, all of a sudden, nobody trusts any documentation, and it all becomes a big waste of time.</font><div><font face="Arial, Verdana" size="2"><br></font></div><div><font face="Arial, Verdana" size="2">I had to open with that, unfortunately I can't remember who said that it was just my GTalk status for a while.</font></div><div><font face="Arial, Verdana" size="2"><br></font></div><div><font face="Arial, Verdana" size="2">GDDs can be really cumbersome and time consuming. If you are spending more time making and maintaining docs than you are making games. You are doing it wrong (exception you are a producer). A GDD is used to communicate an idea with people who are working on the game.</font></div><div><font face="Arial, Verdana" size="2"><br></font></div><div><font face="Arial, Verdana" size="2">You should write things down! Carry a pen and paper, or tablet and stylus, and write down ideas, diagrams, sketches as they come to you. It is really annoying when you go "I'm sure I worked this problem out earlier, but I can't remember it"</font></div>
  • Your GDD doesn't have to be a formal document with chapters, sections and sub-sections.  It could be a mindmap, a task list, Evernote snippets or plain-old text doc; any suitable container that you're comfortable with.<div><br></div><div>You're correct on both points that the purpose of a GDD is to communicate ideas and intention between multiple people, and there's value for an individual to keep track of ideas and progress.  As a team grows the importance of a well maintained document is essential and hopefully, because you have more people, you can have someone at least partially dedicated to maintaining it.  It's also valuable for the individual to keep focused on a particular task by committing other ideas to off-mind storage; and as encouragement during low times to see all the completed items marked off.</div><div><br></div><div>As a hobbyist developer I use a combination of: a tasklist (provided by GitHub or BitBucket for free along with my version control); good commit messages; and a changelog text doc bundled with project releases.  I don't always keep the tasklist well maintained but I go through regular passes of updating it; and I update my changelog before I share a build so people know what to test. The good commit messages goes without needed further comment other than ALWAYS DO THIS!</div><div><br></div><div>What Evan was talking about is agile development with high iteration and short planning cycles; versus a waterfall methodology based on a full design process and change control.  The truth is though, even with the most agile of methodologies you still need some document, however light, giving an overall view of the game to all team members; even if you're not sure how you're going to implement each element and extent of all the gameplay.</div><div><br></div><div>Work with what's comfortable, because Karuji is right; at the hobby/indie level, if you're spending more time on documentation than game dev, you're probably doing it wrong</div>
  • For a website that's been up for like a week, it seems super active :)<br><br>Interesting points. I hadn't actually thought of the possible negative out-of-date documentation would have on a team. Maybe the form of a single document in itself isn't really fit for purpose - something along the lines of a wiki/set of documents that can be edited as developments are made. Anyway, I suppose that becomes defined by the style of organisation the project needs. <br><br>I guess to me, the document would grow in complexity as the game itself becomes clearer. For instance, I want to start on a platformer with a character and his mount. Which is pretty much my entire document at the moment :) I have some ideas to test of various things that might be fun but might turn out shit, of course  As I get an understanding of what works for the game, I can start documenting it and describing the core of the game. Once that skeleton structure is in place, it would start formulating a to-do list and so on. Does that sound about right?<br>
  • edited
    GDDs are an interesting part of what I consider the "legacy" of game development, much like the concept of "engines" that are your one-stop shop for all the shit your game needs to do.<br><br>The classic GDD as a design bible for everything that's going to be in the game before one line of code or one model is even made doesn't make sense anymore. At the same time, you do need some central place that can act as a place to find answers to questions that you or other team members will ask about the game as you're working on it. As such it's better to start with a bunch of questions about the game that help you define your goals with the game. It's also a good idea to use that document to look at questions that come up as important through experience, things you wouldn't usually think about while in the rush of writing down that killer idea.<br><br>Good questions to start with (that I try to answer with every random game idea I have) are:<br><ul><li>What actions are your players going to be performing, what are their goals and why are they playing.</li><li>What emotions are you trying to create in your players, what are you relying on them feeling when they start playing and when they stop?</li><li>What is the minimum setup you need in order to test your answers above?</li></ul><p>Note that these are pretty general questions, they can apply to a boardgame, hardcore multiplayer FPS, casual FB game, ARG, nearly anything. I like them because they make me think about players and I'm typically a mechanics-focused designer.</p><p>At QCF we have a design wiki (that ties in with our SVN server, Trac is pretty damn awesome) that we use to lay out art, sound and music needs, or plan out larger sections of the game in terms of progression or text needs, that sort of stuff. We use that mainly as communication with team members that are far away. Basically if it's going to take a while before we can see something and test it in the evolving prototype, it gets attention in the design wiki.</p><p>We also have a design lunch at the start of every week that we use to talk about what we want to do with the game for the rest of that week. We'll consider community feedback from the beta, design puzzles and classes, work our way through what the crap bug X might be, etc. At the end of that meeting we have a list of all the stuff we've decided to do, which then gets emailed to everyone on the team and we all reply to that email with whatever we're currently working on. When something is done, we record it in the changelist on the design wiki and every week we archive the changes as we release new versions.</p><p>Obviously our needs with DD are pretty different to a game that you're not constantly releasing to the public, but the core things are:</p><ol><li>Rapidly evolving prototype - version control is amazing for this, use it!</li><li>Weekly review and design meetings, produces todo list and task assignments.</li><li>Track your changes as you make them.<br></li><li>Design wiki to store anything that's going to take longer than a week to do.</li><li>Play test, play test, play test!<br></li></ol>
  • edited
    I believe that Notch (Minecraft) makes post-its that he categorizes instead of a massive design doc, likewise Toady (Dwarf Fortress) keeps a list of things that he wants to add in point form. He generates the ideas from stories that his brother rights. <div><br></div><div>Essentially, both of them work like the "Kanban" style of doing things, where they keep a feature-list which they then manage. The thing is that they try to keep it as simple as possible. Nobody likes writing documentation really (also who reads it).</div><div><br></div><div>P.S. we use Jira, moving to GIT, and confluence (corporate though, not gamedev).</div>
  • I use a project management website (Zoho projects) for keeping very informal docs for me and my team. I don't use all it's functionality, as I think that would be a waste of time. I set task-list however, which I can later tick off as I complete them. Sorta like a to-do list. Keeps me motivated as I tick them off!<div><br></div><div>It also has a wiki, where I document particularly nasty bugs I ran into (so if some of them manage to re-occur I know what their cause was). I also document basic mechanics, just so that I know everyone on the team is on-par. As I said, it's a pretty informal process, but it keeps my mind at work!</div>
  • <font face="Arial, Verdana" size="2">We used to write large-ish GDD's, but more recently, a summary of the idea, and a list of it's features are just fine. After that, when you actually get to creating the game, a large list of tasks forms. The iterative nature of game development makes it quite the task to keep a GDD up-to date and listing everything that is actually needed.</font>
  • <span style="font-style: normal; ">I feel I need to point out that a GDD isn't only for the developers benefit but also for contractors and publishers.  It's something you can share with testers to know what functionality and results they're </span><i>supposed </i>to expect and outside developers, artists, sound engineers, actors, etc who haven't been to your meetings and idea sessions need to know what you want them to do.<div><br></div><div>Finally, often the money holders will require some kind of document so they can attach it to a budget and make suggestions and changes to scope so that you have enough money to complete the project.  Often these are non-technical people, so the language of your document has to be appropriate so they don't rip your game to shreds.<div><br></div><div>I just wanted to mention this so that no leaves here thinking GDDs are a complete waste of time.  They have a place; and if you want to work in a AAA studio or run your own one day, you'd benefit from learning how to write and maintain a full GDD. But one isn't entirely necessary for hobby or indie development.</div></div>
  • @aodendaal: I dunno, I really don't think that traditional GDD bibles are that much use anymore. Of your examples of their use outside of regular development, I'd say that the tester interface is probably the most likely, but even then expected behaviors are really easy to pull from changelogs: "Set player mana to scale at lvl * 5" becomes "Player's mana should grow by 5 per level, barring other modifiers".<br><br>I'd caution that using a GDD as a budgetary guide is probably going to be wildly inaccurate - you can do time estimation with a very high level overview of what needs doing, which a good investor will then multiply by pi anyway. Plus detailed GDDs often get pulled apart into detailed milestones, which will always end up screwing you over as you learn more about the game while working on it and change something. Arguing to get milestones changed is not a productive use of your dev time.<br><br>As someone that runs a studio, we definitely have processes in place, some of them might even look a bit like detailed GDDs by the end of a project, but the way we produce them is completely different to the classic front-loaded detailed GDD.<br>
  • edited
    <font face="Arial, Verdana" size="2" style="font-size: 10pt; ">I think the way documents are created and used are highly dependent on the process. In our current project (10 team-members, 6 months development), we made heavily use of a GDD.</font><div style="font-family: Arial, Verdana; font-size: 10pt; font-variant: normal; font-weight: normal; line-height: normal; font-style: normal; "><br></div><div style="font-family: Arial, Verdana; font-size: 10pt; font-variant: normal; font-weight: normal; line-height: normal; ">In fact, when I came on board there was a 125-page design document. (Anyone who has made a game will probably know that that almost gave me a heart attack the first time I saw it). After about a month or so, we cut the thing down to ten pages. We started to prototype, and the game designer (<i>not </i>the originator of the 125-pager) kept the doc up-to-date. The team was spread all-over the country, so the document was a quite valuable reference. During this phase, some parts got fleshed out quite a bit:</div><div><ul style="font-size: 10pt; "><li><font face="Arial, Verdana" size="2">various input systems (we tried out 5 different ones),</font></li><li><font face="Arial, Verdana" size="2">the transaction model / flow,</font></li><li><font face="Arial, Verdana" size="2">the interface flow (near the end of the prototyping phase).</font></li></ul><div><font size="2"><br></font></div><div style="font-size: 10pt; "><font face="Arial, Verdana" size="2">My experience with the design documentation, for this project:</font></div></div><div><ul style="font-size: 10pt; "><li><font face="Arial, Verdana" size="2">It took a long time for people to trust them. (I mean, they would rather ask someone than refer to the doc, everyone was scared the docs were out of date).</font></li><li><font face="Arial, Verdana" size="2">It's hard work to keep them up to date. At one stage we landed in trouble when so many changes were made it took a few days to get the docs up to date.</font></li><li><font face="Arial, Verdana" size="2">When we started to do balancing, a lot of tweaks were made to the core mechanics (not just the numbers, also the way they worked). We did not even try to keep it up to date; these were implemented, tested, refined. At this stage... some of us actually lost track of some off the details (recently I couldn't even tell for sure whether our character was supposed to level up or not).</font></li><li><font face="Arial, Verdana" size="2">Specific sections were very useful to limit the Skype traffic (which was quite extensive as it was).</font></li><li><font face="Arial, Verdana" size="2">The document was very useful to make broad-stroke cuts to the game as we went on (which we did quite aggressively). Do we really need a complicated unlocking system? Cut it! An inventory? Cut it! </font></li><li><font face="Arial, Verdana" size="2">The document was not useful for scheduling. (The technical documentation and assets lists were more useful for this, although these were updated on demand, so could not be used for long-term planning). The biggest reason for this is that the tech behind functionality is not always obvious. For example, the movement of the character is fairly simple in the design document: walk, shoot, idle. The code for blending the animations nicely, starting and stopping them at the right times, doing all the required setup, is much more hectic than the few lines in the GDD would suggest.</font></li><li><font face="Arial, Verdana" size="2">The GDD was not really used as a feedback mechanism; instead, we used a private development blog and weekly builds, which I think worked much better to convey where we actually were. (This, I suppose, depends on the kind of stakeholders you have; I can imagine situations where more upfront detail will be required).</font></li></ul><div><font size="2"><br></font></div><div style="font-size: 10pt; "><font face="Arial, Verdana" size="2">For small project, 2-3 people (6 months), there is way less need for documents. Some projects that I've worked on did not have any documentation (and it was not really missed).</font></div></div><div style="font-size: 10pt; "><font face="Arial, Verdana" size="2"><br></font></div><div style="font-size: 10pt; "><font face="Arial, Verdana" size="2">Some projects I've worked on had so much documentations that no-one knew where was what. It was always a big mess (you could basically always find <i>some </i>document to support a new feature or some change).</font></div><div style="font-family: Arial, Verdana; font-size: 10pt; font-variant: normal; font-weight: normal; line-height: normal; "><br></div><div style="font-family: Arial, Verdana; font-size: 10pt; font-variant: normal; font-weight: normal; line-height: normal; "><br></div>
  • Here's some additional guidelines for design docs.<br><br>The most important reason for a design doc is to make information available to the team so they can do their work.<br><br>The GDD can be a single doc or multiple docs.<br><br>The information should be clear, easy to find and easy to update.<br><br>"easy to find" also includes having simple file names/folder structures, keeping number of docs to a minimum/giving people only the docs they need to read (e.g. there's no need to force the texture artist to read the sound effects doc. So the sound docs can be separate from the art docs. But still available if the texture artist wants to read the sound docs).<br><br>"easy to update" also includes the approval process of ideas and features.<br>It's a good idea to have one or more people (ideally only one person) to be the "keepers of the scope". <br>Herman knows what I'm talking about :)<br>The keepers will have the final say on which features/changes make it into the game (i.e. into the GDD). Their job is to protect the team against feature creep.<br>As mentioned above, people stop referring to the docs if they are constantly changing or out of date, as a result of decisions being made willy-nilly. (If your keepers make decisions willy-nilly then you are in trouble.)<br>Of course, if the whole team feels different about a feature not included by the keepers then the keepers should be open to change.<br><br>If you are going to use a publisher then you will need a GDD.<br>The publisher views the GDD as part of your project plan.<br>In other words: in order to schedule a project you need to quantify what you are going to do.<br><br>The publisher may request a summary doc and a GDD.<br>The summary doc lists all the features of the game.<br>The publisher will first read the summary doc, and refer to the GDD for more information about certain features in the summary doc.<br>For example: The summary doc may state the player will fight 5 types of enemies in level 1. The GDD (or a separate Enemies doc) will contain the details for the 5 types of enemies (e.g. their names, concept art, AI behaviours, weapons, texture sizes, etc.).<br><br><br>
  • Just a quick question, has anyone had any success with using a issue tracker (JIRA or the like) and building the document from the open features / what has been done?
  • edited
    I'd warn against design docs. There's nothing wrong with planning what you're going to do, Todo lists are great, but writing a design doc to define your game is going to hurt you.<div><br></div><div>This is more what I think is going to help you: http://www.lostgarden.com/2008/12/post-it-note-design-docs.html</div><div><br></div><div>The most important is leaning over and talking to your teammates. I do actually make design docs, but my team mates never read them... so for me they're just a repository of ideas, like a cool image I saw or a gameplay mechanic I noticed that I want to try. I guess thats more like a design journal for not forgetting things than a design doc.</div><div><br></div><div>The only time detailed design documentation helps is when you just want to finish stuff. Most people work faster when they don't have to think. But that's only really applicable right at the end of the development cycle when you're fixing bugs and such.</div><div><br></div><div>Working for clients, or working with remote teammates does complicate the matter obviously. The talk I gave was specifically for small teams working on original titles. In a small team working on your own game I'd definitely recommend against a traditional design doc.</div>
  • @avanderw: We use TRAC for DD. It gives us a wiki and a bug tracking system that tie into each other AND hooks into our project SVN as well. It's been great so far and I know that we could be using it better (automatically pulling changelogs out of resolved bug notes, for instance).<br>
  • @dislekcia Your tag confuses me every time I have to write it.

    Yeah, I have been involved in setting up such systems a few times. If you have a team <10 I highly recommend the Atlassian products. They are the best I have worked with so far.

    Besides that, it really is nice to have your bug-tracking system setup to keep track of your change logs and roadmap, likewise it is awesome to have a nightly build that integrates to your tracking system that keeps track of failed builds. Still trying to find a nice way to hook up wiki's to the whole process.

    SVN / GIT integration is no longer a nice to have, it is almost a must. Allows clean tagging of builds and feature requests / bug fixes.

    I have never tried to create a design document from a tracking system though, thus the question.
  • I used JIRA and Confluence a fair bit in my previous job (non-gamedev). Confluence was awesome, but that was only because all the devs embraced it and made regular contributions. Any sort of wiki software will do though. Any solutions to intricate problems should be documented (such as a tricky api, or weapon upgrade system, etc). You be surprised just how often you need to refer to something down the line, even when you're the one that wrote it.

    I also like to have a description of the game here that at least gives people the "gist" of the game, and maybe gives them an idea of how things should work. Suppose this would be a summary doc.

    One thing I do like about a GDD / design documents in general is that they force you to think about systems and consider them properly. Sometimes this forces you to thrash out challenges instead of just waving a wand over it and assuming you'll figure it out later. Though it's naive to think this will eliminate all surprises.

    Even if no one ever reads the doc, at least you still have a much better idea of how things fit together in your head when people ask you questions. Definitely want to keep the level of detail to a minimum though, and I like to only pay attention to areas I feel are tricky and not obvious.

    Also backing up design docs with a working prototype can do wonders for helping people understand how things should work. This can also backfire if they don't understand what the prototype actually represents. Also helps nothing if the prototype hasn't been implemented yet.

    @avanderw JIRA is way verbose and over engineered IMHO. but it did the job. Haven't had much experience with alternatives, but I know there are lots out there. Pulling docs from tickets seems interesting, but I guess that relies on having accurate tickets in the first place. Don't know if a truly automatic system would ever be possible without at least some manual editing.
  • TheFuntastic said:
    One thing I do like about a GDD / design documents in general is that they force you to think about systems and consider them properly. Sometimes this forces you to thrash out challenges instead of just waving a wand over it and assuming you'll figure it out later. Though it's naive to think this will eliminate all surprises.
    You would think that. But I've seen, and written, docs which only deal with things at a high. Writing in the algorithm for enemy movement is not really something that a client wants to see when you send them the doc.

    I like your point about the prototype, but ultimately you can generally convey things better through a prototype than a GDD.
Sign In or Register to comment.