创游世界脚本实战架构入门
本专题不是单纯罗列积木，而是把当前知识库里已经整理出的组件、作用域、广播、UI、系统脚本等内容，收束成一套更接近“实际做项目”的脚本架构思路。
它要解决的核心问题是：在创游世界里，功能不是怎么拼出来，而是怎么不拼乱。
1. 实战里最常见的混乱来源
很多工程越做越乱，通常不是因为不会写积木，而是因为下面这些问题：
- 什么状态都往一个地方写
- UI 直接操控地图逻辑
- 多个对象互相强依赖
- 一个组件既管数据又管表现又管流程
- 地图属性、系统属性、自身属性混着用
- 旧版本 UI 写法和新版本推荐写法混在一起
所以脚本实战的重点不是“多会几个积木”，而是： 会不会分层，会不会让数据流清晰。
2. 建议的最小架构单位：对象 + 组件 + 状态 + 入口
在创游世界里，一个可维护的功能单元通常至少包含：
- 一个对象：功能真正挂载的载体
- 一个或多个组件：能力来源
- 一组状态：记录这个对象当前处于什么情况
- 一个或多个入口：什么时候执行、由谁调用、如何触发
例子：一扇可交互门
可以拆成：
- 对象：门
- 组件：可互动、物理/阻挡、自定义组件
- 状态：是否开启、是否锁定
- 入口：玩家交互时、收到广播时、执行自定义指令时
如果这样拆，门就不只是“一个会开关的贴图”，而是一个可被多个系统调用的功能单元。
3. 先分清四层数据作用域
当前知识库可确认的核心作用域有：
- 局部变量
- 自身属性
- 当前地图属性
- 系统属性
3.1 局部变量
适合：
- 当前一次执行过程中临时使用的数据
- 中间计算结果
- 不需要跨多次触发保留的值
不适合：
- 记录长期状态
- 给 UI 或其他对象长期读取
3.2 自身属性
适合：
- 某个对象自己的状态
- 例如门是否开启、怪物是否已激活、机关是否已触发
这是最常用、也最安全的对象级状态层。
3.3 当前地图属性
适合：
- 当前地图范围内共享的数据
- 例如关卡进度、地图内任务状态、当前波次、地图倒计时
如果某个状态需要在地图中多个对象之间共享，但不必跨全局系统长期存在，优先考虑地图属性。
3.4 系统属性
适合：
- 更高层级、跨地图或跨系统的全局状态
- 例如全局设置、联机房间状态、系统级开关
系统属性不要滥用。否则后期你会发现一堆逻辑都在“抢写同一层全局状态”。
4. 建议的分层思路
第一层：对象内部逻辑
处理对象自己的事情：
- 受击
- 播动画
- 改朝向
- 改自身属性
- 生成子物体
- 销毁自身
这层尽量不要直接操控全局流程。
第二层：地图内协作逻辑
处理同一张地图中的对象协作：
- 门和开关联动
- 怪物死亡后掉落奖励
- 一组机关共同开启
- 地图进度推进
这层优先考虑地图属性和广播。
第三层：UI 展示逻辑
处理：
- 显示当前血量
- 显示货币数
- 提示任务状态
- 更新按钮文本和进度条
UI 层尽量少直接写玩法逻辑，更适合做“显示”和“交互入口”。
第四层：系统级流程逻辑
处理：
- 胜负判定
- 切换地图
- 计时器
- 声音系统
- 联机状态
这层是最上层，适合集中管理游戏流程，而不是承载具体某一个物体的小逻辑。
5. 广播为什么是架构关键
广播最重要的价值，不是“方便”，而是“解耦”。
不推荐的写法思路
- 某个按钮脚本里直接到处找对象改状态
- 某个怪物死亡时直接硬连 UI、奖励、任务系统
- 某个 UI 组件直接把地图里很多东西都写一遍
这样做短期能跑，长期一定乱。
推荐的思路
让事件先发生，再让各系统自己响应：
- 玩家死亡 → 发送广播
- UI 收到广播后弹出失败界面
- 任务系统收到广播后记录失败次数
- 音效系统收到广播后播放音效
这样每个系统只关心“我收到什么”，而不是“我要亲自操控全世界”。
6. 自定义组件最适合承担什么职责
自定义组件非常适合承担三种职责：
6.1 状态容器
例如：
- 是否被激活
- 当前等级
- 冷却剩余
- 是否已领取奖励
6.2 可复用行为模块
例如：
- 一个门组件
- 一个可采集资源点组件
- 一个签到奖励组件
- 一个抽奖机组件
6.3 对外接口层
通过“指令”对外提供统一调用方式。
这意味着别的对象没必要知道你内部怎么写，只需要知道：
- 执行哪个指令
- 提供什么参数
- 会产生什么结果
这就是可维护性的关键。
7. UI 层最容易犯的错
常见错误
- 在 UI 里堆大量玩法主逻辑
- UI 和地图对象互相硬连
- 一个按钮直接控制很多对象内部状态
- 不区分地图 UI、操作 UI、物体 UI 的职责
更推荐的思路
UI 做三件事就够了：
- 展示状态
- 提供交互入口
- 通过广播或明确入口通知下层逻辑
例如：
- 点击按钮 → 发广播 / 调用某对象指令
- 地图状态变化 → UI 收到通知后刷新文本
- 玩家属性变化 → 物体 UI 或地图 UI 更新显示
8. 适合新手练的 4 个架构闭环
8.1 门机关闭环
包含：
- 按钮
- 门
- 广播或指令
- 自身属性
能学会：交互、状态、事件、对象协作。
8.2 血量显示闭环
包含：
- 生命组件
- 受伤逻辑
- UI 血条
- 广播或状态同步
能学会：玩法状态到界面显示的同步。
8.3 货币收集闭环
包含：
- 掉落物 / 可拾取物
- 玩家碰撞或交互
- 地图或系统级货币变量
- UI 货币条
能学会：拾取、累计、界面更新、数据归属。
8.4 奖励领取闭环
包含：
- 按钮
- 条件判定
- 发奖逻辑
- 已领取状态记录
- UI 文本变化
能学会：条件、状态锁定、一次性奖励流程。
9. 一个更稳的实战原则
做功能时尽量按下面顺序思考：
- 这个功能属于哪个对象？
- 需要哪些组件？
- 状态应该存在哪一层？
- 谁来触发它？
- 谁需要知道结果？
- 结果是直接调用，还是发广播？
- UI 是主逻辑，还是只负责显示？
如果这七个问题能先想清楚，脚本大概率就不会乱得太夸张。
10. 与现有知识库的关系
这份文档相当于把以下文档进行“项目视角重组”：
脚本界面与积木知识索引自定义组件深度解析脚本作用域与数据流深度研究系统级脚本能力解析广播机制深度解析UI系统与切换机制解析联机UI演进专题
它不负责提供逐张证据，而是负责把这些知识变成一套更像“做项目的方法论”。
11. 可检索关键词
- 创游世界脚本架构
- 创游世界项目结构
- 自定义组件怎么设计
- 地图属性和系统属性区别
- 广播怎么解耦
- UI 逻辑怎么分层
- 创游世界实战思路
- 脚本功能怎么不写乱
- 对象状态存哪里
- 创游世界系统设计入门