Natural Action Resolution Guide for Hosts, Players, and Passersby

Natural Action Resolution Guide

Table of Contents

Introduction to NAR

Natural Action Resolution (or NAR) is the most standard system of deciding what order to use for resolving actions during a mafia game. It was originally designed by Xylthixlm over on MafiaScum.

To utilize NAR, start by applying the Golden Rule of NAR.

The Golden Rule of NAR: Apply actions which modify other actions before the actions they modify.

Here are two examples of the Golden Rule in action.

Example 1

Red is a Roleblocker, Green is a Redirector, Orange is a Fruit Vendor. Orange targets Green. Red targets Green, who targets Orange, redirecting them to Red.

  1. (Red) Red’s action is the only one unaffected by any other, so Red has priority.
  2. (Green) Green is roleblocked. They learn that their action failed.
  3. (Orange) Orange sends their fruit to Green as originally intended.

Example 2

Green is a Redirector, Red is a Roleblocker, Orange is a Fruit Vendor. Pink is another player. Green targets Red, redirecting them to Pink. Red targets Orange. Orange targets Red.

  1. (Green) Green’s action is the only one unaffected by any other, so Green has priority.
  2. (Red) Red is redirected to Pink. They may or may not learn of this redirection.
  3. (Orange) Orange sends their fruit to Red as originally intended.

But what if two actions modify each other (or nobody has an unmodified action)?

Sometimes the actions that might affect each other form a loop of sorts, or the order of resolution otherwise matters and cannot be determined via the Golden Rule. In that case, you can use the following priority list:

You may notice this list is a little more specific than that on MafiaScum. That is intentional.

Here are two examples of resolving loops using the priority list:

Example 3

Red is a Roleblocker, Green is a Redirector, Orange is a Fruit Vendor. Orange targets Green. Red targets Green, who targets Red, redirecting them to Orange.

  1. (Red/Green) Red and Green are both affecting each other. Since Red is a Roleblocker and Green is a Redirector, Red has priority.
  2. (Green) Green is roleblocked. They learn that their action failed.
  3. (Orange) Orange sends their fruit to Green as originally intended.

Example 4

Pink is a Commuterizer, Red is a Roleblocker, Green is a Redirector, Orange is a Fruit Vendor. Pink targets Red, who targets Green, who targets Pink, redirecting them to Orange. Orange targets Red.

  1. (Pink/Red/Green) Pink, Red, and Green are all affecting each other. Pink is a Commuterizer, so Pink has priority out of the three of them, followed by Red, then Green.
  2. (Red) Red is commuted. They learn their action failed.
  3. (Green). Green has nothing to redirect, but they don’t learn anything.
  4. (Orange). Orange’s target (Red) is commuted. Orange learns their action failed.

Always start with the highest role priority that applies to a part of the role.

Addendum: But what if two players have the same role priority?

Last but not least, sometimes two players may have the same role priority. In that case, the host should determine an order of resolution prior to starting the game. One system for order of resolution for actions of the same priority is as follows:

  1. Different Actions: If the two actions are different, see if the other parts of the role, if any, can be expressed in terms of other role priorities. Order based on the role priority list, with zero other role priorities coming first. For example, a Roleblocker has priority over a Jailkeeper (Roleblocker + Doctor), who has priority over a Super Commandant (Roleblocker + Alignment Cop).
  2. Different Alignments: If the two actions are the same and the two players have different alignments, resolve Neutrals, then Scum (usually Mafia), then Town.
  3. Both Neutral: If the two actions are the same and the two players are both Neutral, resolve the least-aligned Neutrals, then Scum-friendly Neutrals, then Town-friendly Neutrals.
  4. Same non-Neutral Alignment: If the two actions are the same and the two players are both Scum or both Town, choose ahead of time which player’s action will resolve first. If you have forgotten to do so, use a fair system during the game that only utilizes game information from before the randomization of roles, or is entirely random.

Here are four examples of resolving the same role priority:

Example 5

Red is a Roleblocker, Blue is a Jailkeeper. Red is targeting Blue, who is targeting Red.

  1. (Red/Blue) Red doesn’t have the lower-priority Doctor that Blue has. Since Red is a simple Roleblocker, Red has priority.
  2. (Blue) Blue is roleblocked and learns that their action failed.

Example 6

Red is a Mafia Roleblocker, Green is a Town Roleblocker. Red is targeting Green, who is targeting Red.

  1. (Red/Green) Red is Mafia and Green is Town. Red has priority.
  2. (Green) Green is roleblocked and learns that their action failed.

Example 7

Orange is a Neutral Serial Killer (and Roleblocker), Pink is a Neutral Survivor Vigilante (and Roleblocker). Orange and Pink are targeting each other with nightkills and roleblocks.

  1. (Orange/Pink) Orange is closer to a True or even Mafia-Friendly Neutral than Pink, who is usually Town-Friendly, so Orange has priority.
  2. (Pink) Pink is roleblocked. They die (as their actions failed).

Example 8

Forest and Lime are Town Roleblockers. Forest is targeting Lime, who is targeting Forest.

  1. (Forest/Lime) The host has pre-decided to use alphabetical character flavour name order to resolve two players with the same role. Forest has the character “A tree” and Lime has the character “Banana”. As Forest is earlier in the pre-decided system, Forest has priority.
  2. (Lime) Lime is roleblocked and learns that their action failed.

Other Systems of Action Resolution

Should you prefer to use something other than Natural Action Resolution, the primary other type of system that is particularly easy for players to understand is “Linear Action Resolution”, also known as LAR or Order of Operations (OoO). In such a system, the actions are resolved in order of a list, similar to the priority list in NAR.

While this is the easiest type of system to understand, this can be unsatisfactory for the players in the second example on this page. If we were to use NAR’s priority list as an Order of Operations, when Roleblockers ALWAYS resolve before Redirectors, a Redirector cannot redirect a Roleblocker as the Roleblocker’s action has already occurred, and as such, the Redirector will have their action fail when targeting a Roleblocker.

SNARF is an example of Linear Action Resolution.

Another system that people sometimes use is “Reasonable Action Resolution” (RAR). If you feel comfortable with explaining Reasonable Action Resolution to your players, then it can be an alternative for you to utilize. That said, it is not as commonplace as NAR or LAR, and for many players, not as intuitive as either.

Reasonable Action Resolution (From the MafiaScum Wiki)

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

6 Likes

I can’t understand this there aren’t enough pictures

10 Likes

i’ve always been an advocate for reasonable action resolution even though it very very rarely differs from NAR

1 Like

It has its ups and downs. I like the idea of something like a double-jailkeeper resolving as a double-doc, though.

Just don’t have actions

1 Like