Game Ui Frontend

3D Starter Defaults

For exploration, traversal, or third-person starter scaffolds, prefer this UI budget:

• one compact objective chip or status strip at the edge
• one transient controls hint or interaction prompt
• one optional collapsible secondary surface such as a journal, map, or quest log

Do not open every informational surface on first load. The scene should be readable before the user opens any deeper UI.

As a default implementation constraint for 3D browser games:

• no always-on full-width header plus multi-card body plus full-width footer layout
• no large center-screen or lower-middle overlays during normal movement
• no more than roughly 20-25% of the viewport covered by persistent HUD on desktop unless the user explicitly requests a denser layout
• on mobile, collapse to a narrow stack or contextual chips before covering the playfield with larger panels

Prompting Rules

When asking the model to design or implement game UI, include:

• the game fantasy
• the camera or viewpoint
• the player verbs
• the HUD layers
• the camera or control mode when the game is 3D
• the tone of motion
• desktop and mobile expectations
• playfield protection and disclosure strategy
• explicit anti-patterns to avoid

Use ../../references/frontend-prompts.md for concrete prompt shapes.

Motion Rules

• Prefer a few meaningful transitions over constant micro-animation.
• Reserve strong motion for state change, reward, danger, and onboarding.
• Respect reduced-motion settings for non-essential animation.
• Keep 3D HUD motion from competing with camera motion.

What Good Looks Like

• HUD elements are legible without flattening the scene.
• Menus feel native to the game world, not like a SaaS admin panel.
• Layout adapts cleanly across breakpoints.
• Pointer, keyboard, and game-state feedback are obvious.
• In 3D games, menu and HUD states do not fight camera control or pointer-lock.
• In 3D games, the first playable view keeps most of the viewport available for movement, aiming, and spatial reading.
• Persistent information density is low enough that screenshots still read as game scenes, not UI comps.

Anti-Patterns

• Generic app dashboard layouts
• Flat placeholder styling with no theme
• Default font stacks without intent
• Dense overlays that obscure the playfield
• Large title cards or multi-paragraph notes sitting over a live playable scene
• Equal-weight boxed panels distributed around every edge of the viewport
• Controls, objectives, notes, and lore all expanded at once on first load
• Full-width top-and-bottom chrome with large always-on center or body panels in 3D play
• Excessive motion on every element
• Canvas-only UI when DOM would be clearer and cheaper
• Forcing HUD controls into the 3D scene when standard DOM would be clearer
• Letting camera input remain active under modals or inventory panels

References

• Shared architecture: ../web-game-foundations/SKILL.md
• Prompt recipes: ../../references/frontend-prompts.md
• Low-chrome 3D layout patterns: ../../references/three-hud-layout-patterns.md
• React-hosted 3D UI context: ../react-three-fiber-game/SKILL.md
• Playtest review: ../../references/playtest-checklist.md