FANDOM


Mafia is an epic game of skill, persuasion, deception, strategy, participation, cruelty and cunning. It is a contest of wits; a championship of cleverness. It is intense, unforgiving, relentless, dominating and amazing. Some people have had Mafia dreams. Some people drive across the city to get better wireless to play Mafia. People ignore their workload to play Mafia. Mafia is addicting. Mafia is fun. Mafia is wickedly cool, awesome and pulse-poundingly exciting. If a game is designed well and hosted well and played well, it can be a work of art.

You don't need to be the most experienced Mafia player to host, but you should definitely understand all of Mafia basics, so the Newbie's Guide to Mafia is a must.

Note that the purpose of the current guide is to provide helpful information for game designers and hosts.

For Game Designers and Future Hosts

Suggestions and Tips for future hosts

If you're thinking about hosting a Mafia, you should be aware of several things first. Treat the following list of suggestions as a checklist to follow BEFORE attempting to host a Mafia. Hosting a Mafia is fun, BUT ...:

  • GET MAFIA PLAYING EXPERIENCE FIRST: Don't host until you have played at least 4 or more games and know what is necessary and expected of a host. There are many things going on BTSC that only hosts know of. So don't assume reading some game threads is enough to understand what a host is supposed to do during all cycles.
  • 'UNDERSTAND GAME THEORY: Make sure you understand complex Mafia strategy and game theory basis of Mafia inside-out before designing rules/roles and hosting.
  • DON'T PRESSURE YOURSELF INTO HOSTING: Hosting is fun, but also requires different sets of skill. Many great players are just players and are very content with playing. Everyone's got their niche, and we need us all to make good Mafia games.
  • DON'T RUSH OR FEEL THEME-RUSHED: Don't just say something like "Oh, I think hosting is cool so I'm interested in doing it" or "I don't see a game based off of <insert franchise here>, so I'm going to make one! Or someone else needs to make one!". Rather, think carefully about the game. The more creative, original and innovative you are, the better the game will be. Also, if you really want to use a theme for your game, see the section on "claiming Mafia Themes" to check your ideas first.
  • DON'T TRY EVERYTHING AT ONCE: Try a smaller game first with straight-forward roles (6-10 players). Hosting (or co-hosting) a small game is not a shame. It will be easier to run and still give you a hosting experience. Large rosters and experimental roles should only be handled by hosts with enough experience to make tough decisions when unforeseen conflicts occur. Also, if a game is twice as large, it's probably four times harder to host.
  • GET A CO-HOST/MENTOR HOST: If you aren't a good writer or don't have a complete vision for a game or the size of the game is too big, definitely try to get a co-host, it can take some of the burden off. Co-hosting means sharing the hosting burden with a fellow co-host and the two of you together manage the game together.

