Action System

[snayff]

Suggested Feature

Actors need to be able to influence combat. We will call these Actions. There are 2 kinds, active and passive; 1 that happens on demand and 1 that happens in response to something else.

Requirements

• Active Actions can be triggered on demand, when ready. ready is determined by:
  • not being on cooldown e.g. cooldown timer is at 0
  • having an appropriate target
• Passive actions are triggered in response to events. These are:
  • on death
  • on receive damage
  • on healed
• Passive Actions cant be triggered by the same thing more than once in the same chain. i.e. prevent infinite loops. e.g. 2 instances of on_receive_damage both deal damage and then continually trigger one another endlessly.
• All Actions require an appropriate target. Target types are:
  • SELF, ## actor using the skill
  • ALLY, ## actor on same team
  • ENEMY, ## actor on other team
  • ATTACKER, ## actor attacking person asking
  • DEFENDER, ## actor being attacked by person asking
  • ANY, ## anyone, we dont care
• Actions may use "sub-rules", aka target preferences, to specify conditions for a valid target. This is used as a refinement beyond just target type. The target preferences are:
  • ANY, ## anyone
  • LOWEST_HEALTH, ## actor with lowest health
  • HIGHEST_HEALTH, ## actor with highest health
  • DAMAGED, ## actor that isnt full health
  • NEAREST, ## actor nearest caller
  • FURTHEST, ## actor furthest from caller, but still in range
• The Actions known to an Actor are defined at Unit level
• Actions can trigger the following effects:
  • heal
  • damage
  • apply status effect
  • apply knockback
• Actions use one of the following targeting methods:
  • GLOBAL, ## affects all valid units
  • UNIT, ## specific Unit is chosen
  • ACTOR, ## specific actor is chosen. the Action will always hit the target Actor.
  • GROUND, ## position on the ground is chosen.
  • SELF, ## targets self

Additional Context

I quite like being able to build actions logic by chaining together a series of effects, querying conditions as we go. This creates a versatile, but structured, approach. See here for an example.

Note, while all active actions have a targeting method it is only used by the player commander to determine the targeting method used when casting that action.

Current approach works as follows:

• Actor has a component ActorActions that holds references to all of the Actions and acts as the interface for using those Actions.
• There are 3 kinds of Action, Attack (should we rename active? 🤔 ), Reaction, and StatusEffect.
• Actions are defined in code, with their behaviour outside of use() sharing a uniform set of expectations, defined by action_type, action_trigger, target_type. That is to say that on use() the Action can be entirely unique and bespoke, but in all other interactions will follow a set of prescribed behaviours.
• Actions have access to a variety of _effect_* methods to use as building blocks in their use() method, though they are not confined to these. N.B. some of these effect methods exist but are not implemented, use of these will generate a warning.

[snayff]

Some thoughts on the current state:

• targeting def isn't quite right. Try a self target action and sometimes it impacts enemy.
• cooldowns work, but there's something funky happening as lots of warnings are triggered relating to timers being triggered.
• code for target preferences is in place, but not sure it's working correctly. Feel free to rip out or amend, as preferred.
• status effects aren't being applied properly. Sometimes added, sometimes not. Sometimes duplicated. Their effect isn't triggering consistently. For this issue we only need proper application, though.
• code for passives, aka reactions, is in place and I think working, but would appreciate a once over. My work with signals has been error prone so far.

Also, ticked off requirements I believe to be working.

[eh-jogos]

@snayff Just published a draft PR (#43) for some improvements here! I think it accounts for

• targeting def isn't quite right. Try a self target action and sometimes it impacts enemy.
• code for target preferences is in place, but not sure it's working correctly. Feel free to rip out or amend, as preferred.

(except implementing missing preferences logic)

I published the PR as a draft because while the one about the fleeing behavior is not merged, it ends up showing commits for both of them.

[snayff]

@eh-jogos is this fully implemented now? If not, can you tick off what is completed, please?

[eh-jogos]

@snayff Just pushed a PR for status effects #44

To be honest I was going more by your comment then the issue description as there are too many tasks on it. I can't edit it but I'll try to tick off what I know here:

From you comment:

• targeting def isn't quite right. Try a self target action and sometimes it impacts enemy.
• (fixed somewhere along the way) cooldowns work, but there's something funky happening as lots of warnings are triggered relating to timers being
• code for target preferences is in place, but not sure it's working correctly. Feel free to rip out or amend, as preferred.
• status effects aren't being applied properly. Sometimes added, sometimes not. Sometimes duplicated. Their effect isn't triggering consistently. For this issue we only need proper application, though.
• code for passives, aka reactions, is in place and I think working, but would appreciate a once over. My work with signals has been error prone so far.

From the issue description:

• Active Actions can be triggered on demand, when ready. ready is determined by:
  • not being on cooldown e.g. cooldown timer is at 0
  • having an appropriate target

These Might actually be done, just haven't looked at them in detail, but I've seen the functions around.

• Passive actions are triggered in response to events. These are:

  • on death
  • on receive damage
  • on healed

• Passive Actions cant be triggered by the same thing more than once in the same chain. i.e. prevent infinite loops. e.g. 2 instances of on_receive_damage both deal damage and then continually trigger one another endlessly.

Continuing the list, these were either already there and working or already there but needed some fixing:

• All Actions require an appropriate target. Target types are:

  • SELF, ## actor using the skill
  • ALLY, ## actor on same team
  • ENEMY, ## actor on other team
  • ATTACKER, ## actor attacking person asking
  • DEFENDER, ## actor being attacked by person asking
  • ANY, ## anyone, we dont care

• Actions may use "sub-rules", aka target preferences, to specify conditions for a valid target. This is used as a refinement beyond just target type. The target preferences are:

  • ANY, ## anyone
  • LOWEST_HEALTH, ## actor with lowest health
  • HIGHEST_HEALTH, ## actor with highest health
  • WEAK_TO_MUNDANE (found this in the code but it was not listed here in this issue)
  • DAMAGED, ## actor that isnt full health
  • NEAREST, ## actor nearest caller
  • FURTHEST, ## actor furthest from caller, but still in range

• The Actions known to an Actor are defined at Unit level

• Actions can trigger the following effects:

  • heal
  • damage
  • apply status effect
  • apply knockback

These ones have the enum and the property, but property is never used and I'm not sure where they would be used. Or if they're just for the player commander.

• Actions use one of the following targeting methods:
  • GLOBAL, ## affects all valid units
  • UNIT, ## specific Unit is chosen
  • ACTOR, ## specific actor is chosen. the Action will always hit the target Actor.
  • GROUND, ## position on the ground is chosen.
  • SELF, ## targets self

I think these big issues with lots of checklists are a bit confusing, at least if we try to work directly on them, I would prefer to create smaller issues or use the big issue as a "parent" and break off smaller issues from it.