Game Art Pipeline: Concept to In-Game Asset
Game art production runs through five stages: concept, blockout, production, polish, and integration. This guide maps each stage to a concrete task-board workflow with checklists, review gates, and handoffs, so a 2-8 person crew can run art in the same board as code and design instead of siloed in Discord threads and scattered docs.
What are the main stages of a game art production pipeline?
Most game art moves through five stages: concept, blockout (greybox), production, polish, and integration. Concept produces approved sketches that lock the visual direction. Blockout produces rough geometry that proves scale and silhouette in-engine. Production produces the actual assets: modeled, textured, rigged. Polish produces the final pass, including LODs and VFX. Integration produces the asset living in the build, wired to code and audio.
One GDC talk on production art pipelines describes this same flow from concept through in-game delivery, and the details vary by studio, but the handoffs stay consistent:
| Stage | Input | Output handed to next stage |
|---|---|---|
| Concept | Design brief | Approved sketches, color script |
| Blockout | Sketches | Greybox meshes, scale checks |
| Production | Greybox | Textured, rigged assets |
| Polish | Production assets | LODs, final materials |
| Integration | Final assets | Asset in build, verified |
The failure point for a tiny crew is rarely the stages themselves; it's that each handoff lives in a different tool. A sketch in Discord, a greybox note in a doc, a texture review over voice chat. That split is why teams outgrow a generic board like Trello (we compared the two directly), and why pipeline stages need to map to visible columns, not chat threads.
How does concept art become a final in-game asset?
Trace one asset, like a supply crate, through five stages: concept approval, modeling and texturing, rigging if needed, engine import, and final sign-off. Each stage gets its own task with a checklist, so a tiny crew can see at a glance whether the crate is waiting on approval or ready to drop into the build.
The approval gate that prevents rework
Before anyone models anything, the concept needs a signed-off decision from the studio lead. Put the concept image directly on the task card, list the acceptance criteria (silhouette readable at distance, fits the palette), and mark the task blocked until approval lands. This single gate kills most rework: an artist modeling an unapproved concept is burning hours on guesswork. Once approved, the task moves down the kanban board and the checklist expands into concrete steps: blockout, UVs, bake, texture pass.
Engine import as a task, not an afterthought
The last 10% of an asset, importing, setting up materials, checking draw calls, and verifying it reads correctly in the level, is where assets stall. Make engine import its own checklist item with its own owner, not a footnote on the art task. If the crate breaks the build at 11 PM before a milestone, the task card should show exactly who touched it last and what step they were on. A shared board that holds art, code, and design tasks in one place makes this traceable without digging through Discord; Inferno's pricing keeps that setup affordable for a crew of two to eight.
Which game art roles does a small indie team actually need?
A 2-8 person crew rarely staffs a 2D artist, a 3D artist, an animator, and a technical artist separately. One generalist artist usually covers concept, production art, and animation, with a second person handling code-adjacent art duties. Specialists pay off only when your vertical slice demands heavy character animation or a distinctive style a generalist can't hit.
The technical artist gap on small teams
The technical artist role is the one that quietly disappears on tiny crews, and it's the one that hurts most. Someone has to own import constraints, texture budgets, and poly limits so art survives the trip into the engine; Unity's own asset guidelines spell out the import settings and platform limits that make this a real discipline, not a nice-to-have. On a 3-person team, that's usually your lead programmer wearing a second hat. The honest fix is naming the gap out loud: assign one person to own engine-side art correctness, keep asset checklists on your board so nothing ships with missing LODs or broken rigs, and review art in the same board where code and design tasks live. Inferno is built for exactly that shared workspace, though it won't do the technical artist's judgment for you: the role still needs a named owner, whatever board you use.
How should art tasks be tracked alongside programming and design tasks?
Put art on the same board as code and design, with art-specific columns and checklists, so a missing texture blocks the build task next to it instead of hiding in a Discord thread. A tiny crew cannot afford a second pipeline; visibility across disciplines is the whole point.
One board or a separate art board?
One board. A separate art board recreates the silo you are trying to escape: the programmer who needs the sprite never sees it, and the artist never sees the code task waiting on it. Keep one shared board and mark discipline with labels or swim lanes instead. If your crew runs separate boards today, the tradeoff between shared visibility and art-focused columns is worth thinking through deliberately; we break down how that choice plays out in Inferno vs Codecks.
Sample column layout for a mixed-discipline board
A layout that works for a 2-8 person crew:
- Backlog: everything not started, tagged by discipline
- This milestone: scoped work for the current vertical slice
- In progress: one owner per card, any discipline
- Review: art review, code review, or design sign-off, named in the card
- Done: shipped into the build
The Review column matters most for art. An asset is not done when the artist says so; it is done when it reads correctly in-engine. Make "in the build" an explicit step, not an assumption.
Checklist template for a reusable asset
Give every asset card the same checklist so review is mechanical:
- Brief linked or pasted (references, dimensions, style constraints)
- Draft posted for feedback
- Final approved by art lead
- Imported into engine, correct scale and pivot
- Visible in a build
The last two items are the ones tiny crews skip, and they are the ones that turn "done" art into a Friday-night broken build.
How do you write an art task brief that artists can execute without rework?
A brief that survives contact with a tiny crew has four fields: reference images, dimensions and technical constraints, a style anchor, and a definition of done. Skip any one and you get a second review cycle. When the same brief would be handed to an outside artist, the stakes get higher, since outsourced art work is usually billed per revision round, a common decision criterion discussed in guides to art outsourcing for game studios.
Brief template you can copy
One card per asset, with these fields filled before it enters the backlog:
- Reference: 2-3 links or screenshots showing the look you want, plus one showing what you do not want.
- Constraints: final dimensions, poly budget, texture size, target engine import format.
- Style anchor: a link to the approved concept or style frame this asset must match.
- Definition of done: imported into the build, lighting-checked in-engine, approved by one named reviewer.
Why 'make it look cool' is not a brief
Vague direction forces the artist to guess, and every guess is a coin flip against your mental image. The fix is cheap: paste the reference and the constraint into the card so the intent lives next to the work, not in a Discord thread someone will scroll past. Inferno has no dedicated brief fields, so the simplest setup is to paste the brief into the task description, add the checklist as subtasks, and attach the reference as a doc link. That keeps reference, constraints, and sign-off on the same card as the asset itself.
What causes art bottlenecks in game development and how do you prevent them?
Four causes account for most art delays on a tiny crew: unbounded polish (no definition of "done" on an asset), missing technical constraints (art delivered without poly counts, texture budgets, or rig requirements), review latency (art sits idle waiting on feedback), and scope creep on hero assets (the one character or environment that quietly eats three weeks).
Review latency is the silent killer
An artist who finishes a prop Monday and gets feedback Thursday has lost three days they cannot recover, and on a 2-8 person crew that lost time is a third of your art capacity. Fix it structurally, not by nagging: set a rule that any asset in review gets a response within one business day, and make the review stage an explicit column on your kanban board so waiting work is visible. When the reviewer is you and you're deep in code, batch reviews at a fixed time daily instead of reactively.
Cutting art scope before the milestone, not during
Scope creep rarely announces itself; it shows up as "just one more pass" on the hero character while the backlog of environment props starves. Prevent it by writing the asset checklist with a hard polish ceiling at brief time, and by triaging every art task as milestone-critical or post-ship during sprint planning. If a hero asset is genuinely behind, cut a secondary asset instead of extending the milestone. In Inferno, a per-asset checklist is a subtask list on the card, but it has no formal task dependencies, so note a blocker on the card itself. HacknPlan and Codecks support similar review-stage and backlog workflows, so pick whichever your crew already tolerates.
When should a small team outsource game art versus build it in-house?
Outsource when asset volume spikes past what your artists can clear before the next milestone, when the style is already locked and documented, and when the assets sit outside the core loop. Keep in-house anything the player touches every frame: character movement, combat feedback, the vertical slice. Those assets get revised constantly as code and design shift, and a contractor on a fixed brief will churn every time the loop changes.
What to keep in-house no matter what
Keep player-character animation, core UI, and anything tied to the game feel loop in-house. Game jam postmortems consistently show that art made under time pressure works only when the artist can iterate directly against the build, which is exactly what jam teams do in 48-72 hour sprints (Ludum Dare). Outsource background props, marketing art, and bulk variants where a written brief carries enough information.
How do game jam teams compress the art pipeline into 48-72 hours?
Cut the pipeline to three stages: blockout, final, done. Skip concept art entirely and let the blockout become the final asset if time runs short. A grey-boxed character that ships beats a beautiful one that doesn't.
Set up a jam board with three columns: Ready, In Progress, Done. Every asset card gets a hard time estimate, and anything over two hours gets cut or replaced with a pre-made kit. Pull assets from packs you already own before the jam starts, and keep a list of them on the board so nobody burns an hour searching.
Assign one person as the integration gate: art goes in the build only through them. That prevents the last-six-hours merge mess that kills more jams than bad art ever does.
FAQ
How long does it take to produce game art for an indie game?
A single prop might take a few hours from blockout to in-engine sign-off, while a hero character with rigging and animation can eat several weeks. The biggest variable is the review loop: assets waiting on feedback stall no matter how fast the artist works. Set a hard polish ceiling at brief time and batch reviews daily to keep throughput predictable.
What software do indie artists use for game art?
Most small crews standardize on Blender for modeling, Krita or Photoshop for 2D and textures, and Aseprite for pixel art, then import into Unity or Godot. GIMP covers budgets that rule out Photoshop. Whatever you pick, the pipeline matters more than the tool: keep reference, constraints, and sign-off on the same task card so nothing lives in chat threads.
Can one artist handle all the game art for an indie game?
Yes, if the scope is disciplined. A generalist can cover concept, production art, and animation on a 2-8 person crew, but someone else must own engine-side correctness: import settings, poly limits, texture budgets. That technical artist role is the one that quietly disappears and hurts most, so name an owner even if it's the lead programmer wearing a second hat.
How do I give feedback on game art without hurting my artist?
Anchor feedback to the brief, not taste. Point at the reference and the definition of done on the task card: "the silhouette doesn't read at distance like the concept" lands better than "make it cooler." Respond within one business day so the artist never sits idle, and keep the critique on the card itself, next to the work, where the reasoning stays visible.