If you are past that step, tread carefully in the design phase:

  • LOOK AROUND AND READ: Look around at previous Mafia games for role ideas and ways that things could pan out. Also check out Mafia Discussion or other forums from various sites all of which are packed full of mafia discussion topics. Read the Category:Guides to find out how roles and actions might interact and interfere with one another and what you should expect and plan for.
  • GET ORIGINAL: Make sure your idea is original and does not overlap with a recent idea someone had (See "Claiming a theme"). It's fun to write in your favorite universe, but Mafia games are much more than that!
  • GET PUBLIC FEEDBACK: Start a topic (e.g. in the Game Ideas forum) with your game ideas and get valuable feedback from players. If that does not get enough attention, PM (but don't spam) experienced Mafia players/hosts and discuss with them your idea and role concepts. Try to get as much help as possible in designing your game (game balance and role descriptions).
  • ORGANIZE YOUR UNIVERSE: Consider early in the design phase and tell players the order of actions or precedence so that your choices as a host during the game will be consistent and the players can use logic to explain night posts. E.g. if you decide block stops kill then note that as "block>kill", and create a chain of actions that covers all possible actions e.g. redirect>block>save>kill>spy. See Advanced game design issues for more information. It will save you a lot of time preventing 1000+ questions during the game about action or role clashes.
  • GET A FRESH PAIR OF EYES: Once you have the OP/Intro/Rules/Roles/etc stuff well defined and written out, have an experienced host check it over for balance. Game balance is the most important thing in designing a game Make sure you have a deep understanding of what game balance is and how to detect unbalance before even thinking about hosting. You can gain this insight from playing games and talking to experienced players & hosts beforehand while thinking about designing a game. Also, read all the Category:Guides
  • DON'T RUSH: Do NOT assume that if no one answers to your Game Idea it is ready! Shout or PM people if no one answers after a week to attract attention. Don't be too pushy, either. People that are forced to give a review, may only review it to "get it over with". Only once your idea seems balanced enough and several experienced players and hosts have given their thoughts and you've patched it up, then you can add it to the queue and start signups for it once the queue reaches it!
  • USE SIMULATIONS: Play out a demonstration/simulation of your game with the numbers of players in each faction to make sure it's not absurdly in favor of one faction. Better yet, play more simulations.

Once the design phase is over, the queue and signup phase follow:

  • PLAN AHEAD: Know when you're active and when other Mafia games are going to start. PM (or shout) to a Mod to add your idea to the Game Queues if you cannot do that yourself. Make sure to queue your game in a good time slot that works for you and other players and doesn't interfere too much with other games and real life! Hosting takes a lot of your time, beware!!! It will really suck you in. IF you are a good host that is - you SHOULD dedicate a lot of time and effort into it. If you're not, something's definitely wrong.
  • 'QUEUE:
    • If you plan to host it on BD (BrainDen): - Add it to the Games Signup Spreadsheet. Post a reply on Games to Come thread announcing your game is Ready!
    • If you plan to host it on MM (MafiaManiac): Create a new fresh topic in the Games Ready section, where you paste a cleaned up, final version of the game from the Game Idea section. Ask a Mod to help you if your editing time expires (although you should prepare the final version in a local editor beforehand).
  • BE ORGANIZED: Read and use the OP Checklist. Organizing your Original Post (OP) before starting the Mafia will save you a lot of questions and prevent many disputes (during and after the game). Use a nicely organized OP when posting your sign-ups
  • HAVE PATIENCE: Have patience and wait for the games in front of you in the queue to finish. When the game right in front of you is nearing its end, check with the Mods or previous host and then post a signup thread.
  • ATTRACT PLAYERS: Ask a Mod to update the announcements that a new Signup is in progress, shout about it, add it to your signature ... anything short of mass-spamming people. If your sign-ups are not full after a couple of days, consider inviting players that are semi-inactive, i.e. don't check the site daily. They might be interested if someone tells them via PM (which usually is forwarded to their favorite mail client). Again, DO NOT SPAM, make your invitations personal.
  • DON'T RUSH: Keep the sign-up thread open for backups and publicly ask for backups until you have at least 2-3. Even if you rush and start without backups, keep the signup thread open calling for backups.

Finally, during the game:

  • DON'T BREAK YOUR OWN RULES: Keep in mind all of the role interactions that are going on - if someone's action may ( A ) affect another action, or ( B ) be affected by another action, check to make sure. Be mindful of action loops and know where to break them based on your previously decided-upon order of actions or precedence, follow any rules you've established in the OP and your previous answers. Make sure you know who has what 'voting power', so you know what's going in the day and what the votes cast are actually tallied.
  • DOUBLE CHECK: Always double-check your posts before posting them. Read for it from the players' perspective and see if you're not accidentally leaking too much information. Proofread your post before submitting it and check it against your host spreadsheet (or whatever method you use for keeping track of actions). Use the "Preview Post" option to ensure proper formatting.
  • THINK ABOUT LEAKS: Always double-check before you answer a question in the game thread or in BTSCs or PMs. Think twice before answering questions which might confirm inactive players or in other way leak meta-information about the players. DON'T LET ANY INFORMATION SLIP TO PLAYERS THAT THEY SHOULDN'T RECEIVE! After any out-of-the-norm action, sent-PM, player replacement, etc, analyze what kind of information it gives out to players. Also, beware of casual conversations (IRL, on-site via PMs or the Shoutbox or off-site via AIM/MSN/FB etc) and don't let anything slip that could affect the game.
  • DETECT AND REACT: If someone does receive an unfair advantage via information, level the playing field and tell the secret. Think about the ramifications first, though, it may be detrimental to publicly reveal the info and there may be a better solution to the problem. If you've ran into a tricky situation, there's no shame in PMing other experienced hosts (that aren't playing the game of course) and use them as mentor hosts.
  • DON'T BREAK ON MISTAKES: You might make mistakes - from missing an action to accidentally outing someone. Don't be discouraged by that. But help prevent it by using at least a mentor co-host, someone who is told all the roles and has access to all the BTSC. The mentor can act as someone to bounce ideas off and double-check your posts and ruling about action interactions. Especially if you intend to use secret roles or secret WinCons!
  • WORK IN ADVANCE Type the post in advance and alter it based on action changes. Most times, no actions will change in the last 30-45 minutes of a night and this allows for a post right at the end of the night. Be sure to check for any last minute action changes, just in case. In the event of a last minute action change, most of the post is already written. In rare cases, the changed action will change a large portion of the post.
  • BE THERE: Remember your post times. If you can't make the post on time, give warning. It's much better for everyone to know that the post is delayed than having a mob waiting for a MIA host.

Have fun and good luck! Hosting can be tough, but don't forget to:

  • KEEP TRACK OF EVERYTHING: Keep a log of all night/day actions & events that occur.
  • BE ACTIVE: Make sure you're on top of your game, and very active. Answer players' questions, set clear deadlines.
  • ANTICIPATE:Try to anticipate possible role disputes and special cases before the game even begins, so that you don't have to untangle sticky situations once the game has begun
  • BE INSPIRED: Have a vision and a passion behind the storylines behind night and day posts
  • DELIVER: Whatever you do, DELIVER ON TIME! You can't ask players to respect the time limits if you can't even get a night post or day post in on time

Claiming a theme

Some Mafias have themes - either a fictional or a historically inspired setting, possibly pre-established by a book, a TV series, a movie or a game.

The following situations are sometimes encountered and give rise to comments from the community: Someone decides to make a Mafia based around a certain theme and someone tells him that this has already been done. A short discussion ensues: who holds the copyright? Is possible to redo a theme keeping the original roles or redo the roles and game mechanics completely? What are the limitations on the game names? etc.

The following is a set of guidelines that should help clear up the confusion:

  • Mafia Game Names are the property of the originator of the first SUCCESSFUL game of that name.
  • Themes/Game Ideas are the property of the originator of the first SUCCESSFUL game of that theme, BUT can be re-done/re-used so long as ( A ) a sufficient amount of time has passed and ( B ) the current originator of the game idea/theme has either given the okay or is not present to do so.

Comments on the guidelines:

  • The definition of "first SUCCESSFUL game" is there to prevent someone from throwing together a quick Mafia just to claim the theme (and usually not being able to host it till the end).
  • "Sufficient amount of time" for re-doing a theme is ambiguos but translates to: "enough time for people to forget the old game and see this as something new". Obviously a week or two after the game finished isn't, but obviously over 6 months is. It's a case by case basis, but please remember this is a courtesy to those who originally thought of the game.

General DOs and DON'Ts:

  • No two Mafias should have the EXACT SAME NAME - this is mostly for obvious book-keeping purposes and to avoid confusion when speaking about a certain game.
  • Feel free to take a theme that someone else has used (with the above permissions), but please re-name it for cataloging and creative license. Basically, sequels and series are fine as the long as the original creator envisioned them or explicitly gave permission to someone to continue them.
  • Simply naming your game as a sequel (e.g. Mafia X) where someone else has hosted/created the previous mafias with the same name is frowned upon since a little creative work with the title can ensure a new Mafia is related to the same them without having the exact title. A different but related name can be found depicting the focus of the story in that specific game - e.g. Students vs Teachers Mafia instead of High School Mafia; Also renaming it will allow you to add sequels to the series you're starting (without any external interference).
  • If the originator of a game idea is still around (and even if he did not host or play in a while), make sure you talk to them (via PM) before trying to host a game of a similar nature (theme or name). If they aren't around for a while, then you are free to make a game provided the original creator does not return.
  • For the sake of creativity, unless you're trying the exact "redux" of a prior game, the host should change things: new roles or change the focus of the story or make the actual game from scratch (different game mechanics).
  • If a person is preparing a new Mafia, gives updates (e.g. starts a thread with a new Game Idea) and does not go missing for a while, then no one should rush, put together a small Mafia and host it before that person finishes his/her idea. This type of "rushing past someone just to beat him to the finish" is severely frowned upon.
  • As far as enforcing these claims on multiple sites, our mafia community is growing at a good clip. Obviously if you aren't active on the site where the proposed game is then you won't have much of a say if any at all. But if it is obvious that someone is taking your idea that you just finished hosting and is just playing it on another site THAT should be frowned upon and someone would hopefully notify you if they see that happening.
  • Using a very general word (e.g. "Christmas") inside the name of a game, does not prevent someone from doing a Mafia that is related to a previous Mafia. E.g. if there is a Christmas Mafia (and there is) then this should not prevent people from making another Mafia related to Christmas. As long as names are different and roles are dissimilar, there is no restriction. The guidelines above still recommend a change in name i.e. not name it Christmas Mafia II, instead go with a different, yet theme-related name (Christmas Party Mafia, Christmas Spirit Mafia, Special Christmas Mafia, Weird Christmas Mafia etc).

Golden Rule of Hosting

While you are a host, remember the golden rule: "Don't intervene too much in the flow of the game!". This includes, but is not limited to, any forms of aiding one side or another during the game, helping with inactivity, or hinting towards something they might have missed, or assuming too much when reading one of their posts. Be proactive, or at least be there for them when they need the host, but give the players all the breathing space they need and let them play the game!

As hosts we can only sit back and watch the game unfold. Sometimes the players make a mess of our game. Sometimes they make it come to life beautifully. Remember, we are storytellers. We do not control the game!

Advanced game design issues

There are a lot of things to look for when designing your game:

  • First and foremost when designing roles, a prospective host must anticipate all role clashes - how active and passive abilities can interfere with each other (such as "what happens when an indestructible and unstoppable bullet is fired at impenetrable metal"?) AND how dynamic actions can interfere with other actions during the same cycle.
  • Secondly, a host must decide how information will flow during the game, which actions and what information will be leaked in day / night posts and which will be available only to certain factions.
  • Thirdly, balance must be checked during design and re-checked (preferably by a 3rd party) after the design looks completed.

Order/precedence of actions

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.

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.

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.

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

Precedence Based System (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).

What should Day& Night Posts include

Each day and night post should convey enough information so that players are aware of what is going on. The decision what goes into the post is entirely up to the host, but it should be shared with players at the beginning of the game (or when questions are asked).

It's a good idea to look at the game balance before you decide what to include in the post. For example, showing all actions (including information about failed actions) in the night post often leads to the goodies getting too much information too quickly. By accounting for everyone who has acted and who was blocked or trapped, the goodies can pick out the baddies that did not die and find out the other roles that died.

Day Posts:

  • Always reveal the role of the player that is lynched
  • Usually reveal if there was a tie in the vote (if it is not obvious from the result of the lynch i.e. if the lynched was picked randomly from a tie - see Tie lynch rules)
  • Usually reveal the names of the players in the tie
  • Reveal if vote manipulation have acted only if their (combined) actions have either broken an apparent tie or have created one where it was not obvious to the rest of players. Typically, the role of the vote manipulators is not shown, only the manipulation of the votes is hinted at.

Night Posts:

  • Always show kills and RID Kills, but never reveal the role of the killed player
  • Almost always show explicitly who was trapped and by which role if the trap contains a silence action over the day (if the trap does not contain a silence action, then it defaults to the host's decision regarding blocks)
  • Almost always show explicitly or hint when a person was saved - showing the saved player's name (not role)
  • NEVER link actions
Reasoning: Linking actions in the night-post by a common player name / role e.g. "X targeted Y who targeted Z" leaks more public information than roles are supposed to have. For example: "ROLE X followed ROLE Y who spied PLAYER Z". In this case, ROLE X, a follow spy, instead of only knowing what his target (by player name) did, can almost always match his follow spy's result ("PLAYER Y targeted PLAYER Z") with the linked part of the night-post and deduce Y's role as it is shown in the night-post. Thus, his follow spy becomes a de facto role spy + follow spy. Also, other roles may deduce Y's RID because of collateral info not related directly to their own action' results (e.g. by elimination). In many cases, Y is basically outed to some or all the players.

Other things are less standard and depend on the overall balance (and personal preference of the host):

  • Night posts usually show successful blocks - the ROLE of the player who blocks and the NAME of the player who was blocked. Some hosts do not show blocks, treating a successful block as the blocker causing himself AND his target not to act. It is clear that in small/medium games, if most actions are shown and a player is shown as blocked (by name), there is a high chance that the player is outed. Indies and NK carriers (when NK can be blocked) are prone to being outed by being blocked.
  • Night posts usually don't show spies. If spies are shown, sometimes only the ROLE of the spy is shown and not the PLAYER NAME of his target (to account for a successful spy action without revealing the target). The most common option is to show spy ROLES along with the NAME of their target (but not their role). This kind of information leaks to all factions that the spy role is still alive and it adds to the danger of showing blocked players. However specially designed spy roles (broadcast spies) may have the undesired ability of outing both the NAME and the ROLE of their target in the night-post.
  • Night posts usually don't show uneventful saves e.g. ROLE X looked after PLAYER Y all night but no one came to visit him". This is the kind of information that leaks to all sides that the save role is still alive and usually favors opposing factions (especially those with RID Kill roles).
  • When the Night Kill (or any faction's group kill) can be blocked and night posts show who was blocked, this outs the carrier of the kill if the NK does not happen and only one person was blocked/trapped, giving a blow to that factions chances. However, if the Night Kill cannot be blocked, showing blocks does not zero in on someone's role that easy.

Final things to remember:

  • Golden Rule: WHATEVER YOU DECIDE BE CONSISTENT. Basically if something gets posted one night (such as spies), always post them. And if you answered someone that you post spies or something else, keep that promise. DON'T CHANGE THE RULES during the game. And keep a log of what you promise the players.
  • Exception from the Golden Rule: If you feel the game's balance has been severely affected and you want to fix the game balance, you may stop showing some actions (e.g. spies). Remember that mid-game balancing is a last resort! However, don't cheat the players, you should always make a detailed note in the main thread that those actions, successful or not, are no longer in the post. In very rare cases, it's better to change in the middle of the game and break the consistency than have a game that solves itself after N2 or N3.
  • Final Check: Everyone should be able to glean some information from the night post. BUT it shouldn't be possible (or at least it should not be easy) for any random player to figure out all the roles based purely on the night posts. That's why there are spy roles - an extra responsibility to try to ferret out the baddies without exposing themselves. It's a challenging role, but it's the cornerstone of the goodies' power. An effective spy can turn the game around completely.

Game Design Tips

The following list of tips must be kept in mind as fundamental building blocks in the design phase, that should be taken into consideration before evaluating the balance. This design mainly pertains to the structure of the Uninformed Majority (Maj), and Informed Minority (Min).

1) When designing factions, you should start with a ratio of about 3:1, Maj roles to Min roles.

True evaluation of each faction's chances to win and overall game balance comes later, but this ratio is a good starting point. It will probably be a little heavy in favor of the Maj but it's easier to eliminate or tweak one or two roles later than to add entirely new roles.

2) ALWAYS include a Non-Maj/Min RID killer role, or other role that greatly benefits from learning IDs and is not a member of the Maj or the Min.

Reasoning: Mafia is essentially a game where there's an Min faction vs an Maj faction. In order for a game to remain this way, there must be a natural in-game check on all of the uninformed players simply disclosing their roles publicly and simply becoming an overwhelming informed majority. Some hosts tend to take a stance of banning the disclosure of roles, but it still does not prevent the equivalent of indirect disclosure through overt and non-ambiguous hinting. This Non-Maj RID kill should either be a role that is a member of an independent faction, or it could be an option on the Min 's regular night kill that makes it unsavable and unblockable. Either way it will serve to prevent the Maj from throwing the game out of balance by mass role disclosure. If not, consider making the Min's night kill upgradeable. In other words, allow the Min to have the regular night kill, but if it is combined with an RID then it becomes unblockable and the target is unsaveable, and/or the kill can be used during the day cycle.

3) A design should NOT include BOTH an RID Killer role, and a Spy role, in a faction that starts with BTSC.

Reasoning: It really just makes the "RID" part of the kill worthless, and is just a kill with an ability to spy the player. This is an incredibly destructive combination in the hands of a typical Min BTSC with a regular night kill because it essentially grants the single faction 2 kills per night.

4) Maj Killers should never be RID killers.

