5.8 KiB
Quick-Dev - Flexible Game Development Workflow
Communicate in {communication_language}, tailored to {user_skill_level} Execute continuously until COMPLETE - do not stop for milestones Game-specific: Consider performance (60fps), feel, and player experience ALWAYS respect {project_context} if it exists - it defines project standards
Load and execute {advanced_elicitation}, then return Load and execute {party_mode_exec}, then return Load and execute {quick_prototype_workflow}Check if {project_context} exists. If yes, load it - this is your foundational reference for ALL implementation decisions (patterns, conventions, architecture).
Parse user input:
Mode A: Tech-Spec - e.g., quick-dev tech-spec-combat.md
→ Load spec, extract tasks/context/AC, goto step 3
Mode B: Direct Instructions - e.g., implement player jump...
→ Evaluate complexity, offer planning choice
Mode C: Prototype Reference - e.g., quick-dev from prototype...
→ Load prototype code, productionize
Evaluate complexity against game development signals:
Triggers planning (if 2+ signals present):
- Multiple game systems (e.g., combat + inventory + UI)
- Performance-critical code (e.g., game loop, rendering, physics)
- Cross-platform considerations
- Multiplayer/networking
- Save system integration
Simple enough for direct execution:
-
Single mechanic adjustment
-
UI tweak
-
Bug fix
-
Asset integration
-
Config/balance change
This looks like a significant game feature.
[t] Plan first - Create tech-spec then implement (recommended) [r] Prototype first - Test the idea before committing [w] Use full BMGD workflow - For larger features [e] Execute directly - Start implementation now
<check if="t">
<action>Create lightweight tech-spec with tasks and AC</action>
<goto>step_3</goto>
</check>
<check if="r">
<action>Load and execute {quick_prototype_workflow}</action>
<action>Return here after prototype complete</action>
</check>
<check if="w">
<action>Load and execute {workflow_init}</action>
<action>EXIT quick-dev - user routed to full workflow</action>
</check>
<check if="e">
<goto>step_2</goto>
</check>
<check if="e">
<goto>step_2</goto>
</check>
<check if="t">
<action>Create quick task list</action>
<goto>step_3</goto>
</check>
Identify scope:
- Files to modify
- Game systems affected
- Performance considerations
- Existing patterns to follow
Create mental plan:
- Tasks to complete
- Acceptance criteria
- Test approach (manual playtest, unit tests, etc.)
For each task:
- Load Context - Read relevant files, understand integration points
- Implement - Follow patterns, consider performance, handle edge cases
- Test - Run game, verify behavior, check frame rate impact
- Mark Complete - Check off task [x], continue
Game-specific checks during implementation:
Performance:
- Avoid allocations in hot paths
- Use object pooling where appropriate
- Profile if frame time increases
Feel:
- Test input responsiveness
- Verify visual/audio feedback
- Check timing and pacing
Integration:
- Verify save/load compatibility
- Check multiplayer sync (if applicable)
- Test on target platform
HALT and request guidance Fix before continuing Profile and optimize before continuing
Continue through ALL tasks without stopping
Verify completion:
- All tasks [x]
- Game runs without errors
- Feature works as specified
- Performance acceptable (target frame rate maintained)
- Patterns followed
Implementation Complete!
Summary: {{implementation_summary}} Files Modified: {{files_list}} Tests: {{test_summary}} Performance: {{performance_notes}} AC Status: {{ac_status}}
Recommended: Playtest the changes
Run the game and verify:
- Feature works as expected
- No regressions in related systems
- Performance is acceptable
- Feel is right
Before committing: Consider a code review
You are a senior game developer reviewing code for a game project. These changes were just implemented. Look for:
1. Performance issues (allocations in loops, unnecessary calculations)
2. Game feel problems (timing, feedback, responsiveness)
3. Integration issues (save system, multiplayer, platform)
4. Code quality (patterns, readability, maintainability)
Find at least 3 issues or improvements.
Explain what was implemented based on {user_skill_level}