Knowing when it is done — and handing off
The agent will always tell you it is finished — "done" is its favourite word — so the one judgment it can never make for you is the only one that matters at this stage: is this model actually ready to become a game asset?
Choose your track
Read this module through your lens
The word “done” is the trap
Ask an agent if the model is finished and it will say yes. Ask again after a change — still yes. “Done” costs it nothing and means nothing, because the agent has no stake in what happens next and no view of the operations the model must survive downstream. It optimises for ending the conversation, not for the model being correct.
At beginner level you learned to inspect three numbers. At master level the move is bigger: you stop trusting any subjective verdict — yours or the agent’s — and replace “is it good?” with “does it pass the contract?” The contract is a checklist of objective, downstream- relevant properties. The agent can run the checks and report; only you decide that a passing checklist means advance.
This is the single most transferable habit in the course, and it is pure human judgment expressed as a list.
The case study: “ready” that wasn’t
”Is the lamp model finished and ready for game work?“
”Yes, the lamp is complete and ready.” Confident, unqualified.
Running the actual checklist: object scale is 0.4 (never applied), the shade has a non-manifold edge from a boolean, two objects are named Cube.003 and Circle, and there are doubles at the base. Every one of those breaks a Stage-2 operation. The model was “done” only in the sense that the agent had stopped working on it.
”Validate against this handoff checklist and list every failure: applied transforms, manifold, origin, dimensions, names, no doubles. Do not call it done unless all pass.” Then fix each reported failure and re-validate.
The handoff contract to Stage 2
A game asset cannot be built from a model with unapplied scale, holes, or default names — each silently corrupts retopology, UVs, or baking later. So the bridge between Course 1 and Course 2 is a contract the product model must satisfy before it is allowed to travel.
Write it once and reuse it for every object: transforms applied (scale reads 1,1,1); mesh manifold; origin and real-world dimensions correct; meaningful object and material names; no loose geometry or doubles. These are not aesthetic — they are the preconditions for the operations the next course performs.
The master skill is discipline: the model does not advance because it looks finished. It advances because the checklist has zero failures, verified, not asserted. That refusal to proceed on vibes is the judgment the agent cannot supply.
Hands-on exercise
Write your own handoff checklist — at least five concrete, checkable items relevant to a product heading into game work. Take any model you built earlier and ask the agent to validate it against the checklist and report failures (it will find some). Fix each failure explicitly, re-validate, and only then declare the model frozen. Save the passing checklist as the artifact — it is the contract for everything in Course 2.
Second case · the office chair (the hero artifact)
The same lesson, a different object
Is the office chair ready to become a game asset?
Yes, the office chair is complete and ready.
The checklist disagrees: object scale is 1.2 (never applied), the seat has n-gons that will bake badly, the mesh is named Cube, and a boolean left loose vertices at the base.
Validate against the handoff checklist and list every failure: applied transforms, manifold, no n-gons on bake surfaces, meaningful names, no doubles. Do not call it ready unless all pass.
Common failures · spot them fast
The failure gallery
Agent declares "done" with unapplied scale (scale != 1)
Non-manifold geometry that will break baking later
Default names (Cube.001) that poison the asset pipeline
Origin fine for rendering but wrong for rigging/placement
Looks finished, fails the first Stage-2 operation
Each of these is caught by a quality gate — keep the cheatsheet open while you work.
Worked example
See the journey
The pattern
Cheatsheet
Cheatsheet
Prompt skeleton
Validate [object] for handoff to game-asset work. Check and report:
real-world scale (dimensions), origin location, manifold (no holes/non-manifold edges),
no n-gons on hard surfaces that must bake cleanly, applied transforms (scale = 1),
object + material names. List every failed check; do not say "done" unless all pass.
Failure modes
- Agent declares "done" with unapplied scale (scale != 1)
- Non-manifold geometry that will break baking later
- Default names (Cube.001) that poison the asset pipeline
- Origin fine for rendering but wrong for rigging/placement
- Looks finished, fails the first Stage-2 operation
Key operations
- Apply all transforms (scale = 1, rotation = 0)
- Run a manifold / non-manifold check
- Confirm origin + real-world dimensions
- Rename object + materials meaningfully
- Remove stray/loose geometry and doubles
Quality gates
- Scale applied (transform scale reads 1,1,1)?
- Mesh manifold, no holes or non-manifold edges?
- Origin and dimensions correct for downstream use?
- Names meaningful, not defaults?
- Every checklist item literally passed, not asserted?
Workflow steps
- Write the handoff checklist once (reuse it forever)
- Ask the agent to validate against it and report failures
- Fix each failed item explicitly
- Re-validate until zero failures
- Freeze the model and log the passing checklist
Next module
- Course 2 — Game Asset: game_polycount_budget. The same model meets a triangle budget.
Reflection
Reflection card
Active retrieval — answer from memory before re-reading. Saved to this browser.
You've completed this module when…
- A written handoff checklist with at least five concrete, checkable items.
- A validation run where the agent reported real failures (not all-pass on the first try).
- A model frozen only after every item literally passed.
Next: Course 2 — Game Asset: game_polycount_budget. The same model meets a triangle budget.
Finish — back to Product Design →