Reasonable Action Resolution

Type: Modding Author: callforjudgement

Reasonable Action Resolution (RAR) is a new night action resolution algorithm developed in an attempt to fix some of the problems with existing resolution methods.

Motivation

Natural Action Resolution, or NAR, is widely used and produces the expected results in simple cases (thus "natural"). However, it has two main problems. One is that when its Golden Rule breaks down, it resorts to a list system as a fallback, but such a system solves less than half of the Golden Rule breakdown cases that actually come up in practice. (The most famous/infamous such case is a roleblocker and a jailkeeper targeting each other.) The other is that moderators often read the page incompletely and come to incorrect conclusions about how NAR works.

Meanwhile, list systems (such as SNARF) avoid these problems, but have two problems of their own. One is that the list itself is somewhat arbitrary, and thus cannot easily be remembered or predicted by players; it's hard, as a player in such a game, to calculate role interactions yourself without asking the mod (and the mod cannot necessarily do it without spoiling details of the setup). The other is that the night resolutions are a long way from what players and reviewers are used to (e.g. you can't block a redirection effect in SNARF, even if the redirector is targeting players unrelated to you and thus there is no action loop), which can potentially have balance impacts that need to be allowed for in the setup.

Reasonable Action Resolution attempts to break action resolution down to simple, easily-remembered rules that give the same results as NAR in all simple cases, whilst covering all possible interactions between roles in a consistent way. There is no big list of roles; all roles are treated in the same general framework.

Algorithm

In Reasonable Action Resolution, each night action is broken down into a set of basic components, each of which is one of the following:

• An effect that happens at the end of the night (e.g. a Vigilante kills a player at the end of the night; a Cop is told investigation results at the end of the night). These effects don't interfere with or affect any other action.
• An observable effect, that does nothing by itself, but can be seen by Tracker-style roles (a Visitor is a pure example of this, but the vast majority of active roles are trackable and thus have a Visitor-like component).
• An effect that changes the result of another action (e.g. a Doctor causes kills to fail; a Redirector changes the target of an action).

All roles can be seen as a combination of these basic components. For example, a Jailkeeper action has three components (as it happens, one in each category), Doctor + Visitor + Roleblocker. Passive roles are treated the same way as (untrackable and unblockable) active roles that self-target.

Reasoned Action Resolution is based on the principle that what a moderator is actually interested in is the end-of-night effects; the other effects affect action resolution, but the details of what happened are unimportant, just the end result. Thus:

Rule #1: Don't check whether "an action" succeeded; check whether a particular end of night effect happens.

For example, if you think a certain player might die overnight, don't check to see who killed them; just check to see whether they die.

Rule #2: An end of night effect happens if there is a reason that it happens that isn't counteracted by a reason that would prevent it happening (that isn't itself counteracted by a reason that would prevent it happening, and so on).

This is the main idea behind Reasonable Action Resolution, and is best understood using examples.

First, the most trivial examples:

A Vigilante shoots player A:

• Does player A die?
  • Reason for yes: A Vigilante shot them

Yep, the player died. This should not be a surprise.

A Cop investigates player A:

• Does the Cop get a correct result?
  • Reason for yes: Cop investigation on player A

This is analogous to the situation with the Vigilante; nothing affects the action, so it has the usual effects.

More complex are examples involving role modification:

A Doctor protects player A, and a Vigilante shoots player A:

• Does player A die?
  • Reason for yes: A Vigilante shot them
    • Reasons for no: The Doctor action prevents kills

In this case, each reason for yes has a counteracting reason for no, so the action fails.

Player B (a Doctor) protects player A, and a Vigilante shoots player A, and a Roleblocker blocks player B:

• Does player A die?
  • Reason for yes: A Vigilante shot them
    • Reasons for no: The Doctor action prevents kills
      • Reason for yes: The Doctor's protection effect was roleblocked

In this case, we have a non-counteracted reason for yes, so the player dies. This is the same result as would be expected in most other action resolution schemes.

Player B (a Doctor) protects player A, and a Vigilante shoots player A, and player C (a Roleblocker) blocks player B, and player D (a Roleblocker) blocks player C:

