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?