You are viewing the MafiaScum.net Wiki. To play the game, visit the forum.

Reasonable Action Resolution: Difference between revisions

From MafiaWiki
Jump to navigation Jump to search
No edit summary
(I finally figured out a good way to present this; I also removed some arbitrary tweaks in the old version (which had made it less elegant simply to produce the resolutions I wanted), let's tweak by changing the setup not the action resolution)
Line 12: Line 12:
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.
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.
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 almost 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 ==
== 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:
Unlike Natural Action Resolution, Reasonable Action Resolution does not try to place all night actions into one big list of "what happened" or "what didn't happen"; rather, it looks at particular effects that might happen (such as a particular player dying overNight or a particular investigation result), and works out whether or not it occurs via looking only at the actions that might be relevant to it. So it's possible for a roleblock to, e.g., succeed when determining whether player A dies, but fail when determining whether player B dies.
* 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 ([[Ninja|untrackable]] and [[Strong-Willed|unblockable]]) active roles that self-target.
RAR also considers actions to be broken down into their components; for example, a Jailkeeper protects and roleblocks a target. In RAR, the protect and roleblock are considered separately, so (when determining whether some particular effect happens) one of them might succeed, and the other one might fail. Likewise, if one player roleblocks another, and the other player is taking two different actions, then the roleblock of each individual action is listed separately, treated as blocking action A and separately as blocking action B. (This splitting of roles into the simplest possible components is required for the algorithm to give a single, unambiguous result.)


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:
To determine whether an effect occurs using RAR, you create a list of actions. First, list any actions that might (if they resolved) cause that effect. Then, add any actions that might (if they resolved) interfere with the actions you've already listed to the list. Keep going until you run out of actions to add, with the proviso that once an action has been placed on the list, it can't be placed there a second time (this guarantees that you will eventually stop listing actions). Once you finish making the list, resolve all the actions you've listed in the reverse order that you listed them; if that list of actions would produce the effect you're looking at, then it occurs, otherwise it doesn't.


; Rule #1<nowiki>:</nowiki> Don't check whether "an action" succeeded; check whether a particular end of night effect happens.
The only extra complexity comes from redirection-style effects. These are implemented as two separate actions: a "redirect away" which acts similarly to a roleblock, and a "redirect onto" that only does anything if the action was previously redirected away by the same redirect. An "action that could cause an effect" includes the "redirect onto" part of a redirection, so any potential redirections that might cause a particular effect need to be listed at the start of the list. Actions that could have been redirected to produce that redirection need to be added to the list once the redirection is there (as they affect whether the redirection could occur; you can't redirect an action that doesn't occur). See the examples below.
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<nowiki>:</nowiki> 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).
== Examples ==
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?
:* Vigilante shoots player A
: There's only one action to resolve here, so yes, player A dies.


A Vigilante shoots player A:
; A [[Doctor]] protects player A, and a Vigilante shoots player A.
* Does player A die?
: Does player A die?
** Reason for yes: A Vigilante shot them
:* Vigilante shoots player A
Yep, the player died. This should not be a surprise.
:* Doctor protects player A from one kill
: The Vigilante is listed first, because it can ''cause'' player A to die (the Doctor can't cause that). Only after adding the Doctor to the list, can we list the Doctor (who can't cause player A to die, but can protect against the Vigilante action). We resolve the actions in reverse order, so the Doctor protects player A, the Vigilante fails to shoot them, and player A survives.


A Cop investigates player A:
; Player B (a Doctor) protects player A, and a Vigilante shoots player A, and a [[Roleblocker]] blocks player B.
* Does the Cop get a correct result?
: Does player A die?
** Reason for yes: Cop investigation on player A
:* Vigilante shoots player A
This is analogous to the situation with the Vigilante; nothing affects the action, so it has the usual effects.
:* Player B protects player A from one kill
:* Roleblocker blocks player B's protection of player A
: This is similar to the previous case; we can add the Roleblocker action to the list only after an action taken by player B appears on it. Resolving the actions in reverse order, we find that the Roleblocker blocks player B, no protection happens, and the Vigilante action goes through.


More complex are examples involving role modification:
The same idea chains indefinitely, e.g. if we add a second Roleblocker:


