Order of triggered actions

[Spatula]

Heh. As someone who is working on a similar project, the logic of immediate actions is the biggest hurdle that I've come across. There is no defined order, so you'll just have to pick one. And then there's the possibility that one triggered action might invalidate the original action, or could change conditions such that someone else's triggered action goes off. Or both. It's a huge headache.

As far as the structure for processing immediate actions goes, I went with an approach similar to the one AbdulAlhazred talks about.

 

[tentfox]

I am not going to go entirely with the stack method, but I do like the way you broke down an action into atomic sub actions.

Here is what I am thinking:
- Each action is built up of sub actions and action flows, and each of those can likewise be broken up. While this seems complex in most cases it will be as simple as an attack action is an attack roll which flows on to a damage roll on the condition of a hit, but allows for far more complex actions.

- Each action, and therefor sub action can potentially have interrupts and reactions. To model this before each action/sub action is performed I will gather all potential interrupts and resolve them in initiative order. Any of these actions will need to recursively go through this same process.

- After the interrupts are resolved attempt to perform the original action/sub action, testing for validity as an interrupt may have changed the condition of this succeeding (ie the performer is now dead or out of range).

- Now compile a list of all potential reactions and resolve them in initiative order, once again doing this recursively.

- Once the action or sub action has been completely resolved in this manner move on to the next action in the chain based on the final result of the first action.


And then this is further complicated by the granulation of these actions and sub actions. Potential interrupts could not just be being attacked, but being hit by an attack. So the chain might be, attack roll (result hit) -> hit (result ok)-> damage. This is easily going to be the most complicated part of this.

 

[AbdulAlhazred]

After thinking about it, one more refinement. The fundamental units should be 'Events' that are atomic steps at the level of interruptability. All of these within a given action would share one ReactionQueue (actually what sort of structure it needs to be is not defined by the rules, could be a stack or a queue or any other type of collection depending on how the developer decides to order reactions). Each Event would have to send out some kind of event notification to anything that could generate interrupts (or other instant things) or reactions.

So I THINK the drill would be along the lines of an Action could invoke a Power. The Power would simply call whatever Events it needed, which can do both the UI stuff and make state changes to the overall game world state. Entities could register to be notified of any of these state changes as well as occurrence of non-state-changing Event types. Thus an Event could call GameState.doDamage(target, self) at the appropriate moment and the Wizard Entity that is getting smacked will be notified, at which point it could simply INVOKE an interrupt by calling it (say because the Shield power is triggered) or it could tack a Reaction onto the ReactionQueue for the whole Action.

I think that is cleaner than just having each Action/Power keep calling back with "and now I've started doing X, and now I'm done doing X." because now it can all be pooled into a quite abstract Event that can be reused for each step. Thus the code for a given Power can be fairly minimal and boilerplate (so most Powers can probably use one set of code that is just driven by some data describing it, or be easily scripted).

 

[QuestionC]

