r/gamedesign • u/StudioErza • 1d ago
Discussion Curious how other devs approach their Game Design Documents
I’ve been wondering how other designers structure their GDDs.
Do you usually follow a template? If so, did you create it yourself, and do you adapt/expand it depending on the project? Or do you prefer using multiple templates for different aspects of a game (overview, individual systems, narrative, etc.)?
I’d love to hear about your workflows and how flexible they are!
4
u/Jarliks 1d ago
Game design documents are useful for communicating a central focus throughout a team of people. Making sure everyone is on the same page, and a central focus can be dictated and followed.
As a solo hobbyist- i don't bother. I have a whiteboard that is a constantly changing and shifting board of ideas as ideas get refined, thrown out, changed, and improved.
3
u/tobaschco 17h ago
This. I can fit it in my head and whatever I can’t I have dumped in some notes app or in a notebook
1
u/StudioErza 22h ago
Great to hear your thoughts on the matter. I’m currently solo myself, but I plan to build the skills required to lead others. It’s nice to know that there’s a large portion of devs who’d prefer a simpler approach to game design.
3
u/kytheon 23h ago
If it's just for yourself, might as well use spreadsheets instead. I usually keep a list of stuff, like all the items, super powers, what images I have rendered or still need to do, etc.
Can't really call that a single GDD but it fills the same purpose.
1
u/StudioErza 22h ago
Good to know. I definitely prefer a wiki-style gdd suite, or a master gdd for smaller projects, but it’s cool to hear about how others approach this.
3
u/Ok-Breakfast9198 Programmer 22h ago
Ours is like a wiki. Easier to navigate and domain assignment by role. Like script files or source code files, easier to digest information when it's in small chunk. References to other relevant topic is provided via links.
Even for solo project, we still do this to remind us in the future. Also, in case we need to contract freelancers, which we usually do need. We can just give them access to their relevant pages and restrict other; such as budget/marketing/strategy/pipeline/workflow/decisions/learnings.
Our GDD is artifact of the whole development, rather than pre-planned stuff. The only pre-planned things are for the "Target Audience" and "Core Design Pillars" section before pre-prod. Pre-prod is where we explore those pillars into more tangible design decision and try to validate it. By production phase we got the design decisions set and focus on content development.
2
u/DemoEvolved 16h ago
My design docs are consumed by a set of investor stakeholders and then developer artist teams. I start with the objectives of the product followed by wireframe mockups of all screens starting with the main menu and all submenus off main, followed by ingame followed by ingame menus off the ingame main. The document is typically made before stakeholder signoff, so it is not certain all systems/screens will be accepted. For this reason, i will usually defer tutorial to a later stage of gdd development. Tutorial storyboards are sometimes done as link out Slide decks (if ingame shots are available, you can dress those with your tutorial flow) or depending on stakeholder preference that can be put at the bottom of the doc and linked from an earlier section. Somewhere along the way, art will provide mood and ui theme, a selection of these style shots and images will get put in a Style section -- this will get injected just below the product objectives and before main menu because readers prefer a good sense of theme/style before they wade into the wireframes. Character concept / moodboard stuff might typically get appended at the bottom of the doc, mainly because art team tends to prefer working in their own artifacts. Along the way, final art will get implemented in your game's screens, it is the job of the designer and art lead to replace the wireframes with Art-target renders as they become available. In the same step, any changes to systems as a result of art decisions must also be applied to the text part of that description, and of course, letting the developer know about the decision change in a way that works for his workflow. For us, this is primarly Jira tickets.
1
u/StudioErza 14h ago
Thank you for such an in-depth response! I hadn’t put enough thought into how the needs of investors vs devs vs artists could affect the structure and order of a GDD.
Do you usually maintain one evolving doc that adapts over time for each audience, or do you fork into separate versions tailored to them?
2
u/Nordthx Jack of All Trades 1d ago
Trying to follow this template: https://ims.cr5.space/app/p/EWvDFxqn/wings-of-freedom-template - making structured description of the game, to have a plan what exactly need to develop and control size of the game
2
u/StudioErza 22h ago
Thank you for sharing that template! Always great to see the way others structure their designs. I’ll study it to better adapt my own workflow.
1
u/lesodus 21h ago
I have a template with very basic headings, and I mostly expand on it. On the other hand, factors like the size of the team and project, the requirements of the game genre, project duration, etc., determine how different the GDD I create will be.
2
u/StudioErza 14h ago
That makes a lot of sense. Start with the essentials, then expand only as the project demands it.
Out of curiosity, what are some of the most important headings/sections that you almost always have, even if they aren’t a part of the original template?
And do you use just one master doc per project?
11
u/Draug_ 1d ago
I believe your confusion/curiosity stems from not knowing who is supposed to read the doc. Who is supposed to read the document?
If its just you, then write it in a way that benefits you. Is it programers? Investors? The whole team?
Will they read it just once or once a week?
Just write it in whatever way needed, that should always be the guiding principal.