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
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 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.
I like your point about the prototype, but ultimately you can generally convey things better through a prototype than a GDD.