Skip to content
SlashClone
DiscoverUse in ClaudeSubmit a link
Sign in
Made by@gameforge

Game design doc

@gameforge/game-design-doc

Write a one-page game design doc from a rough idea: the hook, core loop, controls, the one rule that makes it interesting, scope cut into must, nice, and later, and a first-playable plan. Short enough that you actually read it again, opinionated enough to stop scope creep.

SkillOtherv1.0.0 (latest)
Use in Claude Save Like Clone Comment
Activity
New: be the first to try it
  1. 1---
  2. 2name: game-design-doc
  3. 3description: Write or update a one-page game design doc (GDD) from a rough idea, a pitch, or an existing prototype. Covers the hook, core loop, controls, the twist, win and lose conditions, scope cut into must, nice, and later, and a plan for a first playable build. Use when the user says "write a design doc", "help me plan my game", "GDD", "I have a game idea", "scope my game jam entry", or before starting a new game project.
  4. 4license: MIT
  5. 5---
  6. 6
  7. 7# One-page game design doc
  8. 8
  9. 9Most game design docs are 30 pages nobody reads. This one fits on a page and answers the only questions that matter before building: what does the player do every few seconds, why is that fun, and what is the smallest build that proves it.
  10. 10
  11. 11## Inputs
  12. 12
  13. 13Ask in one message for whatever is missing. Offer a default for each so the user can say "go":
  14. 14
  15. 151. **The idea** in a sentence or two.
  16. 162. **Platform and input**: browser, phone, desktop, console; keyboard, touch, gamepad. Default: browser, keyboard plus touch.
  17. 173. **Time budget**: a 48-hour jam, a month of weekends, or longer. This drives the scope cut.
  18. 184. **Who it is for**: themselves, kids, friends, a jam theme, a store release.
  19. 195. **Reference games** they like (optional). Use them to name the feel, not to copy them.
  20. 20
  21. 21If `docs/game-design.md` exists, read it and update it in place instead of starting over. Keep the user's wording where it still holds.
  22. 22
  23. 23## Steps
  24. 24
  25. 251. **Find the hook.** One sentence: "You are X, doing Y, but Z." Z is the twist. If there is no Z, propose two or three and let the user pick.
  26. 262. **Write the core loop** as 3 to 5 verbs in order, measured in seconds (for example: aim, launch, bounce, collect, repeat). If one loop takes longer than about 30 seconds, say so.
  27. 273. **Name the one rule** that creates interesting choices (risk versus reward, limited resource, timing). Every feature later must support it.
  28. 284. **Define win, lose, and progress**: how a run ends, what carries over, what the score means.
  29. 295. **Cut scope** for the stated time budget into three lists. Must is what the first playable needs. Be ruthless: for a 48-hour jam, Must has at most 5 items.
  30. 306. **Plan the first playable**: the build that answers "is the core loop fun?" with placeholder art, in at most a quarter of the time budget. List the 3 questions a playtest of it should answer.
  31. 317. **List risks**: the two things most likely to sink the project (usually scope and feel), each with a cheap test.
  32. 328. **Write `docs/game-design.md`** in the format below. Keep it under about 80 lines.
  33. 33
  34. 34## Output
  35. 35
  36. 36```markdown
  37. 37# <Title>: one-page design
  38. 38
  39. 39**Hook:** You are a tiny lighthouse keeper keeping ships off the rocks, but your light also wakes the sea monster.
  40. 40**Platform:** browser, keyboard and touch | **Budget:** 48-hour jam | **For:** jam theme "light and dark"
  41. 41
  42. 42## Core loop (about 10 seconds)
  43. 43Sweep the beam, spot a ship, guide it past the rocks, dim the light before the monster wakes, repeat.
  44. 44
  45. 45## The rule that matters
  46. 46Light saves ships and wakes the monster. Every second of light is a choice.
  47. 47
  48. 48## Win, lose, progress
  49. 49- Lose: three ships wrecked, or the monster reaches the lighthouse.
  50. 50- Score: ships saved. Nights get longer and busier.
  51. 51
  52. 52## Controls
  53. 53| Action | Keyboard | Touch |
  54. 54| ------ | -------- | ----- |
  55. 55
  56. 56## Scope
  57. 57- **Must:** ...
  58. 58- **Nice:** ...
  59. 59- **Later (not this version):** ...
  60. 60
  61. 61## First playable (by hour 12)
  62. 62Questions it answers: 1. ... 2. ... 3. ...
  63. 63
  64. 64## Risks
  65. 65| Risk | Cheap test |
  66. 66| ---- | ---------- |
  67. 67```
  68. 68
  69. 69## Guardrails
  70. 70
  71. 71- One page. If a section grows past a few lines, move detail to a separate doc and link it.
  72. 72- Never pad Must to look complete. A short Must list is the point.
  73. 73- Name feelings with verbs and numbers ("jump reaches 3 tiles, lands in under half a second"), not adjectives alone ("tight", "juicy").
  74. 74- Reference games describe a feel. Do not copy their names, characters, art, or text into the design.
  75. 75- Write only `docs/game-design.md`. Ask before replacing a doc the user wrote by hand.
Sign in to comment on a line