So, this is a video that many of you have been requesting for a while. I've seen endless questions about it in comment sections and on Discord, with few actual resources available to provide guidance. So, let's remedy that, shall we?
In this video, I'm going to show you how to utilize game design documents to help yourself and others stay aligned with your vision. and how to use a GDD to ultimately bring that vision to life. If this is your first time hearing about game design documents, no worries, I'll explain what they are, when to use them, and why, walking you through several examples, including one that my team has put together for our own project, and providing some additional resources and templates that you can use in crafting your own.
Before we begin, here's a brief overview of what we'll be covering in this presentation. Starting off with introductions. Who are you and why should I listen to you? Moving on to what is a GDD? When should you use it?
Why should you use it? A brief aside about storage and accessibility. Locking things in at production.
We'll then briefly go over all the essentials that go into a good GDD, before walking through a real example using one of our own design documents for a project we're currently working on. to show you what an actual professional level GDD looks like. There might be things in ours that you're missing and never thought to include, in which case, feel free to take inspiration from that and incorporate those ideas into your own. And then finally, finishing off with some additional tools and resources you can use to help you make your own. Intros!
Okay, so who are you and why should I care? Hi, my name is Marushia Dark, author, artist, game developer. Among other things, I hold a bachelor's in fine arts from Savannah College of Art and Design, and have been making games and apps in Unity for close to 10 years now.
Occasionally, you'll catch me teaching art students on the CanKL Discord, or game design principals on the Pirate Software Discord. Additionally, I'm the founder of a small indie outlet called Circuit Studios, which recently published a tracker app on itch.io for use by Let's Players and randomizers. My partner and co-founder, Drackey3k, has been working as a professional graphic designer since 2008, with a degree in game design, and has been working as an industry programmer since 2017, specializing in front-end UI UX, as well as senior software engineering and project management.
Together, we're currently working on a game called The Alchemask. More on that later. Okay, now that introductions are out of the way... Let's get to the thing you all came here for, which is, what is a GDD?
Wikipedia defines a game design document, or GDD for short, as a highly descriptive living software design document of the design for a video game, which I think wins the award for worst possible description ever. I mean, you're using the word in the definition itself for crying out loud. That's what I think of Mr. J. Evans Pritchard.
We're not laying pipe. We're talking about poetry. A GDD is created and edited by the development team, and it is primarily used in the video game industry to organize efforts within that team, resulting in a collaboration between designers, artists, and programmers, and here's the money shot, as a guiding vision, which is used throughout the game development process. The purpose of a game design document is to unambiguously describe the game's selling points, target audience, gameplay, art, level design, story, characters, UI, assets, etc. In short, every part of the game should be included in enough detail for the developers to implement it.
The living part, quote-unquote, just means it's able to grow and change over time as the need arises. So, a GDD is more than just a simple document. It flushes out all the key elements of a game, and will serve as the blueprint for your project no matter the size.
It goes over the core details, such as mechanics, system requirements, or what platforms it's for, and features design elements like how the interaction with players will be structured. It is not all about the specifics and technical details, though. A GDD covers the narrative elements, keeping the story and visuals aligned to the project's purpose.
It will cover the setting, themes, plot, design, and characters, as well as how they interact with the world. A good way to think of it is by analogy. If you were to write a novel, people are familiar with the idea of a pitch summary, often shown on the back or inside cover of a book, that gives a high-level overview of what's contained inside. Then, you also have an outline that breaks down the major beats of the story, essentially the skeleton of your novel.
In my experience, a lot of game developers, when just starting out, treat game design documents like the elevator pitch, when really you should be thinking about it more like a comprehensive outline or floor plan. This is essentially your first pass through all the steps of the piece from beginning to end. And that's what your game design doc is when it comes to development.
In terms of when you should use a GDD, the answer is, pretty much always, for every project that you care about and want to succeed. A GDD allows all members of your team to be on the same page with respect to expectations and scope. But What if I'm working by myself, I hear you ask. When working solo, a GDD is still an important tool for organizing your thoughts and scoping out your project.
Ultimately, the GDD guides every stage of the life cycle of the game, from pre-production planning to post-launch updates. It will keep your vision consistent and ensure that future work will serve the original intent. Should I use this for a game jam?
It may sound counterintuitive, but taking the time to write out a GDD can actually speed up production of your game jam entry by getting ideas out of your head and onto paper. The first one I ever did like this, I actually tricked our community into learning, which was quite funny. So many people were like, I don't want to do that. I can't make a game. I can't program.
And I was like, okay, then we won't do a game jam about making a video game. We'll do a game jam about what you would do if you did make a video game. So they created what's called a game design document.
which is you make a piece of paper that says everything you would do on the if you made a game all the tools you would work with all the things that you would learn everything you needed to know how you would plan it out and then that was the first week of the game jam i was like it's just a week-long jam after the week was over i said okay second week bonus round go make the prototype and they went well i already know how i'm not afraid anymore i did all the research now it's easy and they went and did it we had um i think it was 98 of the teams actually went forward and made a prototype on our first game jam wow as a result of awesome dude By writing things down, you can also A-B test ideas to decide what works and what doesn't work, before having to expend precious time, energy, and resources writing code or making art assets, since some ideas can just be eliminated outright as either not fitting the theme or being too ambitious or not interesting enough to pursue. Returning to the analogy of an outline, for smaller, simpler projects, a streamlined The back of the envelope outline might suffice. For instance, here's a template for a one-page GDD that could be useful for quick turnaround, or projects in which you have a very limited amount of time for development.
Something like this can be filled out in under an hour, and it's quick enough and stripped down enough that you can iterate through a bunch of them quickly until you land on something that works. However, For larger endeavors, more thought, attention, and care is needed to really flush out all the major details. Case in point, here's a template created by Dr. Diane Pazewski, a retired professor from the University of North Carolina with a Ph.D. in Comp Sci, who, among other places, worked in networking and software engineering for IBM for over 25 years. So, you think she might know a thing or two about professional design docs? Just saying.
Which brings us to, why bother? What's the point of all this? As far as why to use a game design document, one of the greatest benefits of having a detailed GDD is risk management.
It will help you anticipate the challenges you will face and give you time to solve problems, or recruit someone who can, way before core development begins. If you're working solo, you might be tempted to think, Oh, I know what my project is about. I don't have to write it down.
I can keep it all in my head. And sure, maybe you're Mike Ross, blessed with a photographic memory and a natural talent for numbers. But 99 times out of 100, this is probably a mistake, and it would be better to flesh things out on paper.
This helps you engage more of your senses to actually see the project objectively, while also ensuring that things are clear, have a natural progression, and won't be forgotten. I'm sure we've all had experiences where a great idea or burst of inspiration flashes before our mind's eye, only for us to struggle to recall it later when we actually need it. Writing things down helps. When working in groups, It also serves as a communication tool.
By having a detailed GDD, you ensure that every team member, from the artists to the programmers to marketing, will understand the game in the same way. This alignment is crucial to maintaining a cohesive project and team, and it helps to manage scope. It will define what's in and what's out, which will keep the project focused and help avoid feature creep, which is a common challenge for game dev.
Interestingly, in one of the recent Blackthorn Prod Pass the Game challenges, Constellation Creative actually made a GDD for the project on their first day, which I thought was really smart. It's something I imagined I would do if I were part of that competition. And as I watched the video, I found myself wondering if anyone was going to make one, or if it might have violated the spirit of the no communication rule, as it's a way to circumvent that barrier by leaving notes to other developers in the assets folder, sort of like, heavily commenting your scripts or writing out a readme. In this case, Constellation were the last ones in the chain to touch the game, so technically they didn't talk to the other devs.
I guess we'll have to see what the community thinks about it over time, as normally GDDs are something you'd lay out at the beginning of a project rather than the end. But assuming it doesn't violate the rules of Liam and Noah's Challenge, I think more game devs will probably make them going forward. and incorporate GDDs earlier in the pipeline, just because they're so damn helpful.
And if there's any doubt of that, you can compare the state of the game before and after Constellation Creative got their hands on it. That's not meant as a put-down to the other devs, all of whom worked hard as well, so much as it's a testament to the power of this tool, and the value of good organization principles. Since Constellation Creative participated as a team, rather than solo, It was arguably even more important to the process, in order that they all worked together towards the same unified goal, instead of at cross-purposes.
After all, failing to plan is planning to fail. One thing that's interesting and unique about Constellation's design doc was that they included a section on bug fixes and problems within the game, since they were receiving an existing product and having to improve upon it, rather than starting from scratch. That's certainly something to consider if you ever find yourself in that position. I don't think their game would have turned out half as well if they didn't start with the GDD.
Ultimately, the game design document guides every stage of the lifecycle of the project, from pre-production planning to post-launch updates. It will keep your vision consistent and ensure that future work will serve the original intent. A quick note about storage.
Before we go on to the actual meat of what goes into a GDD, let's have a quick chat about where to keep them. It's pretty crucial to make sure that this document is accessible and editable by the right people at the right times. Traditionally, many developers and teams start with a simple text document or spreadsheet. These are well and good for small teams that are in close proximity, where any changes can be communicated effectively.
For instance, Drackey and I worked on drafting the GDD for our game together in Google Drive, and discussing implementation over Discord, which worked because it was just the two of us at the time. But as projects and teams grow in scope and complexity, you might find these methods a bit limiting. This is where we can turn to some specializing tools such as Notion or Confluence. The latter is put out by Atlassian, the same people that make Jira, Loom, and Trello if you're familiar with those.
These tools offer features like version control, which will help track changes in authorship and allow you to understand your project's evolution over time. This is crucial to understanding why certain decisions were made when looking back after a few years. Another option that's become popular these days is to set up your own wiki.
These are markdown documents that are easily hostable from your PC or using free online services. Most of you are probably familiar with Wikipedia or Fandom. No matter what tool you choose, the key is consistency and accessibility.
Ensure that you always know where the design information is stored, and let your teammates know where they can get the latest version of the project. I mentioned at the start that a game design document is a quote-unquote living document, meaning that it's open to alteration. Once you have entered production, however, a critical practice comes into play, freezing the GDD.
Freezing the game design document doesn't mean that it becomes untouchable forever after, but it does mean that major elements of your game should no longer be subject to change, like the core mechanics, story arcs, or primary features. This is crucial because it sets healthy boundaries. Constant core changes will lead to a ripple of effects that can include delays, increased costs, or scope creep, and impact every area of development.
As the saying goes, measure twice, cut once. You might be familiar with the idea of model sheets and design bibles that artists and developers will create in reference, so that everyone is on the same page from start to finish. throughout a particular project. The form is solidified in place to maintain consistent quality and reproducibility, even by multiple artists. A GDD functions in much the same way, helping to unify and clarify the goal of what you're trying to produce.
That's not to say these elements are forever set in stone, or that you can't make changes to the project during development as realistic constraints or new innovations arise. But these should be kept to a minimum in practice, as this sort of flies in the face of all the prep work you've done up to this point. For larger, complex projects, having a change control process in place is also useful.
Tools like Sourcetree offer this automatically as part of their software. Or you can track them by hand through a changelog. Obviously, if you're working solo, that's less relevant.
Though, being able to see where you've been and why you did what you did can still save you time, prevent scope creep, and avoid chasing after moving goalposts. So that's the high-level overview of what a GDD is, when to use it, and why. Just to recap, a game design document can be thought of as more of an outline than a pitch or summary. It's a blueprint or roadmap for software development, the skeletal structure upon which to build all your other design considerations. It's useful when working alone, and critical when working in groups, both for staying organized, preventing scope creep, A-B testing your ideas, solidifying your vision, and managing risk.
And as best you can, try to avoid making changes to the document once you enter the production phase, treating it like a model sheet or design bible, unless and until absolutely required to by outside circumstances. Alright, so I know for some of you that might have been a lot to take in, especially if you're new to game dev or this is your first time hearing about game design docs. I promise it's not actually that difficult in practice, and after doing a few of them, you'll get the hang of it.
Remember that this is ultimately meant to be a tool to serve you, not a master to enslave you. Before I walk you through a specific example in detail, using one of our own projects, I just want to check in with you and see how you're doing. giving you a chance to take a break and come back if you need it.
If at any point there's something you don't understand, be sure to leave a question or comment below this video, as we plan to do a follow-up answering your concerns, and which we'll link as an info card or in the description once that becomes available. Also, if you're finding this video helpful so far, remember to please give it a like, subscribe, and share it with others. It really helps out the channel. Thanks.
So now we're going to take a look at a specific example, using the design doc for one of our own games that Draki and I put together, which is called The Alchemask. This game is still in development and I'll be doing devlogs and streams of it on this channel in the future if that's something you're interested in. Importantly, I'm not just going to show you what we put in the design doc, but also explain the rationale for why we included those particular elements.
and some things that we didn't include because they weren't necessarily applicable to us, but which might be applicable to your specific project. Some of what I cover in the following sections might seem kind of basic, but I'm approaching it from the perspective of someone who might not know anything about game design or the development process, and that this is their first time encountering such a thing. So if you already have a fair bit of knowledge and experience, that's great.
I beg your indulgence and hope that you'll learn something from this as well. But for everyone else, let's get started and take a look at the game design document for The Alchemask. First thing you'll want is some kind of header or hook to serve as the barest of bare-bones packaging for your game. That means title, tagline, and maybe some splash art if you have it.
Sort of like if you were setting up the storefront for a Steam page. It's people's first impression when they look at the document, and in turn your game. Even if you're the only one working on it, it's still useful for telling you exactly what's going on at a glance.
At the top we have the title of the game, which should probably tell you a lot about it already. Something about combining alchemy and masks. For your game, you might not have any art assets yet by the time you go to put together the GDD.
That might be something you want to work on in tandem, so you can start to clarify the look and feel of the game early on. Even if you just have concept art, preliminary sketches, or a reference collage of things that I want my game to look like, that can still work as a stand-in, not only to give yourself and your team something interesting to look at, but also because a picture is worth a thousand words. and you can start to see the direction of your game and where it's heading and how it will take shape.
In our case, we have a roster of the different starter characters, and we can go into character design in another video. Below that is a tagline, Choose Your Face, Choose Your Fate, building a bit of branding, identity, and intrigue that a producer or marketer can start to use to help you sell your game down the line. It can also serve as a guiding through line.
So without knowing anything else about the game, we know just from this one slide that we have a 2D vector game with a diverse cast of characters, something to do with alchemical magic and masks, wherein you have player agency and choice in the matter, and that in turn is going to have something to do with determining future actions the player can take, the details of which we'll see later. Below that we have a table of contents, You don't strictly need this, especially if yours is only a single page long, but it helps keep things organized and showcases all the different sections within the design doc, as well as being able to navigate around quickly. You can pause the video and read through that if you want. We'll be going through each of these in brief in just a second. If you're using something like Google Docs, it's really easy to turn these into headers to automatically format everything for you.
Depending on the scope of your game, you might not have all these categories. For instance, if it's a really small mobile freeware or a game jam project, maybe you don't have tertiary mechanics or lighting considerations. Or you might need to flush out specific systems unique to your game in their own section. For instance, Alchemask uses elemental magic, so we have a section dedicated to that.
Same for diegetic menus, which we'll talk about later. Ours is a single-player, single-pay game, whereas if you're working on a multiplayer MMO, maybe you have sections about networking, PVP, chat rooms, recurring payment structure, etc. That's not an endorsement of loot boxes and gacha mechanics, by the way, just using it as an example of how different games will have different requirements.
For some of you, this looks like pretty standard fare if you've written design docs before. Few of you who have experience building and publishing games might even understand why we have sections on marketing and systems, and can begin to formulate a sense of what that refers to. What might be new to some of you if you've never worked in software engineering are the last sections, labeled Work Packages, Activities, and Tasks, and we'll split those off into their own separate presentation as they have to do with transitioning from the planning phase into full production.
Also because it's something we're still working through for our own game. Moving on! Introduction!
Otherwise known as general, overview, or basics. We start with a summary. Alchemask is a cute roguelike twin-stick shooter. Choose your face, acquire elemental magic, and seek out the all-powerful Alchemask.
So some magic MacGuffin, that's our end goal for the game. Remember before how we said a GDD is like an outline? Whereas most people think of it as an elevator pitch. Well, the summary is the elevator pitch in this case.
That's the thing that goes on the back of the book or in your Steam page description or in your social media ad copy. Your short description, and I'm going to tell this for other pages that I'm reviewing today. Your short description is about explaining things that are not story and not mood. When people are shopping on Steam, they're not looking for story.
They really care about the gameplay. So yeah. When I look at short descriptions, I'm always looking for people to explain the gameplay. And so I think you should be very, very specific, not just try and make this sound like it's a narrative beat that there's an AI chasing you. Really say something about how the level changes or the fact that you've coded the level to change to try and kill you, that sort of thing.
So it doesn't sound like just a narrative beat. Obviously, that is not the full extent of what goes into a GDD, as you can tell from the length of the index alone. Hopefully that much should be obvious to everyone at this point, but a lot of people still seem to struggle with that. Inspirations!
These are other games that we love and want to emulate when making our own game, existing titles that have features or systems that we know already work, and that we hope to study and replicate. So for Alchemask, some of our inspirations include games like The Binding of Isaac, Cult of the Lamb, Majora's Mask, Hyper Light Drifter, Hades. If you've got picks, and why wouldn't you if it's an existing IP, even better.
It doesn't have to be just games. We're also inspired by real-world alchemy and pop culture, as you'll see later. So for those of you who love Miyazaki and want to make a Studio Ghibli game, that would go here too.
This doesn't have to be an exhaustive list, and indeed you'll add new inspirations during the production phase, but it should serve as a baseline to help frame the vision and direction of the game. At the same time, you don't want to develop producer syndrome and start to micromanage or kitbash things together in some Frankenstein hybrid monster of stuff that will never work together. By producer mindset, I mean the kind of mentality that thinks Schindler's List could have been improved by adding a talking dog into the mix. Your ideas should be grounded and feasible. By all means, you know, dream a little bigger, darling.
But think through your ideas and try to work out a way they can actually blend seamlessly together. Games like Cult of the Lamb and Jak 2 are examples of hybrids that combined radically different genres together to produce something unique that works synergistically. So know what your ultimate goal is, otherwise you get the game design equivalent of this.
Player experience! otherwise known as UX design, something not a lot of people consider, but how do you want your player to feel as they play your game? A horror game is very different from a cozy game, is very different from a power fantasy action adventure, is very different from a puzzle game. We'll talk about controls later, but an immersive sim can play quite differently depending on whether you're using a dual-shot controller, mouse and keyboard, or a VR headset.
Is your game made to be accessible to children? Or does it have Souls-like difficulty? How long is your game?
You might be able to breeze through an indie platformer in an hour or two, versus Tears of the Kingdom that takes over 100 hours to get full 100% completion, and that's with glitches and speedrunning strats. Sorry if I just dashed your hopes of ever finishing it, but it's true. Things like that you might want to consider as they ripple out and affect the entire rest of your game. Platform.
Fairly self-explanatory. Is this a PC game, a mobile game, console game? Is it going up on itch or steam?
In our case, it's a PC game going on itch and steam. Software. Also self-explanatory. Are you using Unreal, GameMaker, Godot? Are you using Photoshop, Blender, Substance Painter, Audacity, etc.?
In our case, we're using Unity Engine, because that's what we know and love. Pricing controversy aside, it's still a great piece of software that's made tons of top-tier games. Here's just a few of them.
Topic for another time. For the art, we'll be using vector graphics made in Illustrator and supplementing with Krita, because that's what we have already. Depending on your needs, your budget, your skill set, and what's available to you, that will all go here. So for those of you that like pixel art, maybe you have Aesprite on here. Genre.
Again, fairly straightforward. Are you working in 2D or 3D? Or even 2.5D like Paper Mario and Bug Fables?
Is your game horror, fantasy, slice of life? Are you a shooter, platformer, an XCOM-like, etc.? In our case, Alchemask is a top-down twin-stick shooter dungeon crawler with roguelike elements in a medieval fantasy theme. I think that pretty much says it all right there. Although in our case we're still deciding on whether to do a strict top-down 2D like Binding of Isaac, or more of a 2.5D like Cult of the Lamb has.
As of my recording this, that's something we'll have to finalize on our end before going into production, as it makes a big difference to the overall pipeline and what assets we'll need to make. In theory, crafting modular systems should make it easy to switch between the two, since you're separating out logic from visuals from data. Just change Y to Z.
But... But better to figure that out from the start and save time later. I know Ed McMillan took Binding of Isaac and turned it into a 2.5D variant when making Legend of Bumbo.
Maybe during prototyping we test out both methods. We'll see. Problem for Future Circuit.
If you have any thoughts on that, feel free to leave feedback in the comments below. Moving on. Target audience. Otherwise known as market research.
Ooh, scary. Essentially, who is your game for? This is something a lot of new developers don't think about, but the reality is, not everyone on Earth is going to play your game. Sorry, that's just the way it is. Shocking, I know.
So, trying to be Starfield and catering to everyone just isn't going to work, because not all humans like the same thing. People seem to enjoy Pokemon, so making a game like Palworld might make sense. People seem to like Hollow Knight with 93% approval across 300,000 reviews, so creating Runefencer Ilia makes sense. Knowing what people are hungry for by tapping into the cultural zeitgeist helps you figure out what to make, but you still have to deliver the goods in the end.
They're just shopping at the grocery store where they're looking at boxes and they're like, oh, does this cereal look good? Yes? No? Okay, moving.
They don't. But then when they sit down for dinner or to eat the cereal in the morning, that's when they want it to like wash over them. Yeah, so basically at first glance they need to see, okay, this is the kind of cereal I was looking for.
Let me put it into my bag. And that's why you don't do a cereal when you're making a cereal box. You don't try and appeal to everybody. You like say, okay, I'm the person trying to get healthy.
I'm the person shopping for my kid. I'm the person who has a medical condition and needs like a special fiber diet or something. You know, there's like different things.
You don't try and make a serial that appeals to everybody. And so you got to be very specific with what you're trying to approach, if that makes sense. Yeah, that makes sense. Okay. On the other hand, maybe you don't have the resources to do that kind of research, or it's a small project, or you just really want to make the game of your dreams into hell with profitability.
You're doing it for pure passion. Well, even in that case, you should still have an idea of the target audience in mind. What type of person? besides you is going to enjoy playing this game what we in the biz call a target avatar basically an encapsulation of all the qualities an ideal or stereotypical or average gamer playing your game might have so on steam for instance the store gives you messages and recommendations all the time of oh we see you like this game here's another game along those same lines that we think you'll enjoy based on our tracking algorithms they change the algorithm within probably like 2020, I think is when they changed the tagging algorithm a little bit. If I scroll down, so tags control what shows up down here, the games that are more like this.
And what I can typically do is if I go down without even looking at tags, I can tell how good your game is tagged. You want to tell the Steam algorithm, my game is like this one. Because when people shop for Steam games, look, there's sections all over the place where Steam is saying this game is like this game, this game is like this game.
It sounds weird, but When you're marketing your game on Steam, you actually want to say, I'm more like this game. I'm like this game. Because Steam is a recommendation engine. Discovery Queue is actually how a lot of people find games on Steam.
It's a very high traffic source for people who don't have YouTube channels. Basically, you go on Steam and there's this button that says Discovery Queue, and you click it and it just randomly pulls up 10 games that Steam thinks that you're going to like, and shows you those 10 games. And if you like it, you say, yeah, wishlist it. Or you say ignore, and then you hit next.
And it just finds these 10 games. A lot of people on Steam use it. Is your game made for kids or for adults? In our case, Alchemask is a bit grimdark without being M-rated, so our target audience are adults and young adults who enjoy roguelikes, cute characters, vector graphics, shooters, and collect-a-thons.
Players who already enjoy similar games such as The Binding of Isaac, Enter the Gungeon, Cult of the Lambs, Spelunky, etc. Or for those who grew up on things like Invader Zim and other gothic cartoons. The reason this is important is you don't want to be working at cross-purposes and trying to please everyone, again looking at you, Starfield.
You want to make design decisions that cater to your target audience and which reinforce the types of things they enjoy and avoid the types of things they don't enjoy. Someone who loves Call of Duty might not like Banjo-Kazooie and vice versa, although I'm sure some overlap between the two might certainly exist. If your target audience doesn't like something, it wouldn't make sense to include that in your game.
Moving on to the concept stage, this is where we begin to flush out the core gameplay loop, theming, story, and mechanics. Core loop. If you were to distill your game down to its very essence, what is the one thing the player is going to be doing over and over again each time they play your game?
Something that is essential to the identity of your game. For instance, if you're making a Zelda game, the core loop would be start off as Link, find a sword, escape the starting area, go visit a bunch of dungeons, get items, use those items to fight bosses, defeat evil, save the world. For each of the titles in the Zelda franchise, you might get more specific in that.
So in Majora's Mask, you'd have the three-day cycle, in Wind Waker, you'd have sailing, etc. But I think all of us more or less at least have an intuitive sense of the main formula for what makes a quintessential Zelda game. For Alchemask, our core loop will be you pick a character, start in a central hub, pick one of four paths based on the classical elements, earth, air, fire, water, discover and unlock new characters and items along the way, battle your way down that path to the boss, beat the boss, progress to the next floor, rinse and repeat five times till you get to the final boss, whose loadout is then based on the choices you made along the way.
Defeat him, win the game. That might sound pretty generic, but at this stage, that's kind of the point. It laser focuses you on those aspects that are absolutely essential to the game, and which cannot be reduced or taken away.
Actual specifics and things that help your game stand out are covered elsewhere under themes and mechanics. Speaking of theme... And you can have more than one, but these are the concepts, ideas, or symbols that recur throughout the work. So for Ocarina of Time, you have music and time, obviously.
For Twilight Princess, the theme is darkness. For Enter the Gungeon, you have a gun and you're in a dungeon. Themes don't necessarily have to be that on the nose. For instance, a game might have isolation as a theme, or discovery.
I'm sure a lot of people are familiar with that. the stages of grief theory for Majora's Mask, which, if you're not, look it up, it's actually pretty cool and quite compelling. For Alchemask, as the title suggests, the two central themes will be masks and alchemy, masks revolving around the concept of identity and mystery, one's powers are tied to one's face, which can be removed at various times and swapped out for different masks again, not unlike Majora's Mask. One can acquire various masks throughout the game, and some of these might even have special one-off encounters. Different characters will have different strengths and weaknesses, and different motifs.
For instance, the Cartographer is tied to map and compass events. Having ready knowledge of the dungeon layout for better planning. The Makus specializes in elemental magic. The Maniac deals in explosives. The Doctor deals in poison, etc, etc.
These will be further developed and refined and balanced over time. Alchemy will be represented in the elements and in various items one can acquire throughout a run. In addition to fire, earth, water, and air, there's also consideration for things like ice, poison, lightning, darkness, and light.
Elements affect the aesthetics and abilities of rooms, items, enemies, and bosses. Alchemy also plays a role in the various items that one can collect. These tend to be based around the periodic table, or at least their medieval equivalents. and alchemical processes such as putrefaction, sulfur-salt-mercury triad, or the philosopher's stone.
Further research into traditional symbols and practices of real-life alchemy will be required. So it's not like we have every last detail figured out, but we know what the goal is, what the parameters are, and we have a plan of action for what we need to work on that's very specific and focused. Next we have the actual game mechanics.
So you have primary mechanics, which are the main way the player achieves and progresses through the core gameplay loop. For Mario, this would be jumping. For Mega Man, it would be jumping and shooting.
For Doom, it would be first-person shooting, etc. In our case, the main mechanic is just moving and shooting using twin stick controls. One to move, one to aim.
You navigate the room, shoot enemies and objects, and make your way to the end. Simple as. But with room for experimentation in the prototyping stage to actually hone in on the actual feel. Something you can't get from planning alone, but have to A-B test. Just a quick note here.
Some paths and items will be locked, requiring keys in order to access. Keys can be literal keys, money, skulls, bombs, health that gets sacrificed, special abilities, or other consumables. Locks can be doors, chests, bombable walls, traps, islands surrounded by normally impassable terrain. or entities such as enemies and NPCs that drop things once the toll has been paid.
Essentially, a lock is just anything that stops progress, and a key is anything that enables progress. So like an eye switch that you shoot with a bow, to open a door is a form of locking key puzzle. If you've seen GMTK's Boss Keys series with his dungeon mapping, Mark explains the locking key concept quite well, so definitely go check that out if you haven't already.
Returning to our document, locks will never borrow the critical path. The player will always have access to the boss, though they might not necessarily be skilled enough or strong enough to take them on without relying on locked prizes. But they could, if they're skilled enough and understand the mechanics of the game well enough.
So because we're making a roguelike, as opposed to a classic dungeon crawler like Zelda or Banjo-Kazooie, we're not going to have forward progress be locked behind collecting items. but creating a skill barrier is perfectly acceptable, and I'm sure eventually you'll see things like damage-less runs and other self-imposed challenges that players come up with. If you're making something like a Metroidvania, then obviously locking forward progress behind collecting key items is a core mechanic of that genre.
Secondary mechanics are just those things that help augment the primary mechanics, but which aren't strictly critical to achieving the goal. For instance, most Zelda games have Link engage in sword combat or bow combat as a primary mechanic, but not all games will have a musical instrument. In our case, secondary mechanics include consumables, like health upgrades, currency, explosives, orbitals, etc., as well as special rooms that revolve around those things. Here's just some early concept art for what our consumables could look like, which might or might not make it into the final game. We'll have to see as we move into development and polish.
Tertiary mechanics are the same, just further removed. They're things that are nice to have but aren't strictly critical. For instance, we can imagine a Zelda game that didn't have rupees or heart containers or minigames and yet still had all the primary and secondary mechanics like Epona and Warp Songs.
In fact, a lot of mods and ROM hacks tend to do stuff like this. For Alchemask, tertiary mechanics include things like a crafting system and a wardrobe system that give you a bit more variety and customizability, and ways for players to experiment and exert agency and choose to augment their runs. As mentioned previously, our game relies on the use of natural elements as a core system, so we have a section dedicated to that, fireburns, ice freezes, etc. Basically just noting ways in which the different elements will interact with and influence gameplay and visuals. That's its own separate topic for another time.
But the basic idea is that through biological and cultural evolution, humans have built up an intuitive sense of what the elements do and players come with certain preconditioned expectations for how they should behave in your game and will get mad or confused if those expectations aren't met. Here are a couple of great video essays on that topic if you want to know more. Moving on to combat.
In our game and a lot of other games, combat and enemy AI are a core feature. Most of the details will be worked out during production as you design systems and enemies, but having a high level sense of direction for how combat generally works is a necessary consideration at this stage. Shooting is different from swordplay, is different from spellcasting. Combat in Fire Emblem is not the same as the combat in Bayonetta, it's not the same as the combat in Gears of War, for instance. If you have NPCs and quest systems, you can include that here as well.
Obviously if you don't have combat in your game, don't include that. Maybe instead or in addition to combat you have puzzles. and dungeons.
So if you were making Portal, for instance, you'd go into detail about how you use the portal gun to spawn blue and orange portals to redirect beams of energy, and move companion cubes in a lock and key system. Something along those lines. Realistically, we could probably include a lot more detail than what you see here, and we probably will before production. Again, the GDD is a living document, so as you come up with new ideas, new things to add or change or remove.
go ahead and modify it. Nothing's frozen until you actually begin prototyping. So, just as a quick aside to showcase what this looks like, here's an example from the game Mass Flux, which was featured in the 2022 Pirate Software Game Jam, and I believe was even the winner that year.
This comes from the site Develop.Games, which was put together by Jason Thor Hall from Pirate Software. An awesome dude that you should all be following if you aren't already. If you want to get into game dev, you should definitely learn as much as you can from this man.
Thor is very wise. Anyway, Mass Flux is the example template he uses when explaining GDDs, and we can see examples of puzzle mechanics, complete with animated GIFs. So, where a picture is worth a thousand words, a video is worth a million. You can look at these and know exactly what the end goal is.
Note it says art is not necessarily final, and that's okay. These were probably just hashed together in some GIF-making API specifically for the GDD. The idea at this stage is just to clarify the vision and direction as much as possible. It's likely you don't have anything built in the engine yet, and that's okay.
You can build mock-ups in an image editor. For instance, with a few sprites on some keyframes, you could animate this in Photoshop, Krita, or After Effects. For previous projects, such as the Circuit Tracker app that we made, we did mockups in Illustrator to get the layout of UI elements down before rebuilding them in Unity.
Trust me when I say it's a lot easier doing it that way. It isolates and eliminates a lot of variables and moving parts. I only wish I thought to do it sooner.
Moving on, story. Not every game necessarily has story components. For instance, I don't think anyone would argue that Pong or Tetris has a story, unless you want to get incredibly esoteric about it. But most games do, even if it's just a simple one.
How to write good stories, particularly for games, is a massive and complex topic for another time. But for our purposes, if your game has a story, you should include a section about that in your GDD. Obviously, it's not expected that you have every last detail of the story nailed down at this phase. but the more you're able to clarify, the better.
In practice, you'll often find that once you start working on the actual production level assets, the story will influence gameplay mechanics and vice versa, or even feedback from testers in the community or financial backers. Case in point for Runefencer Ilia, which yes, take a shot for me bringing up that game again, but it's an awesome game goddammit. For RFI, backers of a certain tier got to add characters, items, and enemies, which might or might not affect the story and gameplay mechanics. I know one person made fanart of Ilya with a drill rune, which I don't know if Newtbox is planning to add that to the game, but it's super cool and I hope they do.
But as far as story, I mentioned before that a GDD is like an outline for a novel. If you've got a complex story, You can and should be working on an outline in parallel with your GDD, along with concept art, so you can get the big picture things nailed down as quickly as possible. In our case, because it's a roguelike, there isn't necessarily a lot of narrative depth, although you certainly could. A game like Hades is a roguelike with a tremendously deep and complex story. For Alchemask, most of the narrative comes by way of implication, from archetypes and character relationships.
as well as a few cutscenes at the end, sort of like Mortal Kombat 11 and how each character has their own motivations for wanting to win the Outworld tournament. Here, we're more concerned about emphasizing gameplay over story, although something interesting to note when it comes to games, as opposed to any other medium, is that players will very oftentimes create their own emergent narratives. Games like RimWorld and Oxygen Not Included come to mind. wherein players are given necessary tools and components to build stories themselves. So that's something to think about as well.
What tools will you have to make that you can then give the player to craft their own narratives and unique experiences? What are some things that might crop up by accident just from autonomous systems interacting with one another? Like, maybe a random enemy gets attacked by wolves in Breath of the Wild because they aggroed them in close proximity and friendly fire exists. Is that a thing?
Someone will tell me in the comments. If not, I'm sure some other game like Far Cry has done stuff like that. You all know what I'm talking about. Let's move on to artwork.
Specifically visual art. Unless you're making Simon Says or Mother May I, or some purely text-based game like ye olde Dungeon Prompt Adventure from back in the day, chances are your video game is going to have visual art somewhere, someway, somehow, even if it's just box art and UI. We'll talk about what to do if you're not a good artist another time, but whether you're making it yourself, buying assets, or hiring out commission work, you definitely need to include that in your design doc.
Art is its own topic that can be espoused upon endlessly, but for the purposes of your GDD, the main thing you want to focus on is the overall direction. Is it pixel art? Is it vector graphics?
Is it 3D modeling? Does it use cell shading versus hyperrealism? Is it one of those funky non-Euclidean games? You could take the same basic mechanics and apply different art styles to them in order to get two very different games. For instance, people have tried modding 2D pixel versions of some of the 3D Zelda titles, or vice versa, and this affects not just the look of the game, but also the feel and progression as well.
Some decisions just seem bizarre if you suddenly switch out the art style. Like, it wouldn't make sense to have yellow ledges in a game. Full stop, period.
Need I say more? Alright, well, it makes even less sense to have them in a game like Limbo, where everything is 2D black and white horror, and... half the fun is not knowing what the environment is going to do to you.
I mentioned before how, after Ed McMillan made Binding of Isaac, he later went on to develop Legend of Bumbo, which was a 2.5D version of the same thing, using a lot of the same sprite work, yet the game plays a lot differently since now you have a third dimension to consider. For Alchemask, ours is a 2D game rendered in a clean, crisp, vector graphic style. The characters are mostly black and white for readability. Which is the same reason Hollow Knight does it, by the way, helping them stand out against an assortment of colored backgrounds.
As mentioned before, the elements play a big part in the theming and design, so each area is given a particular color to match. This just helps tap into our monkey brains and leverage existing tropes, so the player doesn't have to spend a lot of time thinking about it. They can just look at the environment and know instantly what things mean. We can talk about color theory another time, and how most people get that completely wrong.
Depending on your game, you might want to factor in considerations for people with disabilities, such as color blindness. Mark Brown talks about that in his Designing for Disabilities series, particularly with the use of symbols and sounds in combination with colors. Though, just as an aside, you can also achieve the same result with value contrast and shape language, which is why all of our characters each have their own distinct silhouettes.
For Alchemask, Entities should be iconic, distinct, and easily recognizable with strong silhouettes, as we just mentioned. They should evoke a sense of cuteness, and sometimes also grotesque horror, or spoopiness, taking stylistic cues from things like The Binding of Isaac, Cult of the Lamb, Hollow Knight, Invader Zim, and Has-Been Hotel, and then just throwing in some more concept art, reference, and mock-ups, trying to get a sense of what we're aiming for. Most games have some sort of VFX that contribute to the game's overall juice. Things like particle effects, flashes, squash and stretch, etc.
In our case, a lot of that is built into the weapon system in combat, with explosions, lasers, and so forth. Character emojis, so like how in Oxygen Not Included, the duplicates will have little icons above their heads to indicate their state, although that starts bleeding into UI, which we'll go into in a minute. You can have effects when you interact with things or pick up items and change equipment.
A lot of this is really down to the specific needs and the style you're going for. Here I'm going to wind up doing a lot of the art myself, but also relying on assets from the Unity store, such as all-in-one shader, as well as some VFX packs that match the cartoony style, and which would just be a huge pain in the ass to try and make from scratch, although I could certainly do that if the need arises. Not every game will necessarily have lighting as a consideration. For instance, if you're making a 2D sprite game using nothing but unlit shaders, then all the light and shadow is taken care of in the sprite assets themselves. Something like Baba is You or Pac-Man comes to mind.
However, stuff like Fog of War or 2D lighting could be something you include. For 3D, lighting is almost certainly going to be a factor, and you should include some notes about that in your GDD as well, even if it's just Tune Shading in Bloom. Same goes for Post Processing. For Alchemask, Unity recently came out with its 2D lighting system, so we were hoping to take advantage of that and create an effect similar to what you see in later versions of Binding of Isaac, such as Rebirth and Afterbirth, where the devs started to incorporate dynamic lighting for atmospheric effect.
For us, worst case scenario, we can always fall back on unlit shaders and add that later if it proves too difficult. But again, the point of it GDD is that this is the plan, this is the scope, these are the design parameters we're shooting for before the limits of real-world constraints take effect. Of course, it should go without saying that audio is an important consideration when making a game.
Some of the greatest games ever made are remembered, in part, because of their awesome soundtracks. I'm sure you can list off many of your favorites. If I started humming the Mario theme or anything from Ocarina of Time, I'm sure most of you could probably finish the melody reflexively in your head, and these have gone on to become cultural influences in their own right.
Dedicating a section of your GDD to music is less essential, not just in terms of the soundtrack or even the overall vibe, but also how and whether the music will play a role in the game itself. For instance, Ocarina of Time and Majora's Mask give music as an actual mechanic, even more so for various rhythm games such as Crypt of the Necrodancer, Cadence of Hyrule, Hi-Fi Rush, or something like Guitar Hero where the player is actually making music. Games like Banjo-Kazooie are known for having an adaptive soundtrack wherein the music changes to match the environment, whether that's traveling to different zones throughout the hub world, or even something as simple as muffling the tone when going underwater.
You also have jingles and fanfare, such as when you open a chest or collect the MacGuffin. You can look up channels like 8-Bit Music Theory or Tarot57 to learn more about creating adaptive soundtracks for game design. My buddy Dryden Thomas is also a master composer and talks about creating soundtracks in his devlogs, so definitely check him out.
Sound effects are also something that a lot of devs don't think about in the beginning, but try making a game without them and it just feels hollow and dead by comparison. Sound effects also have the potential to become viral. For instance, I'm sure you can tell me exactly what games these are from.
What sounds you'll need will depend on the specific game you're making, but here are just a few of the ones required for Alchemask. Feel free to pause and look over them and see if there's any you hadn't considered for your own game. While voice acting isn't necessary for Alchemask, plenty of games rely on it, whether it's Mario's Yahoo! Lynx or full-on dialogue.
Hades, for instance, has an incredibly deep and complex dialogue system with full voice acting, and larger games such as JRPGs have entire cinematic cutscenes, all of which require extensive planning, so if your game needs voice acting, you should include that in your GDD as well. I know that for Runefencer Illya, Daniel Swearengen had to commission female vocalists to do some of the more operatic voices in the soundtrack. The and some minor voice acting parts for the dialogue like shouting or as well as some gibberish.
Fun fact, did you know that Minna from Twilight actually speaks English? They just jumbled up the audio in post to make it sound like alien nonsense words. It's true, look it up.
The last section I want to go over is game experience, also known as UI and UX. We touched on that a bit earlier already. UI stands for user interface and refers to the meta information and feedback the game provides to players, often in a HUD or heads-up display.
Typically, this appears in the corners, such as health and mana, on the borders, such as a hotbar, or even in the center in the case of an aiming reticle. UI elements can also appear in the game world itself, such as hit counters above an entity. While it's technically possible to create a game without UI, or even with...
diegetic UI, such as the health system in Dead Space, or the puzzle consoles in The Witness, most games will have non-diegetic UI in some form or another, even if it's just menus or a start screen. Diegetic for anyone who doesn't know, simply meaning it exists seamlessly as part of the in-game world, rather than as an abstract overlay. It's something the characters themselves can interface with and interact with, not just the player.
So, incorporating those considerations into your GDD should be considered essential. What will the UI look like? What elements do you need? Will the player have access to it at all times, or only some of the time?
Where's the best place to put it to avoid information overload, or obscuring the actual gameplay? Even something as simple as whether to disable elements during cutscenes. So, for Alchemask...
The HUD will appear in the four corners of the map, leaving plenty of visual space for gameplay elements. The top left will display player health, element, and active item. UI elements will be designed based on alchemy and pagan symbolism, with health being pentacles instead of traditional health bars or heart containers. Pentacles will be divided into shards and half shards, with different colors indicating different types of health.
Shards will block out or fill in as the player takes damage or gains health. Different characters will have different numbers of pentacles to indicate total health, and more can be acquired during runs. The active item, if there is one, will appear in the center of a lotus flower.
The surrounding points will light up with colors to indicate the current active element. Here's some images of what that might look like. Top right will be the mini-map. Rooms start off hidden until explored unless you have the map and compass, or other related item.
or unless you're playing as the cartographer, as we mentioned. Each of the four paths will tend to branch off into a particular direction from the central room. Bottom left and bottom right will be for displaying additional items and trinkets, such as masks or cards.
Masks can only carry one or two at a time and will swap positions of primary and secondary, as well as reflect in a visual change on the character. Cards will appear like holding a set in your hand, with the active card sitting slightly out from the rest, similar to a deck builder. So again, drawing very heavily from the binding of Isaac HUD design, although we've been toying with the idea of maybe having the map be toggleable like in later versions, thus freeing up more space in the corner.
Something to work out during prototyping, since we can't actually know until we build it, whether that's in-engine or more likely a mock-up in Illustrator. Getting kinesthetic feedback will be important as well, but at least we have a general idea of the vision we're aiming for and parameters to work around. Good UI is something that will likely involve a lot of testing and tweaking during production, but is not something to be discounted.
Good UI can make or break a game. If you have an information heavy game like Civ or a colony management game, UI design is even more important, as it's the primary way you communicate information to the player. You want things to be clear and accessible without overloading them. UX stands for User Experience and includes game juice and feel, but also something as simple as controls. Does your game use mouse and keyboard?
Does it use a gamepad? Does it use some other device like touch or VR and motion controls? What specific buttons map to which particular actions?
This might sound trivial, but actually the limits of what buttons you have available can drastically change the way you go about designing your game. since having fewer buttons means more constraints. For instance, in the Red Alert games, building structures and units relies on radial menus, versus its predecessor that had a fold-out scrolling sidebar.
This decision was made in part as a result of moving from PC to gamepad controls, and how to fit so many options quickly and easily without the use of 24 hotkeys. SPACE! Games like Twilight Princess and Skyward Sword have Link using motion controls, for better or worse, as opposed to a traditional joystick or d-pad, and that changes what Link can do, but also what the player can do.
For Alchemask, our game is a twin-stick shooter, so even though we'll have mouse and keyboard support, we still had to map out controls to work with the more limited DualShock controller. Again, those might need refinement during the production phase as we A-B test how they feel, but... But planning for that up front will save a lot of headache later.
The decision of offering the player control rebinding is also something to consider, especially in designing for disability. And as Unity devs, we're fortunate at least that our engine has a pretty good input system natively that works with a wide variety of devices. Part of UI UX necessarily involves menus. Everything from the Start screen to the Pause screen to the Options menu. Here's some working concept art of our Start screen.
Drackey's not a fan of papyrus like I am, unfortunately, so he's making me change it for the final build. And definitely no papyrus. Papyrus? Are you kidding me? There's no place for that in a professional office setting.
Your menus don't have to be static, so like the little alchemist head at the bottom will blink periodically. If for no other reason, then you'll be able to tell if the game crashed or not. As the player progresses throughout the game, unlocking new items, different orbitals will appear around the central mask as a way to indicate progress to the player.
Menus serve dual purpose in conveying information, but also being a visual hook for the player. Aaron Hansen of Game Grumps actually has a really great video essay talking about the level design of Mega Man X, and that includes how even the Start menu helps teach you about core gameplay elements later on. That series is something every game dev should study, in my opinion. If your game has hotbars, stat screens, or inventory management, that would all fall under this category as well.
For instance, Alchemask revolves around alchemy and collecting items, so we figured why not make the UI look like the periodic table of elements? That might have issues later on with scaling if we suddenly decide to add a ton more items, so we'll have to take that into account and how to future-proof the design. Something as simple as a scroll rect or multiple pages could work. Again, that's why mockups exist.
For our purposes, we also have character selection and stats. Initially, we thought about using a portrait method, similar to what you might see in a lot of fighting games, showcasing a collection of all the archetypes at once alongside an animated sprite with stats and flavor text around them, and silhouettes for characters yet to be unlocked, and also a random roll. More recently we've been considering using a more diegetic system, which we'll get to in a minute. Here's a quick list of some other menus we'll need. Again, if you're building a game that's information heavy, such as Dark Souls or Civilization, then fleshing out menus and UI will become even more important, and your lists will probably go far, far deeper than this.
But in our case, it's a relatively simple game, so relatively simple menus. I also happen to be a big proponent of the philosophy of teaching through level design, which brings me to the next point. Diegetic menus. So, just to recap, diegetic means it exists in the world itself, supposed to an abstract meta overlay.
One thing you might want to consider during the design phase is incorporating some of that information directly into the game. For instance, games like Crypt of the Necrodancer and Hades have hub rooms that let you practice movement and interact with entities that take you to different worlds or load out your character. For Alchemask, we were considering replacing the Carousel model of character selection with a similar hub room, that has branching paths, allowing you to experiment in a safe environment and practice using the controls.
This would then have offshoots to a practice arena, like what Smash Bros. or Street Fighter has. You'd have a wardrobe room to try on different outfits as you unlock them, similar to Mario Odyssey. A challenge room to select different game modes, such as Time Attack, Bosh Rust, Dark Mode, etc. Instead of selecting your mask from a menu, the player would control a character in a room similar to what the actual levels would look like, move towards a particular spot on the wall, or a pedestal on the floor, and interact with a mask that changes their loadout. This then becomes scalable, since we can increase the size of the room to whatever we want, and the player can then walk into a door or portal once they're ready to begin the run.
Design considerations like that can dramatically impact the look and feel of your game, and it's a lot easier to work those out on paper than in the engine itself. Something else we've been toying with, that may become more popular as Let's Plays and eSports continue to rise, is whether to include streamer modes from the get-go. Rather than waiting for modders to do it, your game could include things like randomizers, one-life runs, chaos mode, speedrun auxiliaries like timers, The option to skip cutscenes, Twitch and YouTube integration, localization, and so forth.
Obviously, those are all optional luxuries that first depend on you building a solid game as a foundation, but it's worth thinking about them in the design phase and planning out in advance what sort of systems you'll need to craft, since some of them could be quite difficult to add if your systems are particularly complex, which is really more of a conversation about architecture, but regardless. If you know you'll need them down the line, it can often be easier to build these functions right from the start, rather than refactoring your entire game to patch them in later. I'm not sure about other engines, but Unity also has started to build tools that allow for mod support in games, if you want to give those options to the player.
If you're designing a multiplayer game, or even a single-player game that could be turned into a multiplayer game, then things like races, bingo, or hide-and-seek are among other popular categories. that streamers have invented over the years and overlaid on top of existing titles such as Mario Odyssey or Pokemon. Alright, well, that was a lot of information to take in, especially if you've never written a GDD before.
So, let's recap. A Game Design Document, or GDD, is an outline or blueprint for a game. It's the skeletal structure of all your game's design decisions and choices. It clarifies your vision, and sets down clear guidelines for how to proceed in the production phase. It's useful for just about any game, large or small, solo or collaborative.
It helps manage risk and scope, keeping everyone on the same page with respect to the end goal. GDDs allow you to work out ideas and concepts with little waste by A-B testing and doing mock-ups outside of an engine, saving time, money, and resources. Using project management tools can help speed up the creation of a GDD and allow you to share it with your entire team.
relying on version control to track changes or branching paths. Game design documents can be made in parallel with narrative outlines, concept art, model sheets, and design bibles. It's important to finalize as many decisions as possible in the planning stage before moving on to production, being willing to trust your designs enough to stick to them, while also maintaining flexibility to adapt to genuine constraints and new inspirations as they arise.
To freeze your designs in place, and not get sucked into scope creep, micromanaging, or producer mindset. Your GDD should include the title of your game, a hook or tagline, and some splash art in the header to give a high-level overview before moving on to specifics. Going from broadest possible scope to more narrow, you then need a summary that serves as the store page description or back of the book synopsis. List out your inspirations, both in terms of related games and other non-game influences such as art, movies, or real-life experiences, and what aspects those sources provide that you hope to leverage.
Outline the player experience, and what sort of emotions you wish to evoke when people play your game. What platforms will your game be on? What software will you use to develop it?
And not just the game engine, but other tools as well. What genre is your game, and who is your target audience? Of course, many games can share all of those elements, so here's where you start to get into more specifics as you make your way down the funnel. Describe your core gameplay loop and themes, those behaviors and motifs that will recur again and again and again. Break down mechanics into primary, secondary, and possibly tertiary if applicable, including any systems that are unique to your game, such as combat, puzzles, or crafting.
If you have unlocks or leveling systems, Detail how the player will progress and grow more capable over time. If you have narrative elements in your game, dedicate a portion of your design doc to the major story beats and plot points, as well as characterization. In terms of art, decide whether your game is going to be 2D or 3D.
What stylistic and design choices will you need to consider? Things like shape, color, mood, texture, and so forth. Are there any visual motifs or themes that carry throughout the game? What about music and sound effects and voice acting? Start to build out a visual and audio bible that you and your team can refer back to for direction and guidance when producing art assets, and then stick to those.
For player experience, what choices do you need to make surrounding UI and gameplay controls? How will the look and feel of your menu elements affect gameplay? Do you have accessibility issues to consider?
Can any of those elements be incorporated into the level design itself, making them more diegetic? And what features, if any, do you want or need to include that cater to cultural and technological trends such as multiplayer, mobile, VR, or streaming? So that's a full game design document from start to finish. Hopefully you now have enough knowledge and information to understand what a GDD is, when to use it, and why.
as well as a better sense of what goes into making a professional one. We hope that sharing the specific details of our own indie game served as a helpful example for what your own GDD could look like. Let us know in the comments if there is anything you found particularly eye-opening, or that you think we might have missed, as well as any questions you might have about the process.
If you learned something from this video, please give it a like, sub, share, and also consider supporting us on Patreon or Ko-Fi. as that will allow us to continue making presentations like this one. Also, if you thought our game Alchemask sounded fun, we'll leave a link in the description to the Steam page once that becomes available, so you can wishlist it and play it for yourself. We'll be sharing devlogs and progress on the channel in the coming weeks.
You'll also find additional resources and templates in the description, or in a pinned comment as well. Now, the savvy among you might have noticed in our outline that there are a few other sections that we haven't covered yet. Those include market requirements and technical requirements.
Market requirements help you understand what people actually want, so you can triage things that are critical versus merely nice to have, whereas technical requirements include things like systems, work packages, activities, and tasks. Together, these documents ensure that your game is not only desirable and viable, but also technically feasible. creating a robust framework for your success.
They form the what, who, and how of your project. Each of those is comprehensive enough to have their own dedicated video, but both are still crucially important for the overall design pipeline. If you want to learn more about that, and how to transition from the planning phase to the production phase, we'll post a link once those videos become available. Or to see other analysis and tutorial playlists, check out the links appearing on your screen now.
Until next time, I'm Mauricio Dark of Circuit Studios. Take care.