Design UI surfaces for browser games. Use when the user asks for HUDs, menus, overlays, responsive layouts, or visual direction that must protect the playfield.
1k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
4915
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
Use this skill whenever the game needs a visible interface layer. The job is not to produce generic dashboard UI. The job is to produce a readable, thematic browser-game interface that supports the play experience.
Default assumption: build the game world in canvas or WebGL, and build text-heavy UI in DOM.
Frontend Standards
Establish visual direction before coding.
Genre and fantasy
Material language
Typography
Palette
Motion tone
Use CSS variables for the UI theme.
Build clear hierarchy.
Critical combat or survival information first
Secondary tools second
Rarely used settings behind menus or drawers
Protect the playfield first, especially in 3D.
The initial screen should feel playable within a few seconds.
Default to one primary persistent HUD cluster and at most one small secondary cluster.
Keep the center of the playfield clear during normal play.
Keep the lower-middle playfield mostly clear during normal play.
Put lore, field notes, quest details, and long control lists behind drawers, toggles, or pause surfaces.
Prefer contextual prompts and transient hints over permanent boxed panels.
Keep overlays readable over motion.
Use backing panels, edge treatment, contrast, and restrained blur where needed.
Design for both desktop and mobile from the start.
Design 3D UI around camera and input control boundaries.
Pause or gate camera-control input when menus, dialogs, or pointer-driven UI are active.
Keep pointer-lock, drag-to-look, and menu interaction states explicit.
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