Warning: This section covers FAQ for Mafia and is transcluded in the Guide to Hosting Please don't make changes unless you wish these changes to be included in that guide!

Actions in Mafia are dynamic and can interfere with other actions in the same cycle. Since the games are designed by different hosts, each has a different vision on how actions happen or how actions interfere which each other. Each host may create his/her own "universe" and dictate the action dynamics of that universe e.g a block action cannot stop the nightkill.


In early games, the order of actions was most of the times used only to order the story covered in the night posts. However, loops can appear when two or more people target each other in a circle. These loops were at first solved on a case by case basis, which breaks consistency and easily leads to incorrect assumptions from players gathering information from night posts.

While the dynamics are captured by the host's "universe" and the exact interpretation may vary from host to host, there are some very common (yet somewhat opposite) ways of looking at things, which are more or less standard nowadays:

  1. Precedence (MOS PRECEDENCE UNIVERSE, REAL-TIME UNIVERSE) - all actions happen roughly at the same time. Precedence only matters when collisions appear (loops or chains), which are solved by letting higher order actions happen first.
  2. Order of actions (DETERMINISTIC UNIVERSE, CHRONOLOGICAL) - actions happen in a certain order. Whenever loops appear, these are broken by letting higher order actions happen first. An extreme case, all actions happen in different time-slots (like in turn-based games) and as such, no loops appear.

Precedence (OOP)

Whenever the host lets all actions happen at the same time and chooses a certain set of rules to treat collisions (such as cycles) and determine which action goes through first, a precedence-based order (OOP) is implicitly used. In layman's terms: "All actions happen unless acted upon".

The precedence-based universe states that all actions happen more or less simultaneously and the night-post is in whatever order the host wants it. This non-linear timeline can cause apparent paradoxes such as the player dying in the first action shown in the night post had the role that killed someone else as the last action shown in the same night post.

The policy adopted on mOs and which is favored by a lot of hosts is the same-time aspect of the universe. But instead of solving collisions on a case-by-case basis (which may lead to inconsistencies when dealing with loops of mutually exclusive actions), the concept of precedence should be used to make it completely deterministic, with explicit public rules on detecting and solving collisions.

A side-effect of the same-time model is the fact that kills are by definition non-blocking. In this model, the kill can never block anyone because it will happen at the same time as the target acts. The only thing that can block someone is the block.

The order of precedence comes in play when a collision is detected by the host regarding two or more actions which cannot happen at the same time. The most common type of collisions where precedence is used are cycles (informally called loops) where a set of actions starts from an initial player targeting another and loops back to someone targeting the initial player (e.g. A targets B who targets C who targets A). In this case, the precedence order states which action goes first (to break the loop).

Example 1: Host's OOP: Trap > Save > Kill. 
Action submitted in the same night:
*A wants to kill B
*B wants to trap C
*C wants to save B

These actions cause a 2-loop which (treated as a collision) is bound to be solved by precedence. So B traps C (trap > save), no save occurs as C is trapped and outside the loop, A kills B.

Example 2: Host's OOP: Trap > Save > Kill. 
Action submitted in the same night:
*A wants to kill B
*B wants to trap C
*C wants to save A

These actions cause a 3-loop which (treated as a collision) is bound to be solved by precedence. So B traps C stopping the save and A kills B (this time, as part of the loop).

Some hosts treat only people directly targeting each other (2-loops) as the only type of collisions bound to be evaluated by the order of precedence (e.g. GMaster479). So in example 2, since there are no 2-loops, all actions happen.

Example 3: Host's OOP: Redirect > Trap > Kill. 
Action submitted in the same night:
*A wants to trap B
*B wants to kill C
*C wants to redirect B to A

These actions cause a 2-loop between B and C with A's action interfering with B's. The approach of the precedence rules is to break the loop first (Redirect > Kill), allowing C to redirect B to A, then the remaining actions form another 2-loop:

*A wants to trap B
*B was redirected and wants to kill A

Precedence is again used to break the loop (Trap > Kill) allowing A's action to go through, trapping B and thus stopping the kill.

The order of precedence allows exceptions, for example:

  • If the NK can't be blocked or redirected, then the host typically adds that phrase to the rules, while still allowing other actions (such as save or spy) to be blocked or redirected.
  • If the RID Kill is also a blocking action, then the host typically adds that phrase to the rules, while still considering NKs to be non-blocking actions.

Order of actions (OOA)

Basically, whenever the host determines the outcome of the night by using actions in a certain order, this implies using a certain order of actions OOA. An action higher in the chain beats an action lower in the chain because it happens earlier in that universe.

Two different notations are used to capture the following two transitive relations: strong ">>" and weak ">" (easier to see in the following example):

  • "block > redirect" means redirects can be blocked by targeting the redirector AND the redirector can still redirect the blocker if the blocker does not specifically try to block the redirect (intentionally redefined and used to overlap with the Precedence notation)
  • "block >> redirect" means redirects can be blocked by targeting the redirector BUT redirects can never act on the blocker i.e. "blocks cannot be redirected".

Both types of relations (> and >>) can be used in a single chain as the OOA, e.g.: RID Kill >> Block > Kill > Spy which is equivalent to "RID Kills cannot be prevented. Blocks can stop a kill or a spy."

An extreme case of the OOA favored by some hosts uses only >> relations resulting in a Chronological Universe.

Example: RID Kill >> Redirect >> Block >> Save >> Kill. A host would determine the outcome of the night using that OOA as follows:

  • The first thing host should look at is RID Kills. If for example a RID Kill kills the save, the Saver is dead.
  • By the time we get down the chain to the save, it doesn't matter if the Saver was right or wrong, because he's dead.
  • The kill goes through (unless it was blocked).

Chronological universes can be mapped (exactly) to a deterministic timeline with no loops. For example, the order of actions starts at 8PM (the time is arbitrary). Each action thereafter takes place an hour later than the previous one. That would mean for the above example that a redirect goes at 9PM (the RID kill happened at 8PM, so you can't redirect it). The block goes at 10PM, so the Blocker can't block the RID kill or the Redirect. And so on. If the RID Kill (which happens at 8PM) kills the Saver (at 8PM), by 11PM (the Saver's "time slot") the Saver is dead and cannot save.

This system has a minor loop-hole when considering saves: If saves are supposed to stop nightkills even when the NK has a higher order than the other actions, then the Save has to have precedence over NK (or else it's useless), which leads to saves being unable to be blocked / redirected. A proposed solution is to use a special notation (coming from "Stratego" where Spy can beat Marshall, which has the highest rank, but not other pieces with higher rank) e.g. Night Kill > Redirect > Block > Spy > Save (> Night Kill). The save has higher order than the night kill, but it is the only action with that property.

Order of submission (OOS)

In very rare cases (see Pirates of Penzance Mafia), the order in which actions were submitted to the host by PM (IRL) was used as a timeline to determine which actions affected other actions and how the night post was written instead of Precedence(OOP) or Order of actions (OOA).

This order of submission (OOS) approach has caused problems:

  • with players inadvertently outing themselves as they posted their action was in (forgetting the rules)
  • some players (e.g. in different time-zones than the host) couldn't be on early in the night, so this order made their role useless (e.g. block actions).

See alsoEdit