What Actually Happens During Production

Almost everyone has a game idea worth building. Far fewer people ever turn that idea into something you can actually play. That gap is what production is for — it's the stage where the game design document, the concept art, and the prototype from pre-production stop being reference material and start becoming real, playable assets. If pre-production is where you figure out what you're building, production is where you actually build it.

Bringing a Character to Life

Take a single character and follow it through the pipeline, and you'll see how most of production actually works. It starts with concept art — usually a handful of pieces from pre-production showing the character from the front, with some sense of mood or personality. From there, a concept artist redraws the character in a turnaround: front, back, and side views, arms held out, no pose, no expression — just enough information for a modeler to work from without guessing.

Concept art gives a modeler a feeling to aim for. A turnaround gives them the facts they can actually build from.

The modeler then builds the character in 3D, working inside constraints the GDD already set — a polygon budget, a target texture resolution, sometimes a specific naming convention so the model plays nicely with the rest of the pipeline. Once the base model holds up, it moves to texturing, where materials and surface detail get painted on. Only after that does it go to rigging, where an artist builds the digital skeleton the character will actually move on, and then to animation, where that skeleton gets taught to walk, jump, and fight.

Every step in that chain depends on the one before it. A rigger can't do much with a model that isn't finalized, and an animator can't do much with a rig that's still being adjusted. That's why a character's silhouette and proportions usually get locked early — changing them later means redoing work across four or five disciplines, not just one.

Building a Level

A level goes through a similar chain, but with more people touching it at once. A level designer blocks out the space first — where the player starts, where they end up, what stands between the two — usually with gray boxes and placeholder geometry instead of finished art. Once that layout actually plays well on its own, an environment artist replaces the gray boxes with real assets, a lighting artist shapes how it feels to walk through, and an engineer makes sure none of it tanks the frame rate.

Open-world games add a problem most linear games don't have to solve: how much of the world actually needs to exist in memory at once. A common approach is to load in detail only near the player and quietly swap it out as they move away — part of why huge, detailed worlds became possible without needing correspondingly huge hardware to run them.

A gray box has to answer one question honestly, before a single piece of real art gets attached to it: is this actually fun to move through?

If the blockout doesn't hold up on its own — if it's confusing or just boring to walk through even with nothing but placeholder shapes — no amount of art or lighting fixes that later. Good art on a bad layout is still a bad level. It's just a better-looking one.

The Work That Doesn't Need Finished Art

Not everything in production waits on art. Level layouts, AI behavior, combat systems, and progression — how a player earns new abilities or gear over time — can all be built and tested with placeholder assets, sometimes literal colored blocks standing in for enemies. That's deliberate: it lets a team find out whether a system is actually fun long before anyone commits real art time to it, and it lets multiple disciplines move in parallel instead of queuing up behind each other.

This is also where a lot of a game's real identity gets decided, even though none of it looks impressive in a screenshot yet. Celeste is a good example — a huge amount of what makes that game work is a movement system built around one very well-tuned dash, and that system was clearly prototyped and iterated on long before the finished art went anywhere near it.

Where Schedules Actually Break

Every discipline in production depends on the ones before it, which makes scheduling the thing that actually decides whether a game ships in good shape. If character art runs late, animation runs late behind it. If animation runs late, the level built around that character's abilities can't be properly tested. Delays don't stay contained to one department — they cascade.

Assassin's Creed Unity is the example the industry still points back to. It launched in 2014 with serious technical problems — broken animations, NPCs missing faces, frame rate drops bad enough to make some sections nearly unplayable — and the reporting that followed pointed to a production schedule that had been squeezed too hard for too long. No single team working on it was incompetent. The problem was that small delays across many interdependent systems had nowhere left to go by the time the game had to ship.

Delays in production rarely stay contained to one department — they cascade into every discipline that depends on it.

My advice, if you're a solo developer or a small team: build in slack on purpose. Assume every asset and every system will take longer than your first estimate, because it almost always does, and decide ahead of time which corners you're willing to cut if you run short. Making that call under pressure, a week before launch, is a far worse position to make it from.

Production is the longest stage of building a game, and it's the one where a good plan either holds up or falls apart. Next time, I'll cover the final stretch — testing, polish, and actually getting a game out the door.