A Doctor protects player A, and a Vigilante shoots player A:
; 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?
: Does player A die?
** Reason for yes: A Vigilante shot them
:* Vigilante shoots player A
*** Reasons for no: The Doctor action prevents kills
:* Player B protects player A from one kill
In this case, each reason for yes has a counteracting reason for no, so the action fails.
:* Player C blocks player B's protection on player A
:* Player D blocks player C's block on player B
: As seen here, and like NAR (but unlike SNARF), counteracting reasons can chain indefinitely. Resolving the actions in the reverse order of the list, we find that player D blocks player C, player C's action fails due to being blocked, player B protects player A, and the Vigilante action spends itself on the protection. So player A survives. (In SNARF, this combination of actions would cause player A to die.)


Player B (a Doctor) protects player A, and a Vigilante shoots player A, and a Roleblocker blocks player B:
; 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?
: Does player A die?
** Reason for yes: A Vigilante shot them
:* Vigilante shoots player A
*** Reasons for no: The Doctor action prevents kills
:* Player B protects player A from one kill
**** Reason for yes: The Doctor's protection effect was roleblocked
:* Jailkeeper protects player A from all kills
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.
:* Roleblocker blocks player B's protection of player A
: We now have a choice in how to write the list; after adding the Vigilante to the list, we could add either the Doctor or Jailkeeper protection to it next, and once the Doctor protection has been added, we could add either the Jailkeeper or Roleblocker next. Because the actions are split into their smallest possible components, though, the exact ordering of the list in these cases does not matter. Resolving the list backwards, we find that the Roleblocker and Jailkeeper actions resolve (for the purpose of determining whether player A dies); the Doctor action doesn't, and the Vigilante action is protected against by the Jailkeeper (even though the Doctor couldn't stop it).


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:
; Player B (a Vigilante) shoots player A, and a [[Tracker]] tracks player B.
: What does the Tracker see?
:* Tracker tracks player B
:* Player B shoots player A
: The Tracker action has to be added first (and thus resolves last) because it's the only thing that produces a Tracker report. So for the purpose of calculating the track, the Vigilante action resolves first, and then the Tracker can see it happening.


