游戏 UI 前端
概述
当游戏需要可见的界面层时使用此技能。任务不是生成通用的仪表盘UI，而是生成一个可读性强、符合主题的浏览器游戏界面，以支持游戏体验。
默认假设：在 canvas 或 WebGL 中构建游戏世界，在 DOM 中构建文本密集的 UI。
前端标准
- 在编码前建立视觉方向。
- 游戏类型和幻想主题
- 材质语言
- 字体排版
- 调色板
- 动感基调
- 使用 CSS 变量定义 UI 主题。
- 构建清晰的层次结构。
- 关键战斗或生存信息优先
- 次要工具其次
- 少用的设置放到菜单或抽屉后面
- 首先保护游戏区域，特别是在 3D 游戏中。
- 初始屏幕应在几秒内感觉可以游玩。
- 默认显示一个主要的持久 HUD 集群和最多一个小的次要集群。
- 在正常游戏过程中保持游戏区域中央清晰。
- 在正常游戏过程中保持游戏区域下方中部大部分清晰。
- 将旁白、野外笔记、任务详情和长控制列表放到抽屉、开关或暂停界面后面。
- 优先使用上下文提示和临时提示，而不是永久的盒装面板。
- 确保覆盖层在运动场景下可读。
- 在需要时使用背景面板、边缘处理、对比度和节制模糊。
- 从一开始就同时设计桌面和移动端。
- 围绕相机和输入控制边界设计 3D UI。
- 当菜单、对话框或指针驱动的 UI 激活时，暂停或限制相机控制输入。
- 保持指针锁定、拖拽查看和菜单交互状态的明确性。
3D 入门默认值
对于探索、遍历或第三人称入门脚手架，优先选择以下 UI 预算：
- 一个紧凑的目标芯片或状态条在边缘
- 一个临时控制提示或交互提示
- 一个可选的可折叠次要界面，如日志、地图或任务记录
不要在首次加载时打开所有信息界面。场景应在用户打开任何更深层的 UI 之前就可读。
作为 3D 浏览器游戏的默认实现约束：
- 没有始终开启的全宽页眉加多卡片主体加全宽页脚的布局
- 在正常移动时没有大的中央屏幕或下方中部覆盖层
- 在桌面上，除非用户明确请求更密集的布局，否则持久的 HUD 覆盖的视口区域不应超过约 20-25%
- 在移动端，在使用更大的面板覆盖游戏区域之前，折叠成窄堆叠或上下文芯片
提示规则
当要求模型设计或实现游戏 UI 时，请包括：
- 游戏幻想主题
- 相机或视角
- 玩家操作
- HUD 层
- 当游戏为 3D 时的相机或控制模式
- 动感基调
- 桌面和移动端期望
- 游戏区域保护和披露策略
- 要避免的明确反模式
使用 ../../references/frontend-prompts.md 获取具体的提示模板。
运动规则
- 优先使用少量有意义的过渡，而不是持续的微动画。
- 将强烈的运动保留给状态变化、奖励、危险和入门引导。
- 对于非必要的动画，尊重减少运动设置。
- 让 3D HUD 的运动不与相机运动冲突。
好的范例
- HUD 元素可读且不压平场景。
- 菜单感觉像是游戏世界的一部分，而不是 SaaS 管理面板。
- 布局在断点之间干净地适应。
- 指针、键盘和游戏状态反馈明显。
- 在 3D 游戏中，菜单和 HUD 状态不与相机控制或指针锁定冲突。
- 在 3D 游戏中，第一个可游玩视图将大部分视口留给移动、瞄准和空间阅读。
- 持久信息密度足够低，截图仍被视为游戏场景，而不是 UI 合成图。
反模式
- 通用的应用仪表盘布局
- 没有主题的扁平占位样式
- 没有意图的默认字体堆叠
- 遮挡游戏区域的密集覆盖层
- 大的标题卡片或多段落笔记放在实时可玩场景之上
- 分布在视口每个边缘的等权重盒装面板
- 控制、目标、笔记和旁白在首次加载时全部展开
- 在 3D 游戏中全宽顶部和底部 chrome 加上大的始终开启中心或主体面板
- 对每个元素使用过多的动画
- 仅使用 Canvas 的 UI，而 DOM 会更清晰且代价更低
- 当标准 DOM 会更清晰时，将 HUD 控制强制放入 3D 场景
- 在模态框或库存面板下允许相机输入保持激活状态
参考资料
- 共享架构：
../web-game-foundations/SKILL.md - 提示模板：
../../references/frontend-prompts.md - 低铬 3D 布局模式：
../../references/three-hud-layout-patterns.md - React 托管的 3D UI 上下文：
../react-three-fiber-game/SKILL.md - 游戏测试检查清单：
../../references/playtest-checklist.md