You've heard this phrase before: "it depends."

If you've been commissioned/hired by a client to code a pre-designed game according to their GDD, then you could negotiate a feature with the client.

If you've written this GDD for yourself or for your team (and you are the boss), then hang the GDD - make a fun game, and the GDD matters not a whit.

Yeah, obviously different circumstances offer different flexibility.

This is the 2nd serious project I worked on, and the first one I started with just a fun idea. I ended up achieving most of that, but without an actual game or finished task in mind, I had no idea where to go to next. I was also working with someone, and we had some different ideas on how to proceed. The combination of lack of a goal and the differing ideas ended up with me stopping work on the project because I lost interest.

So, this time, working alone, I decided to set myself more of a goal... the GDD was suppose to summarize my goal so I could keep track of what I'm working on. Like I said, I'm wary of feature creep, especially when working alone. I write some of this code, and realize how easy some feature might be (say a jetpack) to program, but then realize that writing that jetpack in would require me to setup not just the easy-ish physics, but a whole sort of inventory management to decide whether the player has the jetpack or not, because the game I had in mind does NOT focus on a jetpack feature at all...

Anyway, just as that paragraph got out of hand, my ideas kind of do the same, so I'm hoping to stick to a fairly constant document that lists the major goals.

I'm writing out a GDD for a game I've already started work on. I've spend quite some time trying to eliminate any unnecessary features, and to try to keep it as simple as possible. I'm quite wary of feature creep. It's also important to note that it's a one-man hobby project, so I don't have anyone else I'm accountable to.

But I ran into a minor thing which I'm not sure about. Basically I wasn't sure if I want a certain projectile fired by the player to be able to bounce off of terrain or not. It's a very minor decision, which I wouldn't classify as feature creep, but it opens up a possibility for a lot more puzzles.

So the core of the problem is that I haven't written the projectile in code yet.

I'm not sure if I should add this 'feature' to my GDD, and later remove it if I deem it not doable or unnecessary, or if I should leave this out, and only come back and add it to the GDD later if I find it will be easy to add and will improve the game.

But most importantly, I'm not sure how rigid a GDD is supposed to be... obviously rewriting the majority of it while programming will render it rather useless to begin with, and sticking to it like it's written in stone also doesn't seem that flexible to me (that sounded like a tautology..but you know what I mean). Should a GDD be followed as closely as possible with as few changes as possible, or should it be a more dynamic document?

A GDD can NOT be rigid. A GDD is always and always will be unique. I've asked many professional designers if my GDD is "wrong" and the answer is no. I think the complex thing is for you, is you're trying to code and be a visionary at the same time. You'll need another brain.

Should a GDD be followed as closely as possible with as few changes as possible, or should it be a more dynamic document?

You might consider "game design logs" as an alternative to a more traditional design document.

Should a GDD be followed as closely as possible with as few changes as possible, or should it be a more dynamic document?

You might consider "game design logs" as an alternative to a more traditional design document. :)

If you're not going to follow the design doc putting it together is pointless. I design mine for how I want the game done and leave the rest to my team.

A GDD can NOT be rigid. A GDD is always and always will be unique.

I think you might be talking about something slightly different -- the question at hand isn't whether or not a GDD must follow a rigid format, but whether you should stick to it rigidly once it has been written. A design document should be written in any way that communicates the information effectively but is it ok to stray from what the document says? If you stray from the original plan should you update the document?

If you're not going to follow the design doc putting it together is pointless.

Did you read the article I linked to? The point of a design log is to keep a record of your decisions and to help maintain a shared vision amongst team-members. It's not an approach that works for everyone -- and there are certainly good arguments in favour of the more traditional approach -- but it's certainly not pointless, and it's an approach that works well for some developers, particularly if they're taking an iterative approach that can be ill-suited to following a lengthy pre-written document.

You might consider "game design logs" as an alternative to a more traditional design document.

Hadn't seen that before. It's kind of odd how he starts off by saying "If you still practice or encourage the outdated practice of writing long design documents, you are doing your team and your business a grave disfavor." Maybe I just don't get it, but I think that ideas need to be laid out in some fashion, even for a single person team, in order to be followed better.

