创游世界广播完全指南
一句话摘要
广播是创游世界中跨对象、跨层级通知消息的事件驱动机制，核心价值在于解耦发起者和处理者，使 UI、地图、物体之间不需要硬绑死。
适合谁阅读
- 刚学会基础脚本，想要理解对象间通信的新手
- 遇到「广播没效果」或「广播乱发」问题的开发者
- 想了解 UI 与地图如何正确通信的创作者
- 需要做联机项目的开发者
你将学到什么
- 广播不是普通函数调用，而是事件通知机制
- 广播的三种核心用途（事件表达、动作请求、状态变化通知）
- 广播与 UI、地图的关系
- 广播命名的最佳实践
- 联机环境下广播的性能优化
- 广播的常见误区与避坑建议
一、广播基础概念
1.1 什么是广播
广播是一种「发消息给多个对象」的事件通知机制。
类比理解：
- 想象现实中的电台广播
- 发送者相当于电台
- 所有调到对应频道的接收者都可以收到信号
- 发送者不需要知道谁在收听
1.2 广播的工作原理
发送广播 → 所有监听该广播的脚本执行关键特点：
- 发送者不需要知道监听者的具体信息
- 监听者通过订阅事件来接收并响应消息
- 广播可以跨越对象、跨越层级传递
1.3 广播和普通函数调用的区别
| 对比项 | 普通函数调用 | 广播 |
|---|---|---|
| 发送者需要知道目标吗？ | 需要 | 不需要 |
| 接收者数量 | 一个 | 多个 |
| 耦合度 | 高（硬绑死） | 低（解耦） |
| 扩展性 | 差 | 好 |
二、广播的三种核心用途
用途 A：表达事件发生
广播用于表示「发生了什么」。
示例：
- 按钮被点击 → 发送「按钮_点击」广播
- 任务完成 → 发送「任务_完成」广播
- 角色死亡 → 发送「角色_死亡」广播
特点：
- 广播名称表达事件本身
- 所有关心这个事件的对象都可以监听
- 不关心事件后应该怎么处理
用途 B：表达动作请求
广播用于表示「我希望系统执行什么」。
示例：
- 请求打开界面 → 发送「请求_打开背包」广播
- 请求开始下一波 → 发送「请求_开始波次」广播
特点：
- 广播名称表达意图或请求
- 真正的处理逻辑由接收方决定
- 发送方不需要知道具体实现
用途 C：表达状态变化通知
广播用于表示「某个状态已经变化，请相关对象自行同步」。
示例：
- 背包更新 → 发送「背包_更新」广播
- UI 需要刷新 → 发送「刷新_界面」广播
特点：
- 广播名称表达状态变化
- 接收方根据自身逻辑决定如何响应
- 适合多人联机同步
三、广播的基本用法
3.1 怎么发送广播？
在脚本中使用积木块发送广播：
发送广播 "广播名称"或者带参数的广播：
发送广播 "道具_获得" 并携带数字 100
发送广播 "任务_完成" 并携带文本 "任务A"3.2 怎么接收广播？
在脚本中设置触发时机为「当收到广播时」，然后填写广播名称：
当收到广播 "道具_获得" 时
→ 执行相应逻辑
结束3.3 接收广播时怎么获取参数？
当收到广播 "道具_获得" 并携带数字 时
→ 获取道具数量
→ 显示 "获得 " + 参数 + " 金币"
结束3.4 广播可以带参数吗？
可以。参数可以是数字或文本。
发送广播 "道具_获得" 并携带数字 100
发送广播 "任务_完成" 并携带文本 "任务A"四、广播的作用域
| 作用域 | 说明 |
|---|---|
| 当前地图 | 广播只在当前地图内传播 |
| UI 广播 | UI 可以向地图发广播，地图处理后再通知 UI |
| 向当前 UI 发广播 | 地图向当前显示的 UI 发广播 |
⚠️ 注意：广播默认只能在当前地图内传播，不能跨地图通信。跨地图通信需要用玩家变量或系统属性。
五、广播的典型使用场景
场景 1：UI 通知地图处理
场景：玩家在 UI 界面上点击购买按钮，需要扣除金币。
推荐做法：
// UI 脚本
当点击按钮时
→ 发送广播 "请求购买"
结束
// 地图脚本
当收到广播 "请求购买" 时
→ 检查金币是否足够
→ 如果足够，扣除金币并发放物品
→ 发送广播 "购买成功"
结束
// UI 脚本
当收到广播 "购买成功" 时
→ 刷新界面
结束场景 2：一个事件触发多个响应
场景：敌人死亡时，需要同时播放死亡特效、更新任务进度、掉落物品。
// 敌人脚本
当生命值变为 0 时
→ 发送广播 "敌人_死亡"
结束
// 特效脚本
当收到广播 "敌人_死亡" 时
→ 播放死亡动画
结束
// 任务脚本
当收到广播 "敌人_死亡" 时
→ 更新任务进度
结束
// 掉落脚本
当收到广播 "敌人_死亡" 时
→ 生成掉落物品
结束场景 3：跨对象通信
场景：点击一个物体，触发另一个物体的行为。
// 按钮脚本
当互动按钮被按下时
→ 发送广播 "打开机关"
结束
// 门脚本
当收到广播 "打开门" 时
→ 播放开门动画
结束六、广播命名规范
6.1 推荐的命名方式
广播名尽量表达「事件/意图」，而不是实现细节。
| 广播名 | 说明 |
|---|---|
| 开始挑战 | 表达事件 |
| 打开背包 | 表达意图 |
| 任务完成 | 表达状态变化 |
| 刷新界面 | 表达请求 |
| 玩家准备完成 | 表达玩家状态 |
6.2 不推荐的命名
| 广播名 | 问题 |
|---|---|
| 广播1 | 无意义 |
| 执行那个功能 | 太模糊 |
| 刷新1 | 不知道刷新什么 |
| 刷新2 | 不知道刷新什么 |
命名越像「事件语言」，项目就越容易维护。
6.3 命名示例对比
| 功能 | ❌ 不推荐 | ✅ 推荐 |
|---|---|---|
| 金币变化 | 刷新 | 金币_变化 |
| 背包更新 | 刷新背包 | 背包_更新 |
| 任务完成 | 任务 | 任务_完成 |
| 波次开始 | 下一步 | 波次_开始 |
七、联机环境下的广播
7.1 联机广播的特点
在联机环境下使用广播需要注意：
| 问题 | 说明 | 解决方案 |
|---|---|---|
| 上传延迟 | 公共数据需要同步给其他玩家 | 减少连续多次写入 |
| 帧率限制 | 旧版本 UI 帧率被限制到 20 帧 | 更新到 4.52.54+ 版本 |
| 数据冲突 | 多玩家同时操作可能冲突 | 使用地图层集中处理 |
7.2 联机广播最佳实践
UI 只发请求广播
当按钮被点击时 → 发送广播 "请求_购买" 结束地图集中处理
当收到广播 "请求_购买" 时 → 在地图层检查和处理 → 处理完成后发广播通知 UI 结束UI 收到结果后刷新
当收到广播 "购买_完成" 时 → 刷新 UI 显示 结束
7.3 4.52.54+ 版本优化
4.52.54 版本后，每个玩家只运行自己的 UI 逻辑，显著提升了：
- 玩家人数较多的场景
- UI 界面复杂的场景
- 需要无限循环实现动画的场景
八、广播常见问题排查
8.1 为什么广播发了但没效果？
检查清单：
| 检查项 | 说明 |
|---|---|
| 广播名称是否一致 | 注意大小写、空格、标点符号 |
| 监听脚本是否在正确触发时机 | 需要「当收到广播时」触发时机 |
| 监听者在广播发送时是否存在 | 如果对象已销毁则不会响应 |
| 广播发送时机是否在监听者初始化之后 | 确保监听者先注册 |
8.2 广播和指令调用有什么区别？
| 特性 | 广播 | 指令调用 |
|---|---|---|
| 接收者数量 | 多个 | 单个 |
| 依赖关系 | 解耦 | 耦合 |
| 灵活性 | 高 | 低 |
| 性能 | 中等 | 高 |
| 适用场景 | 事件通知 | 精确控制 |
九、广播的常见误区
误区 1：到处发广播，名称混乱
后果：
- 很难追踪谁在响应
- 一改名字全项目崩
- 调试体验很差
误区 2：广播里塞太多底层细节
推荐做法：
- 广播表达「意图」
- 具体实现放在处理端
误区 3：能直接调就不分层
后果：
- UI 绑死地图内部结构
- 项目可复用性很差
短期看省事，长期看容易失控。
误区 4：一个广播干所有事
错误示例：
// ❌ 一个广播干了太多事
当点击按钮时
→ 发送广播 "处理一切" // 扣钱+发道具+刷新UI+播音效+加成就
结束推荐做法：
// ✅ 多个职责明确的广播
当点击按钮时
→ 发送广播 "请求购买"
结束
当收到广播 "请求购买" 时
→ 扣钱
→ 发道具
→ 发送广播 "购买完成"
结束
当收到广播 "购买完成" 时
→ 刷新UI
结束
当收到广播 "购买完成" 时
→ 播放音效
结束
当收到广播 "购买完成" 时
→ 增加成就进度
结束相关页面
- 创游世界广播使用速查卡 - 广播快速查询表
- 广播机制深度解析 - 广播机制深入分析
- 创游世界变量完全指南 - 变量系统入门
- 创游世界脚本入门教程 - 零基础脚本入门
- 常见问题与避坑指南 - 常见问题解决
最后更新：2026-06-16维护者：Azek431