Sign in to follow this  

GDD Level of Detail and Completeness?

This topic is 831 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

This is something I've never really been able to nail down for myself, and I am curious about the opinion of others: how much detail should a game design document contain, and how complete should it be?

 

Let me elaborate....

 

Where is the line between a "sufficient" amount of detail and an overwhelming document?  Does this come down to game priorities/direction?  Should I be concerned that more detail probably means more deviation from the "day 1" design document as the game progresses?  How much about the final product should I actually assume I know/understand when sitting down to write the GDD?

 

I imagine the thoughts on this can widely vary depending on the type of game, the size of the game, the make-up of the development ecosystem (i.e. self-funded vs. investor funded, large team vs. small team), etc.....or maybe it's simply one of those "look, you've really overthought this" scenarios (I've had my fair share).

 

Anyways, I'm interested to hear different opinions and the reasons behind them, and would love to know the thoughts within this community!

Share this post


Link to post
Share on other sites

Well the game design document grows as the game gets developed, especially if you have a section which is an index of links to all completed assets.  And whether you include the script or spreadsheet of flavor text or w/e in the design doc.  A good first draft of a GDD might be quite small - a few paragraphs describing the vision of the game followed by a features list with brief descriptions of each feature.  You might want to then add blank sections to be filled in later, like staff hierarchy and responsibilities, control scheme, UI, platform, 3rd party software, engine, programming language(s), graphical asset types and sizes, audio asset types and sizes, locations or levels, quest chains, NPCs, avatar system, development milestone schedule...  A game design document can also be used for lists of assignments for staff asset creators, then the created asset is linked to the description...  A lot depends on the type/size of game, and some people prefer a development wiki to a document which suggests a different way to structure your information...

 

Edit: The question of creative control vs. collaboration is relevant too.  The main reason I don't have several complete design documents sitting around is that I would really rather create a game's vision collaboratively with some of the other people who are going to be putting a lot of work into the game.  I feel that people are a lot more committed to ideas that they have a personal stake in creating, and I also feel that one wrong detail in a game project description can turn potential contributors away, even if that detail was actually a tentative or negotiable idea on my part.  I don't have the motivation to create complete design documents on my own, because I don't see the point of forcing myself to make decisions on those aspects of the design that I'm not strongly interested in.

 

 

Also this great picture.  These are scripts rather than design docs, but they easily could be design docs for two different genres of game.

gta3_gta4_scripts1.jpg

Edited by sunandshadow

Share this post


Link to post
Share on other sites

a lot will depend on the demands of the "powers that be" for your project. IE them calling the shots will have final say as to whats required.

 

as a general rule of thumb, all that's really required is enough to keep the entire team on the "same page" so to speak and enough to jog your memory of "oh yeah, that's how its going to be done".

 

the place to not skimp is on figuring out how things will be done.  avoid the "cross that bridge when i get to it" approach. you want to have everything figured out in sufficient detail to know its doable, and how to do it.  minor BS like what some graphics detail should look like can come later.  ideally, you'll have already figured out generally how to implement everything before you ever sit down at the computer.

Share this post


Link to post
Share on other sites

the place to not skimp is on figuring out how things will be done.  avoid the "cross that bridge when i get to it" approach. you want to have everything figured out in sufficient detail to know its doable, and how to do it.  minor BS like what some graphics detail should look like can come later.  ideally, you'll have already figured out generally how to implement everything before you ever sit down at the computer.

 

To me that seems like it would be an overwhelming burden before starting a game, and would prevent you from ever doing anything new and interesting in your games as you try to figure out every detail before even getting something playable. I think it would be better to try something new and follow the fun.

Share this post


Link to post
Share on other sites

To me that seems like it would be an overwhelming burden before starting a game, and would prevent you from ever doing anything new and interesting in your games as you try to figure out every detail before even getting something playable. I think it would be better to try something new and follow the fun.

 

