Game UI workflow

Inspect the current game camera, input rules, UI framework and representative screens. Reuse the project's selected visual language and framework. Establish the information and actions the player needs before generating decorative art.

Design against real gameplay

Use a native game capture as the context for a proposal. Keep it intact when comparing HUD alternatives, so changing the background cannot disguise contrast or obstruction. Define shared surface, type, spacing and selection tokens; preserve semantic colours for ownership, health, danger and accepted choices.

Separate visual art from live data. Decide which values come from runtime state, which actions dispatch existing commands and what remains unimplemented. Show unavailable data honestly instead of inventing a currency, timer or gameplay rule. Include hover, selected, disabled, empty and overflow states when relevant.

Review the actual interface scale and aspect ratios. Corner anchors, minimum sizes, long labels and compact rosters should remain usable at a narrow viewport. Test the intended selection/grouping rules; unit type and team may be independent keys. A combined health display and a range of differing stats are different data.

Prepare reusable assets

Keep approved art and source masters, with stable asset IDs and a manifest of source paths/hashes. Export icons at their intended display scale. Check alpha edges on light/dark backgrounds, shared optical weight and silhouette readability. For stretchable panels, identify border regions explicitly; verify corners at several sizes before choosing nine-slicing or another rendering approach.

Static and animated portraits need the same crop and a reliable still fallback. Budget concurrent video decoders/render targets, share identical playback when appropriate and release hidden views. Portrait art should be data-driven rather than adding a new UI branch for each character. Preserve GUIDs and existing bindings when updating imported assets.

Integrate and prove interaction

Use the engine's existing UI tools or an available editor bridge. State the required framework/package instead of assuming a particular MCP is installed. Keep layout and world-input exclusion in agreement: a click over a panel must not also command the world. Verify hover/click, drag, keyboard focus, selection, minimap behaviour and pause/return paths that the changed screen owns.

Read current values and cooldowns from their authoritative systems. Avoid duplicating combat/production timers in presentation code. Reuse views, bound expensive updates and avoid per-frame texture readback for a minimap.

Save the real assets and check them in a fresh engine session. Deliver the theme, asset mapping, native captures, tested interactions and open decisions. A browser mockup approval is a design decision, not a claim of engine integration.

Example request: "Give the existing HUD a compact unit panel and six matching command icons." Success includes consistent icons, real selection data, working commands, overflow behaviour and no click-through. Dependencies: the current UI sources, game captures and target-engine access for implementation.