Step-by-step tutorials
查看所有标签
你需要在手雷落地后延迟2秒引爆。挺简单的，你写了个协程。IEnumerator DelayedExplosion()，yield return new WaitForSeconds(2f)，调用爆炸逻辑。整整齐齐大概10行。感觉还不错。
然后策划说："玩家应该可以拆弹。"好了，现在你得存一个 Coroutine 引用才能调 StopCoroutine()。但等等——如果玩家在协程启动之前就拆了呢？需要空检查。如果 GameObject 在等待中途被销毁了呢？又一个空检查。如果玩家恰好在协程完成的那一帧拆弹呢？竞争条件。你的10行现在变成了25行，而你甚至还没处理"显示拆弹消息 vs 显示爆炸"的分支逻辑。
这就是 Unity 中每个时间驱动事件的故事。第一版实现很干净。第二个需求把代码翻了一倍。第三个需求让你开始怀疑人生。
周二下午三点，你的策划凑过来说："诶，玩家受到50点以上伤害的时候，屏幕震动能不能再猛一点？打击音效延迟半秒再播？还有中毒的跳伤改成1.5秒一次吧，2秒太慢了。"
三个改动。从策划的角度来看，可能也就十五秒的思考量。但实际上会发生什么呢：你关掉 Scene 视图，打开 IDE，等它加载，搜索伤害处理的代码，找到屏幕震动强度那个值——埋在某个方法里面。改掉。然后找音效延迟——在另一个类里。改掉。再找中毒协程——又在另一个类里，而且 tick 频率藏在 WaitForSeconds 的参数里。改掉。保存三个文件。切回 Unity。等重新编译。测试。
八分钟后，策划说："算了，震动还是原来的好，中毒能不能试试1.8秒？"
"我只有 5 分钟，你能直接告诉我怎么让事件系统跑起来吗？"
没问题。不讲理论，不做架构深度分析，不和其他方案做比较。你想从零开始在 Unity 项目里搭建一个能用的事件驱动交互，而且要快。走起。
本指南假设你有一个打开的 Unity 项目（2021.3 LTS 或更新版本）以及大约 5 分钟的时间。读完后，你会有一个在游戏中某件事发生时触发、并在一个完全独立的 GameObject 上引发响应的事件——两者之间零直接引用。
你开了一个新 Unity 项目，创建了十个事件。OnPlayerDeath、OnScoreChanged、OnLevelComplete。命名合理，扔进一个文件夹，继续干活。日子很美好。你脑子里装得下整个事件结构。
快进六个月。你有了 200 个事件。Project 窗口变成了一面 ScriptableObject 文件墙。你需要 OnPlayerHealthDepleted——还是叫 OnPlayerHPLow？还是 OnPlayerHealthZero？你在列表里上下滚动，眯着眼看一堆全以 OnPlayer 开头的名字。三分钟后你放弃了，直接创建了一个新的，因为你甚至不确定你要的那个事件是不是已经存在了。
每个事件驱动的 Unity 项目最终都会走到这一步。不是因为事件模式本身有问题，而是因为没人构建过大规模管理事件的工具。Unity 给了你 Animation 窗口、Shader Graph、Timeline、Input System 调试器。事件呢……只有 Project 窗口。
你写了一个 GameEvent<T>。干净、类型安全、优雅。你创建了一个 GameEvent<float> 字段用来广播血量变化，打上 [SerializeField]。切到 Inspector 一看——字段消失了。就像你让 Unity 除以零一样，它用一片空白面板回敬你。
这是 Unity 最古老的架构痛点。序列化系统不懂泛型，从来没懂过。每一个试图构建类型安全、数据驱动事件系统的开发者都一头撞上了这堵墙。
这不是什么小麻烦，而是那种会毒化整个架构的限制。你要么放弃类型安全，要么淹没在样板代码里，要么接受你那漂亮的泛型设计永远无法触及 Inspector。多年来社区的标准答案一直是"手写具体类就行了"。但问题来了——如果样板代码是 100% 可预测的，为什么要人来写？