• Does player A die?
  • Reason for yes: A Vigilante shot them
    • Reasons for no: The Doctor action prevents kills
      • Reason for yes: The Doctor's protection effect was roleblocked
        • Reason for no: the Roleblocker blocking effect was roleblocked

As seen here, and like NAR (but unlike SNARF), counteracting reasons can chain indefinitely. Player A doesn't die, because each reason for yes has a matching reason for no.

Player B (a Doctor) protects player A, and a Vigilante shoots player A, and a Jailkeeper targets player A, and a Roleblocker blocks player B:

• Does player A die?
  • Reason for yes: A Vigilante shot them
    • Reasons for no: The Doctor action prevents kills
      • Reason for yes: The Doctor's protection effect was roleblocked
    • Reason for no: The Jailkeeper action prevents kills

As seen here, there can be more than one reason why an effect would succeed or fail. An effect fails if each reason it would succeed is counteracted. In this case, the doctor action is counteracted, but the Jailkeeper action isn't, so the "player A dies" effect is successfully counteracted and player A survives.

There are two main categories of interactions which are complex enough that rule #2 isn't enough by itself. One is the case of tracking-style and redirection-style abilities, because multiple actions are involved:

Rule #3: An effect produced by modifying/triggering on an effect requires both an effect to modify/trigger on, and a modifying/triggering effect.

The simplest case is that of a tracking effect:

Player B (a Vigilante) shoots player A, and a Tracker tracks player B.

• Does the Tracker see player B see player A?
  • Reason for yes: the Tracker tracked player B, and player B visited player A.