Reasoning: It's good to give each player a role that contributes to the game. Regular Maj killing roles typically do not act for at least the first two nights for fear of friendly fire. And even in the rare situation where a Maj Killing Role does act, they only know the faction of their target, not the exact role. Because of this, a Maj Killing role that is also restricted to RID his target is essentially a useless role that would likely only be able to contribute once over the course of several games.

5) Consider the repercussions of allowing roles to choose their faction.

Reasoning: If a host is considering allowing a role to choose which faction to officially align with, the player will typically choose the strongest faction, which will tend to unbalance a game.

6) Consider the repercussions of allowing roles to be recruited from a pool of recruitable roles.

Reasoning: Avalanche recruiting (one faction quickly and successfully recruiting more roles than another faction) can destroy a game. Having a pool of recruitable roles requires stringent and thought-out restrictions and contingencies to avoid the possible avalanche recruiting that can quickly and drastically throw a game out of balance.

7) A game designer should carefully consider what actions to include and not include in the night posts.

Reasoning: For example, if there are only one or two blocking roles in a game, and there are only one or two independent roles in a game, and that independent role gets blocked early in the game, then his RID will be disclosed to every player in the game if the block's target is made public in the post (thus potentially destroying the independent faction). This may be perfectly fine in many games, but it is something that should be considered (and not just with respect to blocking roles).

