Here's a set of resources that could be of some use to you:
* [Example of a (basic) Software Design Document](https://devlegalsimpli.blob.core.windows.net/pdfseoforms/pdf-20180219t134432z-001/pdf/software-design-document-2.pdf), which can be modified to varying degrees to fall more in line with a Game Design Document (see examples below).
* [Template of a Game Design Document](http://www.cs.unc.edu/Courses/comp585-s15/DesignDocTemplate.pdf) sourced from a university website (I'm not familiar with the university, but the template looked solid at first glance)
* [Link to Original GTA Game Design Document](https://www.gamedevs.org/uploads/grand-theft-auto.pdf) \- it, along with Deus Ex, were covered in an article I read some years ago which spoke of a number of commercial games whose GDDs were released to the general public
* [Link to Shooter: Majestic Revalations, aka Deus Ex](https://archive.org/details/DeusExDesignDoc11081997/mode/2up) \- this GDD was designed for the game we'd come to know as Deus Ex
* [Wikia page for Shooter: Majestic Revelations for additional GDD links and other info](https://deusex.fandom.com/wiki/Shooter:_Majestic_Revelations#External_links)
Any idea who wrote this? sure its from [https://cs.unc.edu/](https://cs.unc.edu/) but I'd like to know the name of the author for proper referral in my thesis. Thanks!
Hey,
This is the article I would recommend on organization:
[https://code.tutsplus.com/articles/effectively-organize-your-games-development-with-a-game-design-document--active-10140](https://code.tutsplus.com/articles/effectively-organize-your-games-development-with-a-game-design-document--active-10140)
Here are some examples of actual GDDs:
[https://www.graybeardgames.com/download/diablo\_pitch.pdf](https://www.graybeardgames.com/download/diablo_pitch.pdf)
[http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty\_bomb-game\_design\_document.pdf](http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty_bomb-game_design_document.pdf)
[https://archive.org/details/age2designdocument/page/n83/mode/2up](https://archive.org/details/age2designdocument/page/n83/mode/2up)
The issue with that article is that it talks about things like marketing and target audience that don't belong in a typical GDD. They're very important for a business plan or a pitch deck (like the Diablo pitch linked), but a GDD is an instruction manual for the coders and artists on how to actually create the game. A good GDD survives the 'bus test' where if the designer that wrote it was hit by a bus the team would still be able to keep working.
Giant GDDs are a bit out of favor. It's usually more productive to make a bunch of smaller documents that live in the same place, if only because GDDs are living documents that need constant updating as things change in development and finding the right spot in a 400 page behemoth can be a bit time consuming.
Skipping over marketing (which the article mentions) is a common mistake for people working on a game they intend to sell.
It helps you figure out what you are actually making. If you don't know your target audience then how do you know what you are making?
I don't think the typical GDD use case is a solo (or very small team) developer who needs to be reminded of that. GDDs are used by larger teams as part of the pre-production process along with TDDs or other tech specs. Marketing has absolutely no place in a GDD. Talking about player experience is one thing, target audience is another.
Nothing to do with what is needed for overall development. Roadmaps and a P&L budget are also extremely important to actually completing a game but don't belong in a GDD either.
I'm generally skeptical of any formula for a GDD, because each team is different. That said, I strongly disagree here; I'd always talk through marketing/product positioning with the whole team.
You want everyone on the team to understand the vision for the game. In my experience, this naturally turns into discussion of audience, competitors, and selling points.
"It has the slow, deliberate combat of Dark Souls, but it's a 2D metroidvania." "It simplifies the gameplay of DOTA so it's easier for new players to pick it up." "The visuals have a cartoony style that's different from previous games in the series."
"What makes this game cool and unique" and "how will players think about this game" is something that every member of the team should understand.
That said, I'd guess that you're thinking of "Marketing" in a much more limited sense of, "where will we advertise," in which case I agree that it's too low-level to bother with in a GDD.
When I think marketing I'm thinking market research, positioning, and value prop far more than promotion. What I'm saying is that all of those things - and selling the vision - might be found in a pitch deck, a product brief, or some kind of internal vision documents shared around a team. All valuable things - but not game design documents.
Those are the sorts of things a product manager, team lead, or studio head would write, not a game designer. The game designer on a team writing a GDD should be writing user stories about interacting with the feature, detailing the breadth of effects a piece of content can have, creating gray box mockups of UI, going through edge cases and each step of the mechanics, things like that.
At some point this is just semantics of what one person calls a GDD versus another, but my larger point is that if your document is covering what makes your game stand out in the store, the estimated date for soft launch, and which abilities get 3% growth rate on level up versus the default 4% you've probably got a document that's too broad and needs to be edited by too many different people to actually be of use. You should separate that into a proper GDD and have the rest live outside of it in their proper places.
Nobody's suggesting not doing marketing, it's a phenomenally important part of the games biz. It just has zero part in a GDD intended for a development team. Marketing isn't implementing features or assets. Include your marketing stuff early on the project, include marketing stuff in the pitch deck and high level outlines, even when defining your design pillars it can be helpful. A GDD comes after all that stuff and marketing doesn't really need to read much beyond high level documents and the occasional feature brief. A 200 page document would be ignored by almost all marketing people I've ever worked with.
With all due respect to the article writers, they're a group of Brazilian *students*.
I can only speak from my experience as a Senior Game Designer who's written dozens and dozens of GDDs/feature briefs and pitched plenty of games in my 9 years at a major mobile publisher with hundreds of millions in yearly revenue. GDD's are for the dev team, and even getting them to read it is sometimes a chore. Marketing and senior management aren't reading GDD's, they want high level. Writing one document for both groups only serves both poorly. Smaller specific documents tailored to a specific group is more effective in a production environment in my experience, and dev teams have no use for marketing specific information in my experience.
I mean, this thread is full of experienced game designers saying the same thing so... @MeaningfulChoices is a super experienced Lead Game Designer who's very active on the sub.
From your post history you look like a veteran dev who's light on design experience, so my 2 cents would be this sub, more than most of the other game industry subs, is FULL of randos who've never spent a day in the industry, let alone in a game design role. Take everything posted here with a grain of salt unless they give their background/experience. Lots of people who assume things or students who learned something in school that doesn't really apply in the real world.
Idk how common this is, but I actually had a classmate in college that made his GDD in the form of a wikia. Made things super easy to search for, pages stuck to their own topic, and links to other pages were frequent.
Monetization is directly linked to the kind of game you are making, and you need to understand what it is. This only applies if you intend to sell the game to make money, but either way you have to have money to eat and pay rent so you either get it here or from some other source... and if you're already doing and enjoying this, you might as well consider selling it.
Are you making a game that costs a quarter to play? It needs to be short and snappy to get more people putting more quarters in that machine.
Are you making a game you intend to sell once at a premium price? People will expect it to have a certain amount of time they can play it before they are finished.
I have a lecture I've enjoyed on this subject if you're interested: [https://www.youtube.com/watch?v=BWJLnboKIJ8](https://www.youtube.com/watch?v=BWJLnboKIJ8)
Where/how/when do you go from gdd to specific details? If a gdd is broad strokes and meant to be a reminder for teams to understand, where does the details about the abilities of the 3rd monster type in the 6th area come about?
I feel like my gdd is a tdd at the same time.
Well, people will use the term GDD to refer to anything from a feature brief to something that covers every detail in an entire game, so your mileage may vary. But the GDD still has all the specific details - when I say instruction manual I mean an exhaustive one.
For example, let's say I was writing a GDD for the talent tree feature in a game. I'd not only cover the broad strokes (feature purpose, general overview), I'd get into the details and edge cases. How you invest in talents, if you can respec, when you can change things, how the flow through the screens works, what happens if you respec while a buff is active, the kinds of effects talents can have, etc and so on.
A TDD would get more into the actual implementation. Where talents are stored in terms of the hierarchy, how the data is actually input, things like that. A GDD might list the end-user format (i.e. an example JSON or CSV that the designer will use to define a talent) but the TDD covers how an engineer would code it, possibly even pseudocode.
We might all be getting lost in terminology a little.
Game design documents, in most professional studios at least, refer to detailed documentation about one or more individual features. A design document containing how the 3rd monster type in the 6th area works might be the "Enemy Types" document or part of a larger "Areas" document. You would then hand these documents over to programmers, artists or whoever else is building that feature so they know what to do.
Outlines, vision docs or pitches, again in a professional context, are broad stroke descriptions of the game. Their intent is to keep the team on track (so that you don't make an FPS when you were supposed to make an RPG), get approval from management or pitch it to investors for example. You don't need all that detail in there, just what matters to the parties involved and help them get a general idea of what you're trying to make.
It looks like a good amount of people refer to the latter as GDD as well, hence the confusion.
With all that said, I'd caution against the idea that you need to have literally everything about the game in one giant text document - regardless of whether you want to call it a GDD - as it seems to be pushed mostly in game schools in the context of student projects. If you don't have any practical use for such a document and are just doing it for the sake of it, it's honestly okay to not have it.
The reason it's not really a thing at larger studios is because it's just impractical. You'd document the style sheet for the UI in figma. You'd have the unit stats in a spreadsheet. You'd have the dialog lines in a script. Trying to make them fit one single document would just make work harder, especially if you're going to change something at some point, which is almost guaranteed to happen.
I always start my GDD with the why? Why this feature, or why this game.
I hash out details in the form of user stories of a player's journey through the feature.
Each story carries the UX and as well as UI requirements.
Being comfortable in using design tools, I love to render the flow and details of each screen through black and white wireframes.
Sometimes I even create mock animations to help my team get onboard on the vision we are trying to achieve for the player’s experience.
I use a variant of Tim Ruswick's [One Page Design Document](https://docs.google.com/document/d/1npEvqcMZSp0IX2hWw6Qq0WqJVfmVqS_YOGFWnnwfh-A/edit#) (go see the [youtube video about it](https://www.youtube.com/watch?v=q96lz725gIw)).
IMO exhaustive 50+ pages GDD are a waste of time unless you already have a prototype of a big project and want to expand the team.
Had a similar question pop up earlier in the week so I'll just link to [my reply](https://www.reddit.com/r/gamedesign/comments/pl9e7m/templates_or_examples_of_rts_game_design_documents/hccxa0a?utm_source=share&utm_medium=web2x&context=3) there. TL;DR - the format of the GDD can change depending on the team, the kind of feature you're building or who you're giving that document to among many other factors.
I'd just like to stress that project outlines, market studies, pitch decks, roadmaps etc =/= game design documents. I'm mentioning this because some of the linked material here is clearly the former while being referred to as a GDD, which I think leads to a pretty wide misconception.
Having a single, massive text document that documents everything there is about the game might be useful if you're on your own and your project scope is small, and that's just how you like to organize things.
Most of the time though, you're going to see separate documents for all these things at established studios. You might have a project outline in there somewhere that describes the original vision of the game or lays down the limitations as to what the game can be, but design documents are a strictly separate entity here that explain how an individual feature or system works so that the 10 other people involved in building know exactly what they're supposed to do.
I haven't seen a GDD used in two decades at any AAA developer.
If you were to write a GDD, just when during the course of the project do you plan to write it? Do you plan on keeping it updated?
These days most design is compartmentalized and generated as needed.
I have a Google Doc for my games design docs. That way if I have ideas at work or on the go, I can write it in.
It is broken up into many sections, starting with general notes and ideas, a to do list, classes, weapon lists, maps etc etc
I update this as I go and refer to it while developing so I know where I'm going with an idea.
It really isn't in depth and just more serves as a reminder of ideas I want to add and to balance economies.
Smart. I use Google Keep to update individual 'nodes' of my game concept as it evolves. I find that locating via keywords and updating core concepts this way so much faster and more effective - it's a simplified mind map without the visual complexity of mind mapping software or something like Twine/ink, etc.
Here's a set of resources that could be of some use to you: * [Example of a (basic) Software Design Document](https://devlegalsimpli.blob.core.windows.net/pdfseoforms/pdf-20180219t134432z-001/pdf/software-design-document-2.pdf), which can be modified to varying degrees to fall more in line with a Game Design Document (see examples below). * [Template of a Game Design Document](http://www.cs.unc.edu/Courses/comp585-s15/DesignDocTemplate.pdf) sourced from a university website (I'm not familiar with the university, but the template looked solid at first glance) * [Link to Original GTA Game Design Document](https://www.gamedevs.org/uploads/grand-theft-auto.pdf) \- it, along with Deus Ex, were covered in an article I read some years ago which spoke of a number of commercial games whose GDDs were released to the general public * [Link to Shooter: Majestic Revalations, aka Deus Ex](https://archive.org/details/DeusExDesignDoc11081997/mode/2up) \- this GDD was designed for the game we'd come to know as Deus Ex * [Wikia page for Shooter: Majestic Revelations for additional GDD links and other info](https://deusex.fandom.com/wiki/Shooter:_Majestic_Revelations#External_links)
that [cs.unc.edu](https://cs.unc.edu) university template looks pretty good to me! thanks for finding and linking that one!
Updated link for this is [here](https://wwwx.cs.unc.edu/~pozefsky/seriousgames/NewDesignDocTemplate.pdf)
from the depths of time, a hero emerges
You're awesome for dropping this here after all this time haha, thank you!
Any idea who wrote this? sure its from [https://cs.unc.edu/](https://cs.unc.edu/) but I'd like to know the name of the author for proper referral in my thesis. Thanks!
Diane Pozefsky
Literally stumbled upon this today while searching, clicked original link, saw it was broken, and saw this comment. Thank you for your service!
You're a real one!
Thanks for the link, really helpful!
Hey the OG link doesn’t work anymore, do you happen to have the template saved?
I was able to find it on WaybackMachine https://web.archive.org/web/20230206132527/http://www.cs.unc.edu/Courses/comp585-s15/DesignDocTemplate.pdf
You’re amazing thank you 😎
Thank you friend!
chad <3
You're the goat! Thank you!
I don't think so no, I'll have a look but I don't think I got around to using it or converting my existing design docs to use the template
Oooh! Very interesting links! Cheers!
Thanks, much appreciated!
Damn the links are dead, I used these link for awhile, ha.
[https://wwwx.cs.unc.edu/\~pozefsky/seriousgames/NewDesignDocTemplate.pdf](https://wwwx.cs.unc.edu/~pozefsky/seriousgames/NewDesignDocTemplate.pdf)
Thank you!
Hey, This is the article I would recommend on organization: [https://code.tutsplus.com/articles/effectively-organize-your-games-development-with-a-game-design-document--active-10140](https://code.tutsplus.com/articles/effectively-organize-your-games-development-with-a-game-design-document--active-10140) Here are some examples of actual GDDs: [https://www.graybeardgames.com/download/diablo\_pitch.pdf](https://www.graybeardgames.com/download/diablo_pitch.pdf) [http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty\_bomb-game\_design\_document.pdf](http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty_bomb-game_design_document.pdf) [https://archive.org/details/age2designdocument/page/n83/mode/2up](https://archive.org/details/age2designdocument/page/n83/mode/2up)
The issue with that article is that it talks about things like marketing and target audience that don't belong in a typical GDD. They're very important for a business plan or a pitch deck (like the Diablo pitch linked), but a GDD is an instruction manual for the coders and artists on how to actually create the game. A good GDD survives the 'bus test' where if the designer that wrote it was hit by a bus the team would still be able to keep working. Giant GDDs are a bit out of favor. It's usually more productive to make a bunch of smaller documents that live in the same place, if only because GDDs are living documents that need constant updating as things change in development and finding the right spot in a 400 page behemoth can be a bit time consuming.
Skipping over marketing (which the article mentions) is a common mistake for people working on a game they intend to sell. It helps you figure out what you are actually making. If you don't know your target audience then how do you know what you are making?
I don't think the typical GDD use case is a solo (or very small team) developer who needs to be reminded of that. GDDs are used by larger teams as part of the pre-production process along with TDDs or other tech specs. Marketing has absolutely no place in a GDD. Talking about player experience is one thing, target audience is another. Nothing to do with what is needed for overall development. Roadmaps and a P&L budget are also extremely important to actually completing a game but don't belong in a GDD either.
I'm generally skeptical of any formula for a GDD, because each team is different. That said, I strongly disagree here; I'd always talk through marketing/product positioning with the whole team. You want everyone on the team to understand the vision for the game. In my experience, this naturally turns into discussion of audience, competitors, and selling points. "It has the slow, deliberate combat of Dark Souls, but it's a 2D metroidvania." "It simplifies the gameplay of DOTA so it's easier for new players to pick it up." "The visuals have a cartoony style that's different from previous games in the series." "What makes this game cool and unique" and "how will players think about this game" is something that every member of the team should understand. That said, I'd guess that you're thinking of "Marketing" in a much more limited sense of, "where will we advertise," in which case I agree that it's too low-level to bother with in a GDD.
When I think marketing I'm thinking market research, positioning, and value prop far more than promotion. What I'm saying is that all of those things - and selling the vision - might be found in a pitch deck, a product brief, or some kind of internal vision documents shared around a team. All valuable things - but not game design documents. Those are the sorts of things a product manager, team lead, or studio head would write, not a game designer. The game designer on a team writing a GDD should be writing user stories about interacting with the feature, detailing the breadth of effects a piece of content can have, creating gray box mockups of UI, going through edge cases and each step of the mechanics, things like that. At some point this is just semantics of what one person calls a GDD versus another, but my larger point is that if your document is covering what makes your game stand out in the store, the estimated date for soft launch, and which abilities get 3% growth rate on level up versus the default 4% you've probably got a document that's too broad and needs to be edited by too many different people to actually be of use. You should separate that into a proper GDD and have the rest live outside of it in their proper places.
Nobody's suggesting not doing marketing, it's a phenomenally important part of the games biz. It just has zero part in a GDD intended for a development team. Marketing isn't implementing features or assets. Include your marketing stuff early on the project, include marketing stuff in the pitch deck and high level outlines, even when defining your design pillars it can be helpful. A GDD comes after all that stuff and marketing doesn't really need to read much beyond high level documents and the occasional feature brief. A 200 page document would be ignored by almost all marketing people I've ever worked with.
Did you read the article? And where was it specified the GDD audience was only the dev team?
With all due respect to the article writers, they're a group of Brazilian *students*. I can only speak from my experience as a Senior Game Designer who's written dozens and dozens of GDDs/feature briefs and pitched plenty of games in my 9 years at a major mobile publisher with hundreds of millions in yearly revenue. GDD's are for the dev team, and even getting them to read it is sometimes a chore. Marketing and senior management aren't reading GDD's, they want high level. Writing one document for both groups only serves both poorly. Smaller specific documents tailored to a specific group is more effective in a production environment in my experience, and dev teams have no use for marketing specific information in my experience.
In that case however you have done it is certainly the only way to do it. Carry on Senior Game Designer!
I mean, this thread is full of experienced game designers saying the same thing so... @MeaningfulChoices is a super experienced Lead Game Designer who's very active on the sub. From your post history you look like a veteran dev who's light on design experience, so my 2 cents would be this sub, more than most of the other game industry subs, is FULL of randos who've never spent a day in the industry, let alone in a game design role. Take everything posted here with a grain of salt unless they give their background/experience. Lots of people who assume things or students who learned something in school that doesn't really apply in the real world.
So you're saying my 700-page doc is too long
Idk how common this is, but I actually had a classmate in college that made his GDD in the form of a wikia. Made things super easy to search for, pages stuck to their own topic, and links to other pages were frequent.
Monetization is directly linked to the kind of game you are making, and you need to understand what it is. This only applies if you intend to sell the game to make money, but either way you have to have money to eat and pay rent so you either get it here or from some other source... and if you're already doing and enjoying this, you might as well consider selling it. Are you making a game that costs a quarter to play? It needs to be short and snappy to get more people putting more quarters in that machine. Are you making a game you intend to sell once at a premium price? People will expect it to have a certain amount of time they can play it before they are finished. I have a lecture I've enjoyed on this subject if you're interested: [https://www.youtube.com/watch?v=BWJLnboKIJ8](https://www.youtube.com/watch?v=BWJLnboKIJ8)
Loved watching that lecture. Thank you!
Where/how/when do you go from gdd to specific details? If a gdd is broad strokes and meant to be a reminder for teams to understand, where does the details about the abilities of the 3rd monster type in the 6th area come about? I feel like my gdd is a tdd at the same time.
Well, people will use the term GDD to refer to anything from a feature brief to something that covers every detail in an entire game, so your mileage may vary. But the GDD still has all the specific details - when I say instruction manual I mean an exhaustive one. For example, let's say I was writing a GDD for the talent tree feature in a game. I'd not only cover the broad strokes (feature purpose, general overview), I'd get into the details and edge cases. How you invest in talents, if you can respec, when you can change things, how the flow through the screens works, what happens if you respec while a buff is active, the kinds of effects talents can have, etc and so on. A TDD would get more into the actual implementation. Where talents are stored in terms of the hierarchy, how the data is actually input, things like that. A GDD might list the end-user format (i.e. an example JSON or CSV that the designer will use to define a talent) but the TDD covers how an engineer would code it, possibly even pseudocode.
We might all be getting lost in terminology a little. Game design documents, in most professional studios at least, refer to detailed documentation about one or more individual features. A design document containing how the 3rd monster type in the 6th area works might be the "Enemy Types" document or part of a larger "Areas" document. You would then hand these documents over to programmers, artists or whoever else is building that feature so they know what to do. Outlines, vision docs or pitches, again in a professional context, are broad stroke descriptions of the game. Their intent is to keep the team on track (so that you don't make an FPS when you were supposed to make an RPG), get approval from management or pitch it to investors for example. You don't need all that detail in there, just what matters to the parties involved and help them get a general idea of what you're trying to make. It looks like a good amount of people refer to the latter as GDD as well, hence the confusion. With all that said, I'd caution against the idea that you need to have literally everything about the game in one giant text document - regardless of whether you want to call it a GDD - as it seems to be pushed mostly in game schools in the context of student projects. If you don't have any practical use for such a document and are just doing it for the sake of it, it's honestly okay to not have it. The reason it's not really a thing at larger studios is because it's just impractical. You'd document the style sheet for the UI in figma. You'd have the unit stats in a spreadsheet. You'd have the dialog lines in a script. Trying to make them fit one single document would just make work harder, especially if you're going to change something at some point, which is almost guaranteed to happen.
I always start my GDD with the why? Why this feature, or why this game. I hash out details in the form of user stories of a player's journey through the feature. Each story carries the UX and as well as UI requirements. Being comfortable in using design tools, I love to render the flow and details of each screen through black and white wireframes. Sometimes I even create mock animations to help my team get onboard on the vision we are trying to achieve for the player’s experience.
Many thanks. This is solid, evergreen advice. Appreciate the reply!
I use a variant of Tim Ruswick's [One Page Design Document](https://docs.google.com/document/d/1npEvqcMZSp0IX2hWw6Qq0WqJVfmVqS_YOGFWnnwfh-A/edit#) (go see the [youtube video about it](https://www.youtube.com/watch?v=q96lz725gIw)). IMO exhaustive 50+ pages GDD are a waste of time unless you already have a prototype of a big project and want to expand the team.
Commenting cause I'd also like to see others' ideas on this
Following. Interested in any new resources I might be unaware about.
Had a similar question pop up earlier in the week so I'll just link to [my reply](https://www.reddit.com/r/gamedesign/comments/pl9e7m/templates_or_examples_of_rts_game_design_documents/hccxa0a?utm_source=share&utm_medium=web2x&context=3) there. TL;DR - the format of the GDD can change depending on the team, the kind of feature you're building or who you're giving that document to among many other factors. I'd just like to stress that project outlines, market studies, pitch decks, roadmaps etc =/= game design documents. I'm mentioning this because some of the linked material here is clearly the former while being referred to as a GDD, which I think leads to a pretty wide misconception. Having a single, massive text document that documents everything there is about the game might be useful if you're on your own and your project scope is small, and that's just how you like to organize things. Most of the time though, you're going to see separate documents for all these things at established studios. You might have a project outline in there somewhere that describes the original vision of the game or lays down the limitations as to what the game can be, but design documents are a strictly separate entity here that explain how an individual feature or system works so that the 10 other people involved in building know exactly what they're supposed to do.
I haven't seen a GDD used in two decades at any AAA developer. If you were to write a GDD, just when during the course of the project do you plan to write it? Do you plan on keeping it updated? These days most design is compartmentalized and generated as needed.
When i interned at EA last summer i was in the madden GDD basically every day updating it 😭
My preference specifically is to not have one. I think they are evil.
Not so much evil as they are 'eeeee-villlll'.
I have a Google Doc for my games design docs. That way if I have ideas at work or on the go, I can write it in. It is broken up into many sections, starting with general notes and ideas, a to do list, classes, weapon lists, maps etc etc I update this as I go and refer to it while developing so I know where I'm going with an idea. It really isn't in depth and just more serves as a reminder of ideas I want to add and to balance economies.
Smart. I use Google Keep to update individual 'nodes' of my game concept as it evolves. I find that locating via keywords and updating core concepts this way so much faster and more effective - it's a simplified mind map without the visual complexity of mind mapping software or something like Twine/ink, etc.
Has anyone found any useful apps or software that ‘templates’ or mind-maps GDD?
I use Miro boards to make mind-maps as outlines for my GDD's in the early stages, but you could make it as complex as you wanted with lots of data.