AI game assets: what I actually ship, and what I won't touch

2026-10-31 · 6 min read

The first time an AI handed me a game that ran, the code was the least of my problems. A sprite sheet of a knight, a looping synth track, and a background that looked plausible at thumbnail size — and I had no idea whether I was allowed to ship any of it.

That uncertainty is the part nobody demos. Generation is fast now. Deciding what you can legally and practically put in front of players is still slow, still manual, and still your responsibility. This is the working set of rules I've ended up with, plus the places where I genuinely don't know the answer and say so.

The uncomfortable starting point: "AI-generated" is not a license

When a model gives you an image, it gives you pixels. It does not give you a rights statement, and it does not tell you what went into the training set. Anyone who tells you otherwise is either guessing or selling something.

This matters because the thing that gets you in trouble is rarely "someone copies your game." It's a player or a platform asking a simpler question: where did this art come from, and can you show that you had the right to use it? If your answer is "the model made it," you have an answer that sounds evasive even though it's literally true.

I am not a lawyer and this is not legal advice. What follows is how I reduce the surface area of the problem, not a claim that the problem is solved.

My working rule: three buckets

I sort every asset into one of three buckets before it goes into a build.

Bucket 1 — I made it myself. Placeholder art, geometric shapes, generated-but-heavily-redrawn sprites, music I arranged note by note. Boring, slow, and never a problem. If an asset is load-bearing for the game (the player character, the thing you'd put on the store page), it should be here.

Bucket 2 — permissively licensed, with a receipt. Assets where I can point at a specific license file, a specific source, and a specific date I downloaded it. The "receipt" part is the whole point: a LICENSE file in the repo, the source URL in a credits screen, and a note in my asset manifest. If I can't find the receipt within a minute, the asset drops to bucket 3.

Bucket 3 — generated, unverifiable, not shipping. Output that looks great and has a provenance I can't establish. This is where most AI output sits by default, and it's fine — as long as it stays in prototypes.

The failure mode I see most often is bucket 3 assets quietly migrating into a shipped build because they look finished. Look finished is not the same as cleared.

Where generated assets actually work fine

I'm not precious about this. There's a lot of surface area in a small game where nobody cares about provenance and the asset is doing real work:

- Prototyping. Greybox with pretty pictures. The art is there to make playtesting feel like a game instead of a diagram. Nothing leaves the machine.
- Mood and reference. Generating twenty versions of a background to figure out what palette the game wants, then painting the final one myself or commissioning it. The generated images are research, not product.
- Text and UI copy. Item descriptions, flavor text, NPC barks. I rewrite most of it, but the raw output is a decent starting point and the rights question is much less fraught for short functional strings than for a character design.
- Internal tooling. Icons for my own editor, placeholder audio for a build I'm sending to three friends.

What all of these have in common: the asset never becomes the thing I'm selling.

Where I won't use them

Three specific places, because these are the ones that turn into real problems:

The store page and the trailer. This is the asset with the most eyes on it and the highest chance someone recognizes a style. It's also the asset a platform reviewer looks at. If the game has one image that must be defensible, it's this one.

Anything resembling a real person's recognizable work. If a generated character reads as "that artist's style" to me, it will read that way to other people too. I don't ship it. Not because I'm certain it's infringing — I'm not — but because I can't test the claim and the downside is asymmetric.

Music I can't replace. Audio is the worst case for provenance: a melody is short, memorable, and easy to accidentally resemble. For a game I intend to keep online, I use music I arranged, or permissively licensed tracks with a receipt, or nothing. Silent games are underrated.

The boring system that makes this manageable

Rules don't survive contact with a deadline. A file does. I keep an assets/ manifest — a plain text file, one line per asset — with four columns: filename, source (generator / hand-made / URL), license or rights note, and a yes/no on "may ship."

That last column is the one that does the work. When I'm packing a build at midnight, I'm not re-litigating rights questions; I'm reading a column. If an asset says no, the build script refuses to include it. Yes, this is over-engineered for a hobby project. It also takes fifteen minutes to set up and has saved me from shipping twice.

Two habits that cost nothing:

1. Screenshot the generation. Model, date, prompt, output. If a question ever comes up, "here is exactly what I did and when" is a far better position than "I think I made it in the spring."
2. Keep the prompt in the repo next to the asset. Not for rights — for you, six months later, when you need to regenerate a variant and can't remember what you typed.

What I genuinely don't know

I want to be honest about the edges, because most writing on this subject is far more confident than the situation supports:

- whether output from a given model is encumbered in a given jurisdiction is unsettled and moving, and I don't track it closely enough to have an opinion worth repeating;
- whether a platform will ask, and what they'll ask for, varies by platform and by month;
- whether "I edited it substantially" changes anything is a question I've heard confident answers to in both directions, from people who were all guessing.

So the system is designed around not needing answers to those. Ship assets you can explain, keep the ones you can't in prototypes, and you're operating in the region where the answer doesn't decide anything.

The practical version

If you take one thing from this: the asset you cannot explain is the asset that decides whether your game stays up. Generation made it cheap to have a thousand of those. It did not make it cheap to have one in a shipped build.

Spend your manual effort where it pays: the player character, the key art, the music, and anything that reads as someone's recognizable style. Let the model do the prototyping, the reference boards, and the placeholder pass. Keep a one-line manifest with a yes/no column, and let the build script enforce it.

That's the whole system. It's not airtight. It's the difference between "I thought about this" and "I didn't," which is most of what anyone is actually asking.