| name | prototype-roadmap-planner |
| description | Read a prototype GDD and generate a phased implementation roadmap with concrete tasks, organized by implementation phases with specific deliverables and test criteria. |
| domain | project |
| type | planner |
| version | 1.0.0 |
| allowed-tools | ["Read","Write","Glob"] |
Prototype Roadmap Planner Skill
This skill reads a prototype GDD and generates a detailed implementation roadmap. It extracts implementation phases from the GDD, breaks down each phase into concrete tasks, and creates a day-by-day or hour-by-hour development plan for rapid prototyping.
When to Use This Skill
Invoke this skill when the user:
- Says "create roadmap for prototype"
- Asks "plan implementation for prototype"
- Wants to break down prototype into actionable tasks
- Has a prototype GDD and needs a development plan
- Says "what's my implementation plan?" or "what should I build first?"
- Wants a day-by-day breakdown of prototype work
Core Principle
Roadmaps turn design into action:
- ✅ Extract implementation phases from prototype GDD
- ✅ Break each phase into concrete, testable tasks
- ✅ Create hour-by-hour or day-by-day timeline
- ✅ Define clear deliverables and test criteria for each phase
- ✅ Prioritize tasks to get playable core loop as fast as possible
- ✅ Roadmap is actionable, not abstract
Visible-First Ordering Philosophy
Build what you can SEE before what you can't.
Traditional development often goes: Data → Systems → Features → UI. For prototypes, invert this:
VISIBLE-FIRST ORDER:
1. Visual elements (sprites, scenes, UI) ← See it first
2. Player interaction (input, feedback) ← Feel it second
3. Core systems (logic, rules) ← Make it work
4. Data structures (resources, configs) ← Refine later
5. Polish (juice, effects) ← Last
Why Visible-First?
- Observable progress: Seeing sprites move on screen motivates more than seeing console logs
- Early feedback: Spot design problems when you can see the game, not just read data
- Testable sooner: Playtest with placeholder logic, not placeholder visuals
- Avoid over-engineering: Build only the systems you actually need for what you see
Example - Grid Combat:
❌ Traditional Order (invisible progress):
- Create grid data structure
- Create pathfinding algorithm
- Create unit stats system
- Create UI to display it all
- Finally see something
✅ Visible-First Order (observable progress):
- Create grid visual (TileMap or sprites) ← See the board
- Create unit sprites that can be placed ← See the pieces
- Create click-to-select, click-to-move ← Feel interaction
- Add pathfinding for valid moves ← Make it smart
- Add stats and damage calculation ← Make it meaningful
At each step, you can SEE and FEEL progress.
Ordering Rules
- Scenes before scripts: Create the visual scene structure first, add behavior second
- Sprites before data: Use placeholder sprites immediately, define stat Resources later
- Hardcode before configure: Hardcode values to get it working, extract to data files later
- Input before logic: Get player clicking/pressing first, add game rules second
- Feedback before polish: Show that something happened (even ugly), make it pretty later
Dependency Mapping (Visible-First)
When mapping task dependencies, follow this order:
Phase 1: Core Visuals
├── Scene structure (Main.tscn, Game.tscn)
├── Player/unit sprites visible
├── Basic camera/viewport
└── Placeholder UI elements
Phase 2: Core Interaction
├── Input handling (click, WASD)
├── Visual feedback (selection, movement)
├── State changes visible (health bars, etc.)
└── Basic sound effects (optional)
Phase 3: Core Systems
├── Game logic (turn order, combat rules)
├── Data integration (stats affect outcomes)
├── Win/lose conditions
└── State management
Phase 4: Data & Balance
├── Extract hardcoded values to Resources
├── Create data files (JSON, .tres)
├── Balance pass (tune numbers)
└── Configuration systems
Phase 5: Polish
├── Animations and transitions
├── Juice (screenshake, particles)
├── UI polish
└── Audio polish
Roadmap Output Structure
The skill generates a detailed, task-oriented roadmap:
# [GAME TITLE] - Prototype Implementation Roadmap
**Based On:** Prototype GDD v[X.Y]
**Timeline:** [X days from GDD]
**Target:** [Core question from GDD]
**Created:** [Date]
---
## Quick Start
**Critical Path to Playable Core Loop:**
1. [Most important task from Phase 1]
2. [Most important task from Phase 1]
3. [First test milestone - "can play one round"]
**Estimated time to playable:** [X hours]
---
## Phase 1: [Phase Name] ([Timeline] - [X hours])
**Goal:** [What you're building - from GDD]
**Deliverables:**
- [Deliverable 1 from GDD]
- [Deliverable 2 from GDD]
**Test Criteria:** [How you know it works - from GDD]
### Tasks
#### Task 1.1: [Clear Action Verb] [Specific Thing]
**Time:** [X hours]
**What:** [One sentence describing the visible/testable outcome]
**How:**
- [Implementation step 1]
- [Implementation step 2]
- [Implementation step 3]
**Acceptance:**
- [ ] [Specific testable criterion - observable]
- [ ] [Specific testable criterion - observable]
**Files:**
- `[file path]` - [purpose]
- `[file path]` - [purpose]
**Hardcoded Values:**
- [Value name]: [value] (e.g., movement_speed: 200)
- [Value name]: [value]
**Dependencies:** None / [Task X.Y must be complete]
---
#### Task 1.2: [Clear Action Verb] [Specific Thing]
**Time:** [X hours]
**What:** [One sentence describing the visible/testable outcome]
**How:**
- [Implementation step 1]
- [Implementation step 2]
**Acceptance:**
- [ ] [Specific testable criterion]
- [ ] [Specific testable criterion]
**Files:**
- `[file path]` - [purpose]
**Hardcoded Values:**
- [Value name]: [value]
**Dependencies:** [Task 1.1]
---
[Continue for all tasks in phase]
**Phase 1 Checkpoint:**
- [ ] All deliverables complete
- [ ] Test criteria passed: [test description]
- [ ] Ready to proceed to Phase 2
---
## Phase 2: [Phase Name] ([Timeline] - [X hours])
**Goal:** [What you're building - from GDD]
**Deliverables:**
- [Deliverable 1 from GDD]
- [Deliverable 2 from GDD]
**Test Criteria:** [How you know it works - from GDD]
### Tasks
[Same structure as Phase 1]
**Phase 2 Checkpoint:**
- [ ] All deliverables complete
- [ ] Test criteria passed: [test description]
- [ ] Ready to proceed to Phase 3
---
[Continue for all phases from GDD]
---
## Testing & Validation
**After Each Phase:**
- [ ] Run test criteria from phase
- [ ] Document any issues/blockers
- [ ] Adjust timeline if behind schedule
**Final Prototype Test (End of Timeline):**
- [ ] Can complete full playthrough
- [ ] Critical questions from GDD answerable
- [ ] Playtesters can understand core loop
- [ ] Success metrics measurable
---
## Risk Mitigation Plan
**From GDD Risk Section:**
**Risk:** [Risk from GDD]
**If This Happens:** [Fallback from GDD]
**Action Items:**
- [Specific task to mitigate]
- [Specific task to implement fallback]
[Repeat for each risk from GDD]
---
## Daily Schedule (for [X]-day timeline)
### Day 1: [Date]
**Focus:** [Phase name]
- Morning (4h): [Tasks]
- Afternoon (4h): [Tasks]
**End of Day Goal:** [Deliverable]
### Day 2: [Date]
**Focus:** [Phase name]
- Morning (4h): [Tasks]
- Afternoon (4h): [Tasks]
**End of Day Goal:** [Deliverable]
[Continue for each day]
---
## Content Checklist
**Assets to Create:**
- [ ] [Asset 1 from GDD content scope]
- [ ] [Asset 2 from GDD content scope]
**Data/Balance:**
- [ ] [Stats for units/enemies from GDD]
- [ ] [Configuration values]
---
**END OF ROADMAP**
**Next Steps:**
1. Review this roadmap
2. Set up development environment
3. Start Phase 1, Task 1.1
4. Test frequently, adjust timeline as needed
Workflow
Step 1: Read Prototype GDD
-
Find the prototype GDD:
- Look for
docs/*prototype-gdd*.md or ask user for path
- Read the entire GDD
-
Extract key information:
- Timeline (weekend/week/month from GDD)
- Critical questions being tested
- Implementation phases (from "Implementation Phases" section)
- Each phase's goal, deliverables, test criteria
- Content scope (units, mechanics, etc.)
- Risk mitigation plans
- Success metrics
Step 2: Break Down Each Phase into Tasks
For each implementation phase in the GDD:
-
Extract phase metadata:
- Phase name and timeline (e.g., "Day 1, Morning - 4h")
- Goal statement
- Deliverables list
- Test criteria
-
Infer concrete tasks from deliverables:
- Each deliverable becomes 1-3 tasks
- Tasks should be 1-3 hours each (small enough to track progress)
- Tasks should have clear acceptance criteria
Example:
GDD Deliverable: "WASD movement, one weapon, enemy spawning"
Becomes tasks:
- Task 1.1: Player Character with WASD Movement (2h)
- Task 1.2: Basic Weapon Auto-Fire System (1.5h)
- Task 1.3: Enemy Spawner and Basic Enemy (1.5h)
- Define acceptance criteria:
- What specific behaviors must work
- How to test it
- Observable success conditions
Example:
Task 1.1: Player Character with WASD Movement
Acceptance Criteria:
-
Identify file paths:
- Where will code live (scripts/player/player.gd)
- What scenes to create (scenes/player/Player.tscn)
- Based on project structure and GDD organization
-
Map dependencies (Visible-First):
- Which tasks must complete before others
- Follow visible-first order: visuals → interaction → systems → data → polish
- Prioritize tasks that produce observable results early
Step 3: Create Critical Path
Identify the shortest path to playable core loop:
- Which tasks MUST complete to test the core mechanic?
- What's the absolute minimum to get "one round" working?
- Usually 3-5 tasks from Phase 1
Output as "Quick Start" section:
Critical Path to Playable Core Loop:
1. Player movement (Task 1.1)
2. Enemy spawning (Task 1.3)
3. Basic combat (Task 1.2)
Estimated time to playable: 5 hours
Step 4: Generate Daily Schedule
For short timelines (weekend/week):
- Break phases into day-by-day chunks
- Assign tasks to morning/afternoon blocks
- Set end-of-day goals (deliverables)
Example for weekend timeline:
Day 1:
- Morning: Phase 1 (Core Loop Foundation)
- Afternoon: Phase 2 (Economy System)
End of Day Goal: Can place units and earn gold
Day 2:
- Morning: Phase 3 (Full Content)
- Afternoon: Phase 4 (Wave Progression)
End of Day Goal: Full 10-wave game loop works
Day 3:
- All day: Phase 5 (Polish & Juice)
End of Day Goal: Prototype ready for playtesting
Step 5: Extract Content Checklist
From GDD's "Content Scope" section:
- List all units/enemies/items to create
- Extract stats and attributes
- Create checklist format
Example:
Content Checklist:
- [ ] Goblin (15g, 30 HP, 5 ATK)
- [ ] Skeleton (25g, 40 HP, 8 ATK)
- [ ] Warrior Hero (50 HP, 10 ATK, 20g drop)
Step 6: Map Risk Mitigation to Tasks
From GDD's "Risk Mitigation" section:
- Each risk becomes potential task
- Mitigation = proactive task (do during normal dev)
- Fallback = conditional task (do if risk occurs)
Example:
Risk: Auto-battle too fast/confusing
Mitigation Task: Add damage numbers and 1-2s combat pacing (Phase 5, Task 5.2)
Fallback Task: Add "Pause" button during combat (conditional - if playtest reveals issue)
Step 7: Save Roadmap
Save to: docs/[game-name]-prototype-roadmap.md
Output to user:
Created prototype roadmap with:
- [X] phases over [timeline]
- [X] concrete tasks
- Day-by-day schedule
- Critical path to playable in [X] hours
Next steps:
1. Review roadmap: docs/[game]-prototype-roadmap.md
2. Set up dev environment
3. Start Phase 1, Task 1.1
4. Test after each task, track progress
Example Interaction
User: "Create roadmap for prototype"
Skill:
Reading prototype GDD...
Found: docs/dungeon-investor-prototype-gdd.md
- Weekend timeline (2-3 days)
- 5 implementation phases defined
- Testing: Economic auto-battle dungeon defense
- Goal: Answer 5 critical questions
Breaking down phases into tasks...
Phase 1: Core Loop Foundation (Day 1 AM, 4-5h)
- 3 tasks (Player setup, Drag-drop, Auto-battle)
Phase 2: Economy System (Day 1 PM, 3-4h)
- 4 tasks (Gold UI, Shop, Cost system, Payouts)
Phase 3: Full Content (Day 2 AM, 4-5h)
- 3 tasks (5 monsters, 3 traps, 3 heroes)
Phase 4: Wave Progression (Day 2 PM, 3-4h)
- 4 tasks (Wave system, Scaling, Win/lose, Restart)
Phase 5: Polish & Juice (Day 3, 4-6h)
- 5 tasks (Damage numbers, Animations, UI clarity, etc.)
Generating daily schedule...
Day 1: Core Loop + Economy → playable with gold system
Day 2: Full Content + Waves → complete 10-wave loop
Day 3: Polish → ready for playtesting
Critical path to playable: 5 hours (3 tasks from Phase 1)
Roadmap saved to: docs/dungeon-investor-prototype-roadmap.md
Total: 19 tasks across 5 phases over 3 days
Ready to start development!
Integration with Other Skills
Reads From:
prototype-gdd-generator - Input GDD defining the prototype
Feeds Into:
changelog-updater - Track progress as tasks completesystems-bible-updater - Document systems as they're built
Works With:
version-control-helper - Manage commits per task/phasegdscript-quality-checker - Review code quality after each phase
Quality Checklist
Before finalizing roadmap:
Ordering & Structure:
- ✅ Follows visible-first ordering (visuals → interaction → systems → data → polish)
- ✅ Early tasks produce observable results (not invisible infrastructure)
- ✅ All phases from GDD are included
- ✅ Critical path identified (shortest route to playable)
Task Quality:
- ✅ Each task uses 5-part format (What, How, Acceptance, Files, Hardcoded Values)
- ✅ Tasks are 1-3 hours each (trackable progress)
- ✅ Each phase broken into concrete, testable tasks
- ✅ Detail level is actionable but not over-specified
- ✅ Hardcoded values listed (to extract to data later)
Coverage:
- ✅ Daily schedule created for timeline
- ✅ All deliverables from GDD mapped to tasks
- ✅ Test criteria from GDD included in checkpoints
- ✅ Content checklist extracted from GDD scope
- ✅ Risk mitigation mapped to tasks
Key Principles
DO:
- ✅ Visible-first ordering: Scenes → Interaction → Systems → Data → Polish
- ✅ Extract phases directly from GDD (don't invent new structure)
- ✅ Break deliverables into concrete, actionable tasks
- ✅ Include specific file paths and acceptance criteria
- ✅ Use 5-part task format: What, How, Acceptance, Files, Hardcoded Values
- ✅ Create testable checkpoints after each phase
- ✅ Identify critical path to playable core loop
- ✅ Map risks to mitigation tasks
- ✅ Hardcode values first, extract to Resources later
DON'T:
- ❌ Start with data structures before visuals (invisible progress)
- ❌ Build systems before you can see them working
- ❌ Add tasks not related to GDD deliverables
- ❌ Make tasks too large (>3 hours is too big)
- ❌ Skip test criteria or acceptance criteria
- ❌ Ignore dependencies between tasks
- ❌ Create vague tasks ("make it better")
- ❌ Over-specify tasks (save code details for implementation)
- ❌ Assume file structure (use project's actual structure)
Task Breakdown Guidelines
From GDD Deliverable to Tasks
GDD says: "WASD movement, one weapon, enemy spawning"
Becomes:
-
Task: Player Character Setup
- Create Player.tscn scene
- Create player.gd script with CharacterBody2D
- Implement WASD input handling
- Set movement speed to 200 px/s
- Test: Player moves in all 4 directions
-
Task: Basic Weapon System
- Create Weapon.gd script
- Implement auto-fire timer
- Spawn projectiles on timer tick
- Test: Weapon fires automatically every second
-
Task: Enemy Spawner
- Create Enemy.tscn scene
- Create spawner.gd script
- Spawn enemy every 3 seconds
- Test: Enemies appear and move toward player
Task Size Guidelines
Good task sizes:
- 1-3 hours of focused work
- Single responsibility (one system or feature)
- Testable in isolation
- Clear done criteria
Too large:
- "Implement combat system" (4-8 hours, multiple systems)
- Split into: damage calculation, health system, hit detection
Too small:
- "Add constant for move speed" (<15 min)
- Combine with larger task
Feature Description Detail Level
Each task in the roadmap needs enough detail to be actionable without ambiguity, but not so much that it becomes a full specification. Use this framework:
The 5-Part Task Description
Every task description should include these five elements:
#### Task X.Y: [Clear Action Verb] [Specific Thing]
**What:** One sentence describing the visible/testable outcome.
**How:** 3-5 bullet points of implementation steps.
**Acceptance:** 2-4 checkbox criteria that prove it works.
**Files:** List of files to create or modify.
**Hardcoded Values:** Any magic numbers to use (extract to data later).
Detail Level Examples
Too Vague (Unusable)
#### Task 1.1: Add player movement
Create player movement system.
❌ What kind of movement? Grid? Free? How fast? What input?
Too Detailed (Over-specified)
#### Task 1.1: Add player movement
Create a CharacterBody2D-based player controller using the
built-in input map system. The player should use a state
machine with Idle, Walking, and Running states. Movement
should use velocity-based physics with acceleration of
800 px/s² and deceleration of 1200 px/s². Maximum walk
speed is 150 px/s and run speed is 280 px/s when holding
Shift. Implement 8-directional movement with diagonal
normalization. Add dust particles when changing direction...
❌ This is a specification, not a roadmap task. Save this for implementation.
Just Right (Actionable)
#### Task 1.1: Player Grid Movement
**What:** Player character moves between grid tiles using arrow keys/WASD.
**How:**
- Create Player.tscn with Sprite2D and CollisionShape2D
- Add player.gd with input handling
- Move one tile per keypress (no diagonal for now)
- Animate tween between tiles (0.2s duration)
**Acceptance:**
- [ ] Player sprite visible on grid
- [ ] Arrow keys move player one tile in pressed direction
- [ ] Player cannot move outside grid boundaries
- [ ] Movement has smooth tween animation
**Files:**
- `scenes/player/Player.tscn`
- `scripts/player/player.gd`
**Hardcoded Values:**
- Grid size: 64x64 pixels per tile
- Movement duration: 0.2 seconds
- Grid bounds: 12x12 tiles
✅ Clear what to build, how to approach it, how to test it, specific enough to start immediately.
Detail Level by Task Type
Visual/Scene Tasks (High Visual Detail)
Focus on: What it looks like, where things are positioned, placeholder assets to use
#### Task 2.1: Combat Grid Display
**What:** 12x12 grid visible in center of screen with distinct tiles.
**How:**
- Create CombatGrid.tscn with TileMapLayer
- Use placeholder tile (64x64 colored squares)
- Light tiles for walkable, dark for obstacles
- Center grid in viewport (1920x1080)
**Acceptance:**
- [ ] Grid renders 12x12 tiles
- [ ] Grid is centered on screen
- [ ] Walkable vs obstacle tiles visually distinct
- [ ] Grid scale appropriate (fills ~60% of screen width)
**Hardcoded Values:**
- Tile size: 64x64 pixels
- Walkable color: #4a5568
- Obstacle color: #1a202c
Interaction Tasks (High Behavior Detail)
Focus on: What input does, what feedback player sees
#### Task 2.3: Unit Selection System
**What:** Click on friendly unit to select it, showing selection indicator.
**How:**
- Add Area2D with input detection to Unit.tscn
- Create selection_indicator.tscn (sprite or shader outline)
- Track currently_selected_unit in CombatManager
- Click empty tile or enemy = deselect
**Acceptance:**
- [ ] Clicking unit shows selection indicator
- [ ] Only one unit selected at a time
- [ ] Clicking elsewhere deselects
- [ ] Selected unit info appears in UI panel
**Hardcoded Values:**
- Selection indicator: Yellow outline, 2px
- Click detection radius: 32 pixels
System/Logic Tasks (High Rule Detail)
Focus on: Rules, formulas, edge cases
#### Task 3.2: Attack Damage Calculation
**What:** When unit attacks, calculate and apply damage using stats.
**How:**
- Create damage_calculator.gd utility
- Formula: damage = attack_power - (defense / 2)
- Minimum damage: 1 (always deal at least 1)
- Apply damage to target's current_hp
- Emit signal when unit dies (hp <= 0)
**Acceptance:**
- [ ] Attack reduces target HP by calculated amount
- [ ] Defense reduces incoming damage
- [ ] Minimum 1 damage dealt even vs high defense
- [ ] Unit removed from grid when HP reaches 0
**Hardcoded Values:**
- Defense divisor: 2
- Minimum damage: 1
- Test values: Attacker (ATK 10) vs Defender (DEF 4) = 8 damage
Data/Resource Tasks (High Structure Detail)
Focus on: Data shape, field names, example values
#### Task 4.1: Unit Stats Resource
**What:** Create Resource class to hold unit statistics.
**How:**
- Create UnitStats.gd extending Resource
- Export variables for: hp, attack, defense, move_range, attack_range
- Create 3 example .tres files (Soldier, Archer, Knight)
- Update Unit.tscn to use UnitStats resource
**Acceptance:**
- [ ] UnitStats resource class exists
- [ ] Can create .tres files with stats in editor
- [ ] Unit.tscn has exported UnitStats variable
- [ ] Changing .tres values affects unit behavior
**Example Data:**
- Soldier: HP 30, ATK 8, DEF 4, Move 3, Range 1
- Archer: HP 20, ATK 10, DEF 2, Move 3, Range 5
- Knight: HP 50, ATK 6, DEF 8, Move 2, Range 1
What NOT to Include in Task Descriptions
❌ Don't include:
- Full code implementations (that's for coding time)
- Design justifications (that's in the GDD)
- Alternative approaches (pick one, note alternatives in comments if needed)
- Polish details (animations, particles, sounds - save for polish phase)
- Edge cases you haven't thought through yet
✅ Do include:
- Enough to start coding immediately
- Clear done criteria
- Specific numbers (even if they'll change later)
- File locations
- Dependencies on other tasks
Example Output Structure
Example 1: Dungeon Investor (Visible-First Ordering)
Phase 1: Core Visuals & Scene (Day 1 Morning)
- Task 1.1: Dungeon Room Grid Display (1h) ← SEE the board first
- Task 1.2: Monster/Trap Placeholder Sprites (30min) ← SEE units
- Task 1.3: Hero Placeholder Sprites (30min) ← SEE enemies
- Task 1.4: Gold Counter UI Element (30min) ← SEE economy
Phase 2: Core Interaction (Day 1 Afternoon)
- Task 2.1: Drag-Drop Monster Placement (1.5h) ← FEEL placement
- Task 2.2: Shop Panel with Clickable Items (1h) ← FEEL purchasing
- Task 2.3: Hero Spawning and Walking (1h) ← SEE heroes enter
Phase 3: Core Systems (Day 2 Morning)
- Task 3.1: Basic Auto-Battle Combat (1.5h) ← Combat logic
- Task 3.2: Purchase/Refund Gold Logic (1h) ← Economy logic
- Task 3.3: Hero Death → Gold Earned (30min) ← Reward loop
- Task 3.4: Wave Counter System (1h) ← Progression
Phase 4: Content & Data (Day 2 Afternoon)
- Task 4.1: Monster Stats Resource Class (30min)
- Task 4.2: Implement 5 Monster Variants (1.5h)
- Task 4.3: Implement 3 Trap Variants (1h)
- Task 4.4: Hero Stat Scaling Per Wave (30min)
Phase 5: Polish (Day 3)
- Task 5.1: Damage Numbers Floating Text (1h)
- Task 5.2: Death Animations (1h)
- Task 5.3: UI Clarity Pass (1h)
- Task 5.4: Win/Lose Screens (1h)
Notice the ordering:
- Phase 1: Everything visual (you can SEE the game board)
- Phase 2: Everything interactive (you can CLICK and DRAG)
- Phase 3: Everything logical (it starts WORKING)
- Phase 4: Everything data-driven (it becomes BALANCED)
- Phase 5: Everything polished (it feels GOOD)
Example 2: Grid Combat (Visible-First Ordering)
Phase 1: Visual Foundation (4h)
- Task 1.1: Combat Grid TileMap (1h) ← SEE the battlefield
- Task 1.2: Unit Sprites on Grid (1h) ← SEE the pieces
- Task 1.3: HP Bars Above Units (1h) ← SEE health state
- Task 1.4: Turn Order UI Panel (1h) ← SEE who acts next
Phase 2: Interaction Layer (4h)
- Task 2.1: Click to Select Unit (1h) ← FEEL selection
- Task 2.2: Highlight Valid Move Tiles (1h) ← SEE options
- Task 2.3: Click to Move Unit (1h) ← FEEL movement
- Task 2.4: Click Enemy to Attack (1h) ← FEEL combat
Phase 3: Game Logic (4h)
- Task 3.1: Turn Order Calculation (1h)
- Task 3.2: Movement Range Validation (1h)
- Task 3.3: Attack Damage Calculation (1h)
- Task 3.4: Death and Victory Conditions (1h)
Phase 4: Data Extraction (2h)
- Task 4.1: UnitStats Resource Class (30min)
- Task 4.2: Create Unit .tres Files (30min)
- Task 4.3: Extract Hardcoded Values (30min)
- Task 4.4: Balance Pass (30min)
Phase 5: Polish (2h)
- Task 5.1: Movement Animation Tweens (30min)
- Task 5.2: Attack Animation (30min)
- Task 5.3: Damage Number Popups (30min)
- Task 5.4: Turn Transition Effects (30min)
Each task includes:
- Time estimate
- What/How/Acceptance criteria
- File paths
- Dependencies
- Hardcoded values
Timeline Formats
Weekend (2-3 days)
- Day-by-day breakdown
- Morning/afternoon blocks
- Hourly estimates
- End-of-day goals
Week (5-7 days)
- Day-by-day breakdown
- Daily focus areas
- Half-day blocks
- Milestone at midpoint and end
Two Weeks
- Week 1 / Week 2 breakdown
- Daily goals within weeks
- Weekly milestones
- Buffer time for iteration
Month
- Weekly breakdown
- Phase-level milestones
- More flexible daily structure
- Regular playtest checkpoints
This skill transforms a prototype GDD into an actionable, task-oriented roadmap with concrete steps, time estimates, and testable checkpoints. It's designed for rapid prototyping where speed and clarity are critical.
