Game design document for beginners (how to write)
A basic template to write game design documents for beginners.
Game design document basic template
Name and genre. Can be approximate or experimental but your publisher may appreciate something simple and trendy.
Concise high-concept description.
Core game mechanics. Player action, reaction, system purpose.
Gameplay flow. Moment to moment, major gameplay loop, essential "obstacle" mechanics and how players can solve them. Should be assisted by storyboarding.
Systems, mechanics, categories, parts, and parameters. Every system and mechanic will get their own detailed section in specific design documents. Keep the GDD clean with essential system design.
Macro design to mechanics to parameters.
Story summary, major plot points.
Major sources of inspiration, similar in mood and design. Encourage your team to do their own research for inspiring media.
Design philosophy. What the game should achieve, genre demographics, novel features that warrant additional explanation.
Basic market research (optional), potential franchise, genre outreach.
Add visual elements when absolutely needed, do not crowd the core document.
The core design doc will adapt over time. Agile development applies to both your vision and the GDD.
Describe your amazing vision
The GDD is the overview of high-concept specifics: how the game plays, how it feels, sources of inspiration, what makes it compelling - your particular and wonderful vision and why it is awesome to play.
This applies to sharing it - the GDD is one of the main ways to keep your team aware, inspired, focused on the game’s vision. Team input and iteration are mandatory, and the GDD will evolve during production.
Game systems have their own documents inside a wiki database, while the GDD lets everyone know where the game is heading and the specific mood of its world.
Be ambitious while knowing that your vision may not be translated 1-to-1 to the digital medium. While iterating, give yourself and your team space to adapt and improve on the initial design.
Core features and story / plot points
The GDD holds high-concept details:
Gameplay mechanics and abilities plus a clear explanation of each one.
Clear and pulpy detailing of your story and themes, and how they interconnect with gameplay.
What does your game focus on - genre, type of player, mood, level of accessibility, single or multi player.
Each system, complete narrative span and mission / quest will have their own documents inside the wiki.
Game systems are explained clearly - not with abstract notions (“The gameplay is awesome”) but a design-based and player-centric justification of how the mechanic contributes to the game’s vision.
Use sub-sections for each mechanic and category: gameplay, art, writing, world design etc.
Explain to your team each major concept, their necessity and contribution.
When updating, provide links in the GDD to every system design doc in the game’s wiki.
Moment to moment gameplay and flow
Design flowcharts, storyboards and infographics for moment to moment gameplay: how to navigate the world, how to interact, how the UI functions, items, in-game systems.
Give examples of gameplay flow for major mechanics and common actions. This section will be extensive and detailed in specific system docs, linked to the GDD. Even better, use an app able to auto-update links and references across the wiki.
Remember - if the gameplay loop appears to be unintelligible, it is better to readapt it from the beginning. We want mechanics to take as few clicks and taps as possible.
A game mechanic or UI option (menu or gameplay) that takes too many steps is likely poorly thought-out, and should be redesigned for the benefit of the player.
Project leads must be on the lookout for gameplay flow that is unnecessarily complicated or confusing.
Focus and brevity
The idea leading the project may be amazing, but your ability to communicate must follow along and support it.
Write a comprehensive table of contents, use an app that can create a table from your document headers.
Make every bit of information count. Stay on point with high-concept features.
Explain features and function clearly - what it does, how it works, its purpose and relevancy for player experience and immersion.
Keep it organized. Communicate simply and effectively, making sure everything is accessible. Though it is a technical document, the GDD should be precise, easy to browse by anyone. Keep language simple, maintain technical brevity when required.
Go in detail only as much as needed - when describing how major systems work, essential story points, specific gameplay features.
Use headers and short paragraphs. Let people find newly-added information quickly. Let your team know when a major version is updated. Whether in writing or design, remember the golden rule of brevity.
If someone on your team may not want to read the GDD, it is because:
Your GDD is inefficient, due to lack of organization, clarity and brevity. Rewrite the doc into smaller, more detailed sections, where necessary.
They do not agree with your vision for the game. Address the design with your team leads and re-adapt gameplay.
Use images when necessary
Your detailed wiki may use plenty of images.
For the core GDD they need to make a specific point.
Avoid cluttering the document with images.
Depending on your rebellious proclivities, you may wish to keep the mood board separate from the GDD.
Useful visuals in a core document:
Main in-game user interface
World map
One vertical-slice detailed image showing an in-game scene together with the UI
One vertical-slice detailed image showing all the core visual aspects of the world together for maximum impact
High-concept flowcharts and storyboards
A concept of the game’s visual cover
Your protagonist posing with a gun next to his face - the marketing boys love that stuff.
Let your visual designers channel their inner realist, impressionist, surrealist, romantic, and psychedelic painter.
Inspiration and similar media
Motivate your team - let them know what other media has features and mood you wish to replicate or improve upon.
Include video games and absolutely any medium - take inspiration from all the arts and anything outside digital media.
Consider any craft and form of creation - graphic, visual, user interface design; accessibility options, lateral thinking and design; casual games, educational apps, real-world activities.
One-page game design document / concept document, if needed
If the GDD becomes overwhelming, you can experiment with a one-page doc.
This may not provide space for detailing major mechanics, while core gameplay features, sources of inspiration and essential story will do.
The OPD is a high-concept, somewhat vague summary of your design components. Depending on project size, you may augment the prose with visual elements - diagrams, design canvases, storyboards.
The OPD must be as self-contained as possible. Reading it should provide a clear understanding of the game's vision, design philosophy and principles.
A one-page GDD is easy to maintain and update. If nothing else, it will make you not stray from ever-necessary brevity.
Basic market research
Include an additional section with basic market research:
Demographic and specific genre, what various people will love about the game
Comparison with similar titles and what your game does better
Potential for franchise and expansion packs development.
You may or may not need extensive marketing research, especially when working with the resources and requirements of a large studio and publisher, but your core document is not always the place for this.
Fixing communication issues
Like your game, the GDD becomes a living element, adapting to new ideas.
Before and during production, not everyone will agree with your design philosophy. People have different ideas about what constitutes good art, entertainment, gameplay, and may voice these opinions more or less gracefully.
Your job is to care about your craft and do what's good for the end product - your game - and for the end user - the player.
Regardless of your design philosophy and ambition, remember that it is ultimately the player who needs to experience your creation.
Keep your design player-centric by understanding how people experience the digital medium, and what elements your game does and does not need.
When disagreements arise, be open to feedback. Try to understand why a mechanic may not be useful to your game, and if it serves your vision.
Discuss the game with your team while keeping players in mind, both casual and more specific demographics.
Explain to your team, in clear terms, why a mechanic is or is not necessary, and how it sustains the game's wellbeing. Solve disagreements between your developers by keeping in mind the player, usability, and your core vision.
Tools
When working with an established team, you'll use the tools and database developed specifically for their projects.
One essential feature you'll want is the ability to easily create connections between documents and specific systems.
When working on your own, some apps are more useful and feature-rich than others:
Word (eh) or Google Docs (yawn). Familiar and reliable. They do the job when needed, while lacking too many features to be used alone.
Workflowy - or its imitators, is excellent for organizing ideas, though not completely free and uses a proprietary format in its own ecosystem.
Notion is a favorite among people who need to juggle a complex database, though dealing with similar limitations as Workflowy.
Obsidian (the wiki-like note-taking app) is free for personal use, and allows for the creation of a connected database through text files and not a proprietary format. You can work on your documents using markdown formatting even without Obsidian. The app includes canvases, useful when needing to separate documents and systems in categories.
Regardless of which tool you prefer, you'll want to use apps that allow mentions and connections between documents. This way, when something changes in one document it can be referenced across the database through tags and links.
Why write a magic scroll called Game design document
You see a wonderful game in your mind. The gameplay is fluid and precise, the seductive mood flows with nostalgic sunsets and foggy nights, the story is timeless, and the writing can stand among the best classic novels.
(The vision is likely brimming with photorealistic textures and an endless field of reflective surfaces. Thankfully, these are superfluous.)
Exploring that world is mesmerizing. Now you must brave the dragon of game development, level up your skills and patience, and reach the treasure called version one-point-o.
You hold the gift of vision, the arsenal of digital tools and production pipelines, and the magic scroll of... design documentation.
A game design document is useful at conveying the lead vision of your game at a glance. Said vision does not remain engraved in cold stone, but is refined into a beautiful sculpture - flexibility is essential to keep flow and deliver the work.
The GDD cannot include every single piece of information needed to complete production, but it functions as design base. You are communicating to your team, in clear and sweet terms, the major aspects to make your game something grander than the sum of its parts.
It may be debatable on how necessary a core document is, especially for large teams and massive projects. The GDD is not meant to detail the game to its component atoms, but to keep everyone focused on the finish line where the fruits of their labor will be made manifest. And playable.
Practice
Keep the prose clear and sweet.
Focus on core features, mechanics, story, mood and feeling.
Motivate your team.
Play the game in your mind before starting production.
Make sure your leads have a strong vision for the game.
Prototype early.
Learn from your game and from those of others.
You are both developer and player.
Keep your design player-centric.