I often see this objection from newer/younger/less-experienced developers. Nobody is advocating that you work out the literal code of your whole system before you type it in. I also think that sounds like a huge, boring waste of time. What Norman (as I understand his message) is saying (and I agree with him) is that, assuming that you have a vision for your system/game/app/project; i.e. you're presumably embarking on your project because you've had a great idea and you want to make it real, then you're going to want to work out, in advance, what the primary systems and subsystems of your project are going to need, how they're going to connect together, how data is going to flow and so forth. You're going to want to build a strong mental model of all of the primary moving parts of your application, and in going through this process to build up your model, you're going to hit countless things you haven't thought of that would have messed up your architecture too late to fix easily, had you started coding straight away. These will include inefficiencies in your initial approach, deeper requirements that you didn't realise you had, cases where your initial assumptions turned out to be completely wrong, etc.

 

I'm not just parroting stuff I've read somewhere, I've been there. Countless times in my career I have started coding with little-to-no plan, and have worked in environments where that was the approach, and it is almost always a fantastic recipe for coding yourself into a corner and screwing up the project. Think of all of the failed projects; the games that got released after huge delays (if at all) with way more bugs than there should have been, the huge government and corporate website and intranet projects which went millions of dollars over budget and came out as a steaming pile of broken crap, and all of the indie projects which started out great and then ended up being cancelled or tossed in the "developer has lost interest" pile due to the immensity of the problems that the developers created for themselves.

 

I have been there and done that, over and over again. I've learned the hard way, and it changed my approach over time. And it's really not anywhere near as hard (or as unfun!) as you might think!

 

Screw design documents. If you have a large team and publisher-imposed deadlines, or you need VC buy-in or whatever, then sure, go the detailed, official design document route, but for yourself? Keep it simple and employ a divide-and-conquer approach. My approach is actually somewhat analogous to the widely-accepted, age-old process called "critical thinking". Yes, I also used to think that was just a term that meant "thinking about stuff carefully and without bias". It's more than that and there's actually a process, but I'll leave that to you to Google, if you're interested.

 

Anyway, start with bullet points and words. Write down a few sentences that you think explains your game to someone you're pitching it to. This may sound boring, but it's only a few sentences and it's kind of a catalyst that switches your brain from "shutup and let me code" mode into a more thoughtful, ready-for-brainstorming mode. If you're so inclined, you may expand this to a few paragraphs. In the process of doing this, your ideas tap is going to start to flow, and there's nothing you can do to stop it. And once it starts flowing, you're almost not going to be able to write fast enough to keep up with yourself. It's an enjoyable process, trust me! I have lost countless days to this process on numerous occasions just because I was so deep in design, trying to figure out the details of what I was trying to do.

 

Next pretend that this person you're explaining your game to is a developer who is contemplating working with you on the project, but wants to know more, so start putting down a few bullet points just quickly outlining the primary components you're probably going to need to include, and explain what those components do in a way that if you came back to it a month later (because hey, you got distracted with something else, or got a boy/girlfriend or something) then you'd be able to read through your notes, understand what you were trying to do and continue where you left off. Think about your game in terms of the data if you can. Imagine what sorts of data will exist in your game, and would need to be processed if your game were just a simulation of your idea, with graphics and inputs and stuff to be implemented later. Doing this will help you to separate minor implementation details (which you're not going to bother with until you're coding) from the actual logic and underlying architecture that describe the raw game itself. As a quick example, you might think of your player's spaceship as a sprite, and it needs to respond to input and then you'll think about key mappings and that sound effects will need to be played, etc. This is the wrong way to approach things. Instead, think about the spaceship in terms of its data. How big is it? How fast can it go? Can multiple players be on board? What sorts of upgrades and modifications can be performed on the ship? Can it dock anywhere? Can players get out, or is the player the ship itself? What other sorts of attributes might it have? Expand this to the other things in your game. What sorts of interactions with other game entities are possible? Why do you even want those interactions to be possible? And so on.

 

