Why this logic should be in the library, and not user game logic
Checks values are either fed through constructors, or the supplied unit. This becomes an issue when we want more control over the values inside, like changing cooldown timer, cost or chance.
Describe the solution you'd like
Either feeding some kind of state to the checks (either through unit or something separate), or doing manipulation through callbacks/other setup.
Describe alternatives you've considered, and why they don't work
Custom checks are not ideal since we'd need to store data about it directly in the unit, without any refactoring. Which is a bad solution.
Possible issues
Previous checks without mutable state will now most likely not be a thing, unless that mutable state is stored outside the checks and fed instead.
Why this logic should be in the library, and not user game logic Checks values are either fed through constructors, or the supplied unit. This becomes an issue when we want more control over the values inside, like changing cooldown timer, cost or chance.
Describe the solution you'd like Either feeding some kind of state to the checks (either through unit or something separate), or doing manipulation through callbacks/other setup.
Describe alternatives you've considered, and why they don't work Custom checks are not ideal since we'd need to store data about it directly in the unit, without any refactoring. Which is a bad solution.
Possible issues Previous checks without mutable state will now most likely not be a thing, unless that mutable state is stored outside the checks and fed instead.