8) Consider what to do in the event of a tie lynch.

There are typically three scenarios that are used, each with benefits and drawbacks:
  • Both Players Live
    • Benefit = No lynch.
    • Drawback = Players may tend to intentionally create ties on D1 and D2 to prevent a likely Maj lynch.
  • Flip a Coin (50/50 chance)
    • Benefit = Only one player gets lynched.
    • Drawback = It makes the huge decision of a player's dismissal from the game completely out of the in-game events. Thus neither team could truly be said to have won or lost the game based on how they played.
  • Both Players Die
    • Benefit = Players tend to intentionally avoid ties altogether for fear that they may lynch not one, but two of members of their own faction.
    • Drawback = A planned last minute "flash-vote" by the Min faction may cause the Maj to take double-damage in a lynch (at the cost of being outed as members of the Min faction).

Game Balance

Balance is a term used in Mafia to describe the initial position of a game before roles are assigned. A game's balance is said to be good when the chances of any faction winning is about equal. A common "balance breaker" is the unforeseeable random assignment of roles to players, and how well any player utilizes his role.


The following is called Weighting, a method devised by BrandonB and used to evaluate the balance of a game by numerically weighting roles according how much they can potentially impact a Mafia game. It is separated into the categories *Basic Roles, *Augmentations, *BTSC, and *Win Conditions. For more information on these roles, please refer to the roles section of this wiki.

