因为ET是全局注册,并且不卸载的。比如:我要更新某个ui的消息,但是ui处于关闭状态。这时候如果用默认的消息机制的话,也会把消息发过去。这块我是否要重新搞一套消息机制,开启ui就add,关闭就remove。或者有其他好方案吗?(或者把ui作为key,关闭就把相关event全部关闭。因为很容易忘记remove) @[已注销]
nil_boy XuToWei/ET-DynamicEvent: ET的动态事件扩展 (github.com)
colden-rabbit 这个是确实是可以。我其实是想知道猫大的项目这块是咋处理的😄
你订阅的地方会去find这个ui,find不到就return了撒。干啥要搞动态订阅,动态的东西没法热重载。
egametang 动态订阅有个好处就是减少获取ui这一步,因为会提前存下来。还有一个好处就是可以减少消息的遍历。
坏处要释放,无法热重载。性能这块可能你们想的夸张了,千古风流全部是全局事件,根本不存在性能问题
另外一个是可读性,我一眼能看到哪个模块订阅了事件。而动态事件可能有各种逻辑并不去订阅,或者已经删除了,肉眼看不出来,很麻烦
egametang 最近有个想法不知道可不可行,就是类似gate这转发消息一样。比如我给事件补充一个ui参数或者标记。当触发事件传递到标记的消息的时候,获取一次ui组件还在不在,在就继续下传,并且直接把ui组件的带下去。不在就直接返回。这样就不用每个消息都去获取ui组件,同时也保证消息是全局,不需要动态加减。
我之前用的时候,稍微有一点不习惯的就是,事件都是全局的,没法绑定到具体的实体上,例如实体A触发的事件只有实体A相关联的组件可以监听到,现在就是所有的同eventType的handler都会触发,有些地方是不能执行的,还需要添加过滤条件(那种比较通用型的事件,比如怪物死亡,每个功能模块可能都会自己写一个handler,sceneA触发,sceneB也会收到事件,这时候可能就需要做sceneType的判断,当然事件也可以命名成不一样的,但是那样就感觉有点写复杂了)。
evalli 实体a相关联的收到,那肯定是前面有一堆逻辑判断只让a相关联的去注册事件。同样,现在在订阅的地方加一堆逻辑只让a相关的处理即可。至于sceneA sceneB,那完全应该再做一次分发
egametang 猫大,比如开房间战斗,有一个被动技能:队友单位(Unit)造成暴击时,自身攻击力增加。这个被动技能是有些单位(Unit)有,有些单位(Unit)没有。
直观做法是当有队友单位暴击时,抛出一件事件,订阅了这个事件的单位就增加攻击力。在战斗开始前,如果某个单位装配有这个被动技能,就订阅这个事件,如果没有,则不订阅。这样应该是动态订阅的做法。
我目前的做法是遍历全场所有单位,每个单位又遍历其身上的被动技能,如果有这个技能,则执行事先注册好的Handler。这样似乎场上每一次攻击,都要遍历全场所有单位*各单位上的buff数量。
不知道有没有更好的解法呢?
david000999 我的战斗BUFF事件系统是另一套,是动态注册的,因为它的作用是明确而单一的。
david000999 遍历和注册后调用是两码事;buff系统可以有各个"触发点"即使一个角色一个buff也没有,buff系统仍然需要挂在单位上,"产生暴击"就是一个"触发点",应该触发所有单位的Buff系统,至于Buff系统内是否真的有实际需要生效的Buff,这跟这些系统没多大关系,随你怎么写.比如暴击后回血,暴击吸血,暴击破甲,暴击降低敌方士气,暴击后敌方血量不足8%直接秒杀等等.