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?

I suggest making a note of the possibility of bouncing projectiles, and then making the decision once you have a prototype up and running.

I suggest making a note of the possibility of bouncing projectiles, and then making the decision once you have a prototype up and running.

Right, that makes sense.

I probably should have omitted my specific issue though, as I'm not so much curious how to handle that, but more interested how rigid a GDD should be in general.

I see. I imagine the general consensus would be 'not rigid at all'. People will have different opinions about how much detail to put into a design doc before you begin prototyping/development, but few would argue that your initial design should be set in stone. Don't become too attached to the details of your plan, and be prepared to change or drop features if the realities of prototyping, playtesting or time constraints suggest that you should.

This is only a tiny bit tangential, but I'd be interested to see the initial design doc for XCOM: Enemy Unknown, which went through several major design overhauls prior to release. As I understand it, this kind of thing is not at all uncommon: i.e. adherence to a design doc is secondary to making a fun and complete game.

I had thought that the point behind a design doc was simply to get people interested in funding and working on a project, as well as to lay out the ground work to start development; during development a lot of stuff is going to change and you'll probably find the game will diverge quite a bit from the ideas laid out in that document. Really the difference comes down to this: when you call the design doc done and when you start really building your game.

Here's a very good read by GD's own Tom Sloper regarding design documents. Link.

I think one of the important functions of a GDD is to provide a consensus on what direction you're headed when you're working in a team. There could be multiple iterations of the GDD but over all you want to make sure the document remains stable enough that the team members can work consistently without worrying about wasting there time.

If you're the only team member then ask yourself whether the design change you're looking to make is going to be worth the time.

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?

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.

I had thought that the point behind a design doc was simply to get people interested in funding and working on a project, as well as to lay out the ground work to start development;

No. A GDD is a blueprint for the team. A design doc for pitch purposes is not the same thing. You cited my site - see the different kind of design docs described in http://sloperama.com/advice/lesson13.htm

I had thought that the point behind a design doc was simply to get people interested in funding and working on a project, as well as to lay out the ground work to start development; during development a lot of stuff is going to change and you'll probably find the game will diverge quite a bit from the ideas laid out in that document. Really the difference comes down to this: when you call the design doc done and when you start really building your game.

Here's a very good read by GD's own Tom Sloper regarding design documents. Link.

I'm obviously not looking for funding, and there's no one to motivate to work on this except for me. Laying out the ground work to program different aspects is pretty much what I'm using it for.

I originally started programming with a few ideas in mind, but they were getting too complicated to keep track of, so I had to write down how things are supposed to work, and iron out all the details, since the devil is always, always in the details.

I've visited Sloperama over the past couple of years (since I stared visiting this site), and it's been quite helpful, though expanding my gdd i ended up with a slightly different format. I guess I'm not much for motivational or exciting descriptions, because my general introduction is pretty crap.

I think one of the important functions of a GDD is to provide a consensus on what direction you're headed when you're working in a team. There could be multiple iterations of the GDD but over all you want to make sure the document remains stable enough that the team members can work consistently without worrying about wasting there time.

If you're the only team member then ask yourself whether the design change you're looking to make is going to be worth the time.

That's pretty much my concern - if I start editing the document too much, I'll never stop, hence this thread.

Even working alone, having a good idea what I'm doing isn't always 100% clear.

In any case, I guess like all other things, there's some golden balance to achieve with GDD changes. So far this is the first issue I've had to seriously stop to think about so, I'm hoping I won't get any more major rewrites.

I had thought that the point behind a design doc was simply to get people interested in funding and working on a project, as well as to lay out the ground work to start development;

No. A GDD is a blueprint for the team. A design doc for pitch purposes is not the same thing. You cited my site - see the different kind of design docs described in http://sloperama.com/advice/lesson13.htm

Ah, ty sir.