At a big studio, "asset pipeline" means a build system, a technical artist who owns it, and a set of tools nobody outside the team ever sees. At one to three people, it means something much less grand and much more urgent: the sequence of steps between "a thing exists in a design file" and "the thing is in the build, at the right size, with the right name."
You already have a pipeline. It's just undocumented, lives in your head, and takes four hours every time you need to regenerate icons. Writing it down is most of the work.
The rule: anything you do twice gets written down
Not automated — written down. Automation is the second step and it's optional. A five-line text file that says exactly how the app icon gets exported is worth more than a half-finished script, because the text file still works when you come back in eight months having forgotten everything.
Keep one file, in the repo, called something obvious. Every recurring asset task gets a short entry: what the source is, what command or steps produce the output, where the output goes. When a task's entry gets long or tedious enough to annoy you, that's the signal to automate that one — not before.
One source of truth per asset, and it isn't the export
The most expensive habit in small-studio art production is losing the source. Someone exports a PNG, tweaks the PNG, and now the design file and the shipped asset disagree. Six months later you need the same icon at a new size and the source no longer matches what's in the game.
The discipline:
- Sources live in the repo (or in a folder that is backed up and versioned alongside it) — not only in a cloud design tool, and not only on one machine.
- Exports are treated as build output. If you can't regenerate every shipped asset from sources in one pass, you don't have a pipeline, you have a folder.
- Never edit an export. If the export is wrong, the source is wrong.
Vector wherever possible. An icon authored as vector survives every future device resolution; an icon authored as a 512px raster does not.
Naming is the cheapest engineering you'll ever do
Pick a convention on day one and never deviate. Something like
category_subject_variant_state — ui_button_primary_pressed,
tile_color_teal_selected. Lowercase, underscores, no spaces, no capitals,
no version numbers in filenames.
Three things this buys you: assets sort into meaningful groups in any file browser, you can find everything related to one feature with a single search, and — the one people underestimate — you can write scripts against them. A consistent naming scheme is the precondition for every automation you'll ever want.
Corollary: no final, final_v2, or final_real.
That's what version control is for, and if the asset isn't in version control, fix that
before you fix anything else here.
Automate the multiplications
The tasks worth scripting are the ones where one source becomes many outputs. For a mobile game that's usually:
- App icons. One master image, a dozen-plus required sizes. This is a solved problem — there are command-line tools and asset catalog generators for it, and doing it by hand is indefensible after the first time.
- Resolution variants. @1x/@2x/@3x sets from a single vector or high-resolution source.
- Sprite atlases. Packed automatically at build time, never assembled by hand.
- Audio conversion. One master WAV per sound, converted to your shipping format with consistent settings and loudness.
- Store screenshots. The big one — see below.
A shell script that runs all of these in sequence, checked into the repo, is a couple of hours of work and pays for itself before the second release.
Store screenshots deserve their own paragraph
Screenshots are the highest-leverage art in your entire project — they're what most people see before deciding — and they're also the asset most likely to be produced by hand in a panic the night before submission, across multiple required device sizes, in every locale you support.
The pipeline worth building: capture raw frames from a simulator or device automatically, then composite them into framed, captioned templates programmatically. Once that exists, a copy change or a new locale is a five-minute rerun instead of an evening. There are established tools for both halves of this, and for a studio that ships more than once a year it's the highest-return automation available.
Keep the repo honest about binaries
Large binary sources — layered design files, uncompressed audio, video — will bloat a normal Git repository fast, because every version is stored in full. Two workable answers: use large-file storage for binary types, or keep sources in a separate, backed-up, clearly-referenced location and keep only exports in the repo.
What doesn't work is the third option everyone actually picks: sources scattered across a desktop, a Downloads folder and one cloud drive, with no record of which is current. The failure mode isn't a slow repo, it's an asset you can never regenerate.
Working with contractors
The moment you hire an illustrator or a sound designer, your pipeline becomes an interface, and it needs to be documented for someone who has never seen your project.
A short delivery spec, sent up front, prevents nearly all rework: required formats, exact dimensions or vector requirement, colour space, background transparency, naming convention, and what "source files included" means. Say explicitly that you want the editable source, not just the export — this is the single most common gap, and it's much easier to negotiate before the work than after.
For audio specifically: ask for the stems and a loudness-normalised master, and state the loop points you need. Getting a music track back that can't loop cleanly is a week's delay for a two-minute fix on their end.
The version to build first
If you're starting from nothing today, the minimum useful pipeline is four things:
- A naming convention, written down and followed.
- Sources in version control, exports regenerable from them.
- One script that produces all icons and resolution variants.
- A text file documenting every manual step you haven't scripted yet.
That's an afternoon. It removes the specific category of late-night work where you're exporting PNGs by hand at 1am with a submission deadline, which is where small studios lose both time and quality at once.