创游世界广播驱动项目结构实战

1. 为什么要单独讲广播实战

很多人学广播时停留在“知道有这个东西”，但真正项目里会卡在：

UI 怎么通知地图
地图怎么通知 UI 刷新
一个事件会不会把逻辑绕晕
广播多了会不会难维护

广播真正有价值的地方，不是“高级”，而是它能帮你减少模块之间的硬连接。

2. 广播最适合解决什么问题

最适合的是：

一个模块想通知另一个模块发生了某件事，但不想把双方强绑定。

常见例子：

UI 按钮点了“打开背包”
玩家击杀了敌人
商店完成了一次购买
任务进度增加
波次开始/结束

这些本质上都是“事件”。

3. UI → 地图：最常见的广播用法

推荐流程：

UI 负责接收点击
UI 发广播表达意图
地图或系统层收到广播后执行真值逻辑
真值变化后，再通知 UI 刷新

例如：

UI 点击购买按钮
发广播：shop.buy_item
地图控制器收到后判断货币、扣钱、发奖励
再发 ui.refresh_shop 或 bag.refresh

核心原则：

UI 负责说“我想做什么”，地图/系统负责判断“能不能做、做完会改什么”。

4. 地图 → UI：不要反过来乱耦合

很多项目后期会乱，是因为地图逻辑到处直接点 UI 元素。

更稳的方式是：

地图真值变化
发刷新广播
UI 收到后自己决定怎么更新显示

好处：

UI 能换皮
真值逻辑不跟着碎掉
联机/本地差异更容易隔离

5. 广播命名建议

建议采用：

5.1 系统前缀 + 动作

例如：

ui.open_bag
ui.close_shop
shop.buy_item
battle.enemy_dead
task.progress_add
map.wave_start

5.2 动词尽量明确

避免：

doit
change
aaa
按钮1

5.3 一个广播尽量只表达一件事

不要让一个广播既表示“购买”，又偷偷做“刷新 UI、播音效、切页面、发奖励”所有事情。

6. 广播不适合做什么

6.1 不适合做所有细碎局部计算

例如对象自己内部一个临时数值运算，通常没必要广播。

6.2 不适合替代所有直接调用

如果两个逻辑天然属于同一对象内部的局部流程，直接写更清楚。

6.3 不适合把流程藏太深

如果一次点击要经过太多层广播才能知道发生了什么，后期非常难查。

7. 一个常见实战链路示例

以“打开商店并购买”为例：

7.1 打开商店

玩家靠近商店 NPC
点击交互
发广播 ui.open_shop
UI 页面响应并显示商店界面

7.2 购买物品

UI 点击物品购买按钮
发广播 shop.buy_item
地图/系统收到后判断：
- 钱够不够
- 背包是否有空间
- 是否满足前置条件
若成功：
- 扣货币真值
- 写入背包数据
- 发刷新广播
UI 收到 bag.refresh / currency.refresh 后更新显示

这里广播的作用是：

UI 不直接管理货币真值
商店逻辑不必绑死在某一个按钮上

8. 广播驱动项目的结构建议

8.1 UI 层

职责：

发起意图
接收刷新通知
更新显示

8.2 地图控制层

职责：

管理地图内共享逻辑
作为多个对象之间的协调中心
处理地图级事件广播

8.3 对象层

职责：

处理自身行为
在关键时刻发事件

例如：

敌人死亡时发 battle.enemy_dead
宝箱打开时发 loot.chest_opened

8.4 系统层

职责：

处理更高层流程
胜负、切图、全局倒计时等

9. 新手最常见的广播误区

9.1 把广播当万能胶

结果是所有东西都广播，最后根本不知道逻辑入口在哪。

9.2 没有命名规范

后期会出现几十个类似但意思不清的广播名。

9.3 UI 既发广播又偷偷直接改值

这样会形成双路径，后面特别难排错。

9.4 没有区分“事件”和“状态”

广播更适合传事件，不适合替代状态存储。

10. 一条很好记的原则

广播传事件，状态放数据源，UI管显示，地图/系统管真值。

如果你能一直守住这句，项目结构会稳很多。

11. 建议优先使用广播的场景

UI 与地图之间通信
地图多个模块之间的事件通知
战斗事件驱动反馈
任务系统监听击杀/拾取/到达事件
波次、关卡、结算这类阶段切换

12. 自我复盘：这篇文档的边界

12.1 这篇主要讲“广播怎么融入项目结构”

