Craft Game Floors
A functional game that looks and feels like programmer art reads as a failure to the person who
asked for it. This skill is the craft layer: floors — disciplines where every game needs a
minimum and the engine's defaults are unacceptable — each carried by a reference below with
opinionated values, worked examples to imitate, and a verify step. The floors are the heart of the
paved path (Unity's default scaffolding for agent-built games: assumptions declared up front,
reversible on a word); in this skill, "paved" simply means these floors are always on unless the
user declines one.
Before starting any floor or diagnosis, open and read the matching reference below and the Unity
docs pages it links — your engine knowledge may be out of date, wrong, or for a different
version. Name the files and pages you read in your report. Do only what's asked. Don't change
unrelated assets or files. Avoid long explanations.
Two ways in, same floors:
- During project creation — the skill loads this one and carries the
floors through the build in the order below.
- Mid-project, on any craft ask ("fix the look", "add sound", "it feels flat", "make a title
screen", "score it") — jump straight to the matching reference, after the mid-flow check below.
Scope by the ask: a request that authorizes changes ("fix", "add", "polish") gets the floor
applied; an assessment-only ask ("score it", "what should I fix?") gets the scored board and
recommendations, with no project modifications until the user says go.
Entering mid-flow
The references assume an
art bible (style statement + fixed palette) and, where audio meets
UI, the
mixer handshake (exposed params
/
). On an existing project, run
these in order before the asked-for floor:
- Restore point — confirm a clean commit to roll back to, or create one, before any change.
- Render pipeline — read
GraphicsSettings.currentRenderPipeline
- Art bible — look for a type or an art-bible note (CLAUDE.md, docs); if none
exists, write the three-line bible from the game's current look first — retro-tinting later is
the expensive order.
- Identity (live floor only) — verify player identity with a live probe (services
initialized and a PlayerId present), never by assuming an earlier setup step ran.
- Scope the done gate to the surface you touched: a title-screen session scores the shell
and look axes, not the whole board.
A floor fills an engine default, never a developer's choice. If the project already has its
own controller, camera, shader, palette or style, keep it, apply only the floor's opinions that
don't conflict, and name the difference in the report. Write an art bible only from choices the
developer has made, and ask before adding one mid-project.
The floors — numbered in build order, read each at its moment
- art-direction — before the first material, light, or UI element
- scene-lighting — with the visual baseline (3D)
- toon-shading — when the art bible picks a cel/toon style (3D)
- camera-rigs — first gameplay camera (has a 2D section)
- placeholder-assets — first missing asset
- character-motion — first moving character (3D-leaning)
- (the playable loop lands here — loop before content, one system per pass)
- game-feel — the feel pass, after the loop
- vfx — with the feel pass (has a 2D section)
- game-audio — before done
- game-shell — before done (2D backdrop delta). Before the first TextMeshPro text, import TMP Essentials (see the reference's failure table).
- live-floor — with the shell (services before gameplay code)
- visual-scorecard — the done gate, always last; run it once a playable loop exists. During project creation, stop at the lit-baseline capture and skip the gate.
Mid-project asks enter at the matching number and pull earlier floors only as the mid-flow check
requires (the bible, the pipeline, the identity probe).
Resolving in the references' doc links — prefer WebFetch of the exact page over
WebSearch: for
docs.unity.com/en-us/engine/<VERSION>
manual and script-reference pages, use the
project's Editor stream (e.g.
) from
ProjectSettings/ProjectVersion.txt
, and the same
stream for the remaining
docs.unity3d.com/<VERSION>/Documentation
pages; for
docs.unity3d.com/Packages/<package>@<VERSION>
pages, use the installed package's major.minor
from
or the
folder name; the
docs.unity.com/en-us/<service>.md
services pages are unversioned.
Routing follows the game's 2D/3D nature; the 2D look floor (sprite art direction, 2D lights,
sprite placeholders) is not yet covered — on a 2D game, say so at those beats rather than
applying 3D instructions. The scorecard's 2D anchor set still applies.
The boundary (what this skill is not)
This skill owns
opinionated creation and floors — which values, in what order, to what bar.
Catalog neighbours own
mechanics on existing setups: volume/post mechanics →
· routing sources into existing mixer groups →
· audio
import/memory →
· UI framework choice and construction →
· font assets →
· backend services →
· pixel-perfect 2D →
. When an ask is purely mechanical, route there; when it's "make it good," it's
this skill, which then delegates the mechanics. If this index wants to grow, the new thing is a
catalog skill routed by the prompt, not another floor — a floor must apply to
every game.
The done gate
A craft session ends with visual-scorecard's board — scored
frames, not a green compile. In order:
- Score all six axes per the scorecard. All six at 3 or better is the floor.
- Fix pass — anything below 3 gets its fix before done (assessment-only asks: scores and
recommendations, no fixes). If a fix doesn't work, reread the relevant reference and its
linked documentation before trying variations.
- Console — confirm zero console errors.
- Play check — enter Play mode and check the touched behavior with lines you
added for the purpose. If the fix pass or this check fails, reread the relevant reference and
its linked documentation before trying variations.
Final report
State: which floors ran and which references were read · the board (or the scoped axes) before and
after the fix pass · every incidental side effect — packages installed, files or settings edited,
assets imported — and any follow-up the user needs · any floor skipped or gap named (the 2D look
floor, a declined install, a missing neighbour skill), so the user knows what deeper guidance was
skipped.
Common mistakes
- Polishing without a bible — fixing one object's look against no palette; write the
three-line bible first, even mid-project.
- Replacing a developer's choice with a floor recipe — an existing custom controller,
camera, shader or palette stays; the fix pass never swaps it for the floor's default.
- Treating a floor as a feature — floors are defaults; the user declines one with a word, and
the decline is recorded in the report, never argued.
- Running the mechanics from memory when a neighbour skill owns them — route and delegate.
- Skipping the done gate because the change was small — scope it down instead.
- Applying 3D look instructions to a 2D game — name the gap instead.