How to Estimate 3D Art Scope for a Vertical Slice

A decade building mid-core and AAA art pipelines, including scoping the exact kind of demo content this article is about — vertical slices built to survive a publisher’s review, not just look good in a screenshot.

A vertical slice does not need a miniature version of the full game’s asset list. It needs a deliberately chosen set of production-representative assets, built through the actual pipeline and to the role-appropriate quality bar the finished game is expected to hold. Scoping it wrong in either direction is expensive: too little, and the publisher can’t tell whether the quality bar is repeatable; too much, and the team spends pre-production runway proving something the pitch didn’t need to show. The estimate that gets this right is not a percentage of the total asset list. It’s a separate calculation, built around what a reviewer actually needs to see — and, just as importantly, a method for turning that list into a number a team can be held to.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Why scoping a vertical slice is a different problem than scoping full production

Full production scoping starts from the content the finished game needs and works out a schedule to build all of it. Vertical slice scoping starts from a different question: what is the smallest set of assets that proves the game’s visual target, core loop, and production pipeline all hold up at final quality — in front of someone who is deciding whether to fund the rest?

That distinction changes the math. A full-production asset plan is ultimately built for broad content coverage across the intended release scope. A vertical slice asset list is built for something narrower — a useful way to think about it is proof density: every asset earns its place by demonstrating something a publisher, an investor, or an internal greenlight committee needs to see before they commit. An asset that doesn’t demonstrate anything new is scope the slice doesn’t need yet, no matter how central it is to the finished game.

This is also why a vertical slice art estimate can’t be reverse-engineered from a percentage of the full budget. Ten percent of a 40-hour environment kit is not a usable slice of an environment — it’s an unfinished one. The estimate has to be built asset by asset, tier by tier, against what the demo section actually needs to say.

What a publisher is actually judging when they open your vertical slice

Before an asset list can be scoped correctly, it helps to know what it’s being scoped for. Publisher evaluation criteria are not a secret, but they’re inconsistently understood — teams that have never pitched tend to assume a rough section with strong concept art will read as “close enough.” It usually doesn’t.

A GDC Vault session from Finji, built around how the studio prepares its own pitch materials, distinguishes prototypes, gameplay mechanic tests, and vertical slices, and explains why publishers often treat the last of the three as stronger evidence when a funding decision depends on production readiness.

For art scoping, the practical implication is this: the slice has to demonstrate more than an appealing idea. A prototype can prove a mechanic is fun with rough art. A vertical slice is being asked to prove something else — that the visual target is achievable at the finished game’s actual quality bar, by the team and pipeline that will build the rest of it.

In practice, that means the art in a vertical slice is judged less on individual asset quality and more on consistency and completeness within the slice’s boundary. A single stunning hero character next to placeholder props tells a publisher the team can make one great asset — not that they can run a pipeline. A fully dressed, evenly finished section, even a small one, tells them the opposite, and that’s the signal an estimate needs to protect.

The three-tier asset framework: Hero, Support, Filler

A practical framework we use at brief stage is to sort every asset the design implies into one of three working tiers before estimating hours or headcount against any of them. This isn’t the only way production teams divide up a slice — some use primary/secondary/tertiary, others use camera-distance bands — but the underlying logic holds across all of them: the tier, not the asset category, is what determines the fidelity bar.

Tier	What it is	Fidelity bar	Relative cost and volume
Hero	The 1–3 assets the camera lingers on: the player character, a signature weapon, a centerpiece prop or vista	Final quality, no compromises — this is what the publisher remembers	Highest per-asset cost, smallest count
Support	Assets the player interacts with or sees repeatedly but that aren’t the visual anchor: secondary characters, mid-ground props, modular kit pieces	Final quality, but built for reuse and speed — shared materials, trim sheets, modular logic	Moderate per-asset cost, moderate count
Filler	Background dressing, distant geometry, and low-attention scene fillers that read at a glance and are never approached closely	Representative, not hero-grade — silhouette and material read correctly at the distance the player actually sees them	Lowest per-asset cost, can be produced in volume or reused aggressively

