子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、什么是 HUD二、HUD 最大的问题是什么三、一个核心原则四、HUD 的黄金分层PlayerHUD 负责SkillHUD 负责MiniMapHUD 负责五、为什么 HUD 不应该直接读全部 Store六、HUD 与 System 的关系七、伤害飘字怎么设计八、Boss HUD 是独立系统九、多端场景下的 HUD十、HUD 不应该拥有状态十一、未来的 HUDAI HUD十二、一个关键认知升级总结引言很多开发者刚开始做鸿蒙游戏时对 HUDHead-Up Display抬头显示的理解非常简单血条 金币 经验条 技能按钮然后直接写Column(){Text(${store.hp})Text(${store.gold})}游戏小的时候没问题但只要你开始增加Buff 任务 小地图 技能冷却 伤害飘字 Boss状态 队友状态很快就会出现一个现象HUD越来越复杂 页面越来越臃肿 性能开始下降最后整个 UI 变成巨型页面很多人以为HUD 只是一个界面。实际上在大型游戏里HUD 本质上是一个独立系统。一、什么是 HUD很多人理解HUD UI实际上HUD 游戏状态可视化层例如玩家状态HP MP 经验 等级敌人状态Boss血量 Debuff 仇恨系统状态任务 时间 金币 网络延迟本质都是Store中的状态经过HUD展示给玩家。二、HUD 最大的问题是什么很多项目后期会写成这样if(store.hp30){showWarning()}if(store.bossHp0){hideBossBar()}if(store.skillCd0){updateSkillIcon()}问题HUD开始写业务逻辑最后变成UI控制游戏而不是游戏驱动UI这是非常危险的。三、一个核心原则HUD 永远不应该决定游戏逻辑正确关系Store ↓ HUD而不是HUD ↓ Store例如错误if(buttonClick){store.hp100}正确buttonClick ↓ InputSystem ↓ ItemSystem ↓ Store ↓HUD更新四、HUD 的黄金分层推荐拆成HUD ├── PlayerHUD ├── SkillHUD ├── MissionHUD ├── MiniMapHUD ├── BattleHUD而不是GameHUD.ts 3000行PlayerHUD 负责血量 蓝量 等级 经验例如Componentstruct PlayerHUD{Observedstore:PlayerStorebuild(){Progress({value:store.hp,total:store.maxHp})}}SkillHUD 负责技能按钮 冷却显示 连招提示MiniMapHUD 负责地图 NPC 任务点这样职责清晰 独立维护五、为什么 HUD 不应该直接读全部 Store很多项目会这样Observedstore:GameStore然后整个HUD监听整个Store问题来了玩家金币变化整个HUD刷新经验变化整个HUD刷新Boss受伤整个HUD刷新性能直接崩掉正确方式PlayerStore SkillStore MissionStore拆分状态域例如PlayerHUD ↓ PlayerStore SkillHUD ↓ SkillStore这样局部更新性能提升巨大。六、HUD 与 System 的关系很多开发者容易混淆BattleSystem BattleHUD看起来很像其实职责完全不同。BattleSystem计算伤害 处理战斗 修改状态BattleHUD显示伤害 显示血条 显示Buff一句话System 改变世界HUD 展示世界。七、伤害飘字怎么设计很多人会写Text(-100)然后直接放页面问题难管理 难复用正确做法增加EffectHUD结构DamageText HealText CriticalText统一管理effectHUD.showDamage(100)这样战斗逻辑 视觉表现 完全解耦八、Boss HUD 是独立系统大型游戏中Boss血条 Boss技能提示 阶段切换 危险预警复杂度极高所以建议BossHUD独立存在。例如PlayerHUD BossHUD完全分开不要塞进一个页面。九、多端场景下的 HUD鸿蒙最大的特点手机 平板 PC屏幕差异巨大。传统思路做三套HUD维护成本爆炸。System 架构思路Store统一 HUD自适应例如手机 底部技能栏 PC 右下技能栏但读取的同一个SkillStore十、HUD 不应该拥有状态一个经典错误classSkillHUD{privatecooldown10}问题状态重复 数据不一致正确store.cooldown唯一来源StoreHUD只读十一、未来的 HUDAI HUD随着 AI Agent 加入游戏HUD 会出现新形态。例如AI建议 路径推荐 战斗策略 自动提示未来可能变成PlayerHUD BattleHUD AIHUDAI 不直接控制游戏而是辅助玩家决策十二、一个关键认知升级初学者认为HUD 界面进阶之后理解HUD 状态可视化系统再进一步HUD 是 Store 与玩家之间的翻译层。它负责把系统状态变成玩家能理解的信息总结鸿蒙游戏中的 HUD 设计推荐遵循Store ↓ System ↓ HUD ↓ Player核心原则Store存状态 System改状态 HUD展示状态如果用一句话总结优秀的 HUD 从来不是“界面堆砌”而是一个让玩家看懂游戏世界的状态可视化系统。
鸿蒙游戏 HUD 如何设计?
发布时间:2026/6/1 16:29:12
子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、什么是 HUD二、HUD 最大的问题是什么三、一个核心原则四、HUD 的黄金分层PlayerHUD 负责SkillHUD 负责MiniMapHUD 负责五、为什么 HUD 不应该直接读全部 Store六、HUD 与 System 的关系七、伤害飘字怎么设计八、Boss HUD 是独立系统九、多端场景下的 HUD十、HUD 不应该拥有状态十一、未来的 HUDAI HUD十二、一个关键认知升级总结引言很多开发者刚开始做鸿蒙游戏时对 HUDHead-Up Display抬头显示的理解非常简单血条 金币 经验条 技能按钮然后直接写Column(){Text(${store.hp})Text(${store.gold})}游戏小的时候没问题但只要你开始增加Buff 任务 小地图 技能冷却 伤害飘字 Boss状态 队友状态很快就会出现一个现象HUD越来越复杂 页面越来越臃肿 性能开始下降最后整个 UI 变成巨型页面很多人以为HUD 只是一个界面。实际上在大型游戏里HUD 本质上是一个独立系统。一、什么是 HUD很多人理解HUD UI实际上HUD 游戏状态可视化层例如玩家状态HP MP 经验 等级敌人状态Boss血量 Debuff 仇恨系统状态任务 时间 金币 网络延迟本质都是Store中的状态经过HUD展示给玩家。二、HUD 最大的问题是什么很多项目后期会写成这样if(store.hp30){showWarning()}if(store.bossHp0){hideBossBar()}if(store.skillCd0){updateSkillIcon()}问题HUD开始写业务逻辑最后变成UI控制游戏而不是游戏驱动UI这是非常危险的。三、一个核心原则HUD 永远不应该决定游戏逻辑正确关系Store ↓ HUD而不是HUD ↓ Store例如错误if(buttonClick){store.hp100}正确buttonClick ↓ InputSystem ↓ ItemSystem ↓ Store ↓HUD更新四、HUD 的黄金分层推荐拆成HUD ├── PlayerHUD ├── SkillHUD ├── MissionHUD ├── MiniMapHUD ├── BattleHUD而不是GameHUD.ts 3000行PlayerHUD 负责血量 蓝量 等级 经验例如Componentstruct PlayerHUD{Observedstore:PlayerStorebuild(){Progress({value:store.hp,total:store.maxHp})}}SkillHUD 负责技能按钮 冷却显示 连招提示MiniMapHUD 负责地图 NPC 任务点这样职责清晰 独立维护五、为什么 HUD 不应该直接读全部 Store很多项目会这样Observedstore:GameStore然后整个HUD监听整个Store问题来了玩家金币变化整个HUD刷新经验变化整个HUD刷新Boss受伤整个HUD刷新性能直接崩掉正确方式PlayerStore SkillStore MissionStore拆分状态域例如PlayerHUD ↓ PlayerStore SkillHUD ↓ SkillStore这样局部更新性能提升巨大。六、HUD 与 System 的关系很多开发者容易混淆BattleSystem BattleHUD看起来很像其实职责完全不同。BattleSystem计算伤害 处理战斗 修改状态BattleHUD显示伤害 显示血条 显示Buff一句话System 改变世界HUD 展示世界。七、伤害飘字怎么设计很多人会写Text(-100)然后直接放页面问题难管理 难复用正确做法增加EffectHUD结构DamageText HealText CriticalText统一管理effectHUD.showDamage(100)这样战斗逻辑 视觉表现 完全解耦八、Boss HUD 是独立系统大型游戏中Boss血条 Boss技能提示 阶段切换 危险预警复杂度极高所以建议BossHUD独立存在。例如PlayerHUD BossHUD完全分开不要塞进一个页面。九、多端场景下的 HUD鸿蒙最大的特点手机 平板 PC屏幕差异巨大。传统思路做三套HUD维护成本爆炸。System 架构思路Store统一 HUD自适应例如手机 底部技能栏 PC 右下技能栏但读取的同一个SkillStore十、HUD 不应该拥有状态一个经典错误classSkillHUD{privatecooldown10}问题状态重复 数据不一致正确store.cooldown唯一来源StoreHUD只读十一、未来的 HUDAI HUD随着 AI Agent 加入游戏HUD 会出现新形态。例如AI建议 路径推荐 战斗策略 自动提示未来可能变成PlayerHUD BattleHUD AIHUDAI 不直接控制游戏而是辅助玩家决策十二、一个关键认知升级初学者认为HUD 界面进阶之后理解HUD 状态可视化系统再进一步HUD 是 Store 与玩家之间的翻译层。它负责把系统状态变成玩家能理解的信息总结鸿蒙游戏中的 HUD 设计推荐遵循Store ↓ System ↓ HUD ↓ Player核心原则Store存状态 System改状态 HUD展示状态如果用一句话总结优秀的 HUD 从来不是“界面堆砌”而是一个让玩家看懂游戏世界的状态可视化系统。