Make a Puzzle Platformer Game With AI: Prompt and Levels

Make a Puzzle Platformer Game With AI: Prompt and Levels

A puzzle platformer is two games stacked: a character that runs and jumps, and a room that only opens if you do things in the right order. Zugo generates it as a 2D browser game, checks it in a sandbox and hands it over playable. The build costs 6 credits and each edit 3.

It is the most demanding genre to describe in text, because the challenge is not in the movement but in the relationships between objects. One button opening one door is an interaction. Three buttons and two doors are a system, and systems compress badly into a single paragraph.

How is this different from a normal platformer?

The obstacle is order, not precision. In a classic platformer you fail because you mistimed a jump. Here you fail because you have not yet worked out what each object does, and jumping well does not save you.

That changes what the prompt has to carry. On top of gravity, jumping and death, you have to describe objects that react: buttons, doors, boxes that get pushed, platforms that appear, keys. Each one needs its effect written out.

If the movement itself is still unsettled, start there instead. The version without puzzles is covered in make a platformer game with AI, and puzzles sit much better on a skeleton that already jumps correctly.

There is also a resource argument for starting simple. Fixing jump feel and puzzle logic in the same edit makes it impossible to tell which change helped, and each edit costs 3 credits whether or not you learned anything from it.

Which mechanic should you ask for first?

One, and one whose effect fits in a sentence. The five below generate cleanly because they leave no room for interpretation.

The first three rows are enough for a complete first level. The last two introduce dependencies on time, and time is exactly what a single description compresses worst, so add them once the rest behaves.

A rule that saves credits: one mechanic per build, one variation per edit. Asking for five at once usually produces a level where three work, one is silently dropped, and one does something adjacent to what you meant.

How do you describe a room that can be solved?

Write the solution before the room. List the steps in order, then describe the space as the place where those steps are possible.

A concrete example beats any theory: "the player pushes the box onto the button, the button holds the door open, the player walks through and picks up the key, the key opens the exit." Four steps, three objects, one complete level.

That sentence becomes the prompt almost word for word. When you describe the solution, the generation has to build a space where that chain exists, which drastically cuts the odds of receiving a pretty room with no way through.

Then play your own level as though someone else wrote it. The useful question is not whether it can be solved, but whether the purpose of each object is readable without a caption. More on phrasing prompts that survive generation is in how to write a good prompt.

What breaks in the first version?

Three things, and none of them is the jump.

The first is the object that does not react. The box is there, the button is there, and standing on the button does nothing. This happens when the prompt names the objects but never states the relationship, so the fix is one sentence saying what causes what.

The second is the state you cannot undo. The player shoves the box into a corner, the level becomes impossible, and there is no way back. Always ask for a restart key. In this genre it is not a convenience, it is part of the mechanics.

The third is the level solved by accident. If you can jump over the puzzle, the puzzle is not there. It is fixed by raising a wall or moving a platform out of reach, and it is by far the most common edit here.

A fourth, less obvious one: two mechanics that quietly cancel each other out, like a box that can be pushed onto the same tile the door needs to close through. Play every combination once, not just the intended path.

How do you teach a mechanic without a tutorial?

By building the first room so that the wrong move is harmless and the right one is obvious. This is design work, and it is the difference between a puzzle and a riddle.

The pattern that works: introduce the object alone in a room where it is the only thing to interact with, let the player press it and see the door open in plain view, and only then combine it with anything else. Ask for it directly: "make the first room contain only the button and the door, both visible on the same screen."

Colors do the rest of the teaching. Ask for the key, the lock and any related objects to share a color, and for unrelated objects to look clearly different. That single edit removes most of the confusion players report in a first playtest.

Resist adding text instructions. A room that needs a paragraph of explanation is a room with a missing visual cue, and the paragraph hides the problem instead of solving it.

How do you add more levels?

One at a time, and only when the first is finished. Every new level inherits mechanics you have already tuned, so the second costs far less effort than the first.

Decide early how levels connect: whether finishing one moves you straight to the next, whether there is a level select screen, and whether progress survives a page reload. Those are three separate decisions and three separate requests.

Progress kept in the player's browser is the normal answer and needs nothing connected. Progress that follows a player across devices means a database, which means connecting Supabase, and that is work on top of the game rather than another edit.

A good sequence is short. Five rooms that each add one idea beat twenty rooms that repeat three ideas, and five rooms is a realistic target for a build plus a handful of edits.

What does it cost in credits?

This is the most edit-hungry of the arcade genres, because every added mechanic wants its own pass.

A realistic run: one build with the base mechanic, then seven or eight edits covering rules, the restart key, touch controls and three levels. Pro costs $25 a month for 200 credits, which is 66 edits if you spend them purely on refinement, and Business costs $99 a month for 800 credits.

Free includes 5 credits, less than a single build, so it is a way to look inside the tool rather than to finish a game. A simple build takes about a minute, and the genre's cost is measured in edits, not in waiting.

Where are the limits?

Games here are 2D and run in the browser, which suits this genre well and rules out 3D, an installer and an app store listing.

Before delivery each build is started in a sandbox and one that fails to load is reported as a failure. That check answers whether the page opens, not whether the puzzle has a solution, and the second question is answered by you playing it.

The real limit is system complexity. A puzzle with many pieces affecting each other has more interactions than any single description can hold, and those interactions are precisely what a one-shot prompt loses. It gets built in layers or it does not get built.

Said plainly: very specific logic is refined through edits, and Zugo does not replace a development team on a complex product. For a portfolio piece, a demo or a short branded puzzle the fit is right, and the code exports to GitHub if you decide to continue by hand. A physics-driven cousin of this genre is covered in make a physics puzzle game with AI.

Where should you start?

Pick one mechanic, write the level solution as four steps, and ask for exactly that. It is the shortest path to something playable and the cheapest in corrections.

Once that room is understood without explanation, add the second mechanic and not before. A tight puzzle built from two ideas is remembered longer than a confusing one built from six. Published games live at an address like your-game.zugo.run and open on any device, with a custom domain available. Build the first room at zugo.dev.