A note on scope: a unique, story-important set piece — a crashed ship, a boss arena centerpiece — is not automatically Filler just because it’s a single instance. “One-off” describes how many times an asset repeats, not how much attention it deserves. Tier by camera attention and gameplay importance first; treat instance count as a separate, secondary factor.

A common mistake in first-pass estimates is to price every asset in a level as if it were Hero tier, because nobody explicitly decided otherwise. A 3D character that appears once in the background of a shot the player never approaches does not need the same topology budget, texture resolution, or review passes as the character the player controls for the whole slice — but without a tiering pass, both get quoted and built at the same bar, and the estimate balloons before a single hour of work starts.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

The tiering decision has to happen at brief stage, not during production. Once an artist is mid-sculpt, “downgrade this to Filler” is a much more expensive conversation than “this was scoped as Filler from the start.”

Building the asset list from your level breakdown

With the tier framework in place, the actual list-building is a walkthrough exercise, not a brainstorm. Take the level, scene, or gameplay space the vertical slice will show, and move through it the way the camera and the player actually will:

• Walk the critical path first. Everything the player is guaranteed to see — the space they move through, the objects they interact with, the character they control — gets listed and tiered before anything optional.
• Mark repeat geometry as one production entry, not many. A modular wall piece used forty times is one modeling and texturing task with a reuse multiplier, not forty line items. This lowers modeling cost specifically — it does not make the placement, variation, dressing, and validation work of those forty instances free, and that work still needs its own line in the estimate.
• List by what the camera actually frames, not by what exists in the design document. A creature that’s mentioned in the GDD but never appears on-screen in the slice’s playable section isn’t slice scope, even if it will be central to the shipped game.
• Flag anything that needs a decision before it can be estimated — an undecided art style for a prop category, an unlocked camera distance that changes fidelity requirements. Unresolved decisions are a common reason a vertical slice estimate has to be revised mid-production.

The camera walkthrough covers what the player sees, but a vertical slice’s art scope isn’t only what’s visible in a screenshot. After the visual pass, run a second pass for the deliverables a build needs that a reviewer won’t consciously notice as separate objects: collision geometry, rigging and animation states for anything that moves, LODs, material instances and variants, VFX hooks, and the engine integration work that turns a finished model into something running in the actual build. Skipping this pass is how a visually complete list still produces a slice that isn’t actually playable at review time.

A 3D environment built this way — critical path first, reuse counted once, camera-framed rather than document-framed — tends to produce a list that’s smaller and more defensible than one built by copying every asset mentioned in the design pitch deck. That smaller list is also the one a producer can actually schedule against.

What to defer without hurting the pitch

Deferring the right things is as much a part of the estimate as including the right things. A publisher isn’t evaluating whether the slice contains everything the finished game will have — they’re evaluating whether the team understands the difference between what proves the game and what doesn’t yet.

Assets and systems that are commonly safe to defer past the vertical slice:

• Content variety beyond what the slice’s critical path requires — additional enemy types, weapon skins, or biome variants that don’t appear in the demo section
• Edge-case geometry — damage states, destructible variants, or seasonal dressing that isn’t part of the core loop being demonstrated
• Full localization and platform-specific asset variants, unless the pitch specifically depends on showing multi-platform readiness
• Optimization work outside what the slice needs to prove — platform variants for hardware the reviewed build won’t run on, or edge-case performance passes unrelated to the section being shown. This is narrower than “anything not visible”: the slice still needs real engine integration and enough optimization to demonstrate its visual target can run within the intended performance envelope, because that’s part of what a reviewer is checking, not a polish step

What is rarely safe to defer is anything that touches the visual target itself — because that’s the thing a vertical slice exists to prove is achievable. Locking the visual direction is a concept art decision that has to happen before the asset list is finalized, not during production; scoping against an unsettled style guide is how a team ends up rebuilding hero assets mid-slice because the direction shifted under them.

Reuse, modularity, and the props that don’t need to be heroes

The fastest way to shrink a vertical slice estimate without shrinking what the publisher sees is to push as much of the Support and Filler tiers as possible into shared, modular systems rather than one-off builds.

A well-scoped slice typically leans on:

