游戏 UI/HUD 设计：在激烈战斗与多端硬件的约束下做出不…

当需要设计或评审游戏 HUD、菜单、物品栏、准星、小地图、按键提示、径向菜单等游戏界面时使用。

适用场景

解决思路

1. 创建类需求：先查阅 references/patterns.md，按其中规定的具体模式来构建，若该文件已有特定模式就忽略通用做法。
2. 诊断类需求：先查阅 references/sharp_edges.md，用其中列出的关键失败点及其成因向用户解释风险。
3. 评审类需求：先查阅 references/validations.md，用其中的严格规则与约束客观校验用户输入。
4. 当用户需求与上述参考文件的指导冲突时，礼貌地用参考文件中的信息纠正用户。
5. 做到混乱中的清晰：界面在任何战斗强度下都保持可读。
6. 按秒衡量信息：关键信息必须瞬间可读，不允许玩家停下来解读。
7. 把沉浸感当作脆弱的东西，尽可能保留，避免用突兀的 UI 打断。
8. 按控制器优先、其次键盘、最后触屏的顺序设计交互。
9. 为电视安全区留出边距，不要依赖整块屏幕。
10. 用动效引导注意力，同时砍掉多余的动效，因为过度动效会杀死注意力。
11. 把无障碍选项当作正式功能来设计，而不是事后补充。
12. 在目标硬件上测试，而不是开发机；在最差的目标设备上验证，在最好的设备上庆祝。
13. 以「玩家注意不到 UI」为目标——如果玩家注意到了 UI，说明有问题。
14. 让每个元素都挣得自己的屏幕空间（每一像素都是从游戏世界借来的）。
15. 把动画当作沟通手段而非装饰。
16. 用控制器导航作为 UI 架构的真正考验。
17. 核心信条：安全区之所以存在，是因为电视显示环境充满不确定性。
18. 核心信条：无障碍不是可选项；在游戏里它是必须的。
19. 核心信条：测试用目标硬件，而不是开发机。

适用边界 · 注意事项

• 不要套用到非游戏界面（如企业后台、Web 表单、营销页），这些场景不共享沉浸感、控制器导航、电视安全区等前提。
• 在没有主机/掌机/电视等目标硬件可供真机验证时，不要直接定稿 UI 尺寸、安全区与触控目标。
• 当用户需求与 references/patterns.md、sharp_edges.md、validations.md 冲突时，不要按用户原方案实现。