Because both parts of the track result (the track, and the visit that's being tracked) happened, the effect happens.

It can be blocked either way, though:

Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player C.

• Does the player C see player B see player A?
  • Reason for yes: player C tracked player B, and player B visited player A.
    • Reason for no: player C's tracking effect was roleblocked.
• Does the player C see player B take no action?
  • no reasons for yes, thus no by default

The tracker will get "no result".

Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player B.

• Does the player C see player B see player A?
  • Reason for yes: player C tracked player B, and player B visited player A.
    • Reason for no: player B's visiting effect was roleblocked.
• Does the player C see player B take no action?
  • Reason for yes: player C tracked player B.
    • Reason for no: player B visited player A.
      • Reason for yes: player B's visiting effect was roleblocked.

The tracker will get "went nowhere".

Redirection works in much the same way:

Player B (a Vigilante) shoots player A, and a Redirector redirects player B onto player C.

• Does player A die?
  • Reason for yes: player B shot them.
    • Reason for no: the killing effect on B was redirected away.
• Does player C die?
  • Reason for yes: player B shot player A, and player B's killing effect was redirected onto player C.

So do triggered actions:

Player A (a Cop) investigates player B (a Paranoid Gun Owner).

• Does player A die?
  • Reason for yes: player A visited player B, and player B PGO-armed themself.

Player A (a Cop) investigates player B (a Paranoid Gun Owner). A Doctor protects player A.

• Does player A die?
  • Reason for yes: player A visited player B, and player B PGO-armed themself.
    • Reason for no: the Doctor protected them.

In this case, the Doctor role is interfering with the PGO shot, causing it to have no effect. Interfering with player A's visit would work just as well.

So far, all the examples have been simple, but the same reasoning can handle some highly complex cases:

A Vigilante shoots player B. A Bus Driver swaps targets on players A and B. Another Bus Driver swaps targets on players B and C.

• Does player A die?
  • Reason for yes: a Vigilante shot player B, and the killing effect on B was swapped onto player A.
    • Reason for no: the killing effect on B was swapped onto player C.
• Does player B die?
  • Reason for yes: a Vigilante shot player B.
    • Reason for no: the killing effect on B was swapped onto player A.
      • Reason for yes: the swapping effect from B to A failed due to a swapping effect from B to C.
    • Reason for no: the killing effect on B was swapped onto player C.
      • Reason for yes: the swapping effect from B to C failed due to a swapping effect from B to A.

You can't redirect an effect that's already been redirected elsewhere, thus both the bus drives effectively block the other (any attempt to say "the kill was swapped from B to C" is counteracted by "the kill was swapped from B to A", and vice versa). Note that other action resolution methods leave cases like this somewhat unclear.

A Vigilante shoots player A. A Bus Driver swaps targets on players A and B. Another Bus Driver swaps targets on players B and C.

• Does player A die?
  • Reason for yes: a Vigilante shot player A.
    • Reason for no: the killing effect on A was swapped onto player B.
• Does player B die?
  • Reason for yes: a Vigilante shot player A, and the killing effect on A was swapped onto player B.
    • Reason for no: the killing effect on B was swapped onto player C.

This case is different, because swapping a kill from B to C doesn't interfere with any actions against A, breaking the symmetry.

It should be noted that these cases are also implicitly using the final rule:

Rule #4: The same action can't appear twice in a dependency chain; if it would counteract an action that counteracts it, counteracts an action that would counteract it, etc., it has no effect instead.

This gives a consistent way to break up infinite loops, ensuring that the algorithm always comes to a definite result. (Note that this applies to an entire action, not a component of it; if one component of an action appears in a dependency chain, others can't start counteracting or supporting it.) Thus, this leads to a non-arbitrary resolution of the most famous action loop in Mafia:

A Vigilante shoots player A. Player A (a Roleblocker) blocks player B. Player B (a Jailkeeper) jails player A.

• Does player A die?
  • Reason for yes: a Vigilante shot them.
    • Reason for no: player B protected player A (with the Jailkeeper action).
      • Reason for yes: player A roleblocked player B.
        • Reason for no: player B roleblocked player A (with the Jailkeeper action).

Player A dies; the Jailkeeper action has already appeared once in the dependency chain, so it can't appear again.

A related case:

Player B (a Mafia Roleblocker) shoots and roleblocks player A. Player A (a Jailkeeper) jails player B.

• Does player A die?
  • Reason for yes: player B shot them (with the Mafia factional kill).
    • Reason for no: player A roleblocked player B (with the Jailkeeper action).
      • Reason for yes: player B roleblocked player A (with the Roleblocker action).
        • Reason for no: player A roleblocked player B (with the Jailkeeper action).

Again, player A dies. Player A's role can't block player B twice in the same dependency chain, whereas player B's

Summary

Rule #1: Don't check whether "an action" succeeded; check whether a particular end of night effect happens.

Rule #2: An end of night effect happens if there is a reason that it happens that isn't counteracted by a reason that would prevent it happening (that isn't itself counteracted by a reason that would prevent it happening, and so on).

Rule #3: An effect produced by modifying/triggering on an effect requires both an effect to modify/trigger on, and a modifying/triggering effect.

Rule #4: The same action can't appear twice in a dependency chain; if it would counteract an action that counteracts it, counteracts an action that would counteract it, etc., it has no effect instead.

Role rulings

There are some questions about how roles work that don't necessarily have much to do with action resolution, but nonetheless occasionally come up. A mod can answer these questions in the role PM or in the game rules, but here are "default" rulings that players in a Reasonable Action Resolution game can assume are in use, and mods should use, in absence of rules saying so:

• A player cannot self-target (except with abilities that only self-target, or (as always) if the role PM explicitly says otherwise).
• Passive abilities cannot be tracked, roleblocked or redirected.
• Killing a player does not prevent them using night actions.
• There is no implicit "one action per night" limit by default, unless the mod says so in the role PM or start-of-game rules.

Special cases

In general, moderators should use the scheme shown here so that players can predict what the outcome of any set of actions would be. However, occasionally, the outcome (while consistent) would be undesirable.

In such cases, the best solution is normally to use role modifiers in order to change the outcome. For example, if you (as a mod) don't like the Roleblocker/Jailkeeper interaction that this method produces "by default", why not make one of them Strong-Willed?

There is one case, though, in which modifiers don't help much, and the standard RAR outcome is undesirable. This is when a player is killed and recruited in the same night. Following the RAR rules implies that the player's alignment should change, but this outcome is quite bad for balance purposes (even more so than cults are usually, that is). Making killing abilities also give an Alarmist effect is also somewhat undesirable, because then if a player is killed, protected and recruited all on the same night, that player will survive and keep their alignment. The correct fix here is to modify the cult recruiter's PM, by specifying that it does not work on players who die that night; then, any reason why the player would die also becomes a reason why the player would not be recruited, and both reasons will be counteracted by the same things, meaning that you get the desired outcome (without needing to spoil the existence of a cult in any role PM but that of the cult recruiter, who presumably already knows).