Basic Roles/Abilities:

  • Spy (active or passive) = 1
  • Broadcast (Adding to the Night Post) = 1
  • Messenger (Communications - Secret Messages) = 1
  • Vote change / Vote weight manipulation (Vote Redirect or Multiplier) = 1
  • Lynch Frame (Falsifying Lynch Results) = 2
  • Bodyguard
    • If X is unkillable while Bodyguard is alive, then Bodyguard = 2
    • If Bodyguard kills the attacker, but also dies with the attacker, then Bodyguard = 2
    • And if Bodyguard dies in X's place, then Bodyguard = 1
  • Individual Kill (Single) = 3
  • RID Kill (If target can be saved) = 1
  • RID Kill (If target CANNOT be saved) = 2
  • Lynch Save (Lynch Stopper) = 3
  • Lynch Save (From the night post, everyone knows the target cannot be lynched) = 1.5
  • Role Assumption (Assumes ability of deceased player) = 2
  • Role Copy (for single night) = 3
  • Role Copy (accumulating) = Add all weights of all roles, divided by square root of number of players.
  • Multiple Abilities
    • If all are used at the same time on 1 target = All must be added together
    • If multiple abilities at the same time, and possibly multiple targets = All added together and +1 to the total
    • If forced use of 1 specific ability of a collection of possible abilities (die roll) and 1 target = 2
    • If choice of 1 specific ability of a collection of abilities at 1 target = Highest weighted ability in the collection.
  • Save = 1.5
  • Ability Redirect** = 2.5
  • Block** = 2.5

