aetherbound-guild/docs/presentation/PHASE6_ASSET_PRODUCTION_PLAN.md

Phase 6 UI And Asset Production Plan

Date: 2026-08-12 Visual baseline: UI06-05 Stage: FORMAL_UI_MASTERS

Decision

Create formal UI masters before the final asset library. In parallel, define the asset contracts and prove one bounded animation slice. Do not generate the complete content library until page composition, play-size scale and motion anchors are stable.

This order prevents three expensive failure modes:

1. attractive sprites that are unreadable at the final camera scale;
2. UI chrome that cannot hold Simplified Chinese, 130% text or touch targets;
3. hundreds of assets whose camera, outline, pivot, light or palette no longer match the approved game surface.

Phase A — Formal UI Masters

Create and review these master compositions:

Master	Covers
Title and Continue	SYS-003/004, accessibility entry and safe-run summary
New Run and Recruit choice	SYS-005/006, four offers, choose two, no recommendation
Integrated Market	HUB-001, SHP-001..003, Company, offers, inventory and modes
Party Line and Equipment	PTY-001/002, EQP-001/002, order, relations and item delta
Result, Death and Recovery	OUT-001..006, causal result, permanent loss and legal exits
Guild, Dialogue and Settings	hub notices, contract briefing, system dialogue, modal and settings grammar
UI component board	windows, rails, tabs, buttons, states, bars, icons, receipts and empty/error/loading patterns

The approved battle master UI06-05 remains the battle family baseline. After the masters pass, apply their components to all 50 page/state definitions in the HTML Gallery with real engine-style Chinese and English text.

What AI Generates And What UI Code Owns

AI-generated raster candidates may own:

• environment masters and parallax source layers;
• character/enemy identity anchors and compatible action rows;
• physical equipment, artifacts, props and semantic icon candidates;
• texture-bearing frame corners, tabs, rails, seals and decorative chrome;
• dialogue portraits and major outcome illustrations where the screen contract requires them.

Runtime UI must own:

• all text, numbers, costs, tooltips and localization;
• layout, scrolling, safe areas, focus, selection and touch targets;
• progress/health bars, disabled/locked/pending/complete states;
• button hit regions, input semantics, responsive tracks and accessibility;
• nine-slice assembly, palette/state tinting and receipt timing.

No generated screenshot becomes a single flattened production screen.

Phase B — Motion Pipeline Proof

Prove exactly three canonical runtime subjects before content expansion:

1. one base-Profession generated Recruit at 120-165px play height;
2. one ordinary enemy in the same camera and light; and
3. one boss at 260-320px play height.

Required state families:

Subject	Required states
Recruit	idle/breathe, advance, basic attack, Profession action, hit, guard/mitigate, death, victory
Ordinary enemy	idle, advance, attack/telegraph, hit, stagger, death
Boss	idle loop, anticipation, attack, impact recovery, phase change, stagger, death

Generate one compatible action row at a time through sprite-gen; never use a one-shot mixed animation sheet as a final atlas. Lock the accepted idle identity first. Keep feet/baseline, body size, facing, camera and light stable. Generate detached VFX separately so effects cannot alter body extraction or imply an uncommitted result.

Every row is chroma-processed, component-extracted, anchored and inspected as a moving loop. Contact sheets alone do not pass motion. Review at actual battle scale with ten allies and a busy enemy group before accepting the pipeline.

Phase C — Final Asset Library

Generated Recruits

Use modular presentation rather than a unique hand-authored sprite set per random Recruit:

• shared adult body/pose families;
• skin, face, hair and survival-mark layers;
• Profession-owned silhouette, garment, tool/weapon and action vocabulary;
• equipment overlays only where the item must visibly change combat read;
• semantic palette variants that preserve profession and state contrast.

The 12 base, 24 advanced and 6 hidden Professions require 42 readable identities, but compatible weapon/action families should share validated motion grammar.

Enemies And Bosses

Group the 100 ordinary/elite enemies into compatible regional rig families only when body plan, camera, anchor and motion truly match. Never recolor one body and call it a mechanically distinct enemy. The 16 bosses receive dedicated anchors, phase silhouettes and attack telegraphs.

Equipment, Artifacts And UI Icons

• Batch compatible small assets in regular 3x3 or 4x3 2K sheets.
• Keep every cell complete with a shared camera, light and removable background.
• Slice deterministically, inspect edge contamination and export actual-size 128px/256px variants.
• The 320 equipment items and 60 Artifacts are produced by category sheets, not one call per object and not one unreviewable giant sheet.
• UI icons use a separate simpler silhouette family from painted inventory art.

Environments

Create one 16:9 master battle scene for each of eight Regions before layer production. After approval, derive sky, far environment, midground, ground and foreground layers from that master. Keep mobile runtime textures at or below 4096px per layer and extend long stages through controlled outpaint chains, not independently generated segments.

Dialogue And Windows

Aetherbound does not add relationship or fixed-protagonist story systems. Dialogue presentation is reserved for contract briefing, guild notices, tutorial explanation, enemy discovery and short generated-Recruit remarks.

• Use one edge-attached speaker portrait or small full figure, not a gacha card.
• Keep speaker, concise message, history/log, advance and skip visible.
• Use two response choices only when the product contract defines a real state difference; routine dialogue is not fake choice.
• Confirmation windows state target, before/after, cost, consequence and undo policy. Generated art never contains final text.

Evidence States

Track every asset independently as:

source -> processed -> imported -> integrated -> runtime_seen -> agent_visual_reviewed -> human_reviewed -> device_verified -> release_accepted

Formal UI images and sprite rows begin as source or concept_direction only.