Umicat
Introduction

Prompting best practices

How to talk to the agent so it builds what you actually wanted.

Most of the difference between "I love this" and "this isn't what I asked for" comes down to how you write the prompt. This guide is the short version of what works.

The headline rules

  1. Lead with the verb-and-noun. "Add a coin counter at the top-left." not "I was thinking maybe it would be cool if perhaps we couldโ€ฆ"
  2. Be specific about visuals. "A small wizard in a blue robe holding a wooden staff." not "A character."
  3. Anchor numbers. "Wizard moves at 200 px/s, jumps 400 px high." beats "Make the wizard faster" โ€” though both work; the first lands closer to what you wanted on the first try.
  4. One change per turn (usually). Easier to undo if it's wrong; easier for the agent to do well.
  5. Show, don't only tell. Screenshot the preview (๐Ÿ“ท in the toolbar) and paste it into chat to point at something specific.
  6. Trust default knowledge. You don't have to teach the agent what a platformer is. You do have to tell it what kind of platformer yours is.

Initial-build prompts

A good first prompt for a project tells the agent:

  • What kind of game โ€” top-down adventure, side-scrolling platformer, vertical bullet-hell, puzzle, simulation. One phrase.
  • Visual style โ€” pixel art / vector / hand-drawn / "Studio Ghibli pastoral." If you have a reference image, attach it (paperclip in the chat input).
  • Core mechanic โ€” what the player does.
  • The first piece of feedback โ€” what happens when the player succeeds or fails at the core mechanic.

Example that's almost guaranteed to produce a playable prototype:

A pixel-art top-down adventure. The player is a small wizard in a blue
robe walking around a grassy field. They can collect coins scattered
around the field. Show a coin counter in the top-left of the HUD that
increments. Make a soft "ding" play when a coin is collected.

Compare to a prompt that will produce ten clarifying questions:

I want to make a game.

Iteration prompts

Once you have a playable build, prompts get shorter. Some patterns that work:

Tune-something prompts

The wizard moves too slowly. Bump speed by 50%.
Make coins three times more common.

Add-something prompts

Add an enemy: a slime that wanders randomly and damages the wizard
on contact. Two hits and the wizard dies โ€” show a Game Over screen
with a Retry button.

Replace-something prompts

Replace the background music with a slow, melancholy chiptune track.

Polish prompts

The coin pickup feels weak. Add a small particle burst at the coin's
position when it's collected, and shake the camera slightly.

Bug-report prompts

The wizard can walk through the trees. They should block movement.

Use screenshots when words fail

The chat input has a paperclip โ€” attach any image, or:

  • ๐Ÿ“ท Screenshot in the preview toolbar captures the current canvas frame. The capture modal lets you send-to-agent, download, or discard.
  • Record video (also in the capture menu) captures up to 15 seconds.

Common screenshot patterns:

  • "This part looks wrong โ€” fix it" with the bad area screenshotted.
  • "Make it look like this" with a reference image pasted.
  • "The HUD is overlapping the player; move it here" with a screenshot and an arrow drawn (any image editor) showing where.

When the agent gets stuck

  • Try less at once. If a prompt produces a broken build, undo the turn and break the change into two smaller steps.
  • Be more specific about what's wrong. "The wizard isn't colliding with walls" is more useful than "collision is broken."
  • Hand the agent a smaller scope. "Just focus on the player movement feel โ€” speed, acceleration, deceleration. Don't touch anything else."

What you don't need to say

  • "Please" / "thank you" โ€” the agent doesn't care, doesn't cost less.
  • "Make sure it works." โ€” implied.
  • "Don't break anything else." โ€” say it only if a turn already did and you're calling out the regression.
  • "Add comments to the code." โ€” the runtime is generated, you usually won't read it.

Examples by genre

Top-down adventure

Top-down adventure. Pixel art. Player is a knight with a sword.
Walk with WASD. Press space to swing the sword. There are 5 slimes
on the screen at start; each takes 2 hits to die. When all slimes
are dead, show "Victory!" centered.

Side-scrolling platformer

Side-scrolling platformer in landscape orientation. Player runs
auto-right. Tap/click to jump. Procedurally place small ledges and
gaps. The player dies if they fall off the bottom. Score = distance
traveled, shown top-right.

Match-3 puzzle

Match-3 puzzle on a 6x6 grid. Six gem colors. Swap adjacent gems
with a drag. Three-in-a-row clears and refills from the top.
Score = gems cleared. 60-second timer. Game Over shows final score.

Bullet-hell

Vertical bullet-hell. Player ship at bottom, moves with arrow keys,
fires with space. Three enemy waves: straight-line shooters, sine-
wave dodgers, spiral-pattern shooters. Boss after wave 3. Player has
3 lives.

On this page