Jump to content
  • Advertisement
Sign in to follow this  
MilchoPenchev

Rigidity of a GDD

This topic is 2064 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
I suggest making a note of the possibility of bouncing projectiles, and then making the decision once you have a prototype up and running.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Edited by thade

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!