If you are familiar with JASS (WC3's map scripting), it's very similar to the model y'all are throwing around, which is basically the correct one to use for this.

In a JASS-like system, for example, Opportunity attack would look something like this...
Opportunity Attack
* Trigger
Move, Ranged Ability, Area Ability
* Condition
Is Triggering unit threatened by this && Is this able to attack && Can this make Opportunity Action
* Event
Consume Opportunity Action
This Basic Attacks triggering unit

I'd just worry about getting the basics implemented... Basic Melee Attacks, Basic Ranged Attacks, Move Actions, and Opportunity Attacks. Once you've got that done, it's just about adding triggers and new hooks on those triggers.

 

[Spatula]

I'd just worry about getting the basics implemented... Basic Melee Attacks, Basic Ranged Attacks, Move Actions, and Opportunity Attacks. Once you've got that done, it's just about adding triggers and new hooks on those triggers.

Well, it's a little more complicated than that. Basic attacks & OAs are almost trivial to implement, because they don't really do much of anything aside from damage, and they aren't going to trigger additional interrupts. The meat of the implementation is what happens when an event can trigger multiple immediate actions, each of which can (a) change the conditions of the initial event, and/or (b) trigger more immediate actions. And somewhere in the middle there one of the events gets invalidated by someone else's interrupt.

Speaking of which, and getting back to the OP, I have a rules question. I know how I would play this at the table, but I am unsure as to what the RAW say on the topic.

A dragon breathes on 3 PCs.

PC1 is about to be hit, but uses an encounter interrupt to boost his defenses, turning the hit into a miss.

PC2 gets hit and takes damage.

PC3 is hit and is about to take enough damage to drop, but uses an interrupt to make an attack against the dragon. PC3's attack kills the dragon, which invalidates the attack...

...invalidates it against PC3? Or against all three PCs?

The dragon is dead and PC3 took no damage from the breath.

Does PC1 still have his or her immediate action? Is the encounter power expended? Is PC2 still damaged by the attack? Would the PCs be better off if the attack vs PC3 was resolved first?

 

[Dausuul]

A dragon breathes on 3 PCs.

PC1 is about to be hit, but uses an encounter interrupt to boost his defenses, turning the hit into a miss.

PC2 gets hit and takes damage.

PC3 is hit and is about to take enough damage to drop, but uses an interrupt to make an attack against the dragon. PC3's attack kills the dragon, which invalidates the attack...

...invalidates it against PC3? Or against all three PCs?

The dragon is dead and PC3 took no damage from the breath.

That's a tricky one. I would say:

Does PC1 still have his or her immediate action?

No. She used it and it's gone.

Is the encounter power expended?

Yes. PC1 used it and it's gone.

Is PC2 still damaged by the attack?

No. Technically, PC2 should wait to write down the damage from the breath weapon until everyone in the fight has had a chance to declare and resolve interrupts in response to the damage.

Would the PCs be better off if the attack vs PC3 was resolved first?

No. All attack rolls get resolved first; then damage is rolled and applied. Even if the attack on PC3 is resolved first, PC1 will have to declare her defense booster (responding to the attack roll) before PC3 declares his counterattack (responding to the damage).

Of course, this is a fairly unusual situation. Not many "counterattack" interrupts can be declared in response to taking damage--usually it's a response either to being attacked or being hit. Most of the interrupts that respond to taking damage are ones that reduce the damage, grant a healing surge, etc.

 

[AbdulAlhazred]

Yeah, this kind of thing is tricky, but I think Dausuul has it right. The RAW goes something like all damage from an AoE is simultaneous (it is one attack, so all to-hit rolls are made, then one single damage roll). Once the damage roll is made it will be applied, triggering the various effects mentioned. In actual play if say PC3 was handled first then PC1 might skip out on using his immediate, but it should probably be that they are all declared and then all resolved.

[MENTION=2198]Spatula[/MENTION], ANYTHING can potentially trigger immediate actions etc. Any engine someone wrote would have to take that fully into account uniformly across the whole implementation of all action resolution right from the start. Otherwise you'll be trying to hack in stuff later on when you find out you had to have it, or every time some new power happens to do something no other power ever did before even though the underlying mechanics for it existed (like a power dishing out an attack in response to taking damage say).

 

[Spatula]

[MENTION=2198]Spatula[/MENTION], ANYTHING can potentially trigger immediate actions etc. Any engine someone wrote would have to take that fully into account uniformly across the whole implementation of all action resolution right from the start. Otherwise you'll be trying to hack in stuff later on when you find out you had to have it, or every time some new power happens to do something no other power ever did before even though the underlying mechanics for it existed (like a power dishing out an attack in response to taking damage say).

Believe me, I've considered that. Of course, when it comes to replacing the DM with a computer, the line is going to be drawn somewhere. There's always going to be some situation that the computer has not been programmed to handle.

As far as triggered actions go, there are two components that I can see. The first is when the trigger could happen. I do believe there is a finite list of these trigger points, most of them being tied up in turn sequence or power execution. The second is, are the conditions of the trigger met? And as you note, new powers are coming up with new trigger conditions all the time. But even there, most of the triggers resolve around the same issues. Hit point gain / loss. Rolling a crit. Hitting or missing. Positioning relative to other objects in the battlemap. Details of a power that's being used. And so on. So it's possible (and I've mostly done it already) to construct a flexible language of logical statements to test for those conditions.

Granted, there's going to be some wacky triggers coming that I didn't anticipate, that will prove difficult to implement. But I just figure, no program can implement everything.

 

[AbdulAlhazred]

Yeah, I think with proper design of the core 'resolution engine' you can handle anything. I wouldn't say necessarily without needing to write more code, but with the correct object models and abstraction it should be minimal work.

 

[tentfox]

In the dragon example I would resolve all interrupts before the hit is resolved, which would cause both players to use and expand their power but kill the dragon before the hit is resolved. It would then attempt to resolve the hit, but be invalidated by the fact the dragon is dead and the action would end there.

What I am currently doing is compiling a list of unusual use cases as well as usual ones and coming up with a model which can solve them all. The basic flow is ok, but there is far more to it then just that.

Some example triggers are:
- move further away from the character
- start/end turn in range
- end turn closer than started
- take X type of damage
- an ally missed an attack and I grant a reroll

So I was thinking of something which tracks events, relative positions, results of event and allows an event to chain back onto itself. Something like this should handle everything I listed there except end turn closer than started.

Also that WC3 example shows how to display the data, but the underlying mechanics behind it are what is most complex.