Most solo devs skip the game design document because it feels like homework. Then scope creep eats a month.
I'm building Phantom Signal, a tactical FPS in Unity 6 where you switch your weapon's frequency (Red, Blue or Green) to break enemy defenses and open the facility around you. Before building anything like it, I write a short GDD. Here is the method, using Phantom Signal as the example.
Step 1: Write a one-page pitch
If you can't explain the game on one page, the idea isn't ready. A simple table is enough:
| Field | Phantom Signal |
|---|---|
| Genre | Tactical first-person shooter with puzzle elements |
| Engine | Unity 6, URP |
| Platform | WebGL on CrazyGames first, Steam later |
| Scope | Vertical slice: Training Facility (5 connected missions) |
| Hook | Frequency switching changes how the whole level behaves, not just the weapon |
| Audience | Fans of tactical shooters who like short, replayable missions |
The hook line matters most. If you can't write one, you don't know why the game is different yet.
Step 2: Describe the core loop in five lines
- Enter a room and scan for what reacts to which frequency
- Switch frequency
- Shoot, hack or open the matching target
- Clear the room and pass the blast door
- Finish the mission, earn a rating, unlock the next one
Then add one sentence on why that loop is fun. For me it's fast decisions and clear feedback.
Step 3: List your risks before they find you
| Risk | Likelihood | Fix |
|---|---|---|
| WebGL performance drops | Medium | Keep poly counts low, bake lighting |
| Weapon feel isn't satisfying | Medium | Playtest early, tune recoil, bob and SFX |
| Scope creep | High | Lock the feature list before Day 3 |
| Script execution-order bugs | Medium | Set script order and test input first |
Writing "scope creep: high" in a table makes it much harder to ignore later.
Step 4: Put the whole slice on a 7-day schedule
This is the example schedule from my GDD template, filled in for Phantom Signal:
| Day | Focus | Done when |
|---|---|---|
| 1 | Project setup, player movement, camera | Player moves and looks smoothly |
| 2 | Weapon framework, shooting, reload | Weapon shoots and reloads with feedback |
| 3 | Frequency system and reactive objects | Switching changes a test object |
| 4 | Mission 1-3 blockout and blast doors | Three rooms playable in order |
| 5 | Missions 4-5, enemies and targets | Full run playable end to end |
| 6 | HUD, menu, certification hall, save | All screens work, progress saves |
| 7 | Polish, SFX, VFX, WebGL build test | Build runs in the browser without errors |
The "Done when" column is the useful part. Every day ends with something you can actually play.
Two rules that keep it honest
- End every day with something playable. A plan that only works on paper doesn't count.
- Freeze the feature list early. Lock it before Day 3 and add nothing new after Day 5. After that, only fix and polish.
Want the templates?
I turned this into a bundle: a Lite GDD template (11 sections) and a Full one (pitch, design and production plan), each with a filled-in Phantom Signal example. It works for any engine and any genre.
Get the GDD Bundle on Gumroad (I made it, so this is my own product).
What do you put in your GDD, and what do you skip? Tell me in the comments.
Top comments (0)