I can definitely see an advantage to constantly writing down your thoughts on the current build, along with problems and possible solutions. I may start doing that, but probably along side my current design doc, not instead of.

The only thing that sort of bugs me about the method he described is the 'Big, crazy experiments that move the game forward in big steps.". Since there's only some base concept at the start, it seems like any experiments like that are a great way to slowly let feature creep take over the project. I keep bringing that up, because during playtesting my own project, I constantly think "oh, this might be cool, and this might be fun"... which often time is totally tangent to the main idea behind the game.

Still seems like it might be worthwhile to start keeping a document with near-daily logs though, and I like the rest of the things he described there.

A document is a tool for communication. In a team collaboration your doc usually communicates the scope and details of future work to be done by others. They get pissed off if you keep changing it a lot because it interferes with their work, leading to wasted time or even people quitting. Hence it's a bad idea to change the design doc significantly while the team is working, as it delays the project. But the doc is just the artefact - the problem is that what you're telling your team has changed and so have their expectations.

If it's just you on the team, you're just communicating with yourself. As such it's more of a reminder than an instruction, and this is why a design log can be as useful as a design document - you already know the basic information that would otherwise go into a design doc, so you just need somewhere to note down the adjustments that you end up making to the original vision. But whichever way you do it, if the goals of the project change, and you will need reminding of this, change the doc.

If you're worried about feature creep, throw all your features into a list and prioritise them. Never add a planned feature without adding a priority. Revise priorities from time to time. Always work on the highest priority features that remain on the list. Ship the product whenever you're happy with it or when you reach your deadline.

Good GDDs are like design patterns in programming: they should describe what you are currently trying to do, and how you will accomplish it. They should emphatically not prescribe what is going to happen.

Iterative refinement is key. Don't start out on a fresh game with a design doc that details all your enemy types and their hit values and movement patterns. Start out with abstract goals: the player should feel this way, and focus on these actions; the bad guys should communicate this sensation or serve this purpose.

Then prototype it. Build it, even if it's just random numbers at first. Play it. Identify what works and what doesn't. Things that work get to have extra detail refined into the GDD. Things that don't work get cut.

The only time you should have a fully detailed GDD with complete descriptions of the whole gameplay experience is after you have shipped. Until then, everything is in flux, every tweak or change is fair game, and if you aren't iterating, you're dead.

A document is a tool for communication. In a team collaboration your doc usually communicates the scope and details of future work to be done by others. They get pissed off if you keep changing it a lot because it interferes with their work, leading to wasted time or even people quitting. Hence it's a bad idea to change the design doc significantly while the team is working, as it delays the project. But the doc is just the artefact - the problem is that what you're telling your team has changed and so have their expectations.

If it's just you on the team, you're just communicating with yourself. As such it's more of a reminder than an instruction, and this is why a design log can be as useful as a design document - you already know the basic information that would otherwise go into a design doc, so you just need somewhere to note down the adjustments that you end up making to the original vision. But whichever way you do it, if the goals of the project change, and you will need reminding of this, change the doc.

I know the basic info, but I can't keep it in my head with absolute clarity.

If you're worried about feature creep, throw all your features into a list and prioritise them. Never add a planned feature without adding a priority. Revise priorities from time to time. Always work on the highest priority features that remain on the list. Ship the product whenever you're happy with it or when you reach your deadline.

Yep, that's what I started with. I still maintain one, it's just far more developer focused than overall design focused though. The gdd is the game design side I needed to keep track of.

The only time you should have a fully detailed GDD with complete descriptions of the whole gameplay experience is after you have shipped. Until then, everything is in flux, every tweak or change is fair game, and if you aren't iterating, you're dead.

I realized after all the comments on the thread that iteration was key. It makes me feel less constrained by the original document and makes me feel less guilty about trying out new features and amending the document as I go along.

Thanks for the replies people.

Here is what the GDD for Grand Theft Auto looked like: http://www.scribd.com/doc/53563149/Grand-Theft-Auto-Design-Document