qvib.pro
RU

Game Design Document (GDD) from one idea

What for: turn a raw game idea into one structured doc — core loop, mechanics, progression, content and the scope of the first version.

бесплатно любой

Техника: структура GDD (Indie Game Academy, GDD template & how-to) checked 2026-06-01

Updated: 02.07.2026

$ You are a lead game designer. Build a Game Design Document from my idea. IDEA…
Game Design Document (GDD) from one idea

When to use it

You have a one-sentence game idea and you need a working skeleton in a single pass — something you can prototype against, scope, and show to people. The AI's role is lead game designer. Output: a single GDD that honestly separates the "first playable version" from the dream.

The prompt (copy and paste)

You are a lead game designer. Build a Game Design Document from my idea.
IDEA: "<PASTE THE IDEA IN ONE SENTENCE>"
GENRE AND REFERENCES: <PASTE, e.g. "a roguelike in the spirit of Hades">
PLATFORM: <PC / mobile / web>   AUDIENCE: <WHO PLAYS THIS>
SCOPE AND TEAM: <e.g. solo developer, 3 months to a prototype>

Write the GDD section by section, EVERY one concrete, no filler:
1. Pitch (1 paragraph) + tagline + why this will be fun to play at minute 3 and at hour 3.
2. Core loop: what the player does over and over (a 10-60 sec cycle), and what the reward is made of.
3. Mechanics: a list prioritized as must / nice-to-have; for each one — player input, rule, feedback.
4. Progression and economy: how difficulty and player power grow, which resources and what they buy.
5. Content: how many levels/enemies/items are needed for the game to feel "complete", and the minimum for a prototype.
6. USP: the one memorable thing the reference games don't have.
7. Art and sound: direction in one paragraph (no detailed asset lists).
8. Tech doc in brief: candidate engine, key systems, the main technical risk.
9. Scope: explicitly separate "Vertical Slice (first playable version)" from "full game".
10. Risks and open questions: what the prototype needs to test first.
End with a table: Mechanic → why the player cares → implementation difficulty (low/medium/high).
Where data is missing, make a reasonable assumption and mark it as [assumption] — don't invent facts.

The technique: a role plus a rigid structure forces the model to separate "version one" from "the dream" — the single biggest killer of indie projects.

Filled-in example

Idea: "co-op survival on a drifting raft, but the ocean is alive and hunting you". Genre/references: Raft + Subnautica. Platform: PC. Scope: two people, 4 months to a Vertical Slice.

Expected AI response: a pitch around "the raft as a besieged fortress"; a core loop of "gather resources from the water → reinforce the raft → survive the night attack → expand"; USP — "the ocean as an opponent with behavior, not a backdrop"; Vertical Slice = 1 biome, 3 resources, 1 attack type, a 10-minute cycle; main risk — "is defending actually fun" gets tested by the first prototype.

Variations

  • One-pager. Add "now compress all of this into a single page for a publisher pitch" — for the first touch with an investor or publisher.
  • Genre emphasis. For an RPG, ask it to expand the lore and characters; for a puzzle game, the levels and the difficulty curve of the mechanic.
  • Critique the idea. "First find 3 reasons this game could be boring, and propose mechanics that fix them."

Pro tips

  • A GDD is a living document. Don't polish it before the prototype: test the core loop by hand first, then keep writing.
  • Insist on the "implementation difficulty" table — it's your filter against mechanics that sound great and eat the entire schedule.
  • The most valuable section is "what the prototype tests first". If the AI waters it down, ask directly: "which ONE hypothesis kills the project if it doesn't hold?"

Читать по-русски →