# AI Generated pixel art needs a build system, not better prompts

> Source: <https://dev.to/nonatofabio_28/ai-generated-pixel-art-needs-a-build-system-not-better-prompts-280c>
> Published: 2026-09-07 14:37:48+00:00

I rebuilt my tiny homage to Warhammer 40k this week. The original, Hive City Rampage, was a Python/Pygame (monstrocity), top-down grimdark shooter that ran but was a prototype. Now we have a sequel, Ashgate Siege, is Godot 4: gothic isometric, two missions, built for Mac and Android.

I have a confession though, the 95k lines of GDScript, 8 commits, roughly five hours was written by an AI agent under my direction. The sprites are generated too. I'm disclaiming that up front because the interesting part is what came out of it.

This is the simple finding. An engine port is exactly the shape of coding my agents were very good at: the target is well documented, the semantics known, and correctness is checkable by running the thing. Godot 4 plus GDScript is heavily represented in training data for any model. Zero agent struggle.

Here's the hill I'm whiling to die on: **for AI-assisted games, 2D sprite games are harder than 3D.**

That sounds backwards, so: in 3D, the engine guarantees coherence. One mesh, one material, one light rig, and every frame of animation is consistent because it's the same object being transformed. The renderer is doing the work.

In sprite based games there is no shared object. Each sprite is an independent generated map of pixels. So:

None of that is caught by anything automatically. It just ships, and the game looks odd, like a badly executed collage.

The fix was to stop treating generation as commissioning art and start treating it as calling an API with a strict schema. Every prompt pins the geometry:

```
Production game sprite sheet: exactly 4 columns x 3 rows, 1536x1024 canvas, equal cells, solid pure magenta #FF00FF background for color-key import. NO text, shadows, smoke, or border. Every figure entirely within its own cell with ample margin; feet centered at same baseline in each row. All figures face screen RIGHT in three-quarter isometric view [...] Four columns are four coherent walking-cycle poses: left foot forward, passing, right foot forward, passing.
```

Each sentence has to do some work:

`#FF00FF`, not transparency.
If the prompt is a spec, something has to enforce it. Generated atlases go into `art/`, an importer crops and scales them into runtime assets, and a native test suite checks the result: 2,972 reference and combat assertions, 17,112 silhouette combinations, plus a 600-frame combat simulation. `make test` runs it.

Silhouette checks are the super important. A regenerated atlas that's subtly wrong (a pose 8px taller, a gun scaled differently between frames) passes every functional test and looks broken in motion. Comparing silhouettes against frozen baselines should catch most of it.

The way this can generalize: **if AI generation is nondeterministic, everything downstream has to be strict.** The prompt is a spec that gets compiled by the importer, and CI runs with silhouette tests. Without that you don't have a pipeline, at bess it is a slot machine

you need to keep pulling until the art looks okay.

Mac and Android builds are on GitHub Releases. They're previews: macOS is ad-hoc signed and not notarized, Android uses a debug key, so both will warn you. Source builds with `make run` if you have Godot 4.3.
