Gorny's Mafia Game Rule Set v 1.0 (Contains fill in the blanks)

Gorny

Moderator
Staff member
Moderator
Mar 16, 2020
2,409
595
113
Part 1: General game thread rules. Fill in the blanks where applicable and remove parts where applicable.

Gorny’s Revised Mafia Game Modding Rule Template

Notice to players that are new to Mafia Games:
*If this is your first game, then before playing you should head over to the mafia game resources thread and read:

Rules of Mafia FLASH VERSION by mikeburnfire
What is the game of Mafia and how is it played?
A quick guide to mafia
A general FAQ on mafia games, good for first time players
Basic Mafia Game Rules


Finally, we do have a sort of buddy system that will team pair you with an experienced player and then have you both randomly assigned to one of the game’s factions (Town or Scum). Feel free to inquire as to this with the mod of the current game.

This game is:
  1. Normal. No undisclosed mechanics or odd power rules, or other unexpected stuff. A basic mafia game.
  2. Close to normal. There may be a wrench or two thrown in.
  3. Not normal. There are things afoot, you have been warned.
  4. Way out there, you’ll need a crash helmet and maybe a therapist after playing.
  5. A Bad Ash Game. You have been warned. Twice.
  6. A Gorny Game. You have been warned. Multiple times. You’ll need a bout a year to recover after this one, and still might be seeing things that aren’t there and whispering quietly to your self in the corner.


1. Talk about your role and this game is strictly prohibited outside of the game thread until it is over except when allowed by the game mod in a role PM or in specific QT Threads.

2. Do not post in the game thread during the night phase. Any post made after the start of the night phase, regardless of if it is declared by the game mod, cam result in a mod kill of the poster, it will be up to the game mod weather or not a mod kill happens. Repeated posts during the night phase will also result in a mod kill.

3. Editing a post you made in game, for any reason will result in a mod kill.

4. Any flavor story given regarding lynches and kills is for flavor only.

5. Once you're dead, stay that way. Dead people tell no tales, or in this case, dead people make no posts. If you’re dead and either post or try to influence the game (yes, it happened) can be barred from playing and possibly banned from the forum. Posting in a designated “Dead Thread” Quick Topic is fine.

6. Every player gets one lynch vote during the day unless told otherwise in their role PM. Votes and Unvotes need to be bolded . If your unvote isn't bolded, it doesn't count and please try to put it at the bottom of your post. Please be very clear as to who you are voting for, avoid nicknames, etc,.

Example:
Vote: Dredd (Correct)
Unvote: Dredd (Correct)


Vote: Dredd (Incorrect, not bolded)
Unvote: Dredd (Incorrect, not bolded)

V or v: Dredd (Incorrect, the entire word Vote needs to be there)
UV or uv: Dredd (Incorrect, the entire phrase Unvote or Un Vote needs to be there)


7. Lynching requires the majority of the players alive to vote for the same player. That is, half of the remaining number of players + 1 rounded down. A lock occurs when someone with enough votes to be lynched receives an additional vote, and will be lynched at the end of the day and cannot be unvoted. (Add language here for the number that is the majority and the number that would cause a lock.)

8. The 50 % Rule: The game will be called and end early if, the remaining mafia outnumber the town, IE, the town can’t get enough votes in to cause a lynch to happen.

9. If you have any questions or issues with your role, or any other player, please the mod of this game in order to find a resolution. Please don’t suicide or do anything rash before
contacting the game’s mod.

10. Any player may claim any role. I.E. Any player may claim to be something that they
are not. For example, I claim to be the treestump.

11. Do not post any information sent to you in a pm by the host. This includes, but is not limited to, numbers of words/letters/punctuation marks. If you want to claim a role, don't copy paste the PM that was sent to you.

12. The Day lasts____hours and night lasts____hours. This game will start with a ___________. (Day Phase or Night Phase).

