Make a Physics Puzzle Game With AI: Prompt and Tuning
Make a Physics Puzzle Game With AI: Prompt and Tuning
Name the world, the objects, the one action the player gets and the condition that wins the level, and Zugo builds a 2D browser physics puzzle: gravity, collisions, an aim-and-release or drag-and-drop input, and a goal. The build costs 6 credits, each edit 3, and most of the work is tuning numbers.
This genre generates surprisingly well and then feels wrong for reasons that have nothing to do with the rules. Physics is emergent. You describe intent, the simulation produces behavior, and the gap between those two is where the edits go.
What can one prompt build here?
A single-screen level with a physics world: bodies that fall, collide and stack, static walls and floors, one player action, and a win check. Objects that break on impact, ropes that can be cut, planks that pivot on a hinge, and a launcher with an aim line all generate reliably.
Beyond that, one prompt handles a move counter, a star rating based on shots used, a reset key, and a short chain of two or three levels. Those are rules, and rules compress into text without loss.
The part that does not compress is the feel of the simulation: how heavy a crate is, how much a ball bounces, whether a tower falls satisfyingly or slumps like wet sand. Those are numeric values you cannot know until you watch them.
Pick one player verb before writing anything. Launch a projectile, cut a rope, drop a block, or push a lever. A puzzle with one verb and a smart level is better than a puzzle with four verbs and no idea which one you should be using.
What should the prompt name?
Six items, and the last two are the ones people leave out.
| Element | Weak version | Strong version |
|---|---|---|
| World | "a physics game" | "a 2D side view with gravity, ground and two walls" |
| Objects | "some blocks" | "wooden crates that stack, one heavy stone ball, glass panes that shatter" |
| Player action | "shoot things" | "drag back from the slingshot to aim, release to launch, three shots per level" |
| Goal | "knock stuff down" | "the level is won when all three targets have been knocked off their platforms" |
| Failure | (unspecified) | "out of shots with targets still standing means the level is lost" |
| Reset | (unspecified) | "an R key and a button that restart the level instantly" |
The reset row matters more here than in any other genre. A physics level can reach a state where the win is no longer possible, a crate wedged in a corner or the ball rolled off screen, and without an instant restart the player is stuck watching a dead world.
Put the failure condition in words too. Left unspecified, many builds simply let you keep shooting forever, which quietly removes the puzzle: if there is no cost to a bad shot, there is nothing to solve.
Why does the first build feel floaty?
Because default physics constants are conservative, and conservative physics reads as underwater. The three values that cause it are gravity, restitution (bounciness) and friction, and all three are one sentence away.
Ask for them by name and by direction, not by number: "increase gravity so objects fall noticeably faster," "reduce bounciness on the crates so they land and stay," "raise friction on the ground so the ball stops rolling within a second or two." Direction beats numbers because you do not know what unit the build is using.
Change one at a time. Gravity, bounce and friction interact, and adjusting all three in a single edit leaves you unable to say which change caused the improvement. This costs one extra edit at 3 credits and saves several.
The fourth value worth naming is mass ratio. If the projectile weighs the same as the tower it hits, nothing dramatic ever happens. Ask for the projectile to be clearly heavier than the crates and the whole game gets its punch back.
What goes wrong that is not tuning?
Three defects show up often enough to name, and each has a specific fix.
| Symptom | Cause | What to ask for |
|---|---|---|
| Objects jitter in a stack | Too many contacts settling | "let bodies fall asleep when they stop moving" |
| Fast ball passes through a wall | Step-over-step collision miss | "use continuous collision detection for the projectile" |
| Structure collapses on load | Objects overlap at spawn | "space starting objects so none overlap before the first frame" |
| Level cannot be lost | No shot limit | "limit the player to three shots per level" |
| Win never triggers | Goal check too strict | "count a target as knocked out if it moves off its platform at all" |
The last row is the sneaky one. A win condition written as "all targets destroyed" can be impossible if the objects were never given a way to be destroyed. Phrase the goal in terms of position or contact, which the simulation can always measure.
Playing your own level for two minutes finds all of these. Reading the description finds none of them, which is why the sandbox check before delivery only tells you the page opens, not that the puzzle works.
How do you design a level that is solvable?
Write the solution first, then describe the room that makes the solution possible. This is the single habit that separates a physics level from a pile of boxes.
Concretely: "the player launches the ball at the leftmost support, the platform tips right, the crate slides off and lands on the switch, the switch opens the gate." Four steps, four objects. That paragraph becomes the prompt almost word for word, and the generated level has to contain the chain you described.
Then play it as if you had not written it. The useful question is not whether it can be solved, but whether a stranger can tell what each object does without being told. A puzzle that needs an explanation is a puzzle with a missing visual cue.
Add the second and third levels only after the first is finished. Each new level inherits mechanics you have already tuned, so it costs one edit rather than a rebuild. The same discipline applies to a related genre covered in make a puzzle platformer with AI.
What does a physics puzzle cost?
A build is 6 credits, an edit is 3. Hi-Fi mode doubles both: 12 and 6.
This genre lands mid range on total cost. The rules generate on the first pass, and the spend goes into tuning: gravity, bounce, friction, mass, shot count, and one or two extra levels. A build plus eight to ten edits is a normal finished project.
Free gives 5 credits once, which is under a single build, so it is a way to see the tool rather than to finish a game. Pro is $25 a month for 200 credits, which works out to 33 builds or 66 edits. Business is $99 a month for 800 credits. A simple build takes about a minute, and larger projects take several, so budget by edit count rather than by clock.
Where does the genre stop?
Four boundaries, stated plainly.
- 2D only, browser only. No 3D rigid bodies, no installed app. Side-view physics fits this comfortably, but it is the ceiling.
- Fluids, cloth and soft bodies are unreliable. Rigid bodies, hinges and ropes generate well. Water and jelly are a different class of simulation and should not be planned around.
- Exact repeatability is not guaranteed. Physics runs frame by frame, so the same shot can settle slightly differently. Do not build a game whose puzzle depends on pixel-identical outcomes.
- A big level set is authored work. One clever level is a prompt. Twenty levels with a difficulty curve are twenty decisions, made one edit at a time.
Very specific logic gets refined through edits rather than captured in one prompt, and Zugo does not replace a development team on a complex product. For a portfolio piece, a branded mini-game or a short puzzle set, the size is right, and the code exports to GitHub if you want to keep going by hand. A broader list of what generation cannot reach is in what an AI builder cannot build.
What is the fastest path to something fun?
One verb, one room, one goal, then tune gravity before adding anything. Most builds go from lifeless to satisfying on the strength of two or three number changes, and adding mechanics before that happens just spreads the problem across more objects.
When the first level plays well, decide whether you want a shot limit and a star rating, because those two turn a sandbox into a game people replay. Both are single edits.
Published projects get an address like your-game.zugo.run and open on phone and desktop, with a custom domain if you want your own. A calmer genre to try alongside is in make a match-3 game with AI. Describe your world and your one verb at zugo.dev and watch the first tower fall.