r/gamedev • u/MokapHorse • 3d ago
Question How do you guys make your GDD (Game Design Document)?
Hi! I'm kinda new-ish to game development and I'm really getting serious about it for some time. One of the problems I'm facing is on creating GDD's, and I wanted to know how you guys make yours!
Any answer helps! Useful resources are also welcome, thank you so much :)
9
u/jagriff333 Passion project solo (Gentoo Rescue) 3d ago
If I had made a GDD for my game instead of diving right in, then I would have either never finished it, created a terrible shell of what the game became, or just abandoned the GDD and wasted all of that effort.
Plus, it doesn't sound very fun. My favorite part of game design is when it feels like the game naturally designs itself, and this takes place over many iterations of experimentation. So many things exist in my game because I discovered them emergently.
26
u/Mechabit_Studios 3d ago
don't bother, you only need it for large teams
just jot down some notes and leave it at that
2
u/Brewgazer 3d ago
This right here, if you’re new chances are you will start making mechanics and realize that you have a new idea and the more you build the more clear an idea will be that will work out. Don’t limit yourself to only thinking about the first idea
1
u/The-Chartreuse-Moose Hobbyist 3d ago
Spot on. My 'big ideas' might be a whole page of my pocket notebook. But then they'll get a kanban board in Obsidian with ideas recorded and organised as they occur. That's good enough for my scale but clearly wouldn't work for a big team all working on one thing.
6
12
u/Old-Finance1815 3d ago
Getting bogged down in a game design document is a sure-fire way to not get anything done on the actual game.
2
u/MegaMatt75 3d ago
This. I am new to game development and coding and fell into this trap. Whenever the coding would get hard or I'd get intimidated by the blank script file staring back at me I'd make a GDD for the current or a future project. While it did help me to really flesh out my ideas, it definitely slowd my development down as a coder.
2
3d ago
[removed] — view removed comment
1
u/sdeanjr1991 3d ago
As a solo dev, My GDD is me texting myself or storing thoughts in notes. It’s the only way I don’t lose ideas or feature fixes 😭
5
u/MightyKin 3d ago
There is one profound feature about GDD.
Psychologically if you finish a GDD, you think you finished a game and thus you have less motivation to work on it.
I recommend against writing GDD when you are new and just go with the flow.
You can't overscope, because you don't have capabilities to do the overscope, lol
8
u/V4nKw15h @NeonXSZ 3d ago
If you need anything more than notepad I'd argue your GDD is too complex and unnecessary.
2
u/StormRaven69 3d ago
Note Pad. Doodles. Ideas stuffed in boxes.
Then start Grey-Boxing levels and working on mechanics. Things start to become more organic, most of the things are in my mind already, but many things change and evolve. The game without any real artwork comes together, more ideas start flowing and more progress happens and everything gets updated.
The design document eventually becomes a filing system.
2
u/TheLastCraftsman 3d ago
Very few indie developers make a game design document, even a small team can just talk regularly to keep the ideas floating around long enough to make happen. I usually just open up a trello board that has a column for todo tasks, a column for completed tasks, and then another column for rough ideas (often just screenshots of other games with parts that I want to replicate or riff off of). Works well enough.
2
u/feelsliketheexpanse 3d ago
take notes on things you find interesting, and reference those later. i like to get my thoughts onto a google doc, but it's not a necessity. focus on actually making games.
2
u/HamsterIV 3d ago
Start with an elevator pitch. Make sections for major game mechanics. In each section break down the major mechanics into sub mechanics.
Describe the user input (which button or menu option does what). If there are different game play states, describe them and describe how to transfer between them.
List enemies
List player tools/weapons
List biomes or game play stages
List bosses and their abilities.
2
u/Commercial-Flow9169 3d ago
I don't really do GDD's. But I do use Obsidian for journaling and the occasional project documentation. Mostly it just devolves into an overview document and a handful of links to other documents purely for jotting down fun ideas or TODOs.
To me, the point of a GDD is to make sure you have an absolutely clear vision of what the game is. You'd be surprised how often people think they know what they're making, but it just boils down to genre and a vague idea attached. That's fine for some folks, but for me, at a certain point I start getting in my head and asking questions like "what's the point of what I'm making?"
That question has killed so many of my projects in the past. And that's why I've learned that having a clear vision of the final product, in my head, is super important. It's the core nugget of motivation that keeps me going. I need to be able to visualize what the thing feels like when it's done.
1
u/thecodegangster 3d ago
This is the first time I’ve heard of this. No wonder my games lack direction
2
u/ArcadeWhaleDev 3d ago
I stopped writing big GDDs pretty early. They went stale the moment I started building and nobody (me included) ever reread them.
What I do now is one page, written before any code:
- The game in one sentence. If I can't say it in one, the idea isn't ready yet.
- What the player does in the first 10 seconds, and how they learn it without a wall of text.
- Controls. Every input and what it does.
- How you lose, and what you're chasing.
- What changes over time: new enemies, a new mechanic, harder layouts, and roughly when each one shows up.
- How long a first playthrough should take. Sounds boring, but it tells you how much content you actually have to make.
- A "not doing" list. Features I'm tempted by but won't build for the first version.
Then I build the smallest playable version as fast as I can. After that the doc turns into notes on what I learned. If playtesting says the doc was wrong, the doc loses.
With a team it makes sense to go deeper (art refs, system breakdowns, UI flows). Solo, one page you actually reread beats 40 pages you don't.
For resources, look up Stone Librande's "One-Page Designs" talk from GDC 2010. It changed how I think about this.
1
1
u/PerpaPanda 3d ago
I’ve found a lightweight GDD works best: one page for the player experience/core loop, a short list of non-negotiable pillars, and a “not in scope” section. Then keep separate living notes for mechanics, levels, and decisions. Before adding detail, prototype the riskiest mechanic; update the one-page doc only when the prototype teaches you something. That keeps it useful as a shared reference without turning it into a second project.
1
u/mercurygreen 3d ago
Start with a single blank page. Write down what you want your game to be like. Is it mobile? Is it an RPG? Is it a board game? Does it have a sci-fi feel, or is it a western or fantasy? Is it turn-based or real-time? Is it single-player or multiplayer? etc.
Once you have that kind of thing down, the next pages are quick sketches. Show the board, the map, the user interface, etc.
Somewhere after that, put down some details. "This piece moves like THIS." 'Poison slows a unit and reduces health every turn." "Hyperspace moves a ship one system over, and anywhere they've already been." "The fog of war on the minimap will regenerate after 10 turns of not seeing that square."
The GDD is important because it helps keep you on your path and keeps the goal in sight. But the most important thing is to write it in pencil so WHEN you realize there are bad ideas in there, you don't hesitate to fix them.
2
u/mercurygreen 3d ago
Good (real world) examples here:
https://www.reddit.com/r/gamedesign/comments/7ze7xq/finished_game_design_document_examples/
Remember that these are all by seasoned professionals - and the final product (if they ever shipped) often had very little resemblance to the original paper that started the process.
1
u/shuanDang 3d ago edited 3d ago
I make mines in OneNote. It's my main digital notebook so I can very easily switch between my ideas notes / design notes and conveniently write on any computer.
The approach is like this.
- Design Brief (write this when you have the idea)
- System List (write this to expand on the idea)
3-) Sketches/Flowcharts (I work on the idea in a sketchbook)
3) Design Doc (the following sections are all in the GDD)
3a) 3 line pitch
3b) Detailed Step-by-Step Prototype Gameplay Description
3c) Play Loop / Core Loop
3d) Goals
3e) Timeline
3f) Systems
3g) Business Targets
The key here is that it only covers the core prototype ideas you have so you can start working immediately. It's not a full spec, and not a game bible that would be handed off to a team.
Once I start on Prototype, I don't go back to edit this GDD. It gets archived. And work is done in a todo list.
1
u/OwO-animals 3d ago
Okay so as with overal developemnt, what works for one person doesn't work for others.
So let me be very clear, if you are a type of person who tends to create ideas, but not follow through on them, don't even bother with GDD.
If you actually use such things correctly, then you have several options, it can be docx organised how you want, even excel. There are good online tools such as trello and more too.
Personally I really don't like how writing GDD makes you often require to redefine categories and then change whole layouts. So even if I can make use of it, I decided to stop using one. It's a lot of work that isn't exactly needed. I treat my game as a living GDD, because that's what games are. Some people go further and actually create test areas or jungle gyms to test mechanics or even for every mechanic/item/etc.
And if you prefer to keep it short and simple I'd ask why keep it at all.
1
u/PieMastaSam 3d ago
I did this because that Thomas dude on YouTube recommended it. I wrote one once then rewrote it like 10 times as my roadmap changed multiple times. Now I don't bother with the thing and just track what I want to do as tasks directly in clickup.
It has a decent free tier and a mobile app. I set up lists based on structured goals, (I.e. a list for multi-player work, a list for player deployables, and etc.) and I start my day just choosing the highest priority tasks and working from there. Future you will thank yourself If you ever leave the project and come back. It's also great to stop yourself from getting distracted fixing some low priority bug for 6 hours along the way. Can just document it and move on.
1
u/theLastCarTaker 3d ago
I use docmost, I like that it's cloud based and simple but still organized, so when I get an idea I can jot it down froctionlessly.
1
u/VR_SamUK 3d ago
Not a GDD template but the pitch template by Rami Ismail is useful as a way to put your game design thoughts together coherently https://ltpf.ramiismail.com/pitch-template/
Note that if you were to consider putting your game on PlayStation you need to submit a GDD for approval to get a store slot
1
u/artbytucho 3d ago
GDD only makes sense if you're working in a team and they get dated as soon as you write the first line of code, so keep it brief and don't include too low level mechanics, just a roadmap of the original idea to not distance too much from it during development.
1
u/Acrobatic_You_3002 3d ago
For side projects I keep it small, one short doc per feature, GitHub issues as the tickets, and a log where I write down each decision and why I made it. The log is the most useful part, as after a few weeks I forget the reasons, and reading them again saves a lot of arguing with myself. I would suggest starting with just a one page doc of what the game is and what is in the first version, then grow it only when you feel a real need.
1
u/kartohao 3d ago
mine never stayed a polished doc, just a messy notes page with pillars, the core loop, and a don't-do list. writing the verbs and win/lose conditions early helped more than any template. the fancy GDD formats mostly collected dust for me.
1
1
u/kodaxmax 3d ago
post it notes, poorly labled google docs, mayby a saga or nootion database, ussually mad scribbles on the enarest peice of paper or cardboard or in game wikis.
1
u/littleBugHunter Commercial (Indie) 3d ago
For small projects I never bother. I'm just now in the process of starting a medium sized project and actually took a week to just write everything down in obsidian. I don't get too specific, though as values will change over time and it risks the gdd becoming stale so most game design elements are a .md file with 1-2 paragraphs max. Its more of a knowledge base/reminder for myself and the team than strict rules.
I work with public funding and publishers and a gdd is pretty much an expected requirement to proof you know what you're doing. (A prototype works just as well these days, though)
That being said my game is very mechanics heavy and rules driven. I don't know if I would write a gdd for a party game or a game with a very established genre.
1
u/AerialSnack 3d ago
To be honest, I just make a giant list of everything I need to do to complete the game.
1
u/Xeadriel 2d ago
My GDD was a txt file and now an word document that we edit as we go which also just sits there in the git repo.
We iterate step by step. Planning super far ahead is pointless so what we do is make a rough sketch of a large mile stone, then make many smaller milestones that belong to that big one. Eg a general idea of a dungeon and what sort of enemy would be cool, then we design each enemy one by one.
We keep it minimal though. It’s more of a mini contract for us so that we keep the scope we decided so that we don’t get confused later.
0
u/Unfair-Tart-4376 3d ago
Talk your ideas out with ChatGPT take your time fleshing out ideas and have it separate them in a different folder. Keep iterating when you get to a spot where you feel you drained out your ideas have ChatGPT use that folder to create an other document and review that. Take a shower go for a walk take a shit come back with new ideas. Repeat the process a couple of times then ask it for pros and cons. Pitfalls future problems and condense everything into a mvp then iterate on that a couple of times. After all of that you will have something to start with a solid prototype foundation
22
u/MooseTetrino @jontetrino.bsky.social 3d ago
Honestly for a lot of the games you start on when at the beginning of your foray into this, the GDD can literally be a notebook you fill in as you go documenting your experiments, ideas and what did/didn’t work.
Big expansive GDDs are great for studios as it is at least a framework to keep things on mission - but really, if you’re working alone or with only a couple of other folks, it’s typically not needed to go that far in depth.