Chillu1 / ModiBuff

Buff/Debuff/Modifier library focused on feature set and performance, while maintaining 0 GC. Fully pooled
Mozilla Public License 2.0
139 stars 4 forks source link

Implementation help : Trigger Event base Effect not always have source #49

Closed mjfme closed 1 month ago

mjfme commented 1 month ago

Logic description 【Jumping Curse】 Character A applies a debuff to Character B. When Character B jumps, B would get a damage equal to Character A's attack power. Each time this occurs, Character A recovers 50% of the damage dealt as HP.

My idea was to use Event to trigger a damage effect, but the point is that in the Jump methods I usually can't get a clear source (In the previous description, source should be A) like I can with TakeDamage, Heal, etc. Mybe I need to store the effect's source when implement interface something like IEventOwner? Or any other way?

Chillu1 commented 1 month ago

Events will be scrapped/changed soon, so I'd use Callbacks instead, they're basically the same tbh.

This is one of the areas where ModiBuffs has a few problems, adding a modifier on Unit X, but triggering logic on Unit Y. It can probably be solved with using applier gimmicks, but I think the easiest way would be CallbackEffectUnits that stored the original units in the callback.

AddRecipe("AttackOnJump")
    .Effect(new AttackActionEffect()
            .SetPostEffects(new LifeStealPostEffect(0.5f, Targeting.SourceTarget)) 
        , EffectOn.CallbackEffectUnits)
    .CallbackEffectUnits(CallbackType.Jump,
        effect => (target, source) => new JumpEvent(() => effect.Effect(target, source)));

Something like AttackActionEffect will trigger an attack action, if you don't want to you could instead use something like DamageEffect with a meta effect AddValueBasedOnStat/Damage that adds your attack power to the damage value.

Currently only CallbackEffectUnits is able to store original target/source, and it's because it adds a lot of complexity to handle that, and general confusion. But I am looking into making this process more intuitive.

mjfme commented 1 month ago

I get it, it's a bit complicated.... For me, the main reason is that there are too many types of callbacks, and it is not easy to distinguish their respective usage scenarios.

Chillu1 commented 1 month ago

I get it, it's a bit complicated.... For me, the main reason is that there are too many types of callbacks, and it is not easy to distinguish their respective usage scenarios.

Yeah don't worry, think that's currently the biggest problem with the library, handling and explaining complexity. A proper simple example game made in Godot should do the trick, but I don't have the time right now.