\r \r

Game Design One-Page Design Doc\r

\r Create a one-page game design document that is readable, decision-useful, and visually polished — exportable as a PDF that looks like a real product.\r \r Use this skill when the user wants a compact game design summary rather than a bloated GDD. The output is designed to be passed around in meetings, dropped in Slack, or emailed to publishers without embarrassment.\r \r Read references/family-conventions.md when you want the shared style and prioritization rules for this game-design skill family.\r Read references/source-notes.md when you want the distilled takeaways from the reference template and the GDC talk overview.\r \r

Core principle\r

\r A one-page design doc is not a small bad GDD. It is a compressed communication tool.\r \r It should:\r

• state what the game is\r
• state why it is interesting\r
• state what feeling or fantasy it is chasing\r
• state the core features and interaction model\r
• state enough production framing to make it actionable\r \r It should not:\r
• try to explain every subsystem\r
• drown the reader in lore\r
• use vague slogans instead of specifics\r
• hide the real game behind marketing fluff\r \r

What to produce\r

\r Produce:\r

1. One-page PDF — the shareable, visually designed version\r
2. One-page markdown doc — the editable text version\r
3. Structured source JSON — the intermediate data used for rendering\r \r

Visual design\r

\r The PDF renderer (scripts/render_one_page_gdd.py) produces a professional dark-theme layout:\r \r

• Dark background — near-black navy #0F111A, with a lighter panel for the header\r
• Teal accent colour — #00C8A0 for rules, section headings, pillar tag nubs, and bullet markers\r
• Pillar tags — design pillars rendered as pill-shaped labels with a teal left accent in the header\r
• Two-column body — left column for mechanics-heavy content, right column for production/aesthetic content\r
• Section rules — a teal horizontal rule above each section label\r
• Poppins typeface — used when available (falls back to Liberation Sans or DejaVu)\r
• Branded footer — document label on the left, game title on the right\r \r The renderer uses ReportLab (vector PDF — real text, not a raster image), making the output searchable, copy-pasteable, and print-sharp.\r \r

Font requirements\r

\r The renderer searches for fonts in standard system locations automatically:\r

• Linux: /usr/share/fonts/truetype/google-fonts/, /usr/share/fonts/truetype/liberation/\r
• macOS: ~/Library/Fonts/, /Library/Fonts/\r
• Windows: C:/Windows/Fonts/\r \r Preferred: Poppins (Bold, Medium, Regular, Light) from fonts.google.com \r Fallback: Liberation Sans (included in most Linux systems)\r \r

Dependencies\r

\r

pip install reportlab\r
```\r
\r
## Default section structure\r
\r
Left column:\r
- Genre / Story / Mechanics Summary\r
- Key Features\r
- Interface & Controls\r
\r
Right column:\r
- Art Style\r
- Music & Sound\r
- Roadmap / Launch Criteria (includes platform, audience, milestones, launch date)\r
\r
Header band:\r
- Game title\r
- Identity / Mantra (subtitle)\r
- Design Pillars (as pill tags)\r
\r
## Process\r
\r
### 1. Clarify the design input\r
Collect or infer the minimum needed:\r
- game title or working title\r
- game identity / mantra\r
- 2 to 3 design pillars\r
- concise gameplay/story/mechanics summary\r
- 3 to 6 key features\r
- input / interface model\r
- art references or aesthetic direction\r
- sound direction or emotional audio goals\r
- platform\r
- target audience\r
- milestone plan or launch criteria\r
\r
If the user gives messy notes, compress them rather than asking endless questions.\r
\r
### 2. Write for one-page density\r
Keep each section tight.\r
\r
Guidelines:\r
- prefer short bullets over dense paragraphs\r
- keep pillars punchy (2–4 words each)\r
- keep the summary to a compact paragraph\r
- keep features to the strongest few, not every idea\r
- make roadmap milestones concrete enough to be useful\r
- write like the doc will be skimmed in under two minutes\r
\r
### 3. Preserve design clarity over style fluff\r
If the concept is fuzzy:\r
- choose clarity over hype\r
- expose contradictions instead of smoothing them over\r
- keep claims grounded in actual mechanics or fantasy\r
\r
### 4. Build the structured source JSON\r
Write a JSON file matching the renderer schema.\r
\r
Expected fields:\r
- `title`\r
- `identity_mantra`\r
- `design_pillars` (array, 2–4 items)\r
- `summary`\r
- `features` (array, 3–6 items)\r
- `interface`\r
- `art_style`\r
- `music_sound`\r
- `platform`\r
- `audience`\r
- `milestones` (array)\r
- `launch_day`\r
\r
See `references/example-input.json` for a worked example.\r
\r
### 5. Render markdown and PDF\r
\r
```bash\r
# Install dependency first if needed:\r
pip install reportlab\r
\r
# Render:\r
python scripts/render_one_page_gdd.py --input \x3Cslug>.json --md \x3Cslug>.md --pdf \x3Cslug>.pdf\r
```\r
\r
The renderer auto-discovers fonts. If content is too long, shorten the copy before rerendering — do not try to fit more by cramming.\r
\r
### 6. Check fit and trim aggressively\r
Before finalizing, verify:\r
- the concept is legible at a glance\r
- the features list is not overstuffed\r
- the PDF still feels like a one-pager (not wall-to-wall text)\r
- the roadmap is realistic enough to be useful\r
- the strongest idea is visible immediately\r
\r
If the PDF looks crowded, shorten the writing. If there is too much whitespace, the document is probably well-scoped — do not pad it.\r
\r
## Output expectations\r
\r
By default, create files in the current working directory or a user-specified target folder:\r
- `\x3Cslug>.json`\r
- `\x3Cslug>.md`\r
- `\x3Cslug>.pdf`\r
\r
Use a slug based on the game title when naming files.\r
\r
## Response structure\r
\r
When using this skill, report:\r
- where the JSON, markdown, and PDF files were written\r
- any sections that had to be compressed heavily\r
- any major ambiguities or contradictions you preserved or surfaced\r
\r
## References\r
\r
Read these when useful:\r
- `references/source-notes.md` for the distilled source principles and section model\r
- `references/example-input.json` for renderer input shape and field conventions\r
\r
## Working principle\r
\r
If a team cannot explain the game on one page, the design is probably not clear enough yet.\r
\r
Use this skill to produce a one-pager people can actually read, discuss, and pass around.\r