AI image generation

umicat can generate art from a description. There is not one generator, though — there are several, each tuned for a different kind of asset, and each lives in the editor that also edits that kind. You pick what you want to make, not which model makes it.

The fastest way in is still chat. Ask for what the game needs and the agent picks the generator, fills in the prompt, and opens the form for you to review:

The player needs a walk animation — a small knight in blue armour, pixel art.

What you can generate, and where

Each editor's landing page has a Generate action; picking a method shows its form inline, and the result opens straight in the editor — no separate results screen to get out of.

Writing a prompt that works

Be concrete about the four things the model cannot guess:

1. Subject — "a small knight", not "a character".
2. View — facing the camera, top-down, side-on. This is the single most common cause of art that doesn't fit the game.
3. Background — say transparent background for anything that goes on top of a scene. Leave it opaque for actual backgrounds.
4. Style — pixel art, hand-painted, flat vector, and roughly how much detail.

A small pixel-art knight in blue armour, facing the camera, idle pose,
transparent background, 32x32.

Keeping a game's art consistent

This is the part that separates a game that looks made from one that looks assembled. Every generator can take an existing asset as a style reference — the forms call it match the style of or start from. Generate one thing you like, then anchor everything else to it.

Generate three more enemies in the same style as slime.png.

The platform helps: once you add your first visual asset from the library, searches are biased toward that style, so what the agent suggests later stays in family.

For a HUD set specifically, pass the first element you generated as the style anchor for the rest — otherwise the buttons and the health bar will quietly belong to two different games.

Animations

Animation is the slowest thing here — minutes, not seconds — because it is a pipeline, not one call. Two routes:

• From a description. You get a fresh character and its frames. Frame count is yours to set (four to sixteen; eight is a clean walk loop). Different from-scratch characters will not match each other's style.
• From a sprite you already have. Give the sprite plus an action (walk, attack, die) and it animates that sprite, keeping its look. This is the one to use for a consistent cast.

The result lands as a spritesheet with its animation tag already set, so the game can play it by name. Refine frame order and timing afterwards in the Spritesheet Editor.

Tilesets

A generated tileset is not just an image — it comes back as sixteen tiles with the autotile rules already wired, so painting it produces correct edges and corners without you touching a bitmask. You describe two terrains and the transition between them:

Grass on top, sand underneath, with a soft crumbling edge between them.

There is a side-scroller mode too, where you describe the platform material and an optional top decoration instead.

Then paint with it — see Tilemaps.

Costs and failures

Every generation costs credits, and they differ a lot: a pixel sprite is cheap, a music track or a full animation is not. You see the exact deduction in Settings → Credit Usage.

When a generation fails, the message says what actually went wrong — a canvas below the minimum size, a style reference that could not be used, a provider that is down. Read it rather than retrying blind; roughly half of these are one edit to the form.

Next steps