{"id":24669,"plugin_id":"plugins~Plugin_b12006c2cc04819192cb1c1227ac52f7","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:18:34.424Z","digest":"9908aed9031893c1cb2b8c80cdb9a1a7b5d2b8a38b65b7904d6eee69eae50e1b","against":null,"payload":{"name":"game-ui-frontend","description":"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.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":232}],"skill_md_contents":"---\nname: game-ui-frontend\ndescription: 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.\n---\n\n# Game UI Frontend\n\n## Overview\n\nUse 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.\n\nDefault assumption: build the game world in canvas or WebGL, and build text-heavy UI in DOM.\n\n## Frontend Standards\n\n1. Establish visual direction before coding.\n   - Genre and fantasy\n   - Material language\n   - Typography\n   - Palette\n   - Motion tone\n2. Use CSS variables for the UI theme.\n3. Build clear hierarchy.\n   - Critical combat or survival information first\n   - Secondary tools second\n   - Rarely used settings behind menus or drawers\n4. Protect the playfield first, especially in 3D.\n   - The initial screen should feel playable within a few seconds.\n   - Default to one primary persistent HUD cluster and at most one small secondary cluster.\n   - Keep the center of the playfield clear during normal play.\n   - Keep the lower-middle playfield mostly clear during normal play.\n   - Put lore, field notes, quest details, and long control lists behind drawers, toggles, or pause surfaces.\n   - Prefer contextual prompts and transient hints over permanent boxed panels.\n5. Keep overlays readable over motion.\n   - Use backing panels, edge treatment, contrast, and restrained blur where needed.\n6. Design for both desktop and mobile from the start.\n7. Design 3D UI around camera and input control boundaries.\n   - Pause or gate camera-control input when menus, dialogs, or pointer-driven UI are active.\n   - Keep pointer-lock, drag-to-look, and menu interaction states explicit.\n\n## 3D Starter Defaults\n\nFor exploration, traversal, or third-person starter scaffolds, prefer this UI budget:\n\n- one compact objective chip or status strip at the edge\n- one transient controls hint or interaction prompt\n- one optional collapsible secondary surface such as a journal, map, or quest log\n\nDo not open every informational surface on first load. The scene should be readable before the user opens any deeper UI.\n\nAs a default implementation constraint for 3D browser games:\n\n- no always-on full-width header plus multi-card body plus full-width footer layout\n- no large center-screen or lower-middle overlays during normal movement\n- no more than roughly 20-25% of the viewport covered by persistent HUD on desktop unless the user explicitly requests a denser layout\n- on mobile, collapse to a narrow stack or contextual chips before covering the playfield with larger panels\n\n## Prompting Rules\n\nWhen asking the model to design or implement game UI, include:\n\n- the game fantasy\n- the camera or viewpoint\n- the player verbs\n- the HUD layers\n- the camera or control mode when the game is 3D\n- the tone of motion\n- desktop and mobile expectations\n- playfield protection and disclosure strategy\n- explicit anti-patterns to avoid\n\nUse `../../references/frontend-prompts.md` for concrete prompt shapes.\n\n## Motion Rules\n\n- Prefer a few meaningful transitions over constant micro-animation.\n- Reserve strong motion for state change, reward, danger, and onboarding.\n- Respect reduced-motion settings for non-essential animation.\n- Keep 3D HUD motion from competing with camera motion.\n\n## What Good Looks Like\n\n- HUD elements are legible without flattening the scene.\n- Menus feel native to the game world, not like a SaaS admin panel.\n- Layout adapts cleanly across breakpoints.\n- Pointer, keyboard, and game-state feedback are obvious.\n- In 3D games, menu and HUD states do not fight camera control or pointer-lock.\n- In 3D games, the first playable view keeps most of the viewport available for movement, aiming, and spatial reading.\n- Persistent information density is low enough that screenshots still read as game scenes, not UI comps.\n\n## Anti-Patterns\n\n- Generic app dashboard layouts\n- Flat placeholder styling with no theme\n- Default font stacks without intent\n- Dense overlays that obscure the playfield\n- Large title cards or multi-paragraph notes sitting over a live playable scene\n- Equal-weight boxed panels distributed around every edge of the viewport\n- Controls, objectives, notes, and lore all expanded at once on first load\n- Full-width top-and-bottom chrome with large always-on center or body panels in 3D play\n- Excessive motion on every element\n- Canvas-only UI when DOM would be clearer and cheaper\n- Forcing HUD controls into the 3D scene when standard DOM would be clearer\n- Letting camera input remain active under modals or inventory panels\n\n## References\n\n- Shared architecture: `../web-game-foundations/SKILL.md`\n- Prompt recipes: `../../references/frontend-prompts.md`\n- Low-chrome 3D layout patterns: `../../references/three-hud-layout-patterns.md`\n- React-hosted 3D UI context: `../react-three-fiber-game/SKILL.md`\n- Playtest review: `../../references/playtest-checklist.md`\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}