Serial Night Action Resolution Framework

Serial Night Action Resolution Framework (SNARF) is a system of resolving night actions designed by Kagami.

This framework is designed to formalize the system already used by many mods as an alternative to NAR and to make it more transparent to both the players and mods. It also eliminates ambiguity by providing a mechanical basis for action resolution.

This article is a work in progress.

The Golden Rule

All night actions have an "order" value in square brackets [] that determines in what order they are resolved. Actions are resolved from lowest value to highest value. Actions of the same order occur simultaneously and independently.

Standardization of Priority

While a mod could choose any arbitrary set of order values for their night actions, doing so may inform players of how many actions are in the game and could make it impossible for players to fake-claim night action. Best practice is to determine order values relative to the guidelines below.

Standard Priorities

Order Value	Action Category
0	Passives take effect
20	Redirection effects
40	Blocking/Commuting effects
60	Protection effects
80	Killing effects
100	Investigation effects
200	End of the Night

Almost all Normal roles can be represented using only these recommended values.

Simultaneous Action

If two actions are of the same order (often in the case of two instances of the exact same action), they are resolved simultaneously and independently. This means that each action behaves as if the others don't exist.

Example: a roleblocker (order 40) targets another roleblocker (also order 40) who targets a doctor (order 60). In NAR, the first roleblocker in the chain would successfully block the second roleblocker, who would then fail to block the doctor. In SNARF, both roleblocks occur simultaneously, and are thus unable to influence each other. As a result, the second roleblocker would successfully block the doctor.

Note, however, that the first roleblockers action was successful, though it had no bearing on the end result. If the second roleblocker also performed another action of higher order, such as a Night Kill, that action would fail.

Non-standard Orders

While it is often possible to use only standard orders, it may be necessary to use non-standard orders. Non-standard orders are also recommended in cases where the result is identical if everything resolves simultaneously, but it eases understanding to use a different value. E.g. in a setup with both a commuter and a roleblocker, the mod may choose to give the commute an order slightly lower than 40 to make it clear that the commute will succeed even if the player is roleblocked.

Best practice is to use differences of 5 to indicate "slightly" below or above the standard, and differences of 10 when an action goes "in between" two standard values. In the prior example, the commute would have order 35 to indicate it occurs just before roleblocking.

In closed setups with unusual roles, mods should keep in mind how they would want their roles to interact with normal roles, and place them accordingly even if the normal roles don't exist in the game.

Sample Normal Role PMs

I'll put some normal PMs here.

Special Rules/Definitions

The following rules cover specific features of the framework in a mechanical fashion. Understanding these rules may be necessary to resolve certain more unusual cases, but for most situations the results of these rules should coincide with the mod's and players' intuition.

States

Many actions and passive abilities have effects that last throughout the night. Each such ability creates a "state." These states may influence subsequent actions, but will not influence actions that took place before the state came into effect.

Example: The action of a Doctor generates the state "Attempts to kill target player will fail until the end of the night." The Bulletproof passive generates an identical state, though it does so with order 0.

Triggered Actions

Unless otherwise specified, a triggered action will occur immediately after the resolution of the action that triggers it. If multiple actions are triggered by simultaneous actions, the triggered actions also occur simultaneously.

Compound Actions

Some actions may be composed of multiple sub-actions which have different order values. In these cases, each sub-action is treated as if they were separate actions in the resolution queue. If the sub-actions share a target, then the player targeted is only considered to have been targeted once, and the targeting occurs relative to the lowest ordered sub-action.

Example: some mods choose to consider Jailkeeper as a compound action, identical to performing both a roleblock and a doctor action on a single target. In this interpretation, if a jailkeeper is roleblocked, the jailkeeper will successfully roleblock his target, but fail to protect him.

Targeting and Choosing

Targeting is a special mechanic that is featured in many night actions. When a player submits an action that calls for a target, that player must submit the name of a player who is a valid recipient of the action, to the best knowledge of the player performing the action. All targeted actions are functionally compound actions, where the "targeting" sub-action occurs infinitesimally prior to the main actions resolution. As a result, actions that are triggered by the targeting sub-action will occur before the resolution of the initial action.