• A small kit of modular pieces — wall segments, trim sets, shared material masters — that recombine to fill more space than their individual count suggests
• A limited palette of hero materials reused across multiple Support-tier assets, so the visual consistency reads as intentional rather than sparse
• Selective high-fidelity treatment, reserved for the handful of assets the camera actually lingers on, rather than spread evenly across everything in frame

This is where 3D props production earns its place in the estimate as a volume-and-reuse problem rather than a hero-asset problem — a set-dressing pass built on a tight kit of shared props can fill a scene convincingly at a fraction of the cost of one-off modeling for every object in view, without the difference reading to a reviewer who isn’t studying the geometry up close.

Turning the asset list into a production estimate

A tiered, camera-framed asset list is the input. It isn’t the estimate yet. Getting from one to the other means running each line item through the same set of questions, then adding the overhead that a list of individual assets doesn’t show on its own.

For every asset on the list, define:

• Tier — Hero, Support, or Filler, decided above
• Starting point — is this built from scratch, adapted from an existing kit or library piece, or a polish-and-integrate pass on something that already exists? A Support asset built from an existing modular kit costs a fraction of the same asset built from zero, and an estimate that treats every line item as a from-scratch build overstates the total before a single hour is scheduled
• Required deliverables — does it need rigging, animation states, destructible variants, or is it a static mesh
• Production stages it has to pass through — reference and concept lock, blockout, high-poly and low-poly (where the tier justifies it), UV and bake, texturing and material setup, rigging or animation where applicable, engine integration, and optimization or LOD work
• Review load — how many approval rounds this asset realistically needs. A Hero asset the art director will review repeatedly costs more in calendar time than its modeling hours alone suggest; a Filler asset approved once in a batch does not

Then add what the per-asset list doesn’t capture on its own: a shared foundation pass (kit pieces, trim sheets, material masters built once and reused across many Support and Filler assets), lead review and integration time that scales with the number of contributors rather than the number of assets, and a contingency margin for the decisions that are still unresolved when the list is built.

Converting the total into a schedule is where a fixed pitch date meets reality. More people can shorten a schedule, but not linearly — concept has to lock before modeling starts, rigging depends on finished topology, and integration depends on assets actually being done. A date that assumes full parallelization across every stage is a scope signal, not a real schedule; the honest move is to compress the list, not just add headcount against dependencies that don’t compress.

From asset list to effort worksheet

Assigning real hours or a day rate to any of this depends on a studio’s own completed-project data — that’s not something a general framework can respond with a number for without inventing one. What a framework can do is lay out the structure a studio fills in with its own benchmarks:

Line item	Quantity	Base effort (studio benchmark)	Additional deliverables	Review / integration overhead
Playable character (Hero)	1	From comparable past hero characters	Rig + full animation set	Multiple director review rounds
Environment kit (Support)	1 kit	From comparable past kits	Collision + shared materials	Kit validation pass
Support props	6–10	Per-unit benchmark × quantity	LODs, engine integration	Batched review
Filler dressing assets	10–20	Per-unit benchmark × quantity	Simplified materials	Batched review
Scene assembly and set dressing	1 section	Not per-asset — a separate task	Placement, variation, decal and material tuning, lighting coordination	Full-section validation

Total art effort = unique asset production + shared systems + scene assembly + engine integration and QA + review and contingency. Each studio fills the “base effort” column from its own delivered projects rather than a published rate, multiplies unique quantity by that benchmark, adds the deliverables and overhead columns, and only then maps the total to calendar time against named contributors and their dependencies. That mapping — not the asset count on its own — is the number a team should actually be held to.

A worked example, to show the method — not a benchmark

The counts below are illustrative only. A stealth game, a racing game, and a dialogue-driven narrative slice would each produce a completely different list from the same method. This is one way a third-person action slice, built around a single combat encounter in one location, might come out after a tiering and dependency pass:

