Stephen Brenish
Most people asking “what is a game production pipeline?” want an org chart. Pre-Production flows to Production flows to Post-Launch, nice and clean. What they actually need to know is messier, way more interesting, and infinitely more useful: a pipeline is a set of agreements about how work flows through a team. When those agreements fall apart, games die.
I’ve watched that happen more times than I’d like to count.
The honest definition
A game production pipeline is the end-to-end process through which a game gets made, from the first concept sketches to the build that ships on a storefront. It covers people, tools, workflows, and handoffs. Every discipline in game dev, art, design, audio, engineering, QA, has its own internal pipeline, and those pipelines have to connect to each other in ways that don’t create constant bottlenecks.
The word “pipeline” originally comes from the art side of game production. Character art pipelines, environment art pipelines, VFX pipelines. Raw input goes in one end, a game-ready asset comes out the other. That metaphor expanded over time to cover the whole production process, and I think it’s actually useful because it keeps you thinking about flow rather than just tasks.
Here’s what surprises most people new to production: the pipeline exists mainly to manage dependencies, not work. The reason you need a pipeline at all is because 40 people (or 4, or 400) can’t each independently decide when to do what. Someone’s finished character model needs a rig before an animator can touch it. That rig needs approved topology from art before the rigger starts. That topology decision needs a technical artist and an art director to agree. Without a pipeline, that sequence of handoffs becomes a game of broken telephone that costs you three weeks and a lot of goodwill.
What the pipeline actually looks like phase by phase
Pre-production is where the pipeline gets defined, not just where you make your GDD and prototype. A good producer asks: how are we going to track assets? What’s our naming convention? How does a design doc move from “idea” to “spec” to “in development” to “done”? What does “done” even mean on this project? Teams that skip this work, and plenty do, pay for it in production when they have to stop and answer these questions under deadline pressure.
The tools conversation happens here too. Are you using Jira, Flow Production Tracking (formerly ShotGrid), Hansoft, HacknPlan? Are your artists using Perforce or Git LFS? What’s your import pipeline for audio? Small studios can lose months in production to version control problems that a one-week pre-production decision would have prevented. If you’re starting a project right now and haven’t made these calls yet, stop and make them. Codecks is worth a look for smaller teams, by the way. It’s genuinely built for games, and the card-based backlog suits how game designers think in a way that Jira often doesn’t.
Production is where the pipeline gets stress-tested. This is your alpha-to-beta stretch, and it’s where you’ll discover every assumption you made in pre-production that turned out to be wrong. The art pipeline that worked fine for 50 assets starts choking at 300. The design-to-implementation handoff that worked when three people were in the same room breaks down when the team doubles. A good pipeline is designed to be revised. Bad ones are treated like law.
Work during production flows through what most studios call a milestone system, though terminology varies. You’ve got a vertical slice target, an alpha target (usually meaning all features in, rough), a beta target (content complete, bug fixing begins in earnest), and gold or release candidate. Each milestone forces the pipeline to process the full game, which is how you find the problems before your publisher does.
Post-launch isn’t always in the pipeline conversation, but it should be. If you’re shipping a live service game, your production pipeline includes a patch cycle, a content calendar, a hotfix protocol. Even for a “finished” single-player game, you need a pipeline for day-one patches, localization updates, DLC if that’s in the plan. Studios that treat ship date as the end of the pipeline are the ones scrambling when a critical bug hits 48 hours after release with no process for getting a patch through certification quickly.
The disciplines and where they connect
What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube
An art pipeline typically runs concept art, then modeling (high-poly and low-poly), then UV unwrapping, then texture and material creation, then rigging for characters and anything animated, then import into engine, then tech art review, then QA. That’s simplified. In reality there are review gates between most of those steps, and the pipeline has to account for revisions looping back upstream. Good production software lets you track that. A physical whiteboard usually can’t.
The design pipeline is less linear and more iterative. A feature usually goes initial design doc, design review, prototype or paper design sign-off, implementation spec written (sometimes by the designer, sometimes with engineering), then development begins, then design review of the built feature, then iteration, then QA, then certification if it affects a platform-compliance-sensitive system. The gap between “design approval” and “implementation spec” is where I’ve seen the most friction. Designers think a decision is made. Engineers see the spec and realize the decision left a dozen open questions. Budget time for back-and-forth here.
Audio gets chronically underestimated. Sound designers often don’t get assets to work with until late in production because levels aren’t locked. That creates a crunch-time crunch specifically in audio that’s painful and avoidable. Good pipelines involve audio early, even with placeholder content, and build in proper middleware integration time. Wwise and FMOD integration aren’t plug-and-play; they need engineering time and a clear data pipeline.
QA is not a phase. It’s a pipeline that runs parallel to everything else. The teams that understand this ship better games. QA needs reproducible build processes, ideally nightly automated builds, a bug tracking workflow that connects to the dev team’s task management, and clear triage criteria so time isn’t wasted on bugs that won’t make the build anyway. The Pragmatic Programmer has a solid chapter on automation thinking that applies here even though it’s not a games book. That kind of thinking eventually turns your QA pipeline from manual chaos into something scalable.
Tools and resources worth knowing
If you’re a producer trying to understand the pipeline more deeply, or build one from scratch, a few things genuinely helped me.
Jira (free for small teams, with paid plans per user) is the industry standard at mid-to-large studios and for good reason. It’s flexible enough to model almost any workflow. The downside is the setup overhead. For a team under ten people, it can feel like overkill.
Autodesk Flow Production Tracking (formerly ShotGrid) is built specifically for asset tracking and review pipelines in games and VFX. If your bottleneck is in the art pipeline and you have the budget, it is worth evaluating.
For learning, Jason Schreier’s Blood, Sweat, and Pixels isn’t a how-to book, but it’s the most honest account of how game pipelines break under pressure that’s publicly available. Read it as a case study collection. Clinton Keith’s Agile Game Development is the closest thing to a production textbook that actually accounts for how game dev works, including how multidisciplinary teams hand work to each other.
For talks, the GDC Vault’s production sessions and postmortems show how real pipelines held up, or didn’t, under pressure.
The pipeline conversation is the production conversation. Everything else, the tools you pick, the methodology you use, the way you run standups, is in service of getting work to flow. When I’m assessing a team I’ve never worked with before, the first thing I try to understand isn’t their backlog or their roadmap. It’s how a piece of work moves from someone’s head to something in the build. That answer tells me almost everything I need to know about whether the project is going to make it.
Photo: Adonis Arias via Pexels
