The Video Game Development Pipeline for Tiny Crews
A video game development pipeline is the sequence your game moves through, from concept to pre-production, production, testing, and release, with each stage producing specific artifacts your next stage consumes. For a tiny crew, the pipeline lives or dies on how well handoffs between Design, Art, Code, and Audio survive real schedules.
What is a pipeline in game development?
A pipeline is the repeatable sequence your game moves through: concept, pre-production, production, testing, release. Each stage produces defined artifacts (a vertical slice, a locked design doc, a shippable build) and hands them to the next stage with clear ownership. That's the whole definition. Everything else is detail.
Big studios need pipelines because hundreds of people must coordinate. A tiny crew needs one more, not less, because with 2-8 people there's no producer to catch what falls between disciplines. When an art handoff breaks on a small team, the programmer who receives a broken file often has no idea who to ask, and GDC postmortem talks are full of small teams describing exactly this failure mode.
Scattered tools make the problem worse: your backlog lives in Trello, decisions live in Discord, and nobody can trace why a milestone slipped. We compare the two approaches in Inferno vs Trello, and the rest of this walkthrough maps each stage to the artifacts and handoffs that keep a small pipeline moving.
What are the stages of an indie game development pipeline?
Concept: the one-page pitch
Concept produces a single artifact: a one-page pitch. Genre, core loop, target platform, rough scope, and why your tiny crew is the right team to build it. If it takes more than a page, the idea isn't pinned down yet. This document is what you'll return to every time scope creep whispers during production.
Pre-production: the vertical slice
Pre-production exists to answer one question: is this game worth making, and can we make it? The artifact is the vertical slice, a small playable section with art, code, and audio at final quality. A slice forces every discipline to run its pipeline once end to end, which surfaces the handoff problems early instead of during production. Many indie teams skip this stage and pay for it later, discovering in month six that their art pipeline and their build process don't fit together. See what a vertical slice is for how to scope one.
Production: milestones and the backlog
Production is the longest stage, and the artifact is a sequence of milestone builds, each dated and scoped in advance. Between milestones, work lives in a backlog ordered by priority, and a kanban board shows what's in flight across disciplines. The discipline that matters here is simple: every milestone build must actually run, and every change should trace back to a backlog item so nobody is excavating Slack threads on Monday morning to figure out why a system changed. A shared workspace where the design doc sits next to the board removes most of that archaeology; tools like Codecks and HacknPlan are built around this idea, and we compare how Inferno stacks up against Codecks. Where Inferno falls short of some rivals: it's built specifically for game teams, so if your studio also does client work, you may want a more general board.
Testing and release
Testing turns milestone builds into a stable candidate, with the artifact being a written bug list ranked by severity. Release then runs against a ship checklist: store page assets, builds for each platform, trailer, and a rollback plan. If the checklist isn't written down before release week, you'll discover half of it at 11 PM on a Friday.
How does the game art production pipeline actually flow?
Art moves through four gates: concept, blockout, final asset, integration. Each gate has a deliverable and an acceptance check, so nobody paints a hero texture for a prop that gets cut.
| Stage | Deliverable | Acceptance criteria |
|---|---|---|
| Concept | Sketch or paintover | Lead approves silhouette and palette |
| Blockout | Greybox mesh in-engine | Reads at gameplay distance, fits collision bounds |
| Final asset | Textured, rigged asset | Poly budget and texture size met |
| Integration | Asset in a build | No import warnings, correct scale and pivot |
Concept to blockout
The deliverable is a drawing, but the real output is a decision: silhouette, palette, and rough scale. Blockout turns that into a greybox mesh placed in the level, so the team tests whether it reads at actual gameplay distance before anyone spends polish hours.
Blockout to final asset
Only after the blockout survives a playtest does the artist produce the final mesh, textures, and rig. This is where scope creep hides; a written poly and texture budget per asset class keeps it in check.
Final asset to integration
Integration is where naming and import settings matter. Unity's own docs on asset import settings and naming conventions (Unity Manual) are worth reading as a team before you set conventions, not after three artists guess differently. Tracking which assets are blocked at each gate is what a board built for game teams handles; we compare how Inferno and HacknPlan approach that in Inferno vs HacknPlan.
Where do asset handoffs break in a tiny crew?
Four failure points account for most handoff pain on a small team: inconsistent naming, engine import settings, mismatched definitions of "done," and feedback scattered across Discord threads.
Naming and folder conventions
Art names a sprite hero_idle_v3_final_FINAL, code references hero_idle_02, and the build breaks at import. Fix it with a written convention, one shared folder structure, and a rule that no file enters the pipeline without a matching backlog entry. A shared workspace like Inferno makes that entry the single handoff point.
Import settings and rework loops
An asset that looks correct on an artist's machine can arrive with wrong pivot points, scale, or compression, forcing a coder into a rework loop neither discipline budgeted for. Catch this by making the importer's requirements part of the handoff: a short checklist attached to the task, agreed once during pre-production, not rediscovered every milestone.
Defining 'done' per discipline
"Done" means something different to an artist (rendered), a coder (merged and building), and audio (mixed). Write down what done means per discipline and put it on the task itself. Otherwise Friday-night builds ship "fixed stuff" commits and Monday becomes archaeology.
How should you structure handoffs so they survive a 2-8 person team?
A handoff survives when the task card carries everything the next discipline needs. Every card should contain: the goal in one sentence, the asset or system it touches, acceptance criteria, dependencies, and a build or branch reference. Game Developer's coverage of indie production stages argues that unclear stage boundaries, not lack of talent, are what stall small teams.
Define done per asset type: art is done when it's imported, named to convention, and visible in-engine; code is done when the build passes and the card links the commit; audio is done when it's hooked and mixed. Review happens where the work lives, not in a separate meeting.
If your current board can't hold acceptance criteria and commit links on one card, that's the gap to close. Inferno is free for tiny crews (see the pricing page), though any board you already trust can carry this template.
What tooling does each pipeline stage need?
Four tool categories cover the whole video game development pipeline: a doc home for design notes, a task board for the backlog and milestones, version control for the build, and a place where asset handoffs actually land. Concept and pre-production lean hardest on docs and the board; production adds build checks and asset reviews; testing and release are mostly board hygiene plus a working build pipeline.
Generalist boards like Trello handle a flat backlog fine, but they have no concept of discipline, milestone, or asset status, so art, code, and audio work all blur into one column of cards. Game-specific boards fix that: HacknPlan models disciplines and milestones directly, Codecks treats task management like chat so distributed tiny crews stay in sync, and Projects.ink focuses on narrative-heavy planning.
Honest check on us: Inferno pulls docs, board, and handoffs into one workspace, which is exactly what a 2-8 person crew wants. What it does not do is replace your version control or build system, so you still own that glue.
How do you run the pipeline during a game jam?
A jam compresses the video game development pipeline to 48-72 hours, so you cut stages rather than rush them. Skip pre-production docs entirely; a one-page design note and a rough loop diagram are enough. Go blockout-first on art: greybox every asset, then polish only what the core loop actually touches. Audio joins after the first playable build, not alongside it.
The discipline that survives is integration checkpoints. Merge and build every 6 hours, and treat a broken build as the whole crew's problem, not one programmer's. Teams who postmortem their jams consistently report that scope discipline and frequent integration, not speed, decide whether they ship; the Global Game Jam site collects postmortems and jam resources worth reading before your next event.
Anything that fails two checkpoints in a row gets cut from the vertical slice.
How do you keep scope creep from breaking your pipeline?
Treat your vertical slice as the scope contract. Every idea that shows up mid-production gets measured against it: does this make the slice better, or is it a new feature wearing a costume? If it's the latter, it goes to a parking lot board, not the backlog.
Groom the backlog at each milestone, not weekly. Between milestones, new work waits. At the milestone, you cut lines ruthlessly: anything that doesn't serve the next playable build gets deferred or deleted. A tiny crew can't absorb "we'll figure it out later." Our guide to handling scope creep in an indie studio goes deeper on the tactics.
The honest failure mode: even with a shared workspace like Inferno, scope discipline is a human habit, not a tool feature. The board can surface that your sprint grew 40%, but someone on the crew still has to say no out loud.
FAQ
How long does each stage of a game development pipeline take for an indie team?
There's no fixed schedule, but rough proportions hold: concept is days, pre-production is often one to three months for a vertical slice, production consumes most of the calendar across milestones, and testing plus release takes weeks. Stage lengths matter less than artifacts. Don't leave a stage until its deliverable exists and someone owns the handoff.
Do solo developers need a pipeline, or is it just for teams?
Solo developers benefit, because the pipeline disciplines your own handoffs between your designer brain, artist brain, and coder brain. You still produce artifacts: a pitch, a slice, milestone builds, a bug list. The difference is you can hold conventions in your head, so written overhead shrinks. The stage sequence and the vertical slice stay non-negotiable.
What's the difference between a game art pipeline and the overall development pipeline?
The overall pipeline is the project's journey through concept, pre-production, production, testing, and release. The art pipeline is one discipline's workflow inside production: concept, blockout, final asset, integration. Each art gate feeds the broader pipeline's milestone builds. When the art pipeline breaks, production stalls, which is why naming, import settings, and per-asset budgets need writing down.
Which engine import settings should artists hand off with final assets?
At minimum: pivot points, scale, texture compression format, and naming that matches your convention. The exact list depends on your engine, so read the engine's import documentation as a team during pre-production and write a short checklist attached to each handoff task. The goal is that an asset imports correctly the first time, without a coder discovering wrong pivots at integration.