| name | game-dev-studio |
| description | The studio loop for making a game with the owner: pin the fantasy and core loop, write a short GDD, build a vertical slice, iterate on feel, add content, polish and export. Use when the owner wants to make, prototype or playtest a game of any genre; pairs with an engine skill such as godot-4.
|
| version | 1.0.0 |
| author | Remedy |
| tags | ["game","design","studio","playtest","gdd","vertical-slice"] |
| requires | [] |
| tools | ["game_project_info","game_playtest","godot_run","godot_check","godot_export","skill_activate","bash_exec","file_read","file_write","file_edit","repo_search","list_dir","computer_screenshot","vision_decode","comfyui"] |
| triggers | ["\\b(make|build|create|prototype|design)\\b.{0,40}\\b(game|platformer|roguelike|shooter|rpg|puzzle game|metroidvania|tower defense|visual novel)\\b","\\b(vertical slice|gdd|game design doc(ument)?|playtest(ing)?|game feel|juice|core loop|level design)\\b"] |
Game dev studio (the loop)
A procedure for building a game with the owner, who holds creative
direction. Every phase ends with something that runs. Activate the engine
skill first (godot-4 for a project.godot project; game_project_info(path)
tells you the stack) and follow its verification rule: every change ends with the engine's headless
verify or the stack's test command, and you say what ran.
Phase 0 — the fantasy and the core loop (one paragraph)
Before any file: write one paragraph with the owner. It names the fantasy
("you are a ghost stealing dreams"), the 10-second loop (verb → feedback →
reward → verb), the win and lose condition, and one reference game. If the
owner is vague, propose two concrete options and ask them to pick; do not
ask open questions. Save it as the first section of the GDD.
Phase 1 — GDD (docs/gdd.md, 1–2 pages)
Use references/gdd-template.md. Fill only what is decided; mark the rest
TBD and keep the cut list live from day one. Re-read the GDD before
each phase and update it instead of letting it rot.
Phase 2 — vertical slice
One level, one mechanic, a way to win, a way to lose, restart. Placeholder
art (coloured rectangles) and placeholder audio are correct here. Order:
- Player controller + the single mechanic, in an empty room.
- One hazard or enemy, death, restart.
- A goal, a win screen, a lose screen.
- Main scene wired, smoke passes, the owner plays it.
Stop here and playtest. Do not add a second mechanic until the first one
is fun with rectangles. "One mechanic deep beats five shallow."
Phase 3 — feel (juice)
Read references/juice-and-feel.md. Tune in this order: input latency and
acceleration curves → coyote time / input buffering → hit-stop, screen
shake, squash-and-stretch → particles, sound, camera. Each is a number the
owner can feel; change one, playtest, keep or revert.
Phase 4 — content, then polish/export
Content = more levels/enemies/items using the same systems. Only now
replace placeholder art (see game-assets), add menus, settings, save
(references/save-systems.md), input remapping (references/input-maps.md),
audio mix (references/audio.md), then export per platform and test the
export, not the editor run.
Scope control
Keep docs/gdd.md → Cut list current. Anything not serving the core
loop goes there first and comes back only if the slice is finished and
fun. Milestone shape and time estimates: .
If the owner asks for a feature mid-slice, add it to the cut list and ask
whether it replaces something or waits; do not silently expand.
