Jump to content

  • Log In with Google      Sign In   
  • Create Account


Rigidity of a GDD


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
21 replies to this topic

#1 Milcho   Crossbones+   -  Reputation: 1171

Like
0Likes
Like

Posted 23 January 2013 - 09:07 AM

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?



Sponsor:

#2 WavyVirus   Members   -  Reputation: 735

Like
3Likes
Like

Posted 23 January 2013 - 09:14 AM

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

#3 Milcho   Crossbones+   -  Reputation: 1171

Like
0Likes
Like

Posted 23 January 2013 - 09:18 AM

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.



#4 WavyVirus   Members   -  Reputation: 735

Like
3Likes
Like

Posted 23 January 2013 - 09:48 AM

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.

#5 thade   Members   -  Reputation: 1484

Like
0Likes
Like

Posted 23 January 2013 - 10:44 AM

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, 23 January 2013 - 10:46 AM.

I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#6 kseh   Crossbones+   -  Reputation: 1551

Like
0Likes
Like

Posted 23 January 2013 - 11:03 AM

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.



#7 Tom Sloper   Moderators   -  Reputation: 7429

Like
1Likes
Like

Posted 23 January 2013 - 11:43 AM

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.


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#8 Tom Sloper   Moderators   -  Reputation: 7429

Like
3Likes
Like

Posted 23 January 2013 - 11:46 AM

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


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#9 Milcho   Crossbones+   -  Reputation: 1171

Like
0Likes
Like

Posted 23 January 2013 - 12:04 PM

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.



#10 thade   Members   -  Reputation: 1484

Like
0Likes
Like

Posted 23 January 2013 - 12:09 PM

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.


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#11 Milcho   Crossbones+   -  Reputation: 1171

Like
0Likes
Like

Posted 23 January 2013 - 12:12 PM

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.



#12 RealityFails   Members   -  Reputation: 153

Like
0Likes
Like

Posted 23 January 2013 - 05:25 PM

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.



#13 jbadams   Senior Staff   -  Reputation: 14682

Like
0Likes
Like

Posted 24 January 2013 - 01:40 AM

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. smile.png



#14 RealityFails   Members   -  Reputation: 153

Like
0Likes
Like

Posted 24 January 2013 - 02:30 AM

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.

#15 jbadams   Senior Staff   -  Reputation: 14682

Like
0Likes
Like

Posted 24 January 2013 - 03:02 AM

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. smile.png

Edited by jbadams, 24 January 2013 - 03:03 AM.


#16 Milcho   Crossbones+   -  Reputation: 1171

Like
0Likes
Like

Posted 24 January 2013 - 03:22 AM

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

 

 

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.



#17 Kylotan   Moderators   -  Reputation: 3163

Like
0Likes
Like

Posted 24 January 2013 - 12:42 PM

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.

Edited by Kylotan, 24 January 2013 - 12:42 PM.


#18 ApochPiQ   Moderators   -  Reputation: 12344

Like
1Likes
Like

Posted 24 January 2013 - 01:24 PM

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.

#19 Milcho   Crossbones+   -  Reputation: 1171

Like
0Likes
Like

Posted 25 January 2013 - 03:48 AM

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.



#20 MrDaaark   Members   -  Reputation: 3535

Like
0Likes
Like

Posted 25 January 2013 - 07:52 AM

Here is what the GDD for Grand Theft Auto looked like:




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS