When making up a game design document, do you usually document every piece of code that goes into it, or do you just document info about the various libraries, art assets, items, characters, etc?
I havenât got into the habit of making them yet - I know, bad Philip! smack - but I certainly wouldnât go to that level of detail. Iâd be more inclined to make it a high-level specification, and have separate documents for more specific things like the characters, the setting, etc.
A game design document shouldnât reference any pieces of code, let alone all of them. Its purpose is to define the look & behavior of the game as seen from the outside. What screens you need, how the pieces can move, what the bonuses are, etc.
The more detail you have your design worked out in the beginning, the faster and smoother the implementation will go. On the other hand, itâs rare to find a designer who can work all that out well ahead of time; often more iterative prototyping is required in order to find and polish the fun.
Iâm working with one of the exceptional designers now on a game that will be going to Steam Greenlight very soon. Itâs amazing â he had a clear idea of exactly what he wanted, beautiful art & sound assets to back it all up, a clear description of the rules, etc. We had only a couple of âoops, I should have mentionedâ moments in the whole project.
(But then again, this was his second attempt to have it implemented; the first one got bogged down, but probably got far enough to hammer out all the design kinks.)
2 Likes
Ideally a design doc reads almost like a story that not only tells you the feel, style, and look of a game and its setting, but also describes the underlying mechanics in a clear and detailed way.
Then you simply take all these mechanics and feel and transport them into a Technical Design Doc, which will go over all the code ideas/reliances/technical hurdles to implement (but not actual code, that isnât needed) and an Art Design Doc (which as many names) that goes over the styles, references, etc. In a larger studio youâll end up with 1 person in charge of each doc and responsible for their design with another person, usually the producer or lead designer, acting as quarterback and ensuring everyone is communicating clearly and efficiently and the documents all stay on target (as changing one item in one doc may radically affect another).
2 Likes
GDD should generally be code and engine agnostic. Its a guide for what you are going to make, and why. Not how.
2 Likes
I agree. But you do talk about methods such as: Control scheme, AI behavior, and other Gameplay methods. If you start with the design document youâll understand WHAT you have to code much better. It wouldnât hurt to have a folder of scripts to reference even if itâs not in the GDD.
1 Like
In my design document I have a general list of the assets required under their section. So a list of sound effects, how they sound and when they are activated under the audio tab for example. I do have some flow charts for menu structures in my GDD, but I am no programmer so I give him/her the freedom to do what they think is right, and I trust in their expertise.
You could go deeper into the coding of the game by making a technical design document in coöperation with the programmer.
In my opinion, and I know this will get a lot of disagreement, this is the best thing to do. Unless you work for a big game company and need to document it, it serves the purpose of procrastination for many who cant code and dont want to go through learning.
âWell, I better get to making my game nowâŠOh wait how convenient I cant make my game I still have a big document to write I guess Iâll have to do that laterâ
2 Likes
A design document is not something to use to procrastinate. Blame that on the developer, not the document. We have a design doc and it was the first thing I did. It helps us to stay on course and I can send it to my programmers with notes and it helps them to know what we need for the game. We are able to stay more organized.
Procrastination does not need a design docâŠplenty of ways to do that. Playing Witcher 3 for three months, watching TV shows, and videosâŠvisiting the forums. Those all work equally well and a true procrastinator is probably going to procrastinate on the design doc as well. 
4 Likes
There is that one segment of the community that think a design document is simply a 200 page list of MMO character classes and cool abilities.
2 Likes
Like the âperfect MMORPGâ guy?
True, having a spec is useful. I think what @ostrich160 was getting at is that getting too detailed when making it is just as bad as not bothering.
2 Likes
As a beginner with simple games I use it like a map, to clarify the boundaries of the game (here be dragons is replaced with here be scope creep), highlight key landmarks (mechanics, decision points, effects etc), & the look/feel/sound. Lower level documents then fill in the gaps within those boundaries
2 Likes
Thats pretty much the kind of dev Im on about.
1 Like
An interesting subject. Would anybody here be willing to post their design docs? Maybe not for a current project, but maybe for an idea that sounded good at first but was later discarded / set aside?
Unfortunately I donât as I may go back to them (Iâm to noobish to waste anything at this stage) but I found this which might be useful.
Thought Iâd add this as well as it might shed some light on our process: http://ironbellystudios.com/gdd-template/
Iâm pretty sure every developer who is serious about his project will make at least basic documentation describing how the game is going to work before they start working on it.
This wouldnât, as you apparently think, include code or what characters you use, instead it would rather include descriptions of game mechanics and aesthetics of the game that you intend to have.
As for making a scripting reference of your code, it depends. If you have multiple people working on it, or if you might replace your programmer or if you just intend to use some of the code in another similar project then you should definitely document it.
Always document your code, preferably before you actually write the code, even if youâre the only programmer and itâs a one-off script. This clarifies the preconditions and postconditions that your methods and classes must meet. Unless youâre writing a flappy bird game in 24 hours, youâre going to end up going back to code that you wrote months ago. Documentation will help you get back into the code faster.
Kinda late to the party, but check out gamasutra.
They have some awesome articles on design documents, tech docs, and other helpful pre-production documentation writings.
Depends. I always prefer self documenting code. Something like this
public class ProjectileShooter {
public GameObject projectileToFire;
public void Shoot (Vector3 directionToFireIn){}
}
Beats this
// This class is used to fire projectiles
public class Projectile {
// The projectile to fire
public GameObject thing;
// Use this method to shoot
public void Activate (Vector3 direction){}
}
Admittedly my projects are on the small side. But using the self documenting approach Iâve seldom had trouble reading my own code from months to years ago.
Occasionally Iâll throw in a couple of lines of comments. But its mostly to document what I was thinking, rather then to document what the code does. Lines like
// This is a mess, fix it
// This class is meant to be used by SomeOtherClass
// A* algorithm to do pathfinding
1 Like