Thread by @marcmcg

Seems to be a lot of demand for this, so here are some GDD Writing tips I've picked up over the years (Thread) #gamedev #gdd #gamedesign

1/ GDDs should be as long or as short as they need to be to describe the features of the game

2/ If you're working in a super collaborative team, keep your GDDs short and agile. Use supporting docs & evolve your design through collab

3/ If your team just want the info - document your design in more detail. I find that ~30 pages is good for small to medium sized games

4/ A GDD is not the right place for content. Content changes often, it's not part of the design. Document it elsewhere.

5/ Write in present tense. Your goal is to help people imagine the features existing. Present tense absolutely does that. Don't use "will"

6/ Reveal features in logical sequence. Don't write about a feature that relies on the reader knowing a feature they haven't read about

7/ Use lots of diagrams, wireframes or sketches to communicate ideas more clearly

8/ GDDs shouldn't mention a business / marketing plan (like they teach in some Game Design programs at school)

9/ Formatting is your friend - use section headings for big features and subheadings for sub-features. Don't forget that table of contents

10/ A GDD is not a task list. It should, however be used to create one. Don't equate the two though

11/ Summarize your controls in a controls section. It serves as a nice overview of what you can do in the game. Use tables / diagrams

12/ Don't worry about describing the visual feedback / SFX. Just note down where it occurs. Figure out those details elsewhere

13/ GDDs will go through constant iteration. If you can't keep it up to date, then you're doing them wrong. Reduce size or improve structure

14/ Your GDD is just the beginning. It's a conversation starter, not the end of your job on the project. Don't expect people to just read it

15/ Organize meetings to go over the GDD content to ensure people have read it and have the opportunity to ask questions or raise concerns

16/ Avoid lengthy paragraphs. Use bullet points where possible, especially describing lists of options (e.g. buttons & what they do)

17/ It's OK to state design goals and target audience, but ideally those live in separate docs. A GDD is about *how* you meet those goals

18/ Hyperlinks are awesome. Link the reader to key features or sections - don't make them work for the information

19/ Tables can often communicate a lot more effectively than words. They're best when drawing comparisons and distinctions between things