When to use it
You have a GDD and you want to feel the core mechanic in an engine as fast as possible — no art, no menus, but it has to actually run and be playable. The AI's role is a gameplay programmer on a specific engine. Output: a minimal playable build that tells you whether it's fun or not.
The prompt (copy and paste)
You are a gameplay programmer working in <ENGINE: Phaser 3 / Godot 4 (GDScript) / Unity (C#)>.
Build a MINIMAL playable prototype that actually runs.
GAME: "<PASTE THE CORE MECHANIC IN ONE SENTENCE>"
CONTROLS: <e.g. WASD + mouse / tap / arrow keys>
GOAL AND LOSS CONDITION: <when the player wins, when they lose>
Requirements:
1. Core loop only: input → action → world reaction → win/lose condition. No menus, art or sound.
2. Graphics — primitives/colored rectangles as placeholders; structure the code so they're easy to swap for sprites later.
3. Give the FULL code file by file with paths + exact run instructions (commands/steps in the engine editor).
4. Pull the gameplay parameters (speed, spawn rate, damage) into a single block of constants at the top — so I can tune balance without digging through the code.
5. No external assets or paid dependencies. If something has to be installed — give the install command.
6. At the end: the first 3 steps to grow the prototype, and where in the code to make them.
If a choice is ambiguous (version, how to run it) — pick the most common option and mark it [assumption].
The technique: a hard "core loop only, must run, parameters in one place" keeps the model from drifting into a pretty but unplayable skeleton.
Filled-in example
Engine: Phaser 3. Game: "dodge falling meteors, collect stars". Controls: arrow keys. Goal: survive 30 seconds; you lose on touching a meteor.
What the AI should come back with: index.html + game.js with a single scene; a rectangle player on the arrow keys; meteors spawned on a timer; a "meteor → game over" collider; a star counter and a survival timer; a const CONFIG = { playerSpeed, meteorRate, ... } block at the top; run instructions "open index.html through a local server with npx serve".
Variations
- For Godot/Unity. Swap the engine — ask for the scene and node/prefab structure, not just the scripts.
- With live balance tuning. "Expose the parameters in a simple on-screen panel so I can change them on the fly" — fast tuning without restarting.
- Iteration. After it runs: "the mechanic works but it's boring — suggest one twist and show me the code diff."
Pro tips
- Ask for the minimum runnable thing and test the build immediately — half of all "finished" code trips over small version differences; fix from the real error, not from a guess.
- For an engine you don't know, pin the version (Godot 4 ≠ 3, Phaser 3 ≠ 2) — the APIs differ, otherwise you get code that won't build.
- The constants block at the top isn't cosmetic: it turns the prototype into a tool for hunting the numbers that feel fun.