By now you should have quite a few bullet points and they'll probably be quite disorganized. That's fine! Every time you write down an idea, one of two things will be true. (1) you're going to already have a detailed mental model of exactly how you're going to approach it in code, and I don't mean line-by-line, I mean conceptually. If you were to sit down and implement this feature right now and you don't even know where to start, then you probably haven't thought about it enough in advance, which brings me to point (2) you don't really know how you're going to approach this just yet; you may have no idea at all, or maybe sort of a hazy concept of how you might go about it. If this is true, then hit the tab key for your next bullet point (you're indenting it from the idea bullet point you're breaking down), and literally write the question "How am I even going to approach this?", and then start thinking of rough ideas. Write them down as bullet points. Every time you write down an approach, question it and try to think of a reason why it might fail. Write that down. If you think it's a good idea, write down why.

 

What you're doing is breaking your approach down and coming up with the architecture of your game. Every time you pose a question to yourself that (a) is not a minor implementation detail, and (b) you don't know the answer to, then indent, add a new bullet point and start breaking it down by posing the question to yourself "how am i going to approach this?". After you have done all of this, you're going to find that you very rapidly start crystallizing your game idea into something that you have a clear mental model of. You're going to have inadvertently hit many, many brick walls in advance of having done so in code, and moved beyond them in a very short space of time before having ever coded up the suite of classes and functions that it would have otherwise taken for you to realise the flaws in your own approach.

 

To all those who say "there are some things you just can't know before you write the code", I say that either you're just being argumentative, or you haven't adequately figured out the difference between implementation details and architecture. If you're hitting fundamental architectural problems in code, then you failed to invest in what would have been valuable time spent figuring out your architecture in advance. If on the other hand, your architecture is sound, but the problems you're hitting are at the implementation detail level, then you're missing my point. Take this as far as you need to know that your approach, across the board, covers that which you wanted to achieve up front. If your requirements change halfway through, then, well there's not much you can do to plan for that other than being careful to balance consideration of the "what-ifs" against venturing too far into YAGNI territory. If you don't have enough information to know whether your approach is sound, then research! Find out what algorithms are available that could be used once you start coding. Learn about some new data structures that could solve your problem. Write a few quick sample apps using the frameworks or libraries you're thinking of so that you can get a sense of whether or not you really want to use them. Read a few articles. Ask some questions on StackOverflow. "I didn't know that in advance" is not a good enough excuse for wasting three months coding something only to realise that your approach was fundamentally flawed and destined for grand failure.

 

Finally, if one of your requirements is that you want the freedom to evolve, experiment and change your approach as you explore, then fine. Plan for that. Ask yourself the questions "what sorts of ways could my approach hypothetically diverge from what I'm planning at the moment?" and "how can design my code in a way that will preserve the important stuff without boxing me in?".

 

Take a leap of faith and try this process this once (I mean properly - you should end up with pages and pages of notes at a minimum), and notice how good you feel having encountered and moved passed six months or more of roadblocks in a tiny space of time without having wasted the time coding to get to those realisations. Feel how great it is coming up with a theoretical model of your game that you now have a really good idea of how to tackle and what architectural requirements you're going to need to deal with almost before you've written a line of code. I know coding is fun, but please. Take the time. Trust me on this. Architecture is architecture, whether you're writing a game or a stock trading system. Get it as right as you can, before you start to code, and you'll save a huge amount of time and have a result you're a lot more proud of and which is a lot easier to maintain and extend.

 

That is all.

Edited by axefrog

Share this post


Link to post
Share on other sites

 


To me that seems like it would be an overwhelming burden before starting a game, and would prevent you from ever doing anything new and interesting in your games as you try to figure out every detail before even getting something playable. I think it would be better to try something new and follow the fun.

 

I often see this objection from newer/younger/less-experienced developers. Nobody is advocating that you work out the literal code of your whole system before you type it in. I also think that sounds like a huge, boring waste of time. What Norman (as I understand his message) is saying (and I agree with him) is that, assuming that you have a vision for your system/game/app/project; i.e. you're presumably embarking on your project because you've had a great idea and you want to make it real, then you're going to want to work out, in advance, what the primary systems and subsystems of your project are going to need, how they're going to connect together, how data is going to flow and so forth. You're going to want to build a strong mental model of all of the primary moving parts of your application, and in going through this process to build up your model, you're going to hit countless things you haven't thought of that would have messed up your architecture too late to fix easily, had you started coding straight away. These will include inefficiencies in your initial approach, deeper requirements that you didn't realise you had, cases where your initial assumptions turned out to be completely wrong, etc.

 

