※ 引述《NDark (溺於黑暗)》之铭言： 十年前我写了关於 Event 事件系统的文章． 十年过去其实我经历过很多专案，发现了越来越多的反例（Anti-Pattern， 使用了事件系统专案的开发者却无法驾驭，发现了问题无法除错解决的情况）． 简单来讲，事件系统的目的是把混沌整理为有序． 但在某些情形下也有机会产生更多的陷阱． 专案使用了事件系统， 但没有配套系统（或是团队文化）的事件系统仍然会受到执行顺序的困扰． （这边讲的配套系统是负责显示记录的系统， 能够即时或事後检查游戏过程中发生了甚麽事． 团队文化指得是团队中是否有遇到问题能够细心检查的成员及工作环境） 在系统及设计还未进入稳定态的（新案） 或是在旧案装上新系统（尤其是演出，如跑马灯，弹出介面）特别容易发生这个问题． 以Unity来说．这个问题就是因为各脚本执行是有顺序的（即便没有设定脚本的执行顺序) ．Update() 都是一个一个脚本依序执行． 那麽同一个画格送进事件系统也就有了顺序．那麽陷阱就来自於 １．有时候我们希望A的执行顺序要高於B．而有时候又希望B的顺序高於A． ２．事件的结果发动有时候需要时间（尤其是动画／Coroutine），事件发动下去又继续 会有顺序的问题． 举例来说： A脚本中总共写了A1 A2两个事件． B脚本中总共写了B1 B2两个事件． 在某个运作中A1 B1会同一个画格发动． 另一个运作中A2 B2会同一个画格发动．（假设A的执行顺序快过B） 规格刚开始实作时A1->B1 的顺序是对的， 但过了一阵子实作另一个系统时却又希望 B2 -> A2 这样的顺序．这时候就会出现冲突． 没有一个配套系统很难发现问题在哪里． 第二最简单的修理方式就是把B调整为比A快． 这样就会反过来让A1->B1（或更多的类似流程）这条坏掉． 次简单的方式就是让A2去等B2．这可以临时解决问题． 但是要祈祷未来不要再对这个规格做修改． 这个问题的复杂度会随着 事件数（事件类别的种类及包含产生的结果）ｘ系统数 （通常是专案内被命名为Manager的类别） 而以乘法线性而更复杂．也就是越复杂的专案，这个连锁效应就越大． 不会感觉到这个问题，最有可能的情形是： 专案已经稳定了，系统不变只是扩充游戏内容的专案．（通常是续作）； 或是专案就不够大或久到会有这个问题． blog连结: https://ndark.wordpress.com/2021/06/25/%e4%ba%8b%e4%bb%b6%e7%b3%bb%e7%b5%b1%e7%9a%84anti-pattern/ -- "May the Balance be with U"(愿平衡与你同在) 游戏设计教学，讨论，分享。欢迎来信。 黑水沟历史文库 https://ndark.wordpress.com/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.129.48.101 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/GameDesign/M.1624619586.A.119.html