Lets Learn Game Dev | What is a Game Design Document? (GDD)

Love this its something valuable I found while doing my game project for a client. It was based on a board game but the requirement was to redesign the game in such way that it look something more original than the inspiration. Client was not sure about the final idea of the game then so, we did few research. And during that time documenting the whole process helped our project. After few iterations of the documents we found the final idea. It is always good to add something to a single document other than random documents.

Hi i want to record audio by my phone while there is sound and play when the sound is stop. Like talking tom. How can i

awesome video ! and btw there is a typo in your thumbnail i just noticed it 😅

Really interesting video for any developers. Music is a bit distracting, though.

Great video! This is so helpful, as I'm just about to start with my next project.

Maybe you have noticed this already, but your opening has a typo: "docuement"
Thanks for the video was really helpful!!

I really struggle with planning a game. My ideas are too nebulous and I find it hard to nail them down without just getting on with it and making a start. A start is all I can do though, I never get anywhere with my projects despite being mostly capable of every individual part of them. Sometimes projects fall apart because of some technical thing I just can't surmount but mostly I manage that part. A lot of the time it's just lack of vision, I think.
I feel like a design doc would help but I can't write one. They're so corporate but it's just me working alone. They're quite narrowing, limiting the scope of what a game can be just by their very existence. On the other hand, perhaps that's what I need?
Obviously a game design doc isn't gospel and can be changed/ignored or whatever in mid-development but I find it difficult to answer most of the questions because I just don't know and I won't know until I get stuck in and start trying things out.

One thing I haven't gotten figured out is how will I pay other people that I work with on a game project?
I'm relatively new to game development, so I haven't worked on a larger scale project that is monetized yet (though I'm almost at that point). I do the programming, and I plan on working with artists and audio people.
I imagine, especially starting out, that offering a revenue cut of the game to others will be the way to go, however how will that be executed? One person earning the revenue and then the others trusting that they will get paid monthly or so?
I think I'm interested to hear yours or other people experience splitting a game's revenue to help my naivety

Awesome video, great job! I read about it on Game Design school, but I never really understood how indie designers use it, until now... Thanks for explaining everything, with examples and stuff. I'm starting a game design blog and channel (in Brazilian Portuguese, though, I'm not a native english speaker) and I'm gonna use this video as a reference, mentioning your channel and linking other videos for the readers. Thanks for the video, your channel is awesome!

Awesome video and extremely important. GDD's are so powerful, even if you're making a really small game - just writing down your ideas, mechanics and goals really solidifies the process and gives you something set to work towards.

Some of the things, like the used software or work schedules, should be moved into their own respective documents. GDD should be left only for the game experience relative stuff.
Speaking of which, unless it's a core aspect of the game, I would put all the enemies, items, levels under a single category, as they are all mutable game content that is built atop of the main game mechanics.
But what do I know, I happened to get paralyzed by trying to find the best possible template (or rather a way). Not only to document stuff, but to use it as a plan for development, and to find and eliminate possible problems before I go straight into production.

I prefer a Wiki to a traditional GDD. It also can incorporate more than just the game design.

IMHO GDDs are for business only, therefore whether you need one or not depends on what exactly and why you're doing. If it's a learning project or a free open source game (or simply put for as long as you don't have to explain what you're doing to someone non-technical) GDD is a waste. Almost everything it'd normally contain should be in UMLs and tickets. ADR is more useful because it explains the whys - why this tech?, why this lib?, why no network support?, etc.

Thank you so much for the template! ❤

Gotta restart this intro with, "What is a GDD and why YOU NEED one!" lol
Great video man, thanks for the info