I find it less intimidating to regard this as a revision step rather than something that should be in the first draft.  It's enough to worry about one thing at a time, and the first draft already has extra burdens like the intimidation factor of looking at a blank page and trying to figure out what you want to say and how you want to format the words.  So, let the first draft be a vague description of the game and it's main features.  Then when that's been successfully completed, revise it to be more detailed, and fill in any obvious holes.  Now revise it again, and this time you can worry about the 'how'.

Share this post


Link to post
Share on other sites

Thanks so much, everyone for putting your two cents in.  This is really interesting and fantastic!

 

 

 


To me that seems like it would be an overwhelming burden before starting a game, and would prevent you from ever doing anything new and interesting in your games as you try to figure out every detail before even getting something playable. I think it would be better to try something new and follow the fun.

 

I often see this objection from newer/younger/less-experienced developers. Nobody is advocating that you work out the literal code of your whole system before you type it in. I also think that sounds like a huge, boring waste of time. What Norman (as I understand his message) is saying (and I agree with him) is that, assuming that you have a vision for your system/game/app/project; i.e. you're presumably embarking on your project because you've had a great idea and you want to make it real, then you're going to want to work out, in advance, what the primary systems and subsystems of your project are going to need, how they're going to connect together, how data is going to flow and so forth. You're going to want to build a strong mental model of all of the primary moving parts of your application, and in going through this process to build up your model, you're going to hit countless things you haven't thought of that would have messed up your architecture too late to fix easily, had you started coding straight away. These will include inefficiencies in your initial approach, deeper requirements that you didn't realise you had, cases where your initial assumptions turned out to be completely wrong, etc.

 

I find it less intimidating to regard this as a revision step rather than something that should be in the first draft.  It's enough to worry about one thing at a time, and the first draft already has extra burdens like the intimidation factor of looking at a blank page and trying to figure out what you want to say and how you want to format the words.  So, let the first draft be a vague description of the game and it's main features.  Then when that's been successfully completed, revise it to be more detailed, and fill in any obvious holes.  Now revise it again, and this time you can worry about the 'how'.

 

I wonder if this really comes down to semantics.  To me, it sounds like you two have the same idea, but just have a different definition of what completed document/design is.  axefrog may agree that this may not be something that is necessary in the first draft, but just be sure that there are additional drafts in the works.  The differentiating factor may be, "when does work begin?".  Can you start coding after this first draft or is should it be used as a starting point for further conversation; conversations that will finalize the design and allow for coding to begin?

Share this post


Link to post
Share on other sites
 

I often see this objection from newer/younger/less-experienced developers. 

 

Screw design documents. 

 

architecture

architecture

architecture  architectural  architecture architecture

architectural  Architecture is architecture

 

That is all.

I agree with the screw design documents line. You go on a lot about making a design document though.

 

I am a less experienced game developer though. I love sketching ideas for a game design, but I don't know if I have enough of a programming background to figure out how i'm going to do the code (architecture?) before I start writing it. Lately I've found I get a lot more done when I don't worry too much about what I'm going to do next. 

 

Finally, if one of your requirements is that you want the freedom to evolve, experiment and change your approach as you explore, then fine. Plan for that. Ask yourself the questions "what sorts of ways could my approach hypothetically diverge from what I'm planning at the moment?" and "how can design my code in a way that will preserve the important stuff without boxing me in?".

Sure, some parts are better off planned ahead, but planning what you're going to do after experimenting defeats the purpose of the experiment. The point of the experiment is that you don't know what result you're going to get, or where it's going to take you. 

Share this post


Link to post
Share on other sites

This topic is 831 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this