AI Game Art Is Not Engine-Ready Until You Define the Asset Contract

An AI image can look finished and still be unusable in a game.

The failure usually is not visual quality. It is the missing agreement between art generation and the engine: dimensions, pivots, camera, stretch behavior, naming, frame cadence, and acceptance tests.

That agreement is the asset contract.

An asset contract is a small, explicit specification that says what the engine expects before anyone generates or draws the asset. It turns "make a fantasy panel" into "make a panel whose corners never deform, whose center can stretch, and whose text remains inside a known safe area."

This matters even more with generative tools. They can produce many plausible images quickly, which makes it easy to postpone technical decisions. Then the team discovers that the outputs cannot share a prefab, animation controller, atlas, or UI layout.

Here is how I define the contract for five common 2D asset families.

1. UI: define the 9-slice behavior before the decoration

A menu panel is not just a rectangle with an ornate border. It is a resizable component.

Before generating it, specify:

• the native canvas size;
• the left, right, top, and bottom cap widths;
• which center regions may stretch or tile;
• the text and icon safe area;
• the smallest and largest intended aspect ratios;
• required states such as default, hover, pressed, disabled, and selected;
• whether corners and edge ornaments may overlap adjacent UI.

The fastest acceptance test is to apply the 9-slice settings in the engine and render the panel at three deliberately awkward sizes: tall, wide, and close to the minimum. Corners should retain their shape, edge motifs should not become rubbery, and the center should not reveal seams.

If the panel only works at the dimensions of the concept image, it is a mockup, not a component.

This AI game UI workflow shows the FrameSprite approach to generating around those implementation constraints.

2. Icons: review at runtime size, not presentation size

A 1024-pixel icon preview can hide every problem that matters in play.

The contract should name the real display sizes: perhaps 16, 24, 32, and 64 pixels. It should also lock:

• silhouette complexity;
• outer padding and alpha bounds;
• background treatment;
• stroke weight;
• palette and contrast range;
• lighting direction;
• rarity or state markers;
• atlas cell size and naming.

Review the icon set at 100% scale against the lightest and darkest surfaces in the actual UI. If the object class is not recognizable in a quick glance, extra detail will not save it.

Consistency across a set matters more than isolated polish. A sword, potion, key, and quest item should look as though the same visual system produced them.

The practical examples in this game icon generation guide focus on building that system rather than chasing one impressive image.

3. Eight-direction characters: directions are animation data

"Generate eight views" is underspecified.

First define the camera elevation and the canonical direction order. For example:

S, SW, W, NW, N, NE, E, SE

Then define the contract shared by every direction:

• identical canvas dimensions;
• a fixed feet pivot;
• stable character scale and bounding box;
• the same number of frames per action;
• matching contact, passing, recoil, and recovery beats;
• rules for handedness and asymmetric equipment;
• direction and action naming conventions.

The feet pivot is especially important. When it drifts between directions, the character appears to slide or jump during turns even if each frame looks good alone.

Test the full directional set in a simple controller before producing every action. Walk a circle, change direction rapidly, and overlay the pivot. This exposes scale drift, camera drift, and inconsistent timing early.

Our eight-direction character sprite guide goes deeper on keeping identity and structure stable across the complete directional set.

4. True top-down characters: 90 degrees is a production choice

"Top-down" often gets interpreted as a high three-quarter view. That may look more expressive, but it is not the same camera.

A true 90-degree overhead character changes which planes are visible, how the head overlaps the torso, how weapons point, and how the sprite communicates facing. The contract should explicitly state:

• camera pitch: 90 degrees overhead;
• no visible horizon and no three-quarter facial view;
• character center and ground-contact convention;
• allowed shadow shape;
• facing cues for head, shoulders, weapon, and feet;
• rules for tall hats, backpacks, capes, and long weapons;
• collision footprint versus visual footprint.

Place the sprite on a checkerboard map with props and narrow passages. If it appears to lean toward the camera or exposes too much of the front plane, the camera has drifted back toward three-quarter.

A true top-down sprite workflow is useful when the project needs overhead readability rather than an isometric-looking compromise.

5. Portraits: derive identity from the full-body master

Generating a portrait and a full-body character independently often creates two believable people who are not quite the same person.

Treat the approved full-body design as the identity master. Extract a short list of invariants:

• face shape and skin tone;
• hair silhouette and color;
• headgear construction;
• distinctive marks;
• costume neckline and shoulder details;
• core palette;
• age, expression range, and rendering style.

The portrait contract then defines crop, head angle, eye line, lighting, background, expression variants, and output sizes. It should also say which costume details must remain visible to preserve recognition.

Compare portrait and full-body views side by side at their real UI sizes. Do not accept a portrait just because it is attractive; accept it when players can reliably connect it to the in-world character.

This portrait-from-full-body workflow demonstrates the reference-first method we use.

A compact contract template

Before generating an asset family, write down:

1. Runtime role — where and how the asset appears.
2. Output geometry — canvas, cell, crop, padding, and alpha rules.
3. View rules — camera, direction, pose, lighting, and scale.
4. Engine behavior — pivot, stretch zones, animation timing, and collision relationship.
5. Set consistency — palette, line weight, naming, and variant rules.
6. Acceptance tests — the exact engine scenes and sizes used for review.

This can fit on one page. The important part is that it exists before the first batch is generated.

Generation is the middle of the pipeline

A reliable workflow looks like this:

contract -> reference/master -> generation -> normalization -> engine import -> acceptance test

Prompting is only one step. Normalization and engine validation are what turn images into assets.

If a generated image fails the contract, regenerate or repair it before it enters the content library. Do not let exceptions accumulate inside prefabs and controller code. Technical debt in art pipelines is still technical debt.

Disclosure: I work on FrameSprite. The five links above point to FrameSprite guides. I included them because they document the concrete workflows behind these contract examples, not as neutral third-party recommendations.