Example: if a Doctor performs a protective action on a player who reflexively commits suicide, the suicide attempt is triggered prior to the resolution of the doctor action, and thus the player dies.

In some cases, it may be desirable to select players without targeting them (typically to avoid confusing situations with trackers). In this case, the term "choose" should be used instead of "target." Choosing player(s) is functionally identical to targeting, but does not interact with actions that specifically refer to targeting.

Example: in Tales of You, AngryPigeon fakeclaimed an action in which he selected three players, and the scumteam chose one of them, for whom he'd get a cop investigation result. In SNARF, the action would be worded something like: "Choose three players, the mafia will choose one player among them whom you will target. You will be informed of the target player's alignment at the End of the Night." If this player were tracked, the tracker would only be told that he visited the targeted player, and not the other two players.

Invalid Targets

While players should not be permitted to knowingly choose an invalid target, it may be the case that a target is invalid without that player knowing he is, or he may become invalid through the resolution of lower order actions. In these cases, the action fails. This may often occur in the case where the target needs to be alive, but is killed that night prior to the action resolving, or if an action cannot self-target, but is redirected to oneself. If the action text specifies an alternative resolution in the case that the target becomes invalid, the action does not fail and instead the alternative resolution occurs.

If the action calls for a target, but the result of the targeting sub-action results in more or fewer targets than the action intended, the action also fails as if the target were invalid.

Being Dead

Unless otherwise specified in the action text, a player being killed on the night that he/she submits an action will not prevent the action from succeeding, even if the action is of higher order than the kill.

Failsafe Rules

The following rules should only be relevant if the setup designer chooses to use poor wording in ability text and/or poor choices of priority. Nevertheless, how these instances should be resolved is outline here for completeness.

Contradictory Non-simultaneous States

If two states contradict each other directly, the newest one takes precedence. Usually, this can be avoided by choosing less ambiguous wording within the ability texts.

Example: A vanillaiser has the following ability "Vanillaize (order 40): target player is a Vanilla Townie," while an inventor has the following ability "Give Gun (order 90): target player is a one-shot Vigilante." If they target the same player, that player becomes a one-shot vigilante because the "Give Gun" ability happens later. This contradiction would be easily avoided by using "becomes" instead of "is," or by changing the vanillaize text to "Target player loses all active and passive abilities," which is much clearer.

One notable case where it's not poor form to have contradictory states is the strongman ability, which should have text like "When you target a player with a night kill, it cannot fail." It's well understood how strongman works, and would mean a lot of excessive text to deal with the contradiction otherwise. Note that the text specified works because it sets up a trigger that occurs just prior to the resolution of the kill, and thus it will always be the newest state at the time of the kill.

Contradictory Simultaneous States

In the event where the mod really screwed up and put two directly contradictory states into effect simultaneously, a shrodinger's cat mechanic takes place. All actions that would interact with the contradictory states "splits" and interacts independently with each contradictory state as if there were two instances of the action. If both the split actions are unaffected by the contradictory states, they rejoin into a single action. Otherwise, they proceed as if two actions had been performed. This calls for examples.

Example: Two bus-drivers have the ability "Choose two players, attempts to target the first player instead target the second player and vice versa." One bus driver targets Alice and Bob, the other targets Bob and Carol. The mafia chooses to kill Bob. A contradictory state has been established where actions targeting Bob instead target Alice and actions target Bob instead target Carol. The targeting sub-action of the mafia Night Kill interacts with this contradiction and splits, with one branch resulting in a target of Alice, while the other results in a target of Carol. Thus, the night kill has two targets when it expects one target, and fails.

If the mod really wants two bus drivers, best practice would be to give one higher order than the other, to adjust the wording of the ability in a way that avoids such contradiction, or to make the ability fail if either player is chosen by another busdriver.

Example: A player is simultaneous targeted with two effects: "Attempts to kill target player will fail" and "Attempt to kill target player will succeed." If that player is targeted with a kill, the kill action will split. One branch of the kill will fail, the other will succeed. As a result, the player dies.