GUIDE

What is an AI sprite sheet generator?

An AI sprite sheet generator turns a character image plus a described action into a strip of aligned animation frames you can load in an engine. PX-Art does this by generating a short clip from your base sprite, decoding every frame, sampling by delivery semantics, keying out the background, and packing the result onto one baseline and one scale. You export PNG, GIF and Aseprite-format JSON.

The part that is not image generation

A general image model can draw a running character. It cannot, on its own, draw the same character eight times in a row with the same silhouette, the same palette, the same camera and the same ground contact — and then hand you those eight images trimmed to a shared bounding box. That alignment work is what separates a sprite sheet generator from an image generator.

A usable sprite sheet needs four properties that are easy to state and hard to get:

• Frame coherence. Frame 3 has to be the same character as frame 0, not a lookalike.
• A fixed camera. If the virtual camera drifts, the sprite appears to slide even when the character is standing still.
• A clean alpha edge. Backgrounds must come off without eating the character's outline.
• One baseline and one scale for the whole sequence. Otherwise the character bobs when the animation loops.

How PX-Art builds the strip

You give it a character base image (optionally with reference images), an action, a facing direction, a frame count, and whether the action loops. The backend then runs a fixed pipeline:

1. Take the base image. For a non-front facing, first produce a turned base — a single standing image of that character at the target viewing angle — so the held hand and the near/far limbs are settled before any motion exists.
2. Composite that base onto a key-color canvas.
3. Run image-to-video to get a two-second clip with a locked camera.
4. Decode every frame of the clip with ffmpeg.
5. Sample frames by delivery semantics: a looping action is sampled over [first, last) so the loop does not stutter on a duplicated pose; a one-shot action keeps its real first and last frames.
6. Key out the background, then compute the union bounding box across the whole sequence and trim to that — so intentional displacement inside the animation survives instead of being cropped away frame by frame.
7. Lay the frames into a strip with a shared scale and a shared baseline, apply palette post-processing, then run quality checks for facing drift, frame-to-frame coherence and ground contact before anything is stored.

A denser frame set (capped at 30 frames) is kept alongside the delivered strip. If you delete frames on the results bench, replacements are pulled from real decoded frames — and the replacements inherit the same scale and baseline as the surviving frames, so the strip does not need to be rebuilt.

Generating one, step by step

1. Create a game projectAssets live inside a game, not in a flat folder. The game fixes the art style (a style key plus tags); color scheme is chosen per generation. Modules are fixed: characters, actions, effects, UI design, cards & icons, map.
2. Make the character base firstGenerate the character in the character module. This base image is the anchor for everything else: three-view sprites, portrait, avatar and battle sprite all trace back to it.
3. Pick action, facing and frame countTen common actions are offered directly; anything else is described in your own words and matched to an internal choreography profile. Five facings are generated (south, north, east, south-east, north-east) and the remaining three (west, south-west, north-west) are produced by mirroring.
4. Decide loop or one-shotThis changes frame sampling, not just playback. A walk cycle and a death animation are sampled differently on purpose.
5. Review on the results benchStep through frames, delete bad ones, redo the whole take, or do a local repair on a single frame.
6. ExportSprite sheet PNG, GIF, an Aseprite-format packing, or a plain ZIP with images and a manifest.

What the export actually contains

A character export ZIP is prefixed with the character name so several characters can be unpacked side by side:

hero-sprite-sheet.png      # the atlas
hero-sprite-sheet.json     # Aseprite-format atlas JSON
hero-manifest.json         # PX-Art manifest (animations, pivots, trims)
frames/idle/hero-frame-00.png
frames/idle/hero-frame-01.png
gif/hero-idle.gif
apng/hero-idle.png

The Aseprite-format JSON is the one most engine-side importers already understand. Each frame carries real trim metadata, each action becomes a frame tag, and each action also gets a slice whose pivot is the foot anchor:

{
  "frames": [
    { "filename": "idle 0",
      "frame": { "x": 4, "y": 6, "w": 40, "h": 52 },
      "trimmed": true,
      "spriteSourceSize": { "x": 12, "y": 8, "w": 40, "h": 52 },
      "sourceSize": { "w": 64, "h": 64 },
      "duration": 125 }
  ],
  "meta": {
    "app": "px-art",
    "image": "hero-sprite-sheet.png",
    "format": "RGBA8888",
    "frameTags": [ { "name": "idle", "from": 0, "to": 7, "direction": "forward" } ],
    "slices": [ { "name": "idle",
                  "keys": [ { "frame": 0, "pivot": { "x": 32, "y": 60 } } ] } ]
  }
}

sourceSize is the original cell, spriteSourceSize is where the trimmed content sat inside that cell, and duration is milliseconds per frame. Together they let an importer place a trimmed sprite exactly where the untrimmed one would have been — which is why the character does not jump when you switch from idle to walk.

How the character stays the same character

Palette lock

A shared palette is extracted from the character base and reused across every action of that character, so colors do not shift when the game switches states.

Body-size profile plus proportion references

Each character is assigned a body-size profile — small, normal, tall or giant — and normalized against proportion reference images (a horizon line and a head-top line). Within one game, characters end up on a consistent scale instead of drifting per generation.

Cached turned bases

The turned base for a given character and facing is cached, so every later frame in that direction is anchored to the same settled pose rather than re-deciding which hand holds the weapon.

Limits and caveats

• Generation is probabilistic. Results are not guaranteed to match your description. Check assets yourself before shipping them.
• The video stage depends on model compliance. The pipeline needs the model to respect the key-color background and the locked camera. When it does not, the request fails and asks you to regenerate — it does not hand you broken frames.
• Ten actions are exposed directly. Everything else routes through a free-text description matched to an internal choreography profile, so unusual actions vary more.
• Rights are your responsibility. Legitimately generated assets can be used commercially, but you still need to check third-party rights, applicable law, and the terms of the AI providers involved. AI output is not guaranteed to be exclusive to you, and is not guaranteed to be copyrightable.
• Prompt engineering stays server-side. The final assembled prompt is never returned to you.
• Engine support is deliberately narrow. There is a thin adapter on the Godot side; the Aseprite-format JSON and plain PNG/GIF exports are engine-agnostic interchange. Anything beyond that is integration you write yourself.

Full behaviour of the generator, including facing coverage and the results bench, is on the sprite sheet generator page; the animation pipeline in more depth is on pixel art animation.

FAQ

Related