13. You will get mod killed if you are inactive (at least___actual contributive posts per day
phase required to be considered "active" ). Posting just to meet the posting requirements and actually not doing anything that adds to the discussion, or informational process of the game, or just posting for the sake of posting can and will likely result in a mod kill. This rule is amended to avoid a Prestige7 situation.

14. If you are (temp) banned from the site itself, you will also be mod killed.

15. If you cannot continue to play the game foe any reason, send the host of the game a PM.

16. Behavior - Please don't take anything said in this thread that may be directed at you as a personal attack, it's the way this game is played. Rivalries (such as the infamous Noodle vs. Bad Ash rivalry) are fine. It's all in the spirit of the game. Don’t be a ****. Mafia can and will get heated, but below the belt attacks will not be tolerated. Attack the play not the player. Calling another player or players morons or any other forum of disrespect, is Prestige7. Don’t be a Prestige7. It won’t be tolerated.
Have fun and good luck!

17. Read the rules and your Role PM once more. Have fun and good luck! May the best team, faction, or loner win!






*****************************************Templates********************************

List of Players:




Players alive:




Players dead:



Vote Tallies:
 
Last edited:
Part 2 Resolving Night Actions, Method 1:

There are multiple methods to resolve night actions with:

1: The simple method, this works easily for smaller games that do not have a lot of power roles or complicated night actions to resolve. With this metnod it's a good idea to set a deadline for players to submit any night actions , should they choose to. You'll need time to run all of the night actions you receive and determine the outcome before the day starts. The deadline can be whenever you want, leave at least an hour or two for you to be able to resolve night actions before the start of the next day, and send out result PMs, this way you have time even if IRL steps in.

Example, we have 7 players, as follows:

1. Noodle (Cop, sanity is sane for this example)
2. Bad Ash (Bus Driver)
3. Leopold Stotch (Mafia goon)
4. Gorny ( Vanilla Town - one shot BP Vest)
5. Pyrotechnician (Mafia Hitman)
6. Caluin Grey (Doc)
7. Zarniwoop (Vanilla)
8. Dredd (Vanilla)
9. Ankeli (Treestump)
10. Orphan (Mafia Goon)

Night actions that came in are:

A. Noodle investigates Himself
B. Bad Ash switches Pyro with Leo
C. Pyro targets Gorny for the Mafia NK
D. Caluin targets Orphan with his doc save ability


The above four are the only night actions you will get (Leo is the goon and does not target, Gorny is Vanilla and the BP vest works by itself, Zarn is vanilla and has no night action, Dredd is vanilla and has no night action, Ankeli is the treestump but is in effect vanilla and has no night action. Orphan is a mafia goon and has no night action)

Note: In the event of a lynch on Pyro during a day phase, either Leo or Orphan becomes the hit man and then would replace Pyro.

Results of night actions above:

1. Noodle targets himself with his cop ability.

Result would depend on is role's sanity, which only the game mod knows. Since he is a sane cop for this example, the result of Noodle's investigation on himself is accurate. The actual result is "Not Mafia." Side note, depending on what the name of the actual mafia faction is, this could also be changed to not ___________ (fill in).

Noodle gets sent a PM saying something along the lines of the result of his investigation is "not mafia or not________."


2. Bad Ash switched Pyro and Leo.
Since no night actions were directed at either Pyro or Leo, nothing more happens here.
However, if say Caluin targeted Leo with the doc save then the above Line "D" would instead read something like: Caluin targets Leo (switched with Pyro) for the doc save. The Pyro become the target of the doc save and not Leo.

In either scenario in #2 Bad Ash does not receive a PM before the days starts. Neither do Pyro or Leo

3. Pyro targets Gorny for the mafia NK.
Result here is that the NK goes forward on Gorny but is blocked by the one shot BP.
Neither Pyro or Gorny really need to be sent a PM about the result, as the news that the NK attempt has failed will be revealed in some manner during the opening of the next day. Sending the mafia notice that the kill attempt failed can be done in place of no notice to anyone. It's the mods call.

