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