Marc McGinley Profile picture
Nov 7, 2017 20 tweets 3 min read Twitter logo Read on Twitter
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

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Marc McGinley

Marc McGinley Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!