Making an effective GDD
Pitch deck vs GDD
Pitch deck
- Short presentation to answer high level questions
- Entice collaborators
- Acquire funding
- Give overall vibe of the game and what will take to make it
GDD
- Detailed description of the game, allowing developers to know exactly which tasks are needed and how long it will take to implement everything
- Main goal is to make sure everyone has the same mental image of the game you’re making
- Many diagrams and references
A successful GDD is one that people will read
- Elevator pitch – two sentence explanation
- Gameplay.
- Does the programmer know what they need to build?
- What are the smaller components of each system?
- Do you have references from other games?
- Do you know any useful plugins? And how will they need to be adjusted?
- Break it down into a gameplay loop diagram
- What is the moment-to-moment gameplay and what happens?
- How does the player interact with the game?
- What happens if the player does well or poorly?
- In what way does their experience change when they do the same interaction?
Challenge activity
We were given a sheet of paper containing a well-known simple game to make gameplay diagram of. Our table got the no Wi-Fi Dino game. We all worked individually despite it being a group activity.
I wrote a simple one.
When Sophie saw my sheet, she gave me some criticism like “is the dino really moving? There aren’t just obstacles to jump over” and also something regarding the increase of points from avoiding obstacles.
This made me realise that even for such a simple game, there’s many small details I missed.
Visuals
- Concept
- 2D/3D? stylised/realistic? Perspective?
- Characters
- Fit within narrative, mechanics, etc?
- Environment
- Does it fit into the level design, mechanics, etc?
Level design
- Diagrams, maps, whiteboxing
Look into tutorials, narrative design, and what every part of the game communicates, and the audio. Main time winks? What is the minimum viable product? What can be removed or scoped down?