Visual event configuration and management
查看所有标签
玩家死了。死亡音效响了。布娃娃激活了。UI 弹出"你死了"。游戏自动存档。数据分析事件发出去了。重生倒计时开始了。六个不同的系统，全部在响应一个事件：OnPlayerDeath。但我的问题是——这些关系记录在哪？
不在你的代码里。不在项目管理工具里。不在任何图表里。它存在于一个地方：最初配置它的那个人的脑子里。如果那个人半年前离职了，那它哪儿都不存在。
这就是事件驱动架构的脏秘密。我们采用它是因为它解耦了系统。我们庆祝 AudioManager 不需要引用 UIManager 了。但我们从不谈代价：执行流变得不可见了。而不可见的东西，从定义上来说，就是没法可视化调试的。
每个游戏说到底就是一大堆条件判断。"只在敌人没有免疫火焰伤害、且玩家有火焰 buff、且暴击判定通过的时候才造成火焰伤害。"在原型阶段，你随手在回调里写个 if 就继续了。三十秒搞定，能跑，感觉效率很高。
然后原型进入正式开发。那些三十秒写的 if 语句开始疯狂繁殖。一个变五个，五个变五十个，五十个变成"第二关 Boss 的掉落概率到底在哪个鬼条件里控制的？"然后你的策划站在你身后问能不能把一个伤害阈值从0.3改成0.25，你在解释这得重新编译。
欢迎来到 if-else 地狱。常住人口：每一个活过三个月的 Unity 项目。
周二下午三点，你的策划凑过来说："诶，玩家受到50点以上伤害的时候，屏幕震动能不能再猛一点？打击音效延迟半秒再播？还有中毒的跳伤改成1.5秒一次吧，2秒太慢了。"
三个改动。从策划的角度来看，可能也就十五秒的思考量。但实际上会发生什么呢：你关掉 Scene 视图，打开 IDE，等它加载，搜索伤害处理的代码，找到屏幕震动强度那个值——埋在某个方法里面。改掉。然后找音效延迟——在另一个类里。改掉。再找中毒协程——又在另一个类里，而且 tick 频率藏在 WaitForSeconds 的参数里。改掉。保存三个文件。切回 Unity。等重新编译。测试。
八分钟后，策划说："算了，震动还是原来的好，中毒能不能试试1.8秒？"