**If included in the night post, gets +1 because it can leak a lot of information on the target of the action (equal to a potential public spy/reveal)

Augmentations

  • Restricted to "not the same player 2x in a row" = -0.5
  • Restricted to “not usable 2 nights in a row” = -1
  • Restricted to "Odd/Even/Prime Nights" = X/2
  • Anything else that generally acts negatively on a role = -1
  • Lesser requirement for successful lynch = -1
  • Adding an RID Requirement = -1
  • Knows the ID of a non-BTSC-sharing player = +0.5
  • Un-spyable (Looks like a general role or beneficial faction) = +1
  • Unblockable = +1
  • Un-killable (at night) = +3, (during the day) = +2
  • Enslavement (another player dies in his place) = single = +3, cumulative = number of total players divided by 2
  • Secret ability = +2

Faction Extras

  • BTSC (for entire group) = X2 MULTIPLIER! Group’s total added weight multiplied by 2
  • Group Kill = +4 (Added AFTER BTSC multiplier!!!)
  • Secret Faction = ??? (at least 0.5 x number of members if they don't have BTSC but they know each other IDs)
  • Betrayer/Mole = ??? (at least +2 for the actual faction?, at least +0.5 for each ID known, at least 1 for the ability of creating a confusion?) - if a role is part of one faction / BTSC, but actually is aligned with another faction.

Win Conditions

  • Last Standing = No Bonus
  • Must Kill/Spy/ID/Act upon X Players in any order = MULTIPLIER! (W*N)/(X*X) Where W is the faction's total weight, N is the total number of players in the game, and X is the number of roles needed to affect. E.g. a faction with weight 4 (a kill and a spy) that needs to kill 2 players in a 10 player game would have an adjusted weight of (4*10)/(2*2)=10.
  • Outlive X = If X is a balanced faction that has a wincon of "last standing", then the multiplier is N*((F-1)/F) where N is the number of players in the game, and F is the number of factions with "last standing" wincons. E.g. a faction with weight 4 (W=4, e.g. a kill and a spy) that needs to outlive 1 balanced Faction in a 10 player game (N=10) with 2 factions with "last standing" wincons (F=2) would have an adjusted weight of 4*10*(2-1)/2=20.
  • Secret WinCon = +3

Evaluating Faction Weight

  1. Calculate each role's basic weight and edit according to augmentations in order to get the final weight of each role.
  2. Add all final weights together within a faction (If any small groups within a faction have BTSC, calculate their BTSC with the multiplier BEFORE adding them with the rest of the faction).
  3. Add any Faction Extras.
  4. Adjust faction weight according to WinCon.
  5. Repeat for each faction.

Evaluating Balance

  • Add all Faction Weights together to get the Total Game Weight
  • Individually divide each faction by the Total Game Weight.
  • The resulting percentages are the estimated win probabilities for each faction.
  • The smaller the spread between the highest and lowest percentages, the better the game is balanced.
  • A spread of 5% or less is considered balanced, a spread between 5% and 10% is unbalanced and should be fixed, and a spread of 10% or greater will is not playable and will not be accepted into the game queue.

Hosting a Mafia

Signups Phase

  • Once your game is next-in-queue and the one before that started and completed at least one cycle, feel free to start your signups.
  • Always post an up-to-date version of the roles and rules with the signups and be prepared to answer questions people might have during the signups phase.
  • Always give people in the signups thread an indication on the start of the game: either immediately after the current game is finished, or after a certain date (depending on your IRL availability to host).
  • After the current game is finished, your signups are full and either the current host or one of the Mods signals you (via PM or ShoutBox), create your game thread, separately (see next section).

Game thread - The Checklist

Before starting a game thread, hosts should organize the information contained by the OP. The order (checklist) in the original post should be:

  • Intro / Prelude (optional) - providing a backstory to your game. If it is long, you can either put it in a spoiler, or put it as a reply after you describe all the other stuff
  • Factions & Roles - using different colors for different factions. Not necessarily the standard Red/Blue/Green, but be consistent. Always include WinCons when describing each faction (or just say secret WinCon when players are not supposed to know it).
  • Rules - include at least the order of actions or precedence, tie lynch rules, all Q&A from the signups thread, and cycle normal ending times (including the timezone)!
  • Roster - latest copy of the roster from the signups thread.

Example:

Intro / Prelude
----
........
Factions & Roles
----
[color=red]Baddies WinCon - BTSC[/color]
...
[color=blue]Goodies WinCon[/color]
...
[color=green]Indy WinCon[/color]
...
Rules
----
Order/Precedence of Actions: .....
In the event of a tie lynch, .....
FAQ from signups: .....
........
Nights and days will end at .....

Roster
----
Host: X
1. Y
2. Z
....

Before posting a day post or night post, a host should organize the information using a checklist similar to the OP Checklist, ensuring that all day/night posts always have a similar format:

  • Day / Night number
  • A list of actions - story for the day/night post.
  • Roster - latest copy of the roster including changes by day/night post actions.
  • Next cycle normal ending time (including the timezone).
  • You should also specify if the cycle can end earlier than the normal ending time. E.g. if you accept pleas of "no contest" (ending the day early by lynching the one who pleads "no contest") or finalized actions in red (ending the night early when you receive all actions in red).

Example:

Day X (or Night X)
----
........
----
........
----

Roster
----
Host: X
1. Y
2. Z
....
Nights X+1 (or Day X) will end at .....
(optional) Night will end early if all actions are sent in red.

MafiaManiac specific instructions for hosting

Here you will find a basic list of Before, During, and After Game things you need to do when hosting on MafiaManiac.

First: Contact your In-Game Mod if you have any questions. In-Game Mod = A moderator who is currently not playing in your game or a Mod who is co-hosting with you.

Before the Game:

  • There are 2 parallel Mafias, each with it's own separate area and 5 BTSC forums already available which will allow you to separate 4 factions (Goodie, Baddie, Indie, Other) + a Ghost thread. As a current host, you'll be able to access exactly one of the slot for your Mafia and will have moderator rights on those threads.
  • After randomizing the roles, PM the In-Game Mod with who needs to be added to which BTSC.
  • Make sure all the PM's are sent out correctly. Always click the "Add a copy of this message to my sent items folder" before sending, so that you will know which PMs you sent and to whom.

During the Game

  • PM the In-Game mod to update the BTSC Permissions (Adding/removing players) after each night and day based on who is dead or alive or if anyone gets recruited.
  • Give dead people access to the Ghost BTSC after they die. Post all roles and such in there (in spoilers) if you want. Keep an eye on the Ghost thread and answer their questions as well. Exception: Don't use a Ghost thread if you have a role capable of resurrect actions!
  • Make sure everyone knows when days/nights end. Make sure you mention that at the end of day/night-posts. Optionally, edit your Signature to include the same information.
  • Edit the Announcements to say when days/nights end. If you want a countdown timer, ask your In-Game Mod.
  • Invoke Manfred using :manfred: when you feel some players are inactive. Ask your In-game mod to help you move a person to the Toad usergroup!
  • Edit your signature with links to Intro, N1, D1, N2, D2, etc. It's a very nice touch and it really helps people find older day/night-posts with ease :thumbsup:

After the Game ends

  • Clear out your inbox as it will shrink when you get your member status back!
  • Give out the rep points accordingly
  • Ask the In-Game Mod to take away the permission masks for baddies/other people with BTSC.
  • Choose an MVP(Most Valuable Player) and PM your In-Game Mod your choice to add an award
  • Remind your In-Game Mod to give you rep points/host award.

Rule breakers

Community Rules and Game Specific Rules

  • The game of Mafia has many community enforced rules (mentioned in the guides) and each host can add to those rules for his/her specific Mafia game. Each host needs to be on the lookout for anyone breaking those rules and should take appropriate measures.
  • First and foremost rule is the one concerning illegal BTSC. Illegal BTSC is defined as Behind The Scenes Contact using a channel that is not explicitly allowed by the host to convey information regarding roles, strategy, in-game events, desires about the game, ANY information regarding the game including probes for information or personal opinions on lynch votes or night-posts.
  • Another important rule is the one concerning activity. Players missing more then one day/night cycle (or any other limit imposed by the host) can be declared inactive and replaced by the Host with available backups (or killed if no backups exist).
  • (Less frequent) For specific Mafias, the host can declare (when starting the game) that outing your role in the game thread is illegal. Typical measures to counter outing is to nullify or diminish the effect of their night or day abilities for the next night.

When are rules broken? - In Mafia, as in any game involving at least 2 players, there will almost never be an unanimous call on whether a rule was broken. The first judge on the matter is the host, upon discovering the incident (or being told by another player). The host should:

  • hear both/all sides in private (PM or any other out-of-game communication available)
  • consult with a person not playing in the game (co-host or In-Game Mod) for advice before reaching a verdict, if the host feels necessary.

Prevention, warning and action

  • Prevention - Hosts should explicitly warn newbies of the dangers of accidental illegal BTSC as soon as possible - e.g. when sending the roles (directing them to or quoting chapters in the Mafia guides). And they should explicitly (in the game thread) state any rules specific to their game (e.g. outing / claiming a role publicly) and the penalty of breaking it. This goes a long way towards preventing any incidents
  • Warning - Hosts should warn people when they're crossing the line. If no incident has been called in the game thread, it's better to warn people privately, especially if the line is accidentally crossed. If an incident needs to be hidden from other players, a host can ask for the help of the In-Game Mod.
  • Action - When a host decides that someone clearly broke the rules, the host should not be afraid to take action. If the penalty crosses the game boundary, the host should contact the In-Game Mod for details.

Host is always right

  • This section's whole purpose is to ascertain the principle that within the boundaries of the game, any ruling a host gives is FINAL!
  • You can ask the host as many questions as you like, point out the things in your defense you think the host might have missed, but once the host hears all that and still does not change the decision, this means it's final!
  • For out-of-the-game rulings (e.g. kicking a player or banning him for next Mafias) an Administrator/ Moderator needs to be notified, to agree and enforce that ruling.

External Links

Previous Mafias and Mafia sites

  • Check out the History of Mafia project and the Games by Eras List for previous Mafias (including links to the original game threads).
  • Check out the places where Mafia is played / was played in this form ("Den Mafia"): Mafia Forums

External Mafia-related sites

Enjoy hosting Mafia, it's an experience you will not forget ;)


Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.