I am looking for a sample game design document or template to start planning a game.
I did try to get Gemini to find me one, but it started trying to take over things in the name of ‘help’.
It might be a case that, in reality, as each game is different, they need different things in the GDD, but it would be good to have something with some basic structure to get me to think of the important things and stop going off at tangents.
Recommend you use search (not AI) on this set of keywords:
game design schools papers free
That’s like saying you are searching for example school papers without specifying whether its a math or history paper. What kind of game are you looking to make? 2D? 3D? Platformers? FPS? RPG? JRPG? MMO? Open world?
Answering some of those questions might help you find a design document that will actually help you. As someone who has written a few professional game design documents, and read hundreds more, I recommend you figure out what kind of game you’re trying to make. Then write that out, and make that the introduction to your game design document.
Also, if you’ve never used Godot, I recommend you keep your game design document purely non-technical. Because you cannot make thoughtful design decisions with an engine you’ve never used - even if you have decades of programming expereince.
Thanks for the reply, as it took some time for my post to be approved, I started along that journey anyway. I have used the Unreal and Unity ones, but I always found them quite overwhelming by the time I finished. I’m sort of thinking I might just create some freeform notes and then take it from there. As to your question about the game, I have had a few ideas so far, but trying to work out which will be a good scope for an engine I haven’t used.
I second what dragonforge-dev wrote, and have also worked in the industry. Your GDD should match your G, so to speak 
That said, here are (briefly) some common things to consider:
Pitch: the razor sharp “definition” of your game: unique selling points, the overall scope / budget, and essentially why this game deserves to be made. It’s not just an executive summary you can show a publisher - it should force you to think carefully about what makes your game worthwhile. So long as you don’t have an answer to that, the idea needs more time in the oven, from a professional standpoint at least.
Game mechanics: a description of all the features and mechanics in the game (main game loop, win and lose conditions, player actions, enemy behavior, and much more), which should be detailed enough that you could theoretically play a board game version based on this information. This doesn’t mean you have to define every aspect in rigorous detail before starting coding, but I personally feel that the code should never get ahead of the GDD, so the design doc should be maintained, always. Keep in mind that designing is much cheaper than making, so you’re saving your own time by designing as much as you can before committing it to code!
UI: Flowcharts and descriptions of what the UI can do, from options menus to in-game overlays, and how these things connect.
Style: this part of the GDD should act as a unifying bible for the team - the writing style, type of humor, the difficulty, the art style, the sound, the music and really any kind of content. This isn’t only useful for a team, as it also forces you to think about, and define, what your game should be like, and why - an entire style guide can spring from the idea that a game is about triangular hedgehogs who can only survive on hotdogs, or what have you. This in turn can inform seemingly unimportant decisions like “what font should I use for this minigame”, and helps to ensure that your game is as thematically tight as a feature film.
Narrative: This is closely related to the style, and isn’t equally relevant for all games, but even with a non-narrative game it can help to have some kind of backstory, to guide the style and direction. Some games rely heavily on a strong narrative, and this should not be underestimated - a relatable story can make the difference between bland and unforgettable, even for a Tetris clone
Plan: Not to be confused with the day-to-day task management system, this is more of an early tool to help scope the game. It should contain a general asset list (sprites, stills, 3D models, animations, UIs, sound effects, music tracks, dialogue trees, cutscenes, …), code features (“enemy AI”, “pathfinding algorithm”, “multiplayer networking”), and really anything that touches the budget (ie man hours). This is essential to get a sense of what you’re embarking upon, and will also serve as a checklist you can gradually fill out as development rolls along. Don’t set out on a journey without knowing at least roughly how far you’ll be walking!
In addition to being vital (I say as a biased former producer) to development, the GDD is also essential if you’re going to approach a publisher. In my experience they won’t even read the nitty gritty of the mechanics etc, but they will be very interested in the pitch and the plan - essentially what they’re getting, and what they’re going to be paying for it.
That turned into more words than I thought it would… I hope it’s of some help!
I just use a blank Google Doc, then fill-in information and ideas. Then after a while, iterate upon them to make them better. I don’t really have a template for that.
But for me, that method has been working for 7 years.
I think what’s interesting here (and others have mentioned it) is that the docs fit the needs of the game. I think I got caught up with the idea of ‘doing this right’ that I missed the important part and that for me is something which is as short as possible which keeps me on track.
That’s why I posted it, so you can see it can be approached in different ways. There’s no The Template. Quite the opposite in fact. You can get creative and playful with it. It is for a game after all, not for an annual report.
Don’t underestimate the value of thinking before acting
I now have a start (two pages long) which nails the idea, general mechanics, visual style and win/lose states. Going to put it aside now for a day or two, come back and see how I feel about it. But I can already see how the game works (a massive improvement over previous attempts). Now just got to get Godot sorted..
I’ll let you in on a big secret. Just don’t tell anyone else. It’s totally possible to create a very successful game without a design document at all.
While Chahi had a clear idea of how to implement his game engine, he mostly improvised when creating the actual content of the game, allowing the game to develop “layer by layer without knowing where it was going.”
I think this is the issue I have found. I want to have a structure so I get projects finished, but I can find the GDD just a bit of overkill if most of the bits are basically TBC. Sometimes you just want to play just to see if it works….
I just go to sleep at 3 AM and then remember what I have to do the next day.
My comments in the script are the GDD.
3 posts were merged into an existing topic: Should you comment and/or document code?
I agree. start is best.
I moved the parallel discussion to the separate topic Should you comment and/or document code?, so I will just copy over my answer about the GDD here, as it was still on-topic
As for the GDD, I tend to have a Notion page describing the general idea of the game, along with the TODO list. Although the TODO list I’m trying to incorporate into the Godot project directly, I’m yet to find a really good Plugin that satisfy all my needs in that regard. I’m thinking about doing the same with GDD to make it a part of the project directly and be reflected in the git commits. GDD is a living document for me, so it makes sense to bind it to the project.