GUIDE

How do you keep AI-generated characters consistent?

Consistency comes from constraints, not from better prompt wording. PX-Art locks three things per character: a shared palette extracted from the base sprite so every action reuses the same colors, a body-size tier plus a proportion reference image that normalizes scale across a game project, and a cached turnaround still that anchors each non-front facing before any frames are generated.

Why re-prompting alone does not hold a character together

A text-to-image model resamples everything on every call. Ask it twice for the same character and you get two characters: the belt buckle moves, the hair darkens by a few shades, the sword swaps hands when the view turns. Adding "same character, consistent style" to the prompt does not fix this, because nothing in the request is actually pinned to the previous output.

The fix is to remove degrees of freedom before generation, and to reuse an already approved image as the anchor for the next one. PX-Art does that in three places.

The three mechanisms PX-Art uses

1. Palette lock, per character

A shared palette is extracted from the character's base sprite. Every subsequent action for that character reuses that same set of colors, so armor tone and skin tone do not drift when you switch from idle to run to hurt. Color drift is the failure mode players notice first, because it shows up as flicker the moment two states alternate in game.

Style is pinned one level higher: a style key plus tags are set on the game project, not on the individual generation, so every module (characters, actions, effects, UI, cards and icons, map) inherits the same look. Color choice is made per generation inside that style.

2. Body-size tier plus proportion reference

Each character is assigned a body-size tier — small, normal, tall or giant — and generation is normalized against a proportion reference image carrying a horizon line and a head-top line. That normalization is deterministic, not a judgment call the model makes per image, so two characters in the same tier stand at the same height and two characters in different tiers stay in a fixed relationship. Without this, characters generated weeks apart do not share a scale and every sprite needs manual rescaling before it can share a scene.

3. Cached turnaround stills for non-front facings

PX-Art supports eight facings. Five are generated — south, north, east, south-east, north-east — and west, south-west and north-west are produced by mirroring their counterparts, so left and right can never disagree about design details.

For each generated non-front facing, the pipeline first produces a single standing turnaround still: the front base sprite rotated to that viewpoint, nothing else. Every animation frame for that facing is then anchored to that still. Which hand holds the weapon, which arm is the near arm and which is the far arm — these become settled facts before frame generation starts, instead of being re-decided per frame. The still is cached per character and facing, so the second and third animation in the same direction start from the identical anchor.

Step by step

1. Create the game project first, then the characterSet the game's style key and tags before generating anything. Characters, actions, effects, UI and map assets generated later inherit it, which is what keeps a whole project coherent rather than just one character.
2. Generate and approve one base spriteThis image is the source of the locked palette and the input to every turnaround still. Spend the iterations here — a static image costs 5 credits — and do not move on until the design is final.
3. Set the body-size tierPick small, normal, tall or giant. This is what the proportion reference normalizes against, so a character you add three weeks later still lines up with the first one.
4. Generate the front-facing actions firstFeed the approved base sprite, the action, the facing, the frame count and whether the action loops. Looping actions are sampled from the first frame up to but excluding the last, so the loop does not stutter on a duplicated pose; one-shot actions keep their true first and last frames.
5. Add non-front facings and let the turnaround still cacheThe first action in a new direction pays for the turnaround still; later actions in that direction reuse it, which is also why they hold together with the first one.
6. Fix individual frames instead of rerunning the actionThe result bench lets you preview frame by frame, delete frames, redo the whole sequence, or repair one frame locally (2 credits per local edit). A dense frame set of up to 30 frames is kept, so a deleted frame can be refilled with a real generated frame that shares the surviving frames' scale and baseline — not an interpolated fake.

A worked example

One character, four actions, three facings. What is fixed and what is chosen per call:

game        harbor-town          style key + tags  (set once, project-wide)
character   dockhand
  base      dockhand_base.png    approved front sprite -> palette source
  tier      normal               small | normal | tall | giant
  palette   locked from base     reused by every action below

  facings   south north east south-east north-east   generated
            west south-west north-west               mirrored

  turnaround stills (cached per character + facing)
            turn_east.png        anchors every east-facing frame
            turn_north.png       anchors every north-facing frame

  actions   idle    4 frames  loop      sampled [first, last)
            walk    8 frames  loop      sampled [first, last)
            attack  6 frames  one-shot  true first and last kept
            hurt    3 frames  one-shot

After export and unzip, a workable project layout — the names are yours to choose, except manifest.pxart, which is the JSON entry file inside the package:

assets/dockhand/
  dockhand_base.png
  walk_south_8f.png      8-frame strip, uniform scale and baseline
  walk_east_8f.png
  walk_west_8f.png       mirrored counterpart of walk_east
  attack_south_6f.png
  manifest.pxart         JSON entry file listing what is in the package

Because the whole sequence is cropped against one union bounding box, every strip for this character shares a baseline. That is what lets you swap walk_south_8f.png for attack_south_6f.png on the same node without the sprite jumping vertically. The same property is what makes the sprite sheet generator output importable without per-frame nudging, and it carries through to Aseprite and Godot.

Limits and caveats

• Generation is probabilistic. These mechanisms remove the largest sources of drift; they do not guarantee the result matches your description. Review every asset before it ships.
• The video-based action pipeline depends on the model obeying a key-color background and a fixed camera. When it does not, the run fails and asks for regeneration rather than delivering broken frames — that is deliberate, but it means a retry sometimes costs another attempt.
• Ten common actions are exposed as direct entries. Anything else is described in free text and matched to an internal choreography profile, so an unusual action lands on the closest profile rather than on a bespoke one.
• The final assembled prompt sent to the model is internal and is never returned to the user interface or the API. You control inputs — base sprite, reference images, action, facing, frame count, loop flag — not the prompt text.
• Legally generated assets can be used in commercial projects, but you still need to check third-party rights, applicable law and the restrictions of the AI providers involved. AI output is not guaranteed to be exclusive to you or to be registrable for copyright.
• Checkout is still under review and not open yet. New accounts start with 20 credits.

FAQ

Related