#game design document

[codingcorgi]

Going to teach my Game Development Class! I'm nervous, because today's the first day I'll be presenting as a Creative Director!

On another note... anyone interested in a small video and template for game design?

[askagamedev]

Usually I am working solo but I am going to work in a studio as game designer and I would like to make good design documents for the team. So what does a design document for a feature/puzzle/challenge etc look like? What information should I include? And thank you for sharing your answers to all these questions we ask!

Remember, the goal when writing a design document is to help provide a road map for the feature or system you're working on. You need to explain to the readers what you are building, why you are building it, and what you need in order to build it. When I write a design document, I usually try to address the following:

High level goal - What is this feature/system/puzzle/etc. supposed to do? What kind of experience do I want the player to have?

Reaching the goal - How to break the high level goal down into a set of rules and expected behaviors to achieve that goal

Needs to reach the goal - What is needed from the stakeholders to reach the goal? Engineering for A, VFX for B, animations for C, environments for D, and so on.

Minimum Viable Product - What is the least amount of work needed to prove out the design? What is most important to this design and must be done first? What are the stretch goals and nice-to-haves?

Let's dig into this with an example. Imagine that I'm working on a looter shooter and I'm designing a new feature to extend the lifespan of player gear and allow more player customization of specific weapons they favor. Let's call this hypothetical system the Weapon Inheritance feature.

High Level Goal

As a player, I want to be able to keep using my favorite weapon and dislike it when I have to drop it if I find another weapon that has better stats. I would like to be able to use new weapons I find to upgrade my preferred weapon to keep it relevant.

Reaching the goal

Weapon Inheritance is a means by which players can transfer bonuses from one weapon to another. Weapon inheritance will require the player to bring two weapons to a weapon modification station - one they wish to consume, and the other they wish to upgrade. The player will be able to choose which bonus or ability/proc from the donor weapon to be transferred to the receiving weapon and be prompted with a confirmation dialog to proceed. Once the player confirms, the donor weapon is destroyed and the receiving weapon receives the selected bonus or ability. The number of bonuses and procs on a weapon should be capped by rarity, with six being the maximum. A receiving weapon with maximum bonuses for the rarity should require the player to choose one old bonus to overwrite. Some abilities should be unique to certain weapons, we should be able to mark them as "uninheritable".

Needs to reach the goal

UI Art - New UI screens weapon inheritance overview, donor weapon selection, receiving weapon selection, weapon diagrams and highlights

UI Engineering - new screen flow from weapon modification station: confirmation dialog, weapon inheritance overview, donor weapon selection, receiving weapon selection

UI Engineering - means of selecting a specific ability to transfer

Gameplay/Itemization Engineering - Ability to set/copy over a specific bonus or ability on a weapon, including any randomly-generated stats

Gameplay/Itemization Engineering - Ability to mark a specific bonus or ability on a weapon as uninheritable

Gameplay/UI Engineering - hook UI confirmation to call the code to execute the transfer

Server/Persistence Engineering - weapon changes must be saved to the database upon successful transfer

Minimum Viable Product

Must Haves:

Weapon Inheritance accessible via Weapon Mod Stations

UI flow functions to select required

Max # of bonuses is rarity-enforced

Bonuses are transferred/overwritten

Donor weapon is destroyed

Transfers are saved to DB

Stretch goals:

Uninheritable bonuses marked in data

Rarity upgrade/transfer

Scaling costs based on number of prior upgrades/rarity

These are the fundamentals to explain to your teammates what you're trying to build, how you're trying to build it, and what you need in order to build it, and the minimum success criteria for it to be evaluated. It gives them the needed direction to get started with the work they need to do. You can apply these principles to many kinds of design ideas, and your ability to identify what resources and work are needed for those tasks will improve over time as you level up in your chosen field. You can also practice writing design documents like this for features in other games. Pick a feature and try to break it down into these four categories. The more practice you get in, the easier the doc-writing will become.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[jonnestt]

What I hand in for grading.

[koopytron]

My entire sense of humor can be summed up by the video game pitches I wrote down when creating my first GDD.

- survival horror game with bullets but no gun

- collectible game where some collectibles are out-of-bounds but in full view of the player

- hallway game where there's 200 doors but 199 are locked

- open world game where boss music plays when you approach certain species of flowers

- dating sim but as a middle aged office worker on tinder

- rpg in which the character's internal monologue contains nothing relevent

- escape room but you are a fly who cannot comprehend windows

- VR game as an underwater basket weaver

- home alone but you play as a normal, bastard cat

- sequel where your owners have a baby and you must reclaim your throne of king attention whore

- turn based rpg but everyone in the party is above the age of 60 and they are hard of hearing

- flight sim starring that flying lawnmower

- rpg where everyone speaks pig latin

[jaydenhansendesign]

What I’ve learnt so far

My experience with the Introduction to game design unit at AIE has been a great insight into the tasks that a game designer will complete in their careers. I’ve learnt how much thought it requires to make a working Game Design Document, but also how fun it can be to just throw my ideas into a document and mess around with what works and what doesn't.

In the unit I have been playing around with Unity and Photoshop learning some important skills in designing games. I have learnt how to grey box and create basic levels in Unity, I’ve played with particles and other little interesting features built into the Unity engine.

It was great to find out more about the history of games and that E.T. wasn't that bad of a game after all.

We have covered board games which was a fun little segment, giving me a good understanding of game mechanics.

Important games like Wolfenstein 3D and Doom were great ways to learn where the 3D games market evolved.

There is heaps of other things i have learnt throughout this unit that i haven't mentioned but to sum it up it has been awesome and i cannot wait until the next unit! I am going to continue to push myself and be the best i can be.

If i were to give anyone any advice about my experiences so far, stay positive, work hard and you'll get things done.

[pixelprospector]

GTA Game Design Document + Early Mockup (by Mike Dailly @mdf200)

[awitchatdinner]

GDD Diary Entry 1: Title Page

Hi, My name is Chu BEE and I am an aspiring game maker. I am currently writing my game design document (GDD) and I have chosen to share it here to keep myself accountable. First things first Game Title: PularIntended game systems: I intend to use Unity to make the game accessible for Windows, Android, iOS and Kindle.Target age of players: 8-18 years old.Intended ESRB rating: E10 (Everyone 10+)…

GDD Diary Entry 1: Title Page

[soloindiegamedev]

How To Write A Game Design Document (GDD) As A Solo Developer

You have a great idea for a game! In fact, you’re so enthusiastic about showing it to the world you’re already working on it. But without a proper Game Design Document (GDD) it’s highly likely that idea will never materialize into a fully released game. Why? A GDD keeps you focused, makes sure that you stay within the scope of your vision, and is a major reference point as your game development…

How To Write A Game Design Document (GDD) As A Solo Developer