Phaser 4 Game Design Document Generator

GDD Structure (13 Sections)

<!-- ASSUMPTION -->

Section 1 — Game Overview

• Title — Working title (can be placeholder).
• Tagline — One punchy sentence that sells the hook.
• Genre — Primary genre and any sub-genres (e.g., "roguelike platformer").
• Target Audience — Age range, player profile, casual vs. hardcore.
• Elevator Pitch — Exactly 2 sentences: what the player does and why it is fun.
• Unique Selling Points (USPs) — 3-5 bullet points that differentiate the game.
• Comparable Titles — 2-3 existing games the user or audience would recognize, with a brief note on what is borrowed and what is different.

Section 2 — Core Game Loop

• 30-Second Loop — The smallest atomic action cycle (e.g., jump-land-collect).
• 5-Minute Loop — A medium arc such as completing a level or a wave.
• Session Loop — What a full play session looks like (15-30 min for casual, 60+ for hardcore).

[Action] --> [Feedback] --> [Reward] --> [Decision] --+
   ^                                                  |
   +--------------------------------------------------+

• Win Condition — What the player must achieve to "beat" the game or level.
• Lose Condition — What causes failure and what happens next (restart level, lose life, game over).

Section 3 — Mechanics Deep Dive

• Primary Mechanics — The 1-3 core verbs (e.g., jump, shoot, match). For each: input, physics behavior, edge cases.
• Secondary Mechanics — Supporting systems (e.g., inventory, crafting, dialogue). Describe how they feed back into the core loop.
• Control Scheme — Map inputs per platform:

Section 4 — Progression System

• Difficulty Curve — Describe the intended ramp (linear, exponential, sawtooth). Reference specific milestones.
• Unlock Sequence — What new abilities, levels, or items the player earns and when.
• Scoring System — How score is calculated, combo multipliers, leaderboards if any.
• Replayability Hooks — What brings the player back (new game+, daily challenges, procedural generation).
• Estimated Play Time — Time to first completion and time to 100% completion.

Section 5 — Level / World Design

• Level Count — Total number of levels, worlds, or zones.
• Themes — Visual and mechanical theme per world (e.g., "World 2 — Ice Caves: slippery surfaces, breakable walls").
• Flow Maps — ASCII diagram showing level progression and branching:

[Level 1] --> [Level 2] --> [Level 3]
                  |
                  +--> [Bonus Level A]

• Difficulty Scaling — How enemy count, speed, puzzle complexity, or time pressure increases per level.

Section 6 — Characters & Entities

• Player Character — Base stats (speed, health, jump height), abilities, state machine (idle, run, jump, hurt, dead).
• Enemy Types — Table format:

• NPCs — Role, dialogue triggers, quest associations.
• Collectibles & Power-ups — Effect, duration, rarity, visual indicator.

Section 7 — UI/UX Wireframes

• HUD Layout — ASCII wireframe of the in-game overlay:

+---------------------------------------+
| [Lives: x3]          [Score: 00000]   |
|                                       |
|                                       |
|              GAME AREA                |
|                                       |
|                                       |
| [Item1] [Item2] [Item3]    [Pause]   |
+---------------------------------------+

• Menu Flow Diagram — ASCII showing navigation between screens:

[Title Screen] --> [Main Menu] --> [Play] --> [Level Select] --> [Game]
                       |                                           |
                       +--> [Settings]                     [Pause Menu]
                       +--> [Credits]                          |
                                                         [Game Over] --> [Main Menu]

• Screen Mockups — Brief description of each unique screen (title, main menu, settings, game over, win).
• Accessibility Considerations — Color-blind modes, font size options, remappable controls, screen reader hints.

Section 8 — Art Direction

• Visual Style — Describe in 1-2 sentences (e.g., "16-bit pixel art with modern lighting effects").
• Color Palette — 5-8 hex codes with role labels:

• Resolution & Scaling — Game resolution (e.g., 800x600), scale mode (Phaser

  FIT

  ,

  RESIZE

  , etc.), pixel-perfect flag.
• Animation Guidelines — Frame counts, FPS per animation type (idle: 4 frames @ 8fps, run: 6 frames @ 12fps).
• Asset List with Specs — Table of every required asset:

Section 9 — Audio Design Plan

• Music Mood per Scene — Table mapping each scene/level to a musical mood and tempo:

• SFX List — Action-to-sound mapping:

• Format Requirements — All audio must be provided in both MP3 and OGG for cross-browser compatibility. Phaser will select the best format at runtime.
• Volume Hierarchy — Define relative volume levels: Music (0.4), SFX (0.7), UI sounds (0.5). Describe how they interact (SFX duck music briefly on major events).

Section 10 — Technical Requirements

• Phaser Version —

  phaser@beta

  (v4.0.0-rc.7) unless the user specifies otherwise.
• Physics Engine — Choose one and justify:
  • Arcade — Simple AABB, best for platformers and shooters. Low CPU cost.
  • Matter.js — Full rigid-body physics. Use for games needing rotation, joints, or complex collision shapes.
  • None — For puzzle or card games with no physics simulation.
• Performance Budgets — Target frame rate (60 FPS), max draw calls per frame, max simultaneous particles, texture atlas size limits.
• Browser/Device Targets — Minimum browser versions, mobile device tier (e.g., "must run at 30+ FPS on 2020-era mid-range Android").

Section 11 — Platform Targets & Device Profiles

• Primary Platforms — Desktop browser, mobile browser, PWA, Electron, Capacitor/Cordova.
• Input per Platform:

• Deployment Method — How the game is built and distributed (static hosting, itch.io, app store via Capacitor, etc.).

Section 12 — Monetization & Release Plan (Optional)

• Business Model — Free, premium, freemium, ad-supported, or donation-ware.
• Milestones — Key dates or phases:

• Distribution — Where the game will be published (itch.io, GitHub Pages, Steam, app stores).

Section 13 — Acceptance Criteria

player.y

player.y

atMost: spawnY - 96

enemy.active

enemy.active

equals: false

registry.get('score')

atLeast: 10

body.velocity.y < 0

enemies.countActive(true)

equals: 12

game.loop.actualFps

atLeast: 55

game.scene.isActive('MainMenuScene')

equals: true

### Vertical Slice
- [ ] Player spawns at level start and responds to left/right/jump within 1 frame
- [ ] Falling off the map triggers respawn at the last checkpoint within 500ms
- [ ] Collecting a coin increments score by 10 and plays the pickup sound

### Alpha
- [ ] All 8 levels load without console errors
- [ ] Enemy AI pathfinds around static geometry (no wall-clipping over 30s)

### Human review required (not automatable)
- Difficulty curve across levels 1-8 feels fair to a first-time player
- Art reads clearly against every background
- Audio mix is balanced at 50% volume

docs/acceptance-criteria.md

Post-GDD Workflow

1. Scaffold the project — Use

   /phaser-new

   to generate the base project structure matching the GDD's technical requirements.
2. Design the architecture — Use the phaser-architect skill/agent to translate the GDD into a technical architecture: scene graph, class hierarchy, data flow, and system decomposition.
3. Start implementing — Use the phaser-coder skill/agent to begin coding scenes, mechanics, and entities as specified in the GDD.

Output Format

• A top-level

  # Game Design Document: [Title]

  heading.
• Each of the 13 sections as

  ## Section N — Name

  headings.
• ASCII diagrams for all flow charts, wireframes, and level maps (no external image dependencies).
• Tables for structured data (enemies, assets, audio, controls).

• <!-- ASSUMPTION -->

  comments next to any detail the generator inferred rather than received from the user.

docs/GDD.md