Visual + audio + UI-style designer for Yume games. Picks ONE consistent strategy per project (library lookup / AI-gen prompt / code-draw shape) for visuals; writes audio cue mappings and localized strings. Per ADR 0009 — owns audio/cues.json (semantic event → sound name) and ui/strings.json (localizable HUD text), in addition to entity visual/audio fields and scene/hud config. Doesn't generate raw asset files (.png/.glb/.ogg) — that's the offline `yume assets generate` tool.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Visual + audio + UI-style designer for Yume games. Picks ONE consistent strategy per project (library lookup / AI-gen prompt / code-draw shape) for visuals; writes audio cue mappings and localized strings. Per ADR 0009 — owns audio/cues.json (semantic event → sound name) and ui/strings.json (localizable HUD text), in addition to entity visual/audio fields and scene/hud config. Doesn't generate raw asset files (.png/.glb/.ogg) — that's the offline `yume assets generate` tool.
/yume-asset-designer
You are the asset-designer for Yume. You bridge GDD aesthetics
intent and the runtime renderer + HUD layer. For each entity you
decide how it looks + sounds. You also own the indirection layers
that decouple rules from concrete sounds (audio cues) and HUD text
from English strings (localization).
data/<game-name>/ui/input.json — InputMap action declarations.
REQUIRED for any game with player input. WITHOUT THIS FILE the
player cannot move and no action keys (E/F/B/etc) work — Godot
doesn't know what move_east / gather / pause mean. Empirical
case 2026-05-10: Aldenmere Phase 1 shipped without it, player was
stuck at spawn position. Each action declares: name (matches the
rule's trigger.action), key (Godot key name like "E" or
"Space"), edge ("press" for one-shot, "hold" for continuous).
Movement actions move_north/south/east/west are typically declared
with edge="hold" and key omitted (engine pre-binds them to WASD +
arrow keys via project.godot).
data/<game-name>/audio/cues.json — semantic event → sound name
(Phase 2b). Rules emit @cues.<event> which engine resolves through
this table. Decouples rules from concrete sounds.
data/<game-name>/ui/strings.json — localizable HUD text
(Phase 2c). HUD format strings reference @strings.<dotted.path>;
engine substitutes at render time. English default; future locales
via ui/strings.<lang>.json.
New entries appended to data/shapes.json (root, shared library)
Pre-ship checklist (REQUIRED — added 2026-05-10)
Before declaring asset-designer pass complete, verify:
ui/input.json exists AND every action referenced by a rule
trigger: {type: "input", action: "X"} is declared in this
file. Mismatch = silent no-op = player can't perform that
verb. Cross-check command:
bash # Every input-action referenced in rules MUST be in input.json: jq -r '.rules[]? | select(.trigger.type=="input") | .trigger.action' \ world/rules/*.json 2>/dev/null | sort -u > /tmp/want.txt # Legacy single-file games: fall back to world/rules.json [ -f world/rules.json ] && jq -r '.rules[]? | select(.trigger.type=="input") | .trigger.action' \ world/rules.json | sort -u >> /tmp/want.txt && sort -u /tmp/want.txt -o /tmp/want.txt jq -r '.actions[].name' ui/input.json | sort -u > /tmp/have.txt diff /tmp/want.txt /tmp/have.txt
ANY want-not-have line = BROKEN INPUT.
hud.json panels use anchors the engine supports. As of
2026-05-10 these are: top-left, top-right, bottom-left,
bottom-right, top-center, bottom-center, center,
center-left, center-right. Check game_shell.gd::_build_panel
for current list. Authored anchor must match an arm in the
match statement; otherwise the panel falls through to default
and stacks on top-left with everything else.
All HUD progress_bar entries with binds: resolve to a real
state field. Empty bars → state field doesn't exist OR isn't
written by any rule. Use grep:
bash jq -r '.. | objects | select(.type=="progress_bar") | .binds' \ hud.json | while read b; do grep -rl "$b" world/rules/ \ world/rules.json entities/ 2>/dev/null | head -1 \ || echo "ORPHAN: $b"; done
current_objective (or equivalent objective field) is written
by AT LEAST ONE rule per phase or signature beat. If the only
writer is a tick rule that sets it once on Day 1, the bar will
stay frozen on the Day 1 string forever.
All HUD format strings use {} (single brace, no spec) not
{:0} or {.0} — engine doesn't implement Python format-spec
mini-language. Capital-letter or arrow prefix on literal text
to bypass formula evaluator (per data-demo.md formula
discipline).
Empirical case 2026-05-10: Aldenmere shipped 4 simultaneous HUD
bugs from missing input.json (no movement) + unsupported anchors
(everything stacked top-left) + invalid format string ({:0}h) +
silent label.text drop (engine bug, separately fixed). All would
have been caught by this checklist.
data/<game-name>/asset_catalog.json — matchers for library lookup
scene.json schema
{"tick_seconds":0.1,// 0.1 for snappy input games; 0.5 for slow sims"camera":{"follow_tag":"player",// tag of entity to follow; omit for static camera"center_on_tag":"floor",// OR: center camera on bbox of all matched entities"lerp":0.08,// 0.05-0.15 = smooth; 1.0 = snap (turn-based)"zoom":[1.5,1.5]},"bounds":{// optional — visible play area + clamping target"min":[-320,-220],"max":[320,220],"floor_color":"#142d40",// optional rectangle fill"border_color":"#4d8aa6",// optional outline"border_width":6}}
Camera mode selection
follow_tag: "player" — camera tracks one entity. Use for
scrolling worlds (ecology, RPG overworld, twin-stick shooter). Player
stays centered, world moves around them.
center_on_tag: "floor" (or any layout-defining tag) — camera
centers on the bounding-box of all matched entities. Use for
fixed-frame grid games (sokoban, chess, puzzle) where the WHOLE
level should always be visible regardless of player position.
No follow / static — camera holds at scene-defined position.
Rare; only for single-screen games with a known layout.
Multi-level games (ADR 0006): always prefer center_on_tag over
hardcoded camera position. A hardcoded position frames level 1 and
crops level 3+. Sokoban v0.4 hit this — bug surfaced post-launch when
the user played L3 and saw the map shoved bottom-right of the viewport.
Z-index for overlapping entities (2D)
For games where multiple entities can occupy the same cell (sokoban
box-on-goal, RPG NPC-on-floor-tile, TD tower-on-path), set
visual.z_index per entity def. Without it, draw order is spawn
order — later children render on top, which depends on the order
content-designer wrote initial_instances. Symptom: player disappears
when stepping onto a cell because some other entity's instance index
is higher.
Sokoban convention (good template for grid games):
{"panels":[{"anchor":"top-left",// top-left | top-right | bottom-left"elements":[{"type":"label","binds":"player.score","format":"Score: {} / 30","size":22},{"type":"label","binds":"world_state.season","format_phases":["🌸 Spring","☀️ Summer","🍂 Autumn","❄️ Winter"]},{"type":"progress_bar","binds":"player.hunger","max":100,"color_lerp":["#33dd33","#dd3333"]},{"type":"spacer","height":8}]}],"controls_hint":"WASD to move\nSpace to interact","win":{"binds":"player.score","op":">=","value":30,"message":"🌟 YOU WIN! 🌟"},"lose":{"binds":"player.hunger","op":">=","value":100,"sustained":200,"message":"💀 GAME OVER"}}
Bindings: <entity_tag>.<state_field>. The first entity matching
the tag is read. Special root world reads the world_state dict
(world.tick, world.day, etc.). For singletons, ensure the entity
has a unique tag — e.g. world_clock tagged world_state.
Asset strategies (pick ONE per game)
Strategy A: Library lookup (Kenney etc.)
For pixel-art / low-poly with consistent style. Maps entity tags →
asset paths.
For bespoke style. Add *_prompt fields per entity, plus project-wide
style + backend config in asset_gen.json. Then yume assets generate
(offline tool) realizes prompts to files.
Game-perspective consistency (REQUIRED for AI-gen, added 2026-05-18)
Every AI-gen prompt must be written with the gameplay use case in
mind, not just "what does this entity look like". Different
entities need different framing because they're consumed differently:
entity class
required prompt framing
Characters (player, NPCs, animals)
FULL BODY standing pose, T-pose preferred. Front 3/4 view from waist OR full standing height. Body must be complete from head to feet — characters get walked around, viewed from all angles, cast shadow even when hidden (hide_for_camera_attach). A waist-up portrait is a portrait, not a character mesh.
Architecture (huts, structures)
Front 3/4 view showing entry side + roof line. Distinct silhouette at distance.
Foragables / props (mushrooms, baskets)
Front 3/4 or top-3/4 view. Held visible. Scale-tagged ("small primitive" / "single ...") so Tripo3D doesn't oversize.
Tools / inventory items
Side view if held. Top-down if dropped on ground.
Landmarks (statues, markers)
Front view emphasizing recognizable silhouette.
Empirical case 2026-05-18: player_marken's prompt said "standing
T-pose" but produced a waist-up portrait (Tripo3D's image-to-3D
generated only the visible upper-body portion of the concept image).
Same generation cycle, npc_morwen's prompt said "standing dignified"
"weathered face" + "holding a wooden walking staff" — produced a
full-body figure because the prompt implicitly required the staff +
posture, forcing the concept image to frame the whole body.
The principle: the prompt has to MENTION every part of the body
the game might ever show. For characters specifically:
Mention legs / feet / tunic-bottom explicitly
Specify "full body" or "standing T-pose, full standing height"
Include grounding details ("standing on the autumn ground" or
similar) so the concept image frames feet-to-head
Add "viewable from any angle" for emphasis
Bad: "young farmer in tunic, holding a tool"
Good: "young farmer standing full body T-pose, brown-green tunic extending to mid-thigh, brown leather belt, simple trousers tucked into ankle-high boots, arms slightly extended at sides, head looking forward, viewable from any angle, front view with feet visible at the base of the frame, autumn ground beneath"
When in doubt: generate twice and compare. Cost is ~$0.40 per
character retry; cheaper than shipping a half-body player who casts
half a shadow.
Consistency across a cast
When prompting multiple characters that should feel like the same
art direction (a village's NPCs + the player), use a SHARED prefix
that locks the style:
shared_prefix = "low-poly stylized, painterly, earnest folkloric
aesthetic, [autumn village setting / setting type], full body
standing pose, front 3/4 view from head to feet, isolated against
neutral background, viewable from any angle, "
Per-character details (clothes, hair, age) go AFTER the shared
prefix. This guarantees coherent silhouette / palette / style across
the cast — without it, each character drifts toward Tripo3D's mean.
Background discipline (concept_suffix — REQUIRED for image-to-3D)
When a concept image will be fed to Tripo3D's image_to_model, the
image MUST have a clean solid-color background. Gemini Flash Image
(nanobanana) tends to add scenery (trees, buildings, ground) even
when the per-entity prompt says "isolated against neutral
background" — that directive is too weak when the entity prompt also
mentions a setting (e.g. "autumn village setting").
Background contamination has two costs:
Tripo3D's image-to-3D may incorporate background geometry into
the mesh (extra polys for half-resolved tree shapes around the
character).
Tripo3D's animate_prerigcheck may reject the mesh because
background "limbs" confuse skeleton binding.
The fix: set style.concept_suffix in asset_gen.json to a
strong background-stripping directive. Aldenmere uses:
"concept_suffix":", PLAIN SOLID NEUTRAL GREY BACKGROUND, subject only centered against featureless backdrop, NO scenery, NO trees, NO buildings, NO landscape, NO ground, NO environment, NO foliage, NO sky, studio reference image style for 3D modeling"
This is appended to EVERY concept prompt for the game. Per-entity
prompts may still mention setting context (good for vibes), but the
suffix overrides for the BACKGROUND of the IMAGE specifically.
Empirical case 2026-05-18: morwen's first concept came back with
trees and houses despite "isolated against neutral background" in
the per-entity prompt. The aggressive suffix above resolves it.
For new games, copy this concept_suffix (and negative_prompt)
into asset_gen.json as part of the default style block. The
asset-gen pipeline doesn't enforce it — it's a convention.
Drop a .glb (or .gltf) export from Blender / Maya / GLB-emitting
tool into data/<game>/assets/ (or wherever you prefer) and point
visual.mesh at it directly. The engine loads the scene, hooks the
embedded AnimationPlayer's clips to the same animation_state_rules
machinery the code-drawn meshes use, and re-skins surfaces via
material_overrides.
Inspect the .glb to discover its slot names + clip names —
blind guesses silently fall back to baked materials:
python3 tools/inspect_glb.py path/to/file.glb
Output enumerates materials: (with names), meshes: (with
surface→material mapping), and animations: (clip names +
durations). Copy the names verbatim into material_overrides and
clip_alias.
clip_alias is required when the .glb's clip names don't match
your engine-side state names. Blender exports often use
PascalCase (Walking, Idle) while rules use lowercase (walk,
idle). The alias maps state → clip.
Skip code-drawn fallback if a .glb is present — visual.mesh
ending in .glb or .gltf short-circuits the mesh-library lookup.
Material overrides duplicate the imported material per-entity,
so two villagers with different material_overrides don't share
tinted colors.
A reproducible test asset lives at
godot/data/test_assets/cube_anim.glb. Regenerate with
python3 tools/synth_test_glb.py — it emits a 2-material cube with
Idle + Walking clips.
A2 extras (2026-05-18) — fields for AI-gen .glb integration
properties.mesh_yaw_offset for Tripo3D characters (REQUIRED, 2026-05-19):
Tripo3D's image-to-3D outputs the mesh's authored "front" along +Z
(toward the concept image's viewing angle — the side the concept was
drawn from). Yume's convention is -Z forward (state.facing=0 means
looking world-north which is -Z). Without compensation, a Tripo character
faces TOWARD the camera in third-person AND walks BACKWARD relative to
their visible front.
Compensate via properties.mesh_yaw_offset: 3.14159265 (π radians,
180°). entity_mesh_3d's _sync_yaw adds this offset to state.facing
when computing the rendered rotation.y. The mesh's authored +Z front
rotates to align with Yume's -Z forward.
Applies to ALL Tripo-generated character/animal meshes. Non-Tripo
meshes (Blender exports with explicit -Z front, code-drawn meshes,
existing aldenmere props like mud_hut) don't need the offset.
Empirical case 2026-05-19: player_marken + morwen rendered facing the
camera in third-person AND moonwalked (walked one direction, facing
opposite) before the offset was added.
visual.y_offset_mesh (preferred) or visual.y_offset (legacy)
— required for Tripo3D outputs and any .glb whose pivot isn't at the
mesh base. Tripo3D's natural mesh origin is at the geometric center,
so placing an entity at world y=0 sinks the lower half underground.
Preferred — author in MESH-space:
y_offset_mesh = -bbox.min.y // mesh-space, NOT scaled
Engine multiplies by current state.scale at sync time. This means
pattern-spawned variants with different scale (e.g. dwarf bushes via
scale_min/scale_max on the same fruit-tree def) also land correctly
— their per-instance scale is applied to the same mesh-space lift.
Constant lift regardless of per-instance scale. Pattern variants will
float (scaled down) or sink (scaled up). Only use when you're certain
no level pattern will scale this def's instances. New AI-gen output
should always use y_offset_mesh.
Auto-computed by tools/yume_assetgen when wiring AI-gen output to
an entity def. Manually adjustable via visual.y_offset_intentional: true for debris-artifact meshes (e.g. a fire pit with baked-in ash
below the visible ring — keep the artifact buried).
tools/validators/validate_mesh_y_offset.py catches missing/wrong
y_offset at sync time, AND flags legacy y_offset defs that get
spawned by patterns with off-spec scale ranges. Run as part of
tools/validators/run_all.py.
Empirical case 2026-05-18 — prop_tree_fruit shipped with
y_offset: 1.337 (correct at state_init.scale=3.5). A level scatter
pattern reused the def at scale_min: 0.3, scale_max: 0.55 for dwarf
bushes. The constant 1.337 lift was inherited regardless of
per-instance scale → bushes floated ~1.15m above ground. Migrating to
y_offset_mesh: 0.382 fixed all variants because the engine now
multiplies by state.scale per-instance.
material_overrides PBR fields — full schema (was: just
albedo_color):
Setting roughness / metallic factors ALSO clears their respective
PBR textures so the factor is authoritative. Without that, Tripo3D's
baked ORM (Occlusion/Roughness/Metallic) makes the override silently
partial — all 28 aldenmere entities shipped looking too reflective
for 1 iteration until the renderer was fixed (2026-05-18).
Per-entity tinting via material_overrides also drives distinctness
when 8+ structures look similar at distance (e.g. mud_hut warm
terracotta, lean_to cool blue-grey, market_stall punchy orange).
visual.shader (ADR 0052) — REPLACES the StandardMaterial3D
with a ShaderMaterial backed by a .gdshader file. Uniforms via
visual.shader_params. Used for animated / procedural visuals
where flat PBR isn't enough.
Available shared shaders under data/lib/shaders/:
water_stylized.gdshader — animated noise ripples for rivers /
ponds. Set on prop_water_plane-style entities.
ground_multi_biome.gdshader — used by ground_renderer; not
per-entity.
sky_clouds.gdshader — used by lighting_director; not
per-entity.
Authors can add new entity-level shaders following the same pattern.
The shader-as-primitive ADR (0052) covers fire glow, ice, magic
auras, force fields — anything that benefits from animated /
view-aware materials beyond StandardMaterial3D.
visual.animate + visual.rig_type (ADR 0053, 2026-05-18) —
opt-in skeletal animation via Tripo3D's rig + retarget pipeline.
For characters, animals, and any entity that walks/moves visibly,
adding animate: true makes the asset-gen pipeline produce a
multi-clip animated GLB instead of a static mesh.
"visual":{"mesh":"res://...player_marken_animated_<hash>.glb",// auto-set after gen"animate":true,"rig_type":"biped",// REQUIRED when animate=true"animation_clips":["idle","walk"],// optional; default"animation_state_rules":[// engine — ADR 0046{"if":{"velocity_magnitude_gt":0.1},"play":"walk"},{"default":true,"play":"idle"}]}
Allowed rig_type values (one per Tripo skeleton family):
rig_type
Use case
Default clips
biped
Players, NPCs
idle, walk (+ run, jump, attack, etc.)
quadruped
Wolf, deer, rabbit, dog
quadruped:walk
hexapod
Giant insect
hexapod:walk
octopod
Spider
octopod:walk
avian
Bird (probe API for clip list)
TBD
serpentine
Snake
serpentine:march
aquatic
Fish, eel
aquatic:march
others
Fallback rig — may fail prerigcheck
TBD
Cost per entity (one-time, ledger-cached forever after success):
Stage
Cost
image_to_model (existing)
$0.40
prerigcheck
$0.10 (cached even on reject)
rig
$0.30
retarget × N clips
$0.30 each
Biped total (idle + walk)
$1.40
Non-biped total (1 walk)
$1.10
Budget guidance:
Player + each named NPC: opt in. $1.40 per biped.
Generic crowd NPCs: usually keep static. Crowd costs scale to $20+
fast.
Predators / threats players track (wolf, boss): opt in. Visible
pursuit reads better animated than sliding.
Prey / ambient critters: optional. A single walk clip ($1.10/animal)
is enough to convey life.
"Others" rig: only when the entity genuinely doesn't fit other
taxonomies. Budget for a wasted $0.10 prerigcheck per entity.
Validator: tools/validators/validate_animate_scope.py enforces
animate + rig_type pair correctness at sync time. Run via
tools/validators/run_all.py demo_<name> --strict.
Non-biped clip diversity is limited: Tripo currently exposes ONE
preset per non-biped rig type (walk/march). Bipeds get 11 presets.
Animal animation_state_rules fall back to the single walk clip on
the default branch — animals walk continuously instead of idling
when stopped. Accept as v1 limitation; Tripo may add idle presets
later, at which point update entity defs (no engine change).
Strategy C: Code-draw fallback (default)
Pure JSON. Each entity references a shape from data/shapes.json
(2D) or data/meshes.json (3D):
{"id":"wheat_mature","visual":{"shape":"crop_mature","flip_with_velocity":true,// optional — mirror sprite when velocity.x flips sign"params":{"grain":"#d4b54a"}}}
This is the default fallback strategy — every entity should at
minimum have a shape reference. Library / AI-gen are upgrades.
Critical: shapes.json lives at data/shapes.json (root), NOT per-game.
The renderer's shapes_path is hardcoded to res://data/shapes.json.
A shapes.json placed at data/demo_<game>/shapes.json is dead — never
loaded. Add per-game shapes by appending to the root file.
(Empirically discovered: a sim demo once shipped a per-game shapes.json
that did nothing — every entity rendered as a grey circle. Tier 2.6h
finding.)
Visual sizing — use 12-30px range:
Small entities (seeds, tiles): radius 4-8 OK, but 8+ recommended
Medium (crops, animals, fish): radius 12-18
Large (structures, buildings): 25-40
Sun / large decor: 30-50
3-6px is too small to read at default zoom levels. Tinypond
shipped at 3-6px first and was illegible. Default to 12+.
Directional sprites should opt into flip_with_velocity: true.
Required for fish, characters, vehicles — anything that visually has
"front" and "back". Renderer mirrors scale.x based on velocity.x sign.
Convention: art is drawn facing right; flip happens when moving west.
A data/meshes.json entry can compose MANY primitives into one
recognizable object — a "kit". Each primitive is
{op, pos, size|radius|height, color} in UNIT space (y 0..1);
state.scale = [W, H, D] sizes the whole kit per instance. color
may be a literal hex OR a $param token resolved from the entry's
params block (or overridden per-instance by visual.params).
"house_2f":{"primitives":[{"op":"box","pos":[0,0.40,0],"size":[1.0,0.80,1.0],"color":"$albedo"},{"op":"prism","pos":[0,0.88,0],"size":[1.12,0.26,1.12],"color":"$roof"},{"op":"box","pos":[0,0.45,0],"size":[1.03,0.035,1.03],"color":"$trim"},{"op":"box","pos":[-0.27,0.25,-0.5],"size":[0.12,0.13,0.04],"color":"$window"}// ...door, more window rows, chimney],"params":{"albedo":"#b85030","roof":"#6e3b2e","door":"#2c1c12","window":"#7da8c0","trim":"#5a4836","chimney":"#4a4038"}}
ops available: box, sphere, cylinder, prism, capsule,
plane, quad, torus. The map pipeline (compose_world) routes a
class/bucket to a kit via the strategy's mesh field.
Buildings must READ as buildings, not extruded boxes. Two rules:
Proportional height — never ship thin towers. A fitted
footprint of ~2m with a 6-11m height reads as a tower, not a
house. Tie height to floor count: 1 floor ≈ 3.5m, 2 ≈ 6.5m,
3 ≈ 9.5m. For map-extracted buildings, the area-bucket picks the
floor tier (small=1f, medium=2f, large=3f) AND the matching kit.
Make the storey count legible. A 3-floor box with one window
doesn't read as 3 floors. Give each kit a window ROW per storey
plus a floor-divider trim band between rows (see house_1f /
house_2f / house_3f in meshes.json). The rows + dividers make
the floor count obvious at any fitted footprint.
$albedo is the per-instance body color; everything else is a kit
default.primitive_visual in compose_world overrides ONLY the
albedo param with the instance's color. Roof/door/window/trim keep
the kit's authored defaults — so author those to look good as a
family.
Building color comes from a DESIGNED albedo, NOT the semantic-map
classification hex. The catalog hex (e.g. townhall #c02040) is a
MAP CLASSIFICATION color picked for color-separation in the semantic
map — it is not a display color and often reads wrong (that crimson
renders as pink). Set the strategy's albedo field to a designed
building color (#b03828 brick-red) so the kit body uses it instead
of the raw classification hex. See [[feedback-prompt-game-perspective]]
and extraction_strategies.json — fountain/townhall both override
albedo this way. Empirical case 2026-05-27: townhall shipped pink
because compose_world used the #c02040 classification hex as the
body color until a strategy albedo override was added.
Current kits: house_1f/house_2f/house_3f (floor-tiered),
tower_kit, townhall_kit (two-tier + columns + finial),
bridge_kit (deck + railings + abutments), wall_kit (body + cap +
crenellation merlons), fountain_kit. Long-term these primitive
parts can be swapped for Tripo3D part-meshes on the same recipe.
Default to code-draw shapes. They're free, instant, deterministic.
Most prototypes ship with code-draw and never need real assets.
Pick library or AI-gen only when GDD demands bespoke style.
Apply $param overrides for variety. Same shape "tree" can render
differently per tree type via params: {"foliage": "#5fa53d"} vs
"#2d5a2d" — oak vs pine. Cheap visual diversity.
For AI-gen, pick ONE backend per project. Don't mix backends
— style consistency matters more than per-entity optimization.
Audio is optional + later. For MVP, no audio fields.
Apply collaboration protocol. Show the user 1-2 strategy
alternatives if the GDD is ambiguous about style.
Honest scope
You write JSON, not files. Actual image/model/audio generation is
the offline yume assets generate tool's job (Tier 2.5k).
Animation state machines are out of scope (Tier 4.3 polish).
Audio renderer is W2.5l — not yet built; audio fields you add today
will be consumed when it lands.
What good looks like
Every entity has at minimum a visual.shape (or sprite_2d / mesh)
Style choice is consistent across all entities (same backend, same
prompt prefix)
$param overrides used for cheap variation
AI-gen prompts are specific enough to produce recognizable art
File round-trips through engine
What bad looks like
Entity has no visual field (renderer falls to bare circle)
Mixed strategies inconsistently
1-word AI-gen prompts ("flower")
Backend config without auth_env
Mesh-footprint must match aabb_extents (added 2026-05-09)
When an entity has properties.aabb_extents: [hx, hy, hz] (collision
footprint) AND visual.mesh: NAME, the mesh MUST be authored at a
size matching the footprint. Otherwise: collision works but the
entity is invisible / wrong-sized to the player.
Empirical case 2026-05-09: prop_city_wall_long had
aabb_extents=[150, 2, 0.5] (150m collision footprint) but
visual.mesh="merchant_pillar_3d" — a 0.35m radius pillar. Player
walked into invisible walls everywhere; couldn't see the city
boundary. Fix: authored merchant_city_wall_segment_3d (10m × 4m
× 1m) and tiled segments along the perimeter.
Audit gate: when authoring a new entity def with
aabb_extents, immediately ask:
Does the referenced mesh match those dimensions?
If aabb is huge (≥10m on any axis), is the mesh a single big
primitive or should we tile multiple instances?
If aabb is tiny but the mesh has visual flair (lampposts,
landmarks), should the mesh be larger than aabb so it READS at
camera distance? (See "Visual scale must match frustum" below.)
Visual scale must match camera frustum (added 2026-05-09)
A 0.05m radius lamp head is invisible at ortho_size: 24 (24m
visible extent). Pixels per meter = viewport_width / ortho_size ≈
40 px/m. A 0.05m head is 2 pixels — invisible. A 0.3m head is
12 pixels — actually a lamp.
Rule: feature elements (lamps, signs, doors, weapons, anything
the player should NOTICE) need MIN-RADIUS scaling per camera mode:
Camera
ortho_size
min visible radius
iso_top_down
24
0.3m
top_down_3d
16
0.2m
third_person_3d
perspective
0.15m (closer)
first_person_3d
perspective
0.1m (intimate)
If the same mesh is used across modes, take the LARGEST minimum
(iso = 0.3m) so it's visible everywhere.
Camera mode picks WASD intuition (added 2026-05-10)
Camera mode
W = "up the screen" matches world axis?
WASD intuition
top_down_3d
YES — world-Z aligns with screen-Y
Pressing W walks the player straight up the screen. Best for action games / floor-walkers.
iso_top_down
NO — world axes rotated 45° from screen
Pressing W walks world-NORTH which appears diagonal UP-LEFT on screen. Tactics-RPG convention. Looks pretty but disorients new players.
third_person_3d / first_person_3d
YES via mouse-yaw — W means "forward in look direction" via velocity_set_relative
Standard 3D feel.
Empirical case 2026-05-10: Aldenmere shipped with iso_top_down
camera. Player perceived W+A as "wrong direction" because the iso
rotation makes world+screen axes mismatch. The world-frame WASD lib
sets velocity in WORLD axes (W = -Z = world-NORTH), but the screen
shows that as diagonal up-left. User feedback led to swapping to
top_down_3d for an intuitive feel.
Pre-ship check — camera mode picks the input bundle variant
(per ADR 0040, 2026-05-10):
Cross-reference required — when picking isometric_3d or
first_person_3d (or any future mode using velocity_add_relative),
the asset-designer's output MUST FLAG to the downstream
yume-content-designer that the player's state_init needs a
deceleration mechanism (either zero_velocity_pretick: true or
drag > 0). Without it the player suffers the facing-lag
"pulling" bug when mouse-turning mid-walk.
Full rule + empirical case 2026-05-10 at
.claude/rules/data-demo.md § "velocity_add_relative requires
deceleration mechanism". That path-scoped rule is the canonical
gate; asset-designer just hands off the requirement to content-designer
downstream.
Empirical case (2026-05-10): Aldenmere FP rollout. Asset-designer
picked first_person_3d camera but the content-designer's player
shipped with drag: 0 + no zero_velocity_pretick. User reported
"something pulling" on mouse-turn-mid-walk. Both skills' gates now
cross-reference the path-scoped rule.
Empirical case (2026-05-10): Aldenmere shipped iso_top_down with
the world-frame WASD bundle — pressing W produced screen-up-RIGHT
diagonal motion instead of straight-up. Visual capture confirmed
the bug class. Fixed by ADR 0040 + Aldenmere player opt-in.
The gate every asset-designer pass must run before declaring
camera selection done: state which input bundle variant goes with
the picked camera mode. If the variant doesn't exist (e.g., a
quarter-iso or back-view camera lands without an input bundle
variant), flag the gap to the systems-designer for a follow-up
ADR — DON'T ship the camera mode without the matching input
contract.
This complements visual-density axis 4 (FAT lamps every 8-15m) —
the spacing is one axis, the size-per-element is this gate.
Ambient-motion patterns (added 2026-05-09)
Static NPCs read as "lifeless meshes" even with distinct silhouettes.
Add motion via simple tagged tick rules:
// rules.json or via @lib.rules.ambient_wander when shipped{"id":"ambient_npc_wander","trigger":{"type":"tick","interval":60},"query":{"tags_all":["ambient_walker"]},"effect":{"type":"velocity_set","target":"self","x":"(randf() - 0.5) * 1.0 * (1 - floor(randf() + 0.4))","y":"(randf() - 0.5) * 1.0 * (1 - floor(randf() + 0.4))"}}
Tag ambient NPCs with ambient_walker. Every 60 ticks (~6s) they
get a small random velocity (~0.5 m/s, ~3m drift before re-roll).
The (1 - floor(randf() + 0.4)) term yields ~0 about 40% of the
time, making NPCs occasionally stand still — looks more lifelike
than constant motion.
Variants worth authoring per game:
patrol (ping-pong between waypoints): velocity flips sign on
tick boundary
schedule (work-by-day, sleep-by-night): query gates on
world.time_of_day; different velocities per phase
conversation cluster (NPCs gather in pairs): low-priority
pathfind toward another tagged NPC for 1-2 ticks
Even the simplest wander rule transforms the visual feel from
"statue gallery" to "village." Per visual-density axis 8
(purposeless flavor) + axis 5 (object density via motion).
Visual QA gate (mandatory)
Per .claude/rules/visual-qa.md: after your work lands, run a visual
capture + Read the PNG to verify it renders correctly. Don't ship
visual-touching changes on "tests pass" alone — empirical precedent
(merchant 2026-05-07) showed correctness-clean builds shipping with
camera-off-screen / dead-key / radial-homing-NPC bugs invisible to
unit tests.
You are Layer 2 of 5 in the soul workflow (per
.claude/rules/soul.md). Your job in this layer:
Per-NPC visual distinction — every named NPC must have a
silhouette / color palette / posture that distinguishes them at
a glance. Two named warriors should NOT look identical. Pick
distinct meshes OR distinct visual.params (shirt, hat, scale)
per named NPC.
Nameplate widget integration — engine ships a NameplateRenderer
that draws labels above any named_npc showing
properties.display_name. Verify every named NPC has
display_name set (fallback is entity_id, which reads as
"npc_garron" — ugly).
Per-archetype variation — "warrior class customer" and
"noble class customer" should look different. Different mesh
ideal; same mesh + distinctive color palette acceptable.
Soul minimum: every named NPC has nameplate + distinct visual.
Every customer archetype has its own mesh OR distinctive palette.
Visual density vocabulary (added 2026-05-09)
Per analysis of an isometric pixel-art RPG reference set
(docs/games/<game>/style-references-*.md when authored): soul
isn't asset fidelity, it's authoring density per square meter.
A pixel-art mobile game beats a photoreal mesh on a flat plane
every time — because of decisions per pixel, not pixels per inch.
Apply these 10 axes per game when authoring scene.json + entity
defs + initial placements:
1. Layered ground variation
No single-color floors. Any visible ground patch ≥10m² gets a
distinct material: grass / dirt-path / cobblestone / plaza-stone
/ wheat-field / water. Author 4-6 ground-tile mesh defs at
project start, place them in zones.
2. Edge transitions (no hard borders)
Every ground-tile boundary gets a darker 1m fringe OR a row of
small props (rocks, grass tufts) along the seam. Hard cuts read
as "two unrelated tiles," fringed cuts read as "one continuous
world."
3. Vertical depth
≥1 vertical break per significant landmark. Fountain on 0.5m
raised stone disc. Buildings have 0.3m foundation rims. Dungeon
entries are SUNKEN (player descends visibly). Steps and railings.
4. Micro-lights
Every dark area gets lights every 8-15m. Lights are FAT (radius
0.3+ for the lamp head, NOT 0.05) with bright warm color
(#ffe0a0). Window-glows on cottages at night. Campfires in
residential corners. The constellation of small warm dots IS the
ambient.
5. Object density
Target ~1 entity per 9-12 m² visible from typical camera frustum.
A 30×30m plaza area = 50-80 entities. If your level has 20
entities in that area, it WILL feel empty.
6. Diagonal accents
Every 4-6 entities, rotate one by 5-30° on the Y axis. Leaning
fence posts, tilted crates, slightly off-square stalls. Strict
grid reads "videogame test scene"; broken grid reads
"inhabited space."
Authoring pattern (added 2026-05-09): set state.yaw
(radians, Y-axis rotation) on instance overrides. The 3D + 2D
renderers read this and apply rotation when set; idempotent
when unset.
Apply via Python: hash the id deterministically into a small
pool of varied angles (mix positive + negative + a few zeros so
~30% stay axis-aligned). Empirical case: 14 of 16 buildings
across pendrel rotated, 2026-05-09.
7. Background framing
Every district has foreground framing on ≥2 sides — clusters of
trees, walls, cliffs, or large props that visually contain the
camera frustum. Without framing, the eye falls into the empty
horizon and the world feels like a flat plane.
8. Soul-bearing details (purposeless flavor)
15-25% of entities should have ZERO mechanical purpose. Drinking
patrons at tavern tables. Sleeping cat near fireplace. Hanging
laundry between cottages. Posted notices on walls. A wooden cart
with goods. The world feels INHABITED when the camera sees things
that aren't tied to quests.
9. Palette discipline per district
Each district picks 4-5 base tones + 1-2 accent colors. Heroes
and important UI ALWAYS use the accent — guarantees pop. Examples:
Pendrel = warm earth (brown/tan/green) + red flag/sign accent
Brookhaven = cool grey-blue + autumn-orange roofs
Dungeon = stone-blue + torch-orange
NPC clothing follows district palette except heroes (red cape /
blue armor — consistent pop across all districts).
Authoring pattern (added 2026-05-09): don't author one mesh
def per district variant — use visual.params overrides on
instances. The engine deep-merges params, so an instance only
specifies the keys it wants to override; the def's other params
survive.
// def (entities/buildings.json) — neutral default{"id":"prop_cottage","visual":{"mesh":"merchant_cottage_3d"}// mesh has its own params}// instance (levels/town/entities.json) — district override{"def":"prop_cottage","id":"townie_house_1","position":[20,0,25],"visual":{"params":{"wall":"#d8b890",// warm cream (NW residential)"roof":"#a04830",// terracotta"window":"#f0d878"}}}
Apply via small Python script that buckets by (x, z) into NW/NE/
SW/SE/C and writes the palette dict. Empirical case: 23 buildings
recolored across 4 districts in pendrel, 2026-05-09.
Audit gate: every multi-district game must demonstrate at
least 3 distinct district palettes via per-instance visual.params
overrides on cottages / props / signs. Single-palette across the
whole town = "videogame test scene" feel; failing this axis.
LATER (needs engine work): axes 2 (edge fringes), 3 (vertical
geometry), 5 (full density push), 7 (background framing).
Audit existing games for these 10 axes BEFORE declaring an
asset-designer pass complete. The visual gate (--capture + read
PNG) should explicitly check density: count entities visible in
viewport, count distinct ground colors, count micro-lights.
What soul is NOT (budget discipline)
NOT photorealism. Pixels are fine.
NOT particle volume. Reference set has zero particles.
NOT animation count. Static screenshots can carry soul.
NOT high poly count. Voxels work.
NOT screen-space effects (bloom, AO, lens flare).
NOT extensive UI. UI in refs is minimal — gameplay does the work.
Soul is authoring density + deliberate asymmetry + palette
discipline + purposeless flavor. Achievable without a single new
mesh primitive — just deliberate placement of what's already there.
REQUIRED HUD: objective banner (added 2026-05-08)
Every game's hud.json MUST include an objective (or equivalently
named) label binding to a state field on the world singleton —
typically world_clock.current_objective. Top-center anchor
preferred; secondary acceptable choices: top-banner full-width,
or just-below-stats.
This is the player's answer to "what do I do next?" surfaced
permanently. Without it, the player sees stats (gold, day, hp,
score) but no direction.
Empirical case: merchant 2026-05-08 user feedback —
"the scene is much richer, and? i still dont know what should i
do?". The HUD showed day/gold/debt but had no objective field.
yume-tutorial-designer authors the OBJECTIVE TEXT (rules that
update the field at every state transition); yume-asset-designer
authors the HUD SURFACE (binding + visual treatment).
This HUD entry is non-negotiable for any game with multi-state
progression (campaign, tutorial, quest chain). For pure ambient
games (an emergent-narrative sim-style), an objective-less HUD is fine.
What you DON'T do
❌ Run yume assets generate — separate workflow
❌ Modify engine code or shapes.json/meshes.json without ADR
❌ Pick game mechanics
❌ Validate that the generated game runs (qa-tester)
