How I Write a Game Design Document (GDD)

Yes, a game design document is worth writing.

There's nothing to lose writing one, but there's a high chance to lose time, money, and resources in general by not writing one.

There are two extremes when it comes to writing a GDD:

1. not writing one at all
2. writing a highly detailed document

It's not helpful to start making a game completely blind, while on the other hand, it's also not very helpful to have a highly detailed document that leaves no room for iteration.

I can imagine studios with more than one person benefitting from writing up a long detailed document though, because it becomes costly when one person breaks a whole system for other people in the team.

As a solo developer though, I find that GDDs are most useful for:

1. Having an overview that seperates preproduction and production
2. Setting the design pillars

Here's a one page document template that I use for my games as an example.

There's no need for me to go over each section.

I have the details on there, but I will go over my process and why all of this matters.

//Seperate Preproduction and Production

Before I commit to any development, I always dump my game idea on here to validate it.

If after filling all the sections in the document and the idea holistically makes sense, I go ahead and take it to the next level by testing the idea again with an actual prototype. Otherwise, I have to drop it unless I can refine it to overall make sense.

The point of the matter is, by successfully filling in the document, not only can I have faith in the game idea working, but I also separate preproduction from production. It allows my brain to set itself free from all these ideas, because its written in this document and I can just focus on developing the game.

//Design Pillars

There's really no type of software that's immune from needed changes in the plan while it's in development and that's why I prefer the agile approach where I can continually iterate on the idea.

To guide my iteration, I always refer back to the design pillars that I had set in my GDD to help with making decisions at times when there's confusion or needed design changes for my game.

As an example, a ranged weapon that can just easily wipe out enemies in a game where the design pillars were for it to be stealthy or tactical is clearly bad design. Players would just pull this weapon out and fire away, because there would be no reason to play tactically, so it will need to be redesigned.

Hopefully you get the point, but imagine if this example scenario was written within a long detailed design document, can you still trust it? Probably not and the whole thing will need to be changed.

The point is, it's hard to tell if things will work by just playing the game in your head and or by translating everything you think will work in a document.

Best to make sure to validate the idea holistically first and keep it loose from there.

//Conclusion

Anyway, that's it for this one my frenz.

Here's the one page game design document in PDF format that you can download truly for free without giving up your email address or any of that.

However, if you are interested in playtesting my games when I eventually need to do testing or hear about my games in general while they're in development, then do subscribe to my newsletter.

Goodluck with your game!

– Renz

//Supporters

Special thank you shout out to the following ongoing generous supporters of my work, making a difference in the world and mine.

• Laura Milligan
• Jacob Huang
• Andrew Abrook
• Faiz Prasla
• Armaigne Rivero
• Joshua Ravasco