4. Caluin Targets Orphan with doc save ability.
Result: Nothing happened. No one targeted Orphan during the night so he lives. The doc does not get notice of the result of the night action nor does Orphan. In this case the doc also does not know weather or not Orphan was even targeted and Orphan does not know either. In the event that Orphan **was** targeted, it's up to the game mod to inform, usually in flavor text at day start, or not.

Now that everything is figured, all that needs to be done is to send out any notices, craft a start of day story if aplicable, and start the day.
 
Last edited:
Part 2 Resolving Night Actions Method 2, Reasonable Action Resolution:

The following is borrowed from Mafiascum.net, and I claim no credit for authoring it:

Reasonable Action Resolution is a method of resolving night actions that replaced Natural Action Resolution


In Reasonable Action Resolution, each night action is broken down into a set of basic components, each of which is one of the following:
  • 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 (untrackable and unblockable) active roles that self-target.

Reasonable 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:

Rule #1: Don't check whether "an action" succeeded; check whether a particular end of night effect happens.
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: 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).
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?
    • Reason for yes: A Vigilante shot them

Yep, the player died. This should not be a surprise.

A Cop investigates player A:


  • Does the Cop get a correct result?
    • Reason for yes: Cop investigation on player A

This is analogous to the situation with the Vigilante; nothing affects the action, so it has the usual effects.

More complex are examples involving role modification:

A Doctor protects player A, and a Vigilante shoots player A:


  • Does player A die?
    • Reason for yes: A Vigilante shot them
      • Reasons for no: The Doctor action prevents kills

In this case, each reason for yes has a counteracting reason for no, so the action fails.

Player B (a Doctor) protects player A, and a Vigilante shoots player A, and a Roleblocker blocks player B:


  • Does player A die?
    • Reason for yes: A Vigilante shot them
      • Reasons for no: The Doctor action prevents kills
        • Reason for yes: The Doctor's protection effect was roleblocked

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.

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?
    • Reason for yes: A Vigilante shot them
      • Reasons for no: The Doctor action prevents kills
        • Reason for yes: The Doctor's protection effect was roleblocked
          • Reason for no: the Roleblocker blocking effect was roleblocked

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.

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?
    • Reason for yes: A Vigilante shot them
      • Reasons for no: The Doctor action prevents kills
        • Reason for yes: The Doctor's protection effect was roleblocked
      • Reason for no: The Jailkeeper action prevents kills

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.

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:

Rule #3: An effect produced by modifying/triggering on an effect requires both an effect to modify/trigger on, and a modifying/triggering effect.
The simplest case is that of a tracking effect:

Player B (a Vigilante) shoots player A, and a Tracker tracks player B.


  • Does the Tracker see player B see player A?
    • Reason for yes: the Tracker tracked player B, and player B visited player A.

Because both parts of the track result (the track, and the visit that's being tracked) happened, the effect happens.

It can be blocked either way, though:

Player B (a Vigilante) shoots player A, player C (a Tracker) tracks player B, and a Roleblocker blocks player C.


  • Does the player C see player B see player A?
    • Reason for yes: player C tracked player B, andplayer B visited player A.
      • 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, andplayer 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, andplayer 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, andthe 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, andthe 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: 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.
          • Reason for no: player B roleblocked player A (with the Jailkeeper action).

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).
          • Reason for no: player A roleblocked player B (with the Jailkeeper action).

Again, player A dies. Player A's role can't block player B twice in the same dependency chain, whereas player B's

Rule #1: Don't check whether "an action" succeeded; check whether a particular end of night effect happens.
Rule #2: 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: An effect produced by modifying/triggering on an effect requires both an effect to modify/trigger on, and a modifying/triggering effect.
Rule #4: 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.



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 prevent them using night actions.
  • 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.


n 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).
 
Last edited:
Diablo 4 Interactive Map
PurePremium
Estimated market value
Low
High