Beginner-friendly guides
查看所有标签
周二下午三点，你的策划凑过来说："诶，玩家受到50点以上伤害的时候，屏幕震动能不能再猛一点？打击音效延迟半秒再播？还有中毒的跳伤改成1.5秒一次吧，2秒太慢了。"
三个改动。从策划的角度来看，可能也就十五秒的思考量。但实际上会发生什么呢：你关掉 Scene 视图，打开 IDE，等它加载，搜索伤害处理的代码，找到屏幕震动强度那个值——埋在某个方法里面。改掉。然后找音效延迟——在另一个类里。改掉。再找中毒协程——又在另一个类里，而且 tick 频率藏在 WaitForSeconds 的参数里。改掉。保存三个文件。切回 Unity。等重新编译。测试。
八分钟后，策划说："算了，震动还是原来的好，中毒能不能试试1.8秒？"
"我只有 5 分钟，你能直接告诉我怎么让事件系统跑起来吗？"
没问题。不讲理论，不做架构深度分析，不和其他方案做比较。你想从零开始在 Unity 项目里搭建一个能用的事件驱动交互，而且要快。走起。
本指南假设你有一个打开的 Unity 项目（2021.3 LTS 或更新版本）以及大约 5 分钟的时间。读完后，你会有一个在游戏中某件事发生时触发、并在一个完全独立的 GameObject 上引发响应的事件——两者之间零直接引用。
你改了一个方法名。就一个——把 OnPlayerDied 改成了 OnPlayerDefeated，因为策划觉得措辞需要柔和一点。点击 Play，什么都没发生。没有编译报错，没有警告。场景里十个通过 Inspector 用 UnityEvent 绑定的对象就这么……哑了。悄无声息。你可能三天后才从 QA 那里听到，更惨的情况是玩家先发现。
如果你觉得这场景似曾相识，恭喜——你已经亲身领教过"隐形意大利面代码"了。这种技术债不会出现在 IDE 里，不会触发编译器警告，也不会出现在任何依赖关系图上。它就这么潜伏着，等着在最要命的时候给你一刀。
这不是水平问题，是架构问题。而且比大多数 Unity 开发者愿意承认的要普遍得多。