Skip to content

pre-asset-ui-pass.md

Latest commit

 

History

History
164 lines (112 loc) · 5.4 KB

pre-asset-ui-pass.md

File metadata and controls

164 lines (112 loc) · 5.4 KB

Pre-Asset UI Pass

Status: working scope for the last major player-facing UI pass before spending real time on Blender blockouts.

Why This Comes Before GLB

The next modeling pass should answer a stable interface contract, not guess at one.

If the client still changes how placement, selection, slicing, machine configuration, and diagnostics work, then asset work will either:

  • encode the wrong assumptions into silhouettes
  • over-model details the UI will later replace
  • or force the UI to bend around early art decisions

The correct order for the current slice is:

  1. lock the remaining player-facing UI behaviors
  2. define exactly what state the world and machines must communicate
  3. then build the first constrained GLB set against that contract

Goal

Reach a player-facing endpoint where the first playable no longer feels like a polished debug tool, but still stays analytical and simulation-first.

This is not a final UX pass. It is the pass that decides what information lives:

  • always in the HUD
  • in contextual panels
  • in overlays
  • in machine silhouettes
  • in transient feedback

What Must Be Locked Before Modeling

1. Build Flow

Players should be able to answer these questions instantly:

  • what am I about to place
  • how many do I have
  • why is this placement blocked
  • what key or click commits the action
  • what changed after placement/removal

Current direction:

  • keep the shared global build inventory
  • keep the hotbar as the primary quick-place surface
  • keep one continuous in-world build view, not modal screens

2. Inspect And Configure Flow

Players should be able to:

  • select one machine and understand its state
  • understand its ports and facing
  • see its current recipe/build recipe
  • see its immediate problem
  • adjust the few machine settings the slice already supports

Current direction:

  • one primary inspect panel
  • no separate machine configuration screen
  • contextual controls stay attached to selection, not hidden in menus

3. Slice And Overlay Policy

Before modeling, the project should lock:

  • what slice modes exist by default
  • whether faint-above structure remains part of the standard view
  • which overlays are structural and which are diagnostic
  • whether above-layer arrows/highlights are ever shown

Current direction:

  • keep Y slicing as the default build mode
  • keep faint-above structural hints
  • keep arrows, tutorial highlights, and similar diagnostics focused on current/below
  • defer X/Z inspect slicing until after the first asset pass unless playtests prove it necessary

4. Placement Feedback Contract

The client should consistently show:

  • valid vs blocked placement
  • support failure
  • occupancy failure
  • out-of-inventory failure
  • port/facing mismatch hints when relevant

This matters before modeling because it determines how much burden sits on the machine shape versus the UI.

5. HUD And Panel Hierarchy

The client should settle on a small number of panels with stable responsibilities:

  • HUD: scenario, simulation speed, objective state, slice/overlay state
  • build panel: hotbar counts, selected part, placement reason
  • inspect panel: selected or hovered machine state
  • prompt panel: tutorial/help only

Avoid adding more permanent panels before the first asset pass.

6. State Signals Assets Must Support

Before Blender work starts, the team should lock which states need to read from shape alone versus overlays/materials.

Assets must support these signals:

  • facing
  • likely item output side
  • likely power side
  • support contact / grounded base
  • category identity

Assets do not need to solve these alone yet:

  • detailed contamination state
  • exact throughput state
  • exact network membership
  • precise blockage reasons

Those remain UI/overlay responsibilities.

Features Worth Doing In This UI Pass

These are the highest-value remaining UI features before GLB work:

  1. Tighten the build panel so counts, selected part, and blocked-placement reasons are always obvious.
  2. Add one more layer of selected-part detail in the build palette so footprint, ports, and behavior are visible before placement.
  3. Improve diagnostics for placement and command failures beyond the status line.
  4. Keep refining panel hierarchy so the screen stays calm under normal play.
  5. Make the inspect panel expose real configuration choices for selected machines instead of only showing abstract state.
  6. Decide whether one lightweight build/catalog expansion panel is needed beyond the hotbar for the first playable.

Features To Defer Until After The First Asset Pass

  • final icon set
  • animated UI transitions beyond what already improves clarity
  • large modal menus
  • diegetic UI experiments
  • X/Z slicing unless a playtest makes it urgent
  • full machine config trees
  • multi-page codex or encyclopedia UI

Recommended Endpoint

The UI pass is done when:

  • a new player can finish the tutorial without needing terminal logs
  • build inventory and placement failures are legible from the client alone
  • the inspect panel answers "what is this doing and why is it failing"
  • the slice view feels stable enough that assets only need to improve readability, not rescue it
  • no obvious planned UI feature would materially change how belt, mixer, or dynamo should be modeled

Recommended Order After This

  1. finish the pre-asset UI pass
  2. model belt, mixer, and dynamo
  3. wire those GLBs into content
  4. run another playtest pass
  5. only then expand content or deeper systems