Advanced techniques and patterns
查看所有标签
你的程序化地牢生成器刚刚造了一个有三块压力板和一个尖刺陷阱的房间。下一个房间是一个连接着锁门的拉杆谜题。再下一个是 Boss 竞技场，环境危害根据 Boss 的血量阶段激活。这些事件关系在编辑期一个都不存在。地牢布局取决于玩家 30 秒前输入的种子。
你怎么连接这些事件？
传统做法是写一个巨大的 switch 语句。每种房间类型手动订阅和取消订阅事件处理器。每种 AI 难度手动串联不同的攻击模式。每个 Mod 创建的内容手动解析配置文件并翻译成事件连接。"手动"就是问题所在 —— 每当拓扑在运行时改变，你就在重新实现事件连线逻辑。
可视化节点编辑器在处理设计期已知的流程时非常棒。但它们从根本上无法处理运行前根本不存在的流程。而越来越多最有趣的游戏系统恰恰就是事件图动态生成的那种。
玩家受到 25 点伤害。血量系统扣血。UI 刷新血条。但血条显示的是 100 而不是 75。你盯着代码看了 20 分钟才反应过来：UI 的监听器比血量系统的监听器先执行了。UI 读到的是旧值，渲染完了，血量系统才完成扣血。等数据正确的时候，这一帧已经画完了。
你刚刚发现了"执行顺序 Bug"。如果你用事件驱动架构上过线，八成已经在不知情的情况下发布过好几个这样的 Bug。它们在测试环境下表现正常 —— 因为脚本恰好按正确顺序初始化了 —— 然后到了线上就炸，因为 Unity 换了个加载顺序。
这不是什么边缘情况，而是大多数事件系统的结构性缺陷 —— 包括 Unity 的 UnityEvent 和标准 C# event 委托。一旦搞明白为什么，你就再也回不去了。
你需要在手雷落地后延迟2秒引爆。挺简单的，你写了个协程。IEnumerator DelayedExplosion()，yield return new WaitForSeconds(2f)，调用爆炸逻辑。整整齐齐大概10行。感觉还不错。
然后策划说："玩家应该可以拆弹。"好了，现在你得存一个 Coroutine 引用才能调 StopCoroutine()。但等等——如果玩家在协程启动之前就拆了呢？需要空检查。如果 GameObject 在等待中途被销毁了呢？又一个空检查。如果玩家恰好在协程完成的那一帧拆弹呢？竞争条件。你的10行现在变成了25行，而你甚至还没处理"显示拆弹消息 vs 显示爆炸"的分支逻辑。
这就是 Unity 中每个时间驱动事件的故事。第一版实现很干净。第二个需求把代码翻了一倍。第三个需求让你开始怀疑人生。
玩家死了。死亡音效和死亡粒子应该同一瞬间开始——没必要等一个完了再开始另一个。但屏幕淡出绝对必须在重生点加载之前完成。重生加载必须在传送之前完成。传送必须在屏幕淡入之前完成。
这就是并行和顺序执行同时存在于一个流程中，由一个事件触发。而尴尬的现实是：大多数 Unity 事件系统只给你一种模式。触发事件，所有监听器响应，完事。至于这些响应应该同时发生还是严格按顺序来？你自己想办法。
于是你就去解决了。用协程。用回调。用名为 _hasFadeFinished 的布尔值。不知不觉间，你搭了一个散落在六个文件里的临时状态机，包括未来的你在内没人能看懂。
每个游戏说到底就是一大堆条件判断。"只在敌人没有免疫火焰伤害、且玩家有火焰 buff、且暴击判定通过的时候才造成火焰伤害。"在原型阶段，你随手在回调里写个 if 就继续了。三十秒搞定，能跑，感觉效率很高。
然后原型进入正式开发。那些三十秒写的 if 语句开始疯狂繁殖。一个变五个，五个变五十个，五十个变成"第二关 Boss 的掉落概率到底在哪个鬼条件里控制的？"然后你的策划站在你身后问能不能把一个伤害阈值从0.3改成0.25，你在解释这得重新编译。
欢迎来到 if-else 地狱。常住人口：每一个活过三个月的 Unity 项目。
Unity Asset Store 上每一个事件系统插件的描述里都写着"高性能"。就夹在"易于使用"和"完整文档"中间。但问题是——1ms 和 0.001ms 对人来说都很快，可一个比另一个慢了一千倍。当一个插件说"高性能"时，到底在说什么？跟什么比？怎么测的？
我以前也不在意这些。大多数人都不在意。接几个事件，游戏在开发机上跑得好好的，发布就完了。但后来我做了一个移动端项目，几百个实体各自监听多个事件，突然"高性能"就不再是营销打勾项了——而是 60 FPS 和幻灯片之间的区别。
这篇文章讲的是"高性能"对于事件系统到底应该意味着什么、为什么大多数实现达不到、以及 GES 如何通过 Expression Tree 编译实现接近零开销。用真实数据说话，不打太极。