* Does player A die?
; Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player C.
** Reason for yes: A Vigilante shot them
: What does the Tracker see?
*** Reasons for no: The Doctor action prevents kills
:* Player C tracks player B
**** Reason for yes: The Doctor's protection effect was roleblocked
:* Roleblocker blocks player C's track of player B
***** Reason for no: the Roleblocker blocking effect was roleblocked
:* Player B shoots player A
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.
: The Vigilante and Roleblocker actions can be added in either order, and can resolve either way round; but in either case, the Tracker gets [[no result]], with their action having been blocked by the time we check to see if it occurred.


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:
; Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player B.
* Does player A die?
: What does the Tracker see?
** Reason for yes: A Vigilante shot them
:* Player C tracks player B
*** Reasons for no: The Doctor action prevents kills
:* Player B shoots player A
**** Reason for yes: The Doctor's protection effect was roleblocked
:* Roleblocker blocks player B's shot at player A
*** Reason for no: The Jailkeeper action prevents kills
: This time there's only one way to build the list; we can't add the roleblock of player B's shot until the shot is added. So the roleblock resolves first, the shot "resolves" next (but fails due to being blocked), and then finally the Tracker finds no actions it can see. So the Tracker gets a "went nowhere" result.


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.
; Player B (a Vigilante) shoots player A, and a [[Redirector]] redirects player B onto player C.
: Does player A die?
:* Player B shoots player A
:* Redirector redirects player B's shot away from player A
: The "redirect away" half of a redirect acts identically to a roleblock from the action resolution point of view. The redirection resolves before the shot, and player A survives, because the shot was redirected away.
; Does player C die?
:* Redirector redirects shots by player B towards player C
:* Player B shoots player A
:* Redirector redirects player B's shot away from player A
: This example is more complex. The action that could kill player C is a redirected shot; this is added to the list first, because it is indeed something that could kill player C. Then the shot of player B at player A is added to the list, because it's something that could affect whether the action occurs. Finally, we add the redirection of player B's shot away from player A, because this is something that would prevent player B shooting player A. When resolving this list, we start by redirecting the Vigilante shot away; then the shot occurs, but fails to kill player A due to being redirected (not that we're checking for that anyway); then player C dies, because a shot by player B was indeed redirected, and thus it hits player C.


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:
; Player A (a [[Cop]]) investigates player B (a [[Paranoid Gun Owner]]).
: Does player A die?
:* Player B shoots player A if triggered
:* Player A investigates player B
: As a hypothetical action that could cause player A's death, the PGO action needs to be listed first; in RAR, actions that could occur need to be listed, even if we don't know whether they will or not (it's important to make a note of what would cause them). Then we list the Cop action, because it could trigger the PGO action. Resolving in the reverse order, the investigate happens first, then the PGO shot (which was indeed triggered), so player A dies.


; Rule #3<nowiki>:</nowiki> An effect produced by modifying/triggering on an effect requires both an effect to modify/trigger on, and a modifying/triggering effect.
The previous examples all give identical results as [[Natural Action Resolution]] does. This is because both methods are designed to resolve interdependent chains of actions in the natural order that allows them all to function, as long as long as there are no ambiguities or paradoxes. The difference between the systems is that when an action loop does occur, an arbitrary tiebreak based on the specific actions is needed to break the loop. RAR also provides a fairly arbitrary method of breaking the loops, but has the advantage of being symmetrical (i.e. the time at which an action is submitted is irrelevant), and treating all roles equally. Here are some examples of ambiguities and paradoxes:


The simplest case is that of a tracking effect:
; A Vigilante shoots player A. Player A (a Roleblocker) blocks player B. Player B (a Jailkeeper) jails player A.
: Does player A die?
:* Vigilante shoots player A
:* Player B protects player A from all kills
:* Player A blocks player B's protection
:* Player B blocks player A's block
:* Player A blocks player B's block
: It looks like we have an action loop here. In most action resolution systems, this needs an arbitrary tiebreak to break up. However, in RAR, the loop naturally comes to an end, because we've run out of actions to place on the list; "Player B blocks player A's block" is on the list already, so we can't place it onto the list a second time even though it could affect player A's block. So the list stops at five entries, and resolving it in reverse order, we find that the blocks of the blocks cancel out, the block of the protection succeeds, the protection therefore fails and the Roleblocker dies.


Player B (a Vigilante) shoots player A, and a Tracker tracks player B.
; Player B (a Mafia Roleblocker) shoots and roleblocks player A. Player A (a Jailkeeper) jails player B.
* Does the Tracker see player B see player A?
: Does player A die?
** Reason for yes: the Tracker tracked player B, ''and'' player B visited player A.
:* Player B shoots player A
Because both parts of the track result (the track, and the visit that's being tracked) happened, the effect happens.
:* Player A blocks player B's shot
:* Player B blocks player A's block
:* Player A blocks player B's block
: Again, the blocks of the blocks cancel out. Just as before, this means that the non-block actions are blocked, and fail, so in this case player A survives (the shot was blocked).


It can be blocked either way, though:
; An [[Inventor]] gives an invention to player A. A [[Vanillaiser]] vanillaises player A.
 
: Does player A gain an invention for tomorrow Night?
Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player C.
:* The Inventor gives Player A an invention.
* Does the player C see player B see player A?
:* Player A is vanillaised.
** Reason for yes: player C tracked player B, ''and'' player B visited player A.
: The Vanillaiser can interfere with inventions, but it cannot itself give an invention. Thus, the invention is added to the list first, and resolves last, after the vanillaisation happens. The invention will be usable the next Night.
*** 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<nowiki>:</nowiki> 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.
***** <s>Reason for no: player B roleblocked player A (with the Jailkeeper action).</s>
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).
***** <s>Reason for no: player A roleblocked player B (with the Jailkeeper action).</s>
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<nowiki>:</nowiki> Don't check whether "an action" succeeded; check whether a particular end of night effect happens.
; Rule #2<nowiki>:</nowiki> 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<nowiki>:</nowiki> An effect produced by modifying/triggering on an effect requires both an effect to modify/trigger on, and a modifying/triggering effect.
; Rule #4<nowiki>:</nowiki> 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 ==
== Role rulings ==
Line 186: Line 129:
* A player cannot self-target (except with abilities that ''only'' self-target, or (as always) if the role PM explicitly says otherwise).
* 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.
* Passive abilities cannot be tracked, roleblocked or redirected.
* Killing a player does not prevent them using night actions.
* Killing a player does not include an implicit roleblock; a player's action goes through even if they died earlier in the resolution sequence.
* 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.
* Redirection abilities cannot themselves be redirected. (This rule prevents a combinatorial explosion in cases where multiple redirectors exist; RAR cannot resolve such cases otherwise, because it's hard to know where to draw the line when coming up with hypothetical redirections affecting other redirections and eventually causing particular actions to happen.) Redirect''ed'' actions, on the other hand, can be redirected again.


== Special cases ==
== Special cases ==

Revision as of 04:48, 15 September 2020

Type:
Author:

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 almost 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

Unlike Natural Action Resolution, Reasonable Action Resolution does not try to place all night actions into one big list of "what happened" or "what didn't happen"; rather, it looks at particular effects that might happen (such as a particular player dying overNight or a particular investigation result), and works out whether or not it occurs via looking only at the actions that might be relevant to it. So it's possible for a roleblock to, e.g., succeed when determining whether player A dies, but fail when determining whether player B dies.

RAR also considers actions to be broken down into their components; for example, a Jailkeeper protects and roleblocks a target. In RAR, the protect and roleblock are considered separately, so (when determining whether some particular effect happens) one of them might succeed, and the other one might fail. Likewise, if one player roleblocks another, and the other player is taking two different actions, then the roleblock of each individual action is listed separately, treated as blocking action A and separately as blocking action B. (This splitting of roles into the simplest possible components is required for the algorithm to give a single, unambiguous result.)

To determine whether an effect occurs using RAR, you create a list of actions. First, list any actions that might (if they resolved) cause that effect. Then, add any actions that might (if they resolved) interfere with the actions you've already listed to the list. Keep going until you run out of actions to add, with the proviso that once an action has been placed on the list, it can't be placed there a second time (this guarantees that you will eventually stop listing actions). Once you finish making the list, resolve all the actions you've listed in the reverse order that you listed them; if that list of actions would produce the effect you're looking at, then it occurs, otherwise it doesn't.

The only extra complexity comes from redirection-style effects. These are implemented as two separate actions: a "redirect away" which acts similarly to a roleblock, and a "redirect onto" that only does anything if the action was previously redirected away by the same redirect. An "action that could cause an effect" includes the "redirect onto" part of a redirection, so any potential redirections that might cause a particular effect need to be listed at the start of the list. Actions that could have been redirected to produce that redirection need to be added to the list once the redirection is there (as they affect whether the redirection could occur; you can't redirect an action that doesn't occur). See the examples below.

Examples

A Vigilante shoots player A.
Does player A die?
  • Vigilante shoots player A
There's only one action to resolve here, so yes, player A dies.
A Doctor protects player A, and a Vigilante shoots player A.
Does player A die?
  • Vigilante shoots player A
  • Doctor protects player A from one kill
The Vigilante is listed first, because it can cause player A to die (the Doctor can't cause that). Only after adding the Doctor to the list, can we list the Doctor (who can't cause player A to die, but can protect against the Vigilante action). We resolve the actions in reverse order, so the Doctor protects player A, the Vigilante fails to shoot them, and player A survives.
Player B (a Doctor) protects player A, and a Vigilante shoots player A, and a Roleblocker blocks player B.
Does player A die?
  • Vigilante shoots player A
  • Player B protects player A from one kill
  • Roleblocker blocks player B's protection of player A
This is similar to the previous case; we can add the Roleblocker action to the list only after an action taken by player B appears on it. Resolving the actions in reverse order, we find that the Roleblocker blocks player B, no protection happens, and the Vigilante action goes through.

The same idea chains indefinitely, e.g. if we add a second Roleblocker:

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?
  • Vigilante shoots player A
  • Player B protects player A from one kill
  • Player C blocks player B's protection on player A
  • Player D blocks player C's block on player B
As seen here, and like NAR (but unlike SNARF), counteracting reasons can chain indefinitely. Resolving the actions in the reverse order of the list, we find that player D blocks player C, player C's action fails due to being blocked, player B protects player A, and the Vigilante action spends itself on the protection. So player A survives. (In SNARF, this combination of actions would cause player A to die.)
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?
  • Vigilante shoots player A
  • Player B protects player A from one kill
  • Jailkeeper protects player A from all kills
  • Roleblocker blocks player B's protection of player A
We now have a choice in how to write the list; after adding the Vigilante to the list, we could add either the Doctor or Jailkeeper protection to it next, and once the Doctor protection has been added, we could add either the Jailkeeper or Roleblocker next. Because the actions are split into their smallest possible components, though, the exact ordering of the list in these cases does not matter. Resolving the list backwards, we find that the Roleblocker and Jailkeeper actions resolve (for the purpose of determining whether player A dies); the Doctor action doesn't, and the Vigilante action is protected against by the Jailkeeper (even though the Doctor couldn't stop it).
Player B (a Vigilante) shoots player A, and a Tracker tracks player B.
What does the Tracker see?
  • Tracker tracks player B
  • Player B shoots player A
The Tracker action has to be added first (and thus resolves last) because it's the only thing that produces a Tracker report. So for the purpose of calculating the track, the Vigilante action resolves first, and then the Tracker can see it happening.
Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player C.
What does the Tracker see?
  • Player C tracks player B
  • Roleblocker blocks player C's track of player B
  • Player B shoots player A
The Vigilante and Roleblocker actions can be added in either order, and can resolve either way round; but in either case, the Tracker gets no result, with their action having been blocked by the time we check to see if it occurred.
Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player B.
What does the Tracker see?
  • Player C tracks player B
  • Player B shoots player A
  • Roleblocker blocks player B's shot at player A
This time there's only one way to build the list; we can't add the roleblock of player B's shot until the shot is added. So the roleblock resolves first, the shot "resolves" next (but fails due to being blocked), and then finally the Tracker finds no actions it can see. So the Tracker gets a "went nowhere" result.
Player B (a Vigilante) shoots player A, and a Redirector redirects player B onto player C.
Does player A die?
  • Player B shoots player A
  • Redirector redirects player B's shot away from player A
The "redirect away" half of a redirect acts identically to a roleblock from the action resolution point of view. The redirection resolves before the shot, and player A survives, because the shot was redirected away.
Does player C die?
  • Redirector redirects shots by player B towards player C
  • Player B shoots player A
  • Redirector redirects player B's shot away from player A
This example is more complex. The action that could kill player C is a redirected shot; this is added to the list first, because it is indeed something that could kill player C. Then the shot of player B at player A is added to the list, because it's something that could affect whether the action occurs. Finally, we add the redirection of player B's shot away from player A, because this is something that would prevent player B shooting player A. When resolving this list, we start by redirecting the Vigilante shot away; then the shot occurs, but fails to kill player A due to being redirected (not that we're checking for that anyway); then player C dies, because a shot by player B was indeed redirected, and thus it hits player C.
Player A (a Cop) investigates player B (a Paranoid Gun Owner).
Does player A die?
  • Player B shoots player A if triggered
  • Player A investigates player B
As a hypothetical action that could cause player A's death, the PGO action needs to be listed first; in RAR, actions that could occur need to be listed, even if we don't know whether they will or not (it's important to make a note of what would cause them). Then we list the Cop action, because it could trigger the PGO action. Resolving in the reverse order, the investigate happens first, then the PGO shot (which was indeed triggered), so player A dies.

The previous examples all give identical results as Natural Action Resolution does. This is because both methods are designed to resolve interdependent chains of actions in the natural order that allows them all to function, as long as long as there are no ambiguities or paradoxes. The difference between the systems is that when an action loop does occur, an arbitrary tiebreak based on the specific actions is needed to break the loop. RAR also provides a fairly arbitrary method of breaking the loops, but has the advantage of being symmetrical (i.e. the time at which an action is submitted is irrelevant), and treating all roles equally. Here are some examples of ambiguities and paradoxes:

A Vigilante shoots player A. Player A (a Roleblocker) blocks player B. Player B (a Jailkeeper) jails player A.
Does player A die?
  • Vigilante shoots player A
  • Player B protects player A from all kills
  • Player A blocks player B's protection
  • Player B blocks player A's block
  • Player A blocks player B's block
It looks like we have an action loop here. In most action resolution systems, this needs an arbitrary tiebreak to break up. However, in RAR, the loop naturally comes to an end, because we've run out of actions to place on the list; "Player B blocks player A's block" is on the list already, so we can't place it onto the list a second time even though it could affect player A's block. So the list stops at five entries, and resolving it in reverse order, we find that the blocks of the blocks cancel out, the block of the protection succeeds, the protection therefore fails and the Roleblocker dies.
Player B (a Mafia Roleblocker) shoots and roleblocks player A. Player A (a Jailkeeper) jails player B.
Does player A die?
  • Player B shoots player A
  • Player A blocks player B's shot
  • Player B blocks player A's block
  • Player A blocks player B's block
Again, the blocks of the blocks cancel out. Just as before, this means that the non-block actions are blocked, and fail, so in this case player A survives (the shot was blocked).
An Inventor gives an invention to player A. A Vanillaiser vanillaises player A.
Does player A gain an invention for tomorrow Night?
  • The Inventor gives Player A an invention.
  • Player A is vanillaised.
The Vanillaiser can interfere with inventions, but it cannot itself give an invention. Thus, the invention is added to the list first, and resolves last, after the vanillaisation happens. The invention will be usable the next Night.

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 include an implicit roleblock; a player's action goes through even if they died earlier in the resolution sequence.
  • Redirection abilities cannot themselves be redirected. (This rule prevents a combinatorial explosion in cases where multiple redirectors exist; RAR cannot resolve such cases otherwise, because it's hard to know where to draw the line when coming up with hypothetical redirections affecting other redirections and eventually causing particular actions to happen.) Redirected actions, on the other hand, can be redirected again.

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).