Are we totally boned?

[nigelrobbins3]

While attempting to design an action system which could properly handle delegating behavior to its listeners, I stumbled across some very dangerous problems. Take the following scenario:

Players: An Enchanter with Chaos (target randomly reassigns its target), a nearby Knight with an aura which prevents flanking bonuses on nearby allies (I'm 90% sure this was an ability, but it's not in my Google doc), and another player who is NOT adjacent to the Knight (let's make him a Thief).

Enemies: An archer and a mage. The archer is far away, the mage doesn't matter.

Define actions: the Knight and the Thief pick their nose. The mage will buff the archer, the archer will shoot the Thief (flanking bonus), and the Enchanter will cast Chaos on the archer. Mage and Enchanter go before the archer.

Perform actions:

• Archer gets a lifesteal buff for their bow.
• Archer is hit with Chaos and is debuffed so his targets are chosen randomly

We begin the problems:

• Game dispatches the archer's attack.
• The first listener is the archer's. He reassigns his target randomly to the Enchanter and applies a +2 from his lifesteal buff.
• The second listener is the Knight's. He recognizes that an adjacent ally is being targeted, and disables the flanking bonus (which was not being used)
• The third listener is the enchanter's. He receives the attack and makes a roll, which succeeds.
• Somehow, the archer needs to know that his attack dealt 0 damage so his lifesteal effect can proc (or not, technically)

BUT! What if the listeners were in a different order...

• Game dispatches archer's attack
• Knight listener sees that the Thief is being targeted, and doesn't care because he's not close enough.
• Thief listener rolls for defense and gets, like, 2.
• Enchanter listener applies a charisma bonus to the Thief (as part of a question to the DM)
• Archer listener switches targets to Enchanter, shoots with super buff (but no flanking since the new target was attacking him, despite having flanking in Prepare) and either game breaks because there is no longer a defense roll, or it uses the Thief's defense roll which was pathetic and the Enchanter dies.
• Also, the archer heals for a boatload.

Now the DM has to explain that the Enchanter died even though he asked the Thief to roll for defense.

Technically this isn't completely accurate; Chaos is not a debuff so it would probably swap the target during its resolution, but there might be a duration version which behaves this way, and it still illustrates the point.

Essentially we have three steps:

1. PREPARE_ACTION (get initiative, mostly).
2. VALIDATE_ACTION (right before we do it, check on the game state to apply weird things like buffs and passives)
3. PERFORM_ACTION (do the thing, get the damage, heal the lifesteal, etc. Probably Charisma?)

The first and possibly third are straightforward. The second is full of complex interactions and might include additional actions (Trip, for example). I see two solutions. One, give up. We're boned, and we should just show the actions to the DM before using them to ask for any changes based on buffs, etc. Two, try to establish a hierarchy for listeners.

Maybe something like:

const highPriorityListeners = {};
const mediumPriorityListeners = {};
const lowPriorityListeners = {};

function subscribe(eventType, listener, subscriber, queue) {
  if (queue === HIGH) { // a constant somewhere
    if (!highPriorityListeners[eventType]) {
      highPriorityListeners[eventType] = [];
    }
   // context is the global state
    highPriorityListeners[eventType].push((action) => listener(subscriber, context, action));
  } else if (/* etc. */) {
    // ...
  }
}

function dispatch(event) {
  const { type: eventType } = event;
  highPriorityListeners[eventType].forEach((listener) => listener(event));
  mediumPriorityListeners[eventType].forEach((listener) => listener(event));
  lowPriorityListeners[eventType].forEach((listener) => listener(event));
}

This assumes that there are only a few distinct classes which MUST follow after each other. It could be more than three, and adding a queue is easy, but if there are priority conflicts we're just completely doomed.

[nigelrobbins3]

Or maybe we can get away with it by pulling actions out of events entirely.

// --- Game.js ---

// ...
while(!isGameOver()) {
  dispatch(prepareAllYourActionsEveryone())
  const actions = this.everyone.map((thing) => thing.preparedAction);
  actions.sortBy(initiativeSorter);
  actions.forEach((action) => {
    action.validate();
    action.perform();
  }); // except a for loop so we can break on GameOver
}

// --- SomeThing.js ---
subscribe("PREPARE_ALL_YOUR_ACTIONS_EVERYONE", thingActionPreparer, this);

function thingActionPreparer(subscriber, context, event) {
  this.preparedAction = this.prepareAction();

  return {
    validate() {
      const validateTargetPayload = { target: this.preparedAction.target };
      dispatch(pleaseChangeMyTargetIfYouWant(validateTargetPayload));
      const target = validateTargetPayload.target; // could have been mutated

      const validateBonusesPayload = {
        target,
        roll: this.preparedAction.roll,
        bonus: this.getBonusesIKnowAbout(),
      };
      dispatch(pleaseUpdateMyBonuses(validateBonusesPayload));
      // etc....
    },
    perform() {
      // maybe unnecessary to have both
      const performPayload = { ...this.buffsAndRollsAndWhatever };
      dispatch(thisActionIsReallyReallyPerformingNow(performPayload));
      dispatch(checkLifestealOrKillstreakOrWhatever()); // not sure how to get this still
  };
}

[nigelrobbins3]

The benefit in the second one is if a particular action comes along and needs to validate something it's easy to slot it into the action and add a listener on the relevant other Things. The drawback is that we still go in arbitrary "listener creation" order, but at least it's isolated more effectively. If two people want to change my bonus that's easy, just buff = oldBonus + newBonus. If two people want to change my target then the last one wins, but maybe that's OK.