Line item	Unique count	Tier	Reuse	Key deliverables
Playable character	1	Hero	None	Rig, full animation set, PBR materials
Featured enemy archetype (encounter centerpiece)	1	Hero*	None	Rig, combat animation set, materials
Signature weapon	1	Hero	None	Static + FP/TP rig-ready mesh
Modular environment kit	1 kit (multiple pieces)	Support	High — recombined across the space	Trim sheets, shared materials, collision
Interactive / set-dressing props	6–10	Support	Some — shared material library	Static mesh, PBR, LODs
Background dressing assets	10–20	Filler	High — reused and recolored	Static mesh, simplified materials
Environment assembly and set dressing	1 playable section	Production task, not an asset	—	Placement, variation, decals, material tuning, collision checks, lighting coordination, validation

*Treated as Hero here because the camera closes on it during the encounter and it carries the same review weight as the player character — a background or non-engaged enemy type in the same slice would tier as Support instead.

Even in this small example, the modeled asset count is dominated by Support and Filler line items, not Hero ones — and the assembly row above is what turns that list from a pile of models into the actual playable section a publisher reviews. Leaving it out is how a visually complete asset count still understates the real scope.

The vertical slice as a milestone gate — and scope discipline after it

A vertical slice estimate isn’t just about getting through the pitch. It’s also the number a team will be held to once the gate is passed and full production begins — which is why scoping it honestly matters more than scoping it optimistically.

We’ve covered the vertical slice’s role as the exit gate from pre-production in more depth elsewhere.

A GDC Vault talk from Volition frames it from the same angle — as a deliberate readiness test the team runs on itself, not a formality to clear before a fixed release date. The consequence that matters specifically for art scoping is narrower: the estimate should reflect a pipeline the team can plausibly repeat at full scale, not a one-off showcase assembled through senior artists quietly overworking a handful of assets.

It’s the same discipline we cover from the budget side in our breakdown of game development cost — the vertical slice is one of the few levers that controls schedule and spend at the same time, but only if the number behind it was earned, not assumed.

Common estimation mistakes

When a vertical slice art estimate goes wrong, it’s rarely because the team misjudged individual asset costs. The failure usually sits upstream, in the scoping decisions:

• Skipping the tiering pass and pricing every asset as Hero tier, which inflates the estimate and the schedule before production starts
• Treating the slice budget as a fixed percentage of the full game’s art budget, instead of scoping it against what the reviewed section specifically needs to prove
• Scoping against an unlocked visual style, which forces rework once the direction settles mid-production
• Counting reused geometry multiple times because the list was built from the design document instead of a camera-framed walkthrough — or the opposite error, counting it once and forgetting that placement, dressing, and validation of every instance is still real work
• Leaving deferred content ambiguous rather than explicitly listing what’s out of scope, which invites scope creep back in as “just one more asset” during production
• Scoping only what the camera sees, and missing the collision, rigging, LOD, and integration work a playable build needs but a screenshot doesn’t show

Each of these is a scoping-stage mistake, not a production-stage one — which is also why each is far cheaper to catch before the asset list is finalized than after art production has started.

What we need to estimate your vertical slice art scope

How clearly the scope has already been tiered and framed is one of the largest variables in a vertical slice estimate. Send us these and you get a real production estimate instead of a range.

We need	Why it changes the estimate
The section or level the slice will show	Defines the critical path — everything else is scoped against it
Existing concept art or art bible	Whether we start at concept or at asset production
Asset tier pass, if you’ve already done one	Hero / Support / Filler decisions shape cost more than category or count
Target engine and platform	Unreal Engine 5 or Unity, and the performance envelope the slice has to run in
What the pitch specifically needs to prove	Core loop, art direction, a specific mechanic — the estimate protects that, not everything the finished game will have
Deadline	A fixed pitch date determines how much of the schedule can realistically be parallelized — it doesn’t shrink the dependencies between concept, modeling, rigging, and integration

About Nasty Rodent

Nasty Rodent is a full-cycle game art studio (Nasty Rodent OÜ, Tallinn, Estonia) supporting mid-core and AAA teams across 3D characters, environments, props, weapons, vehicles, concept art, and UX/UI — including the exact scoping-to-production handoff a vertical slice depends on. If your asset list needs a second, production-grade pass before it goes into a pitch deck, send us your brief and we’ll come back with a scoped, tiered estimate.