9 篇博文 含有标签「Architecture」

上图把卡牌战斗从配置到运行的三个环节放在一起，先在 Game Card Editor 中创建卡牌、角色和遭遇战，再打开各自的 Behavior 定义战斗规则

规则配好后，进入 Play Mode 打出卡牌，用 Game Card Monitor 检查结算结果，并顺着记录找到产生该结果的 Behavior

在 Inspector 中绑定场景里的 HUD，让运行时生成的敌人在启用时注册自己的回调，两者可以引用同一个类型化事件资产，每个监听器都应有明确归属，便于找到配置位置并确定清理时机

常驻音频服务需要在每次切换场景后继续接收关卡开始事件，保留服务 GameObject，让每个关卡引用同一个事件资产，把音频服务注册为持久化监听器，并在服务关闭时移除回调

检查每个监听器和调度任务由谁负责清理，场景对象禁用时移除自己的回调，回调如果还能触发其他事件，就沿连接检查是否会回到源事件

死亡音效和粒子可以由同一个事件分别启动，复活需要等淡出和场景加载完成时使用 Chain，把两种连接挂到同一个源事件后，每条响应都能按自己的时序执行

把受击、击败等相关事件放入同一战斗数据库，再用分类划分更小的事件组，团队可以从同一个入口查找资产，并在编辑场景前检查对应的 Behavior

给高频事件挂上实际使用的监听器后再测量，分别查看类型化派发、条件求值和回调，才能定位帧耗时或内存分配的来源，AOT 构建中的序列化条件使用烘焙生成的求值器

先按监听器需要的数据选择事件签名，Game Event Creator 会为事件及 Inspector 绑定生成具体类型，等 Unity 编译完成后，再把新事件资产赋给发送方和接收方

玩家死亡事件可以由界面和音频共同监听，发送方和监听器引用同一个事件资产，重构前就能按资产查出引用位置，修改 UnityEvent 回调的方法名时需要单独核对序列化绑定