它不是广播功能总说明，也不是逐个积木块手册。若需要看概念总览，应优先回到广播机制专题。

12.2 仍可继续补反例

后续最值得补的是：

广播名混乱的反例
UI 偷改真值的反例
一次事件穿太多层广播的反例

这些会让文档更有实战辨识度。

13. 关联阅读

docs/教程资料/专题研究/广播机制深度解析.md
docs/脚本系统/专题研究/创游世界UI数据同步架构.md
docs/脚本系统/专题研究/脚本作用域与数据流深度研究.md
docs/脚本系统/专题研究/创游世界项目结构模板.md
docs/脚本系统/专题研究/创游世界背包与货币系统设计入门.md
docs/脚本系统/专题研究/创游世界格子UI与列表系统深度解析.md

AI自动文档建设报告

创游世界广播驱动项目结构实战

1. 为什么要单独讲广播实战

2. 广播最适合解决什么问题

3. UI → 地图：最常见的广播用法

4. 地图 → UI：不要反过来乱耦合

5. 广播命名建议

5.1 系统前缀 + 动作

5.2 动词尽量明确

5.3 一个广播尽量只表达一件事

6. 广播不适合做什么

6.1 不适合做所有细碎局部计算

6.2 不适合替代所有直接调用

6.3 不适合把流程藏太深

7. 一个常见实战链路示例

7.1 打开商店

7.2 购买物品

8. 广播驱动项目的结构建议

8.1 UI 层

8.2 地图控制层

8.3 对象层

8.4 系统层

9. 新手最常见的广播误区

9.1 把广播当万能胶

9.2 没有命名规范

9.3 UI 既发广播又偷偷直接改值

9.4 没有区分“事件”和“状态”

10. 一条很好记的原则

11. 建议优先使用广播的场景

12. 自我复盘：这篇文档的边界

12.1 这篇主要讲“广播怎么融入项目结构”

12.2 仍可继续补反例

13. 关联阅读

发现文档问题？

创游世界广播驱动项目结构实战 ​

1. 为什么要单独讲广播实战 ​

2. 广播最适合解决什么问题 ​

3. UI → 地图：最常见的广播用法 ​

4. 地图 → UI：不要反过来乱耦合 ​

5. 广播命名建议 ​

5.1 系统前缀 + 动作 ​

5.2 动词尽量明确 ​

5.3 一个广播尽量只表达一件事 ​

6. 广播不适合做什么 ​

6.1 不适合做所有细碎局部计算 ​

6.2 不适合替代所有直接调用 ​

6.3 不适合把流程藏太深 ​

7. 一个常见实战链路示例 ​

7.1 打开商店 ​

7.2 购买物品 ​

8. 广播驱动项目的结构建议 ​

8.1 UI 层 ​

8.2 地图控制层 ​

8.3 对象层 ​

8.4 系统层 ​

9. 新手最常见的广播误区 ​

9.1 把广播当万能胶 ​

9.2 没有命名规范 ​

9.3 UI 既发广播又偷偷直接改值 ​

9.4 没有区分“事件”和“状态” ​

10. 一条很好记的原则 ​

11. 建议优先使用广播的场景 ​

12. 自我复盘：这篇文档的边界 ​

12.1 这篇主要讲“广播怎么融入项目结构” ​

12.2 仍可继续补反例 ​

13. 关联阅读 ​

发现文档问题？

创游世界广播驱动项目结构实战

1. 为什么要单独讲广播实战

2. 广播最适合解决什么问题

3. UI → 地图：最常见的广播用法

4. 地图 → UI：不要反过来乱耦合

5. 广播命名建议

5.1 系统前缀 + 动作

5.2 动词尽量明确

5.3 一个广播尽量只表达一件事

6. 广播不适合做什么

6.1 不适合做所有细碎局部计算

6.2 不适合替代所有直接调用

6.3 不适合把流程藏太深

7. 一个常见实战链路示例

7.1 打开商店

7.2 购买物品

8. 广播驱动项目的结构建议

8.1 UI 层

8.2 地图控制层

8.3 对象层

8.4 系统层

9. 新手最常见的广播误区

9.1 把广播当万能胶

9.2 没有命名规范

9.3 UI 既发广播又偷偷直接改值

9.4 没有区分“事件”和“状态”

10. 一条很好记的原则

11. 建议优先使用广播的场景

12. 自我复盘：这篇文档的边界

12.1 这篇主要讲“广播怎么融入项目结构”

12.2 仍可继续补反例

13. 关联阅读