Pixelata

At a glance

• Outcome: A generated concept sheet was rejected on a stated project rule before any pack was built from it. The revision that replaced it became four human-accepted 32×32 sprites, an atlas that reproduced identical hashes on a second packaging run, and four Godot AtlasTexture resources that imported under Godot 4.6.3.
• Status: In development. Two real projects have records in the repository. One derives all seven Production Path stages as complete, ending at deterministic processing and QA. The other has the accepted sprites and verified engine import above. Review signoff and delivery authorization are implemented, but no project has crossed them yet.
• Role: Solo.
• Stack & libraries: Python toolkit with a CLI, an optional FastAPI + HTMX local workspace, an MCP server, Pillow-based deterministic image processing, and engine handoff bundles for Macroquad and Godot.
• Source: Private while the product takes shape.
• Limitations: Two projects, neither of which has crossed review signoff or delivery authorization. The one pack that reached a verified Godot import was packaged by a purpose-built script rather than by the product’s own processing kernel. Shortlisting still writes a selection field back onto the completed generation run, which the architecture notes flag as legacy. Canvas workspace layout is planned rather than built.

The problem it’s for

Small teams and solo developers can generate pixel art easily now. What they can’t do easily is get art that’s coherent: a hundred assets that look like they came from the same world, at the right resolution, in the states the engine needs.

But coherence is the symptom. The mechanism is cheaper rejection: kill a weak direction before the team spends a week generating and cleaning a sheet built on it. Generating one attractive image stopped being the hard part. Deciding what the game actually needs, whether a direction survives at native resolution, and when there’s enough evidence to commit to a full pack. That’s the part that still costs real time.

Pixelata is deliberately not a sprite editor and not a prompt-to-sheet generator. It’s the process around those.

The inversion

The organizing object is a visual direction, not a generation run. That’s the decision the whole system hangs on.

A generation run produces images, so it’s the obvious thing to build the product around, and building around it means the next action is always generate more.

Work advances instead through bounded experiments, each of which has to state its question, the evidence it wants, and what would count as failure. Generation is one method inside an experiment, alongside manual import, an external editor, native-pixel cleanup, benchmark comparison, and runtime preview.

Because the direction owns the evidence, the system can name which evidence is missing rather than offering another batch.

The loop

Discover → Explore → Prove → Produce → Deliver.

• Discover: collect what the project actually requires: runtime constraints, pack needs, open questions, visual risks.
• Explore: compare competing visual directions and run small experiments designed to answer one specific question each.
• Prove: promote candidates into representative prototypes and test them at native scale: states, animation, tiles, coherence.
• Produce: lock a direction, confirm the spec, run deterministic processing and QA.
• Deliver: human review, then reproducible export of accepted assets and engine handoffs.

The part I’d defend

Human authority isn’t one gate. It’s seven separate records, and each refuses to stand in for the next.

Confirming a prototype doesn’t lock a direction. Locking a direction doesn’t confirm the Visual Spec. Confirming the spec doesn’t authorize production. Authorizing production doesn’t accept the resulting art. Accepting art doesn’t sign off the review, and signing off doesn’t authorize delivery.

The prerequisites are enforced where the records are written, not in the interface. A direction lock rejects a non-human actor and requires a prototype set with enough coverage behind it. QA passing grants none of them.

Everything the system shows is rebuilt from stored artifacts, so no view holds workflow truth of its own. That means a decision can always be traced to what it was made on, and QA passing never silently implies a human accepted the work. Export is bound to reviewed pixels by SHA-256 lineage, so a pack can’t quietly ship bytes nobody looked at.