Order of triggered actions

[tentfox]

I have been working on making a D&D simulation program as a home coding project and the following is starting to stump me a bit. What is the order you take triggered actions in.

For example, say a party caster provokes an OA from two enemies when using a ranged attack in melee and this attack misses. This party also has a leader who, as a triggered action to an ally missing with an attack grants a reroll. Now 3 actions are triggered here, the ally leader has the reroll and the 2 enemies each have OA's.

How do we determine the order creatures act here when it is outside of the initiative?

 

[Riastlin]

The opportunity actions are interrupts, so they would trigger first (potentially even nullifying the attack by either knocking the wizard unconscious, pushing him out of range, etc.). After the OA's, the leader's trigger goes since his trigger is based off of the miss (which technically happens after the OA's are resolved). As to which of the enemies goes first with their OA, I don't think there is a specific rule so it is likely up to the DM to decide, though a good default rule would be initiative order.

 

[tentfox]

So how does this sound; interrupts in initiative order, followed by reactions in initiative order?

 

[AbdulAlhazred]

Yeah, the rules don't actually define an order for simultaneous events. Initiative or init bonus or just random order will all work and all be within RAW.

The trickier ones are things like rider effects that are 'triggered' by specific conditions such as from feats. There has never been any kind of general clarification of where they fit within the structure of resolving an action where they come into play. I don't think an overarching general rule can be formulated that will work sensibly 100% of the time.

Some other things that can get ugly are 'retroactive' effects, which are rare but do arise sometimes with certain class features and combinations of feats and powers. A simple example is the strict reading of the PHB1 Ranger's HQ damage dice. According to the letter of the rules you can apply the damage once per round to any attacks made during that round. Even with a less generous reading you can certainly roll all your attacks for your turn and then retroactively decide which one gets HQ bonus damage added.

Personally I think even though 4e's rules are fairly well structured they are going to be tough to fully implement in code. You're probably just going to have to accept a certain amount of minor inconsistency with the rules on a few points.

 

[tentfox]

Hopefully I mitigate some of the complexity by limiting what goes into this to essentials classes. But I am not even up to that yet, only started this last week, but triggered actions are proving to be the trickiest part for many many reasons.

 

[Dausuul]

Here's how I'd go about it...

Basically, the way to organize this is with a (slightly modified) stack: Last in, first out. (There's a reason M:tG uses the term "stack" to describe its timing system--it's based on the computer science term, a fact I just now realized. 4E works much the same way.) Our stack will consist of an array of in-game events, plus four methods: AddInterrupt, AddReaction, ResolveEvent, and ExecuteStack.

AddInterrupt takes an event as parameter. It inserts that event at the end of the array. We will use this method when an immediate interrupt or opportunity action is declared, or when an action is declared on an empty stack.
AddReaction takes an event as parameter. It inserts that event in the second-to-last spot in the array. We will use this method when an immediate reaction is declared, or when an event creates another event (e.g., a successful attack roll creates a damage roll).
ResolveEvent looks at the last event in the array and does the following:

1. If event has not been resolved: Resolve it (but do not apply the result), then check to see if anyone has a response. If someone responds, exit ResolveEvent (do not do step 2).
2. Apply the result of the event and remove the event from the array.

ExecuteStack checks to see if anyone wishes to add an event with AddInterrupt or AddReaction. It continues until no one wishes to add an event; then call ResolveEvent. Repeat until the array is empty.

A key thing to note is that I say "event" rather than "action." This is going to be an important distinction, because a lot of actions involve multiple events--typically an attack roll and a damage roll, the latter being contingent on the result of the first.

So, with the example above, we start with an empty array. Since the wizard is casting into an empty stack, we call AddInterrupt to put the spell in the array:

{ Spell }

Then ExecuteStack. Two enemies respond with opportunity attacks, #1 and #2. (As to which of them declares first, I'd go in reverse initiative order.) These are treated as interrupts, so we use AddInterrupt again:

{ Spell, OA #1 }
{ Spell, OA #1, OA #2 }

Nobody else has anything to declare at this time, so we proceed to ResolveEvent. The event at the end of the array is OA #2.

1. OA #2 has not been resolved, so we resolve it by making an attack roll (say it hits). Then check to see if anyone has a response. No one does.
2. Apply the result. This produces a damage event, so we call AddReaction, resulting in this:

{ Spell, OA #1, OA #2 Damage Roll, OA #2 }

Then remove OA #2 from the stack:

{ Spell, OA #1, OA #2 Damage Roll }

ResolveEvent finishes. We're still in the middle of ExecuteStack, and the array is not empty, so we check for new events (none) and ResolveEvent again. This time it's the damage roll. We resolve it (say, 6 damage); check to see if there's a response (no); apply the damage (reduce caster's hit points by 6); and remove the event.

{ Spell, OA #1 }

Go through the same process with OA #1. Maybe this one misses, so we never get a damage roll event; we just move straight on to the spell.

{ Spell }

Check for new events, then ResolveEvent once more. This is where things get tricky. We resolve the spell; the attack misses. Then we check to see if there's a response--and get a yes! The warlord wishes to respond with an interrupt. So we call AddInterrupt and exit ResolveEvent.

{ Spell, Warlord's Reroll }

Notice that at this point, the spell event is resolved. The attack roll has already been made and its value is sitting in Spell. This is important, because if Warlord's Reroll is somehow prevented, the original attack roll should apply--we don't want to come back to Spell and start all over!

Anyhow, we're still in ExecuteStack and the array is still not empty. So we look for new events (no) and ResolveEvent yet again. This time it's Warlord's Reroll. We resolve it by re-doing the attack roll for Spell. Then we check to see if there are any responses and get none. Next, apply the result; go into Spell and change that attack value sitting there to whatever Warlord's Reroll produced. Finally, remove Warlord's Reroll from the array.

{ Spell }

Back here again. We call ResolveEvent. It looks at Spell and sees that this event is already resolved; there's no need to do it over. So it proceeds directly to applying the result. Say the spell hits, we have to call AddReaction to insert a damage roll:

{ Spell Damage Roll, Spell }

And then remove Spell from the array:

{ Spell Damage Roll }

ResolveEvent one more time, to deal with the damage roll--it should be pretty clear by now how this goes. ResolveEvent finishes, Spell Damage Roll is removed from the array, and the array is empty. ExecuteStack ends.

(And damn, that was a lot more complicated than I thought it would be when I started writing it. I don't even want to think about what happens if the spell has multiple targets.)

 

[AbdulAlhazred]

I think this is best accomplished with flow of control vs a data structure. That will handle interrupts perfectly since you deal with them as soon as they are triggered. Reactions being deferred WILL require some sort of stack. The problem is it needs to be a SERIES of stacks, one for each event which is resolving because a reaction to an interrupt would resolve after the interrupt but before the event that triggered the interrupt. Trying to use a global data structure will make your head a'splode real quick like.

So, I'd maintain a current context that includes a list of reactions to run at the end of your power resolution. When one triggers just add it to this list. When an interrupt happens just jump to the code that handles that interrupt. They will all be subclasses of something like 'action' that deals with the plumbing. This should provide a simple and reasonably elegant design that will deal with about 99% of the cases. The remaining 1% like HQ being able to apply damage retroactively you can just ignore, they are simply going to be too complex and the likelihood of them really mattering enough to need an implementation is slim to none.

 

[Dausuul]

I think this is best accomplished with flow of control vs a data structure. That will handle interrupts perfectly since you deal with them as soon as they are triggered. Reactions being deferred WILL require some sort of stack. The problem is it needs to be a SERIES of stacks, one for each event which is resolving because a reaction to an interrupt would resolve after the interrupt but before the event that triggered the interrupt. Trying to use a global data structure will make your head a'splode real quick like.

So, I'd maintain a current context that includes a list of reactions to run at the end of your power resolution. When one triggers just add it to this list. When an interrupt happens just jump to the code that handles that interrupt. They will all be subclasses of something like 'action' that deals with the plumbing. This should provide a simple and reasonably elegant design that will deal with about 99% of the cases. The remaining 1% like HQ being able to apply damage retroactively you can just ignore, they are simply going to be too complex and the likelihood of them really mattering enough to need an implementation is slim to none.

You need a stack for interrupts too.

Suppose the rogue moves, an enemy takes an OA in response to the rogue's movement, and then the fighter takes a Combat Challenge attack in response to the OA. If the fighter's Combat Challenge attack crits and kills the enemy, the OA never completes. How can you handle this without a stack?

[Edited to add: Ah, I see what you're doing--you are using a stack for interrupts, it's just that you're relying on the call stack rather than constructing your own. Fair enough, but I think it makes things unnecessarily complicated, since as you point out you'll have to build a queue of reactions for each interrupt, and the reactions can have interrupts and reactions piled on top of them, and each action is made up of several different events each of which can trigger interrupts and reactions separately, and... talk about head asploding! If you handle the whole thing with a single stack, it's a lot cleaner IMO.]

I don't see why you need multiple stacks, however. The system I outlined above should address all the issues. In the case you mention with a reaction to an interrupt, you start with the original action on the stack:

{ Original Action }

Somebody interrupts it. Interrupts go immediately above whatever they're interrupting:

{ Original Action, Interrupt }

Somebody responds to the interrupt with a reaction, which goes immediately below whatever it's reacting to:

{ Original Action, Reaction, Interrupt }

When the time comes to resolve all this, you deal with Interrupt first, then Reaction, then Original Action. Exactly as it should be.

 

[AbdulAlhazred]

Dausuul, my point was that the interrupt 'stack' is just the call stack of the functions that are resolving each power. So when you get to an interrupt you just jump into its 'resolveAction()' entry point. Now, you will need a context within each resolver that keeps track of any reactions etc that need to be added to the end of that action. You COULD use a single stack for that probably, but it seems better self-contained to just have a list of 'things that need to be called when this action is done resolving'.

So A uses power X on B, C reacts to X with Y (Y added to X's 'stack'), B interrupts X with Z (control passes immediately to Z).

Thus X would have control, Y would be added to X's list/stack of reactions to execute, and then Z would be given control. When Z returns X finishes resolving which will involve executing Y before it returns control to whatever called it.

Maybe I didn't quite understand your design either. There could also be some other wrinkle I haven't thought of, but I think it covers the basic scenario OK.

 

[Dausuul]

Dausuul, my point was that the interrupt 'stack' is just the call stack of the functions that are resolving each power. So when you get to an interrupt you just jump into its 'resolveAction()' entry point. Now, you will need a context within each resolver that keeps track of any reactions etc that need to be added to the end of that action. You COULD use a single stack for that probably, but it seems better self-contained to just have a list of 'things that need to be called when this action is done resolving'.

Thinking through what this would entail... let's see. We've got an Event object, with one public method, ExecuteEvent(). Private methods would be CheckForResponseToEvent(), ResolveEvent(), ApplyResult(), and ExecuteResponseQueue(). Properties would include Resolved (boolean, defaults to FALSE) and Type (interrupt or reaction, no default value).

So, you create the event object and call ExecuteEvent(). This method first calls CheckForResponseToEvent(), asking all combatants if they want to respond to the event being declared. Other actors may reply by passing back events of their own. Any interrupt-type event that gets passed back has its own ExecuteEvent() method called immediately. Reaction-type events get put in a queue*.

Next, ExecuteEvent() will call ResolveEvent(), which does any die rolling or computations needed to figure out the result. Then we set Resolved to TRUE and call CheckForResponseToEvent() again to see if anyone wants to respond to the resolution. Again, interrupts are processed immediately, reactions put on the queue.

Then call ApplyResult(), which checks to see if the result from ResolveEvent() is still valid, and applies it if so. This may entail generating some new interrupt events--e.g., if this event was an attack roll that hit, we generate a damage roll event and call its ExecuteEvent() method.

Finally we call ExecuteResponseQueue(), which goes through the queue in order and calls ExecuteEvent() on each event in it.

...Hmm. Workable, certainly. Might be better than my approach. I'd have to think some more about how it would play out in practice. Is this about what you had in mind?

[size=-2]*I think you want a queue here, not a stack.[/size]