08 拆解UI

起点：UI 是玩家看到的「界面世界」

游戏程序有玩家看不到的部分（逻辑、数据、网络），也有玩家直接面对的部分——UI。

1
2
血条    技能栏    背包    地图    商店    任务
暂停菜单  设置    加载界面   标题画面

拆解 UI，就是回答：

玩家需要看到什么？怎么操作？每个界面背后连着什么？

一、UI 在游戏结构里的位置

闯关游戏的基础结构里，UI 是独立的一块：

1
2
3
4
5
6
7
8
9
游戏
├── 玩家
├── 背景
├── 障碍物
├── 敌人
├── 道具
├── 相机
├── UI          ← 独立于游戏世界
└── GameManager

UI 和游戏世界的关系：

1
2
3
4
游戏世界：游戏内部的状态（生命值、金币、关卡进度）
UI 世界：玩家看到的表示（血条、金币数、关卡进度条）

UI = 游戏世界的「投影」

它不改变游戏状态，只把状态展示给玩家，并把玩家的操作转回游戏世界。

二、拆解 UI 的第一步：玩家需要看到什么

设计流程的第十阶段是 UI 分析，起点是一个问题：

玩家需要看到什么？

1
2
3
4
5
6
血条（生命状态）
技能栏（可用能力）
背包（持有物品）
地图（空间位置）
商店（交易入口）
任务（目标信息）

把这些列出来，就是 UI 的清单。

拆解时对每个界面问：

1
2
3
4
1. 它显示什么？      哪个游戏状态（生命值、金币、进度）
2. 它接受什么操作？  点击、拖拽、按键
3. 操作改什么？      调用什么系统（买道具、换装备、开始关卡）
4. 什么时候出现？    常驻 / 条件触发（受伤才显血条）

三、UI 的两种形态

常驻 UI（HUD）

1
2
始终在画面上：血条、技能栏、小地图
显示的是高频状态，玩家随时需要看

弹出 UI（界面）

1
2
按需出现：商店、背包、设置、任务
通常是「另一个页面」，会暂停或覆盖游戏画面

拆解时要区分：常驻的尽量薄（不挡视线），弹出的尽量全（信息完整）。

四、UI 背后的连接：状态变化

UI 不是自己画自己，它连着一套机制：

1
2
3
4
5
游戏状态变化
  ↓
通知 UI
  ↓
UI 刷新显示

这正是 MVVM 的思路：

1
2
View（界面）      ←→   ViewModel（界面状态）   ←→  游戏系统
显示状态               持有状态、转发操作         真正改状态

拆解 UI 时要画清楚：

1
2
3
血条 ← 生命值变化 → 伤害系统
金币数 ← 金币变化 → 拾取系统 / 商店
进度条 ← 关卡进度 → 关卡系统

每个 UI 元素都有一条「状态来源」的链。

五、UI 操作的三条去向

玩家在 UI 上的操作，去向只有三类：

1
2
3
改游戏状态     点「攻击」→ 调用战斗系统
改界面本身     点「下一页」→ 只翻页，不碰游戏
改游戏配置     调音量 → 改设置（界面和游戏都可能变）

拆解时给每个操作标出去向，能立刻看出 UI 的耦合度：

1
2
操作只改界面 → 纯 UI，安全
操作直改游戏 → 注意调用链是否正确、是否同步

六、拆解 UI 的产物

1
2
3
4
UI 清单        有哪些界面、每个界面有哪些元素
状态映射表     每个元素显示哪个游戏状态
操作去向表     每个操作调用哪个系统
出现条件       常驻 / 条件触发 / 弹出

七、与其他线的关系

1
2
3
4
5
6
GUI-MVVM      UI 拆解的理论基础（View ↔ ViewModel ↔ 状态）
拆解结构       UI 是游戏结构的一部分（挂在 GameManager 下）
拆解美术       UI 素材来自美术资源
拆解资源       UI 素材清单属于资源规划
系统角色       入口系统在游戏里就是 UI 层
从输入到交互   UI 操作是「输入 → 交互」在游戏里的体现

小结

1
2
3
4
5
6
7
8
9
10
11
12
13
UI = 游戏世界的投影（显示状态 + 转发操作）

拆解四问：
  显示什么 / 接受什么操作 / 操作改什么 / 什么时候出现

两种形态：常驻（HUD，薄）/ 弹出（界面，全）

每个 UI 元素都有一条状态来源链：
  游戏状态 → 通知 → UI 刷新

操作三条去向：改游戏状态 / 改界面本身 / 改配置

产物：UI 清单 + 状态映射表 + 操作去向表