Game UI UX

Game UI/UX

This is the canonical generic game-interface contract. It combines the pictured game-ui-design, game-ui-ux, and Three.js game-UI planning lanes without duplicating engine widgets or the project-specific Open Design takeover workflow.

When to use this skill

Use it to:

• design or review a HUD, menu, inventory, shop, map, settings screen, or overlay;
• map player decisions to information priority and visibility rules;
• design screen flow, pause/overlay behavior, focus order, and back/cancel behavior;
• support mouse, keyboard, controller, touch, and assistive input consistently;
• handle aspect ratios, safe areas, text scaling, localization, and content expansion;
• replace per-frame UI polling with a documented state/event contract;
• compare mockups against real runtime states and target devices;
• build a verification matrix before engine implementation.

Do not use it for a landing-page UI, pure visual moodboard, engine-specific widget code, moment-to-moment juice, or a Darkbone Archer Open Design takeover. Route those to web design, Open Design game UI, game-feel, Unity, or Three.js specialists.

Instructions

1. Inventory real screens and states

Inspect the runtime, design files, screenshots, controller maps, supported devices, locales, and accessibility settings. Record each screen, overlay, modal, loading/empty/error state, and game phase. A mockup is partial evidence and must not delete states or information it does not show.

For each screen, name the player decision it supports. If an element supports no decision, feedback, status, or legal requirement, challenge its presence instead of polishing it.

2. Define information hierarchy

Classify information by urgency, persistence, and consequence:

• critical and immediate;
• current decision support;
• contextual or reveal-on-demand;
• historical or reference;
• decorative.

Record visibility triggers, dismissal behavior, conflict priority, and what happens under stress, pause, spectator, reconnect, loading, or reduced-HUD settings. Do not rely on color, position, audio, motion, or haptics as the only carrier of critical state.

3. Model navigation and screen flow

Use explicit screens and transitions rather than scattered booleans. Define push, replace, overlay, modal, pop/back, resume, disconnect, and destructive-action behavior.

For every input method, define initial focus, directional or sequential focus, activation, back/cancel, tab/section change, scroll, pointer takeover, and device-switch behavior. Focus must remain visible, predictable, recoverable after a layout change, and able to leave every focusable element.

Accessibility settings must be reachable before gameplay and fully navigable with declared input methods.

4. Define responsive layout and safe areas

Use layout constraints, containers, anchors, and content rules rather than one fixed pixel composition. Record:

• target device and aspect families;
• safe-area and overscan handling;
• persistent anchors and expandable regions;
• text and UI scaling behavior;
• reflow and scroll ownership;
• minimum readable states based on target-device testing;
• split-screen, picture-in-picture, or streaming overlays when applicable.

Do not copy a universal reference resolution, touch target, margin, or text size. Measure the target devices and apply platform accessibility guidance.

5. Make localization a layout state

Externalize player-visible strings and account for expansion, truncation policy, plural, gender, number/date formatting, bidirectional text, fonts, glyph coverage, line breaks, and input-glyph substitution. Test real representative strings rather than pseudo-localization alone.

Never bake English text into art or size a control only for its shortest label unless the product explicitly accepts that limitation.

6. Define the UI data contract

For each element, record its source, event or query, update conditions, stale state, permission, error state, and owner. Prefer event-driven updates for changes and explicit initial snapshots. Do not expose hidden multiplayer data through an interface binding.

Keep presentation state distinct from gameplay truth. A disabled control must explain why and how the player can proceed when that information is safe to reveal.

7. Verify the real interaction

Test every required screen and state across the target matrix. Include:

• pointer, keyboard, controller, touch, and assistive paths as declared;
• initial focus, logical traversal, focus restoration, and back behavior;
• aspect, orientation, safe area, UI/text scale, and locale changes;
• loading, empty, error, offline, reconnect, and destructive confirmations;
• HUD conflict under peak gameplay load;
• reduced motion, color-independent state, subtitles/captions, narration, and haptics as applicable;
• event update, stale value, unauthorized data, and rapid state-change cases.

Record the exact build, device or viewport, input method, locale, and observed result. A static screenshot does not prove navigation or state behavior.

8. Write and validate the contract

From this skill directory, copy references/contract-example.json, replace the example, and run:

python3 scripts/validate-game-ui.py game-ui-contract.json
python3 scripts/validate-game-ui.py --self-test

Return:

### Game UI/UX packet
- Player decision: <primary decision or flow>
- Screens and states: <covered runtime surface>
- Information hierarchy: <critical, contextual, hidden>
- Input and focus: <methods, initial focus, traversal, back>
- Layout and locale: <safe area, scaling, reflow, languages>
- Accessibility: <barriers and alternatives>
- Data contract: <source, update, stale/error behavior>
- Verification: <matrix result and missing evidence>
- Next owner: <concept, engine widgets, Three.js, feel, accessibility, or implementation>

Examples

Controller cannot navigate settings

Capture the real focus graph, initial focus, back behavior, and device-switch state. Fix the navigation contract before styling. Test every setting and confirm that scaling or locale changes preserve logical traversal.

Three.js HUD request

Use this skill for hierarchy, layout, focus, state, and verification. Route DOM/CSS or canvas implementation to the appropriate web/Three.js skill. Do not create a second threejs-game-ui-designer skill.

Darkbone Archer Open Design mockup

Route the concept, preservation handoff, or takeover to the existing Open Design game UI sequence. Use this generic contract only for cross-project UI/UX questions not owned by that project workflow.

Best practices

1. Reconcile mockups with real states, player decisions, inputs, and supported devices.
2. Treat focus, back, safe layout, localization, accessibility, and hidden data as dynamic contracts.
3. Verify interaction, then route visual concepts and engine widgets to their established owners.

References

• references/interface-contract.md: hierarchy, navigation, layout, localization, binding, and verification model.
• references/contract-example.json: complete validator-accepted contract.
• references/source-notes.md: upstream, engine, and accessibility evidence.
• scripts/validate-game-ui.py: read-only Python 3.9+ validator.