Mafia System - Updates and Suggestions - Page 4

Status:

These are the possible effects I think should be in the game.
Statuses are part of a role, and they can modify the result of an active ability that role performs.

The statuses can be categorized, where they have different types:
Before-Status: This status takes effect before the Active Ability is executed
After-Status: This status takes effect after the Active Ability is executed, but before the result is done

Stops control: After the status is done, it creates a result himself and doesn't give the control back to the active ability
Flows control: After the status is done, it gives the control back to the active ability

Examples of statuses:
Roleblock:(Before-Stop) Terminates the execution of the Active Ability
Insane:(After-Flow) Takes the resulting check, and inverts it
Naive:(Before-Stop) Returns the "naive" check
Paranoid:(Before-Stop) Return the "paranoid" check
Disorientation: (Before-Flow) Changes the target of the ability to another one

As you can see, now I figured out cop sanities can be determined by the cops having a specific status
Roleblock is trivial, so let's focus on the sanities:

Insane: What does this do? Why is it an after-status? Well, because first the check has to be made before it's "inverted".
An "Alignment check" or a "Role Check" are done by a cop. The action is done on a target, and returns a specific check. Before the action is resolved though, the role calls this Insane status, which takes the role, and inverts it, and either returns the control to the Active Action again, or just creates a result himself.
In this case it can return the control to the active ability, since it just acts on the check
Naive/Paranoid: In this case, since the check is always the same, the status can just create the respective result and end the flow of control right there
Disorientation: I don't remember seeing this done in games, but I think it can be a nifty little mechanic. What it basically does is, it changes the target of the active ability.
For instance, a Vig with Disorientation who shoots marv, would instead shoot VE (without him knowing it).

Possibility: We can add the possibility that certain status only are taken into account for certain Active Actions.
For instance, what if we have an Insane Cop who also has KP? In this case the "Insane" status doesn't have anything to do with the KP, but it would with him checking people.
What if we want a Cop/Vig who is disoriented when shooting but not when checking? Then we make his disorientation status execute only for the Vig Shot Active Ability

So it's possible to create Status as well (for roles)
(Technicality: I guess technically we can determine if the status is one-shot or infinite as well. That doesn't make sense for sanities but may make sense for disorientation and maybe other stuff)

Status Creation:

There are different ways a status can be created.
For now I can only think of 2, which will be documented here:

At Role creation:
This is a permanent status on the role, and needs this info:
Ability to react to: It has to choose which Active Abilities of said role it can react to. It can choose "All", or specific ones from the role. Theoretically it should be able to choose from Primitive Active Abilities (PAA from now on) the role may be able to have at some point in the game (for instance because of a passive ability of his someone else created)
Primitive Status: It should choose which primitive status it should have. For now they should be Insane/Naive/Paranoid (for checks), and Disoriented (not Roleblock since it wouldn't make any sense lol)

At Ability creation:
Certain abilities can create statuses on other roles. A Roleblock Active Ability does that in fact, it creates a RBed status on the role that lasts for that night cycle
It needs this info:
Target: Target of the status
Life-Expectancy: How much time the status will be active. May be current-cycle, or forever, or maybe for 2 cycles, etc
Ability to react to: Same as the previous one
Primitive Status: Same as previous one

So, we now know how abilities are used in night actions, right?
Steps:
-A role decides to use an active ability
-First it checks his statuses/effects which may modify said active ability
-Then it targets his ability on a specific role/player
-That role checks all his passive abilities that can modify the result of said active ability
-A result is made

Now what is this "result"?
I made an example of an active ability being "Check getCheck()" or something like that, where the result would be the active ability getting a specific Alignment Check.
But what does it do when he gets that check?

Remember, after the night action the system must be in a consistent state that reflects the reality of the mafia game. This means it should have the necessary data about the result of the night action. In this example it should hold the data that the cop checked that certain target and got a specific check back.

This is why I thought of having a "Result" (as a concept/class/etc).
Every ability when activated, creates a result (maybe it may not though). This result is then stored in the system, for further use later or for info, etc.
For instance, when the game is over sometimes hosts post the "Night Action" list. It would go something like this:

Cop: Checks X, gets scum check
Vig: Shoots Y, who is vet and absorbs shot
Medic: Protects Z
Scum: Shoot Z, who absorbs the shot

Which can be organized like this:
Cop: Checks X
Vig: Shoots Y
Medic: Protects Z
Scum: Shoot Z
Cop gets scum check from X
Y loses his vet life
Z is shot but survives because he was protected

In this 2nd model, the 1st are the Night Actions and the italics are the Results.

So if we follow the 2nd model, the system must keep a list of both Night Actions and their Results.
The Results from that night would just be "Cop gets scum check on X"-"Y loses his vet life"-"Z is shot but survives because he was protected"

The result could have more info I guess. Like who created that result on said player, who are the parties involved, and maybe what ability was used.
If someone gets killed, the result could have this info:
-Who gets killed
-Who is his killer
-What ability was used to kill him
-If many people shot him, alternative have a list of the people that did (unless you just choose one for some reason as his "killer")

If someone gets a check, the result could have this info:
-Who did the check
-Who he targeted
-What type of check it is
-The result

Same with other types of "results".


So this is the "steps" I think should happen when resolving night actions:

• Players send Night Actions to the system, which stores them in a list/collection
  
• The system binds each Night Action with: an actor, an active ability, and a target
  
• After doing this, the system creates the order these active abilities will be executed (because of Action Resolution, for instance RBs are done first, then protection, then checks, then KP, etc)
  
• The execution of each Active Ability does this:
  
  • The Active Ability checks the effects of the actor which could modify the result of the action
    
  • The Active Ability uses his ability on his target
    
  • The target checks all his Passive Abilities, which could modify the result of the action
    
  • Once the process is over, a Result is made and added to a list of Results that happened that night cycle
    
  • Once the process is over, the roles and abilities are left in a consistent state as well; consistent with the state of the current mafia game
  
  
• Once all Results are made, the system checks all of them and does this:
  
  • If the result needs to notify someone, it does (with the specific info), for instance being RBed, getting shot but surviving, cop checks, etc
    
  • If someone died, then the system checks that player as dead (several implementations are possible), and adds the info to the next Day Post
  
  
• After all of this is done, either:
  
  • The system gives the list of Results to the host can create the new Day Post
    
  • The system automatically creates the Day Post with the info he had added above (he can still give the list of results+night actions to the host so he knows what happened)
  
  
• The new Day cycle is started, with the alive players

Does this sound okay then?

The main problem I find is giving the host the power to override any night action and do what he pleases.
For instance, if a Jailer RBes a scum RBer and said RBer RBes the Jailer back, the system would RB the Jailer and that's it. Maybe the host doesn't like that and would want both to be RBed, so he overrides the system and tells it to RB both.

However, this can be averted if the host is given control of the mechanics of the game when creating it. I.e when creating a game the host is given an option "If a Scum RBer and JK target each other, who is RBed?" and he chooses as he wishes, knowing he can't backtrack that decision later.

Which option do we take into account? The 1st one or the 2nd one?
If it's the 1st one then things get more ugly, since Passive Abilities and Active Abilities and stuff are dynamically changing, so the system will be in a inconsistent state when the host decides to override the night actions (for instance, if a vig shots someone he loses his "shot" active ability, even if the host later decides to override that and not let the vig shoot for some reason).

However, if we choose the 2nd one then everything is fine. The only problem is defining how the controler/system should handle the night actions depending on the configuration the host wanted.

One thing I'm not that sure of:


Do we store "irrelevant" Results?

For instance, imagine a Medic decides to protect player X, but nobody shoots X at all.
If this protection gave a "X is medic protected" result, it'd be irrelevant to the game since it doesn't change anything at all.
Not only that, but it could easily be inferred by looking at the Night Action list, where there's an action called "Medic protects X".

However:
That is a legitimate result of a night action. If the medic was RBed, then X would not have been protected
Imagine later we add a feature "Get the list of players that were medic-protected in any mafia game", then how do we determine that?
Do we check all night actions, and see which ones have "Medic protects X"? But what if the medic was RBed, or X was busdriven, or something else happened? That mafia game is not in a "consistent" state anymore (it's in the "ended" state), so after the game is over the system can't re-resolve the night actions and see if the medic really protected X or not.

Because of this I think ALL results should be stored in the system
This includes results like "was framed", or "was medic protected" which don't seem to add much to the game.
We could even make a distinction between Results, "Game Relevant" and "Game Irrelevant". Those results I mentioned would be "Game Irrelevant", while the ones I mentioned in my previous post would be "Game Relevant".
With this, once a cycle ends the system could give the host only the "Game Relevant" results perhaps (since they are the only ones that matter).
The system could give him all results anyways, just so the host knows exactly what happened that night

Setup Creation:
We include basic stuff (deadlines, plurality/mayority lynch, if it allows a no-lynch vote, etc).
We include Faction Creation (or choosing from an already existent one)
We include Role Creation (or choosing from an already existent one)

Faction Creation:
For this 1st iteration we should just force there to be 1 Town and 1 Scum factions with predefined win conditions, and the possibility of including 3rd party factions (or maybe making this automatic by including the SK/jester/etc roles in the "Role Selection" phase anyways)
For the long run however, we can create a faction with a predetermined Win Condition
+ Show Spoiler [Create Win-Con] +

Role Creation:
Several things are noted for the role:
Name: Name of the role
Faction: Must be a faction from the ones defined above
Alternate Win Condition: Creates a win condition for this specific role, even if it belongs to a specific faction. This should be developed later though, right now I think roles should just have the default win condition from their faction
Active Abilities: Must be able to create Active Abilities for the role
Passive Abilities: Must be able to create Passive Abilities for the role

Active Ability Creation:
An Active Ability should have a name, and a set of primitive active abilities. The primitive active abilities are the actions done on the target when this active ability is executed.

List of possible primitive active abilities:
Visit: Just visits the target. Jesters sometimes have this Active Ability to increase the chance a tracker/watcher sees them so they get lynched. Not only that, but several other primitive actions inherit from this one (actions that need to visit another role)
Kill Power: Uses KP on the target.
Create Passive Ability: Creates a Passive Ability on the target. Example: A Medic creates a protective passive ability on his target. It should specify the life of the Passive Ability (how much it should last). It can be permanent or just for the current night; can be 1-shot or several shot
Create Status: Creates a status on the target. Check "Status" below for more info.
Alignment Check: Checks the alignment of his target.
Role Check: Checks the role of his target
Tracks: Checks the people the target visited
Watches: Checks the people that visited the target

Passive Ability Creation:
A Passive Ability is an ability that reacts to an Active Ability, and does something back affecting the result.
To create a Passive Ability, any Active Ability may be chosen. Both primitive and custom active abilities may be chosen. If a primitive active ability is choosen, then any custom ability that uses that primitive active ability is inherently chosen as well.
After that, a primitive passive ability is chosen. A primitive passive ability is a "basic" ability that can be done passively when an action is done on him. Potentially, primitive passive abilities can be determined from the primitive active abilities that it reacts to

List of possible primitive passive abilities.
Protection: Protects self for 1 KP
Return Alignment Check: Returns a specific alignment check
Return Role Check: Returns a specific role check
Communication: Allows external communication with a specific target (target "actor" is included, i.e the guy that used an active ability on him)
Reflect: Reflects the Active Ability to another target (target "actor" is included, i.e the guy that used an active ability on him)
To avoid loops a reflected action might have a "was_reflected" flag or something to indicate it shouldn't be reflected back to him. Other algorithms may be used too
Ninja: Returns a null result
Create Active Ability: Executes an active ability (target "actor" is included, i.e the guy that used an active ability on him). The usability (one-shot, infinite) is not stated since it's executed every time the passive ability reacts.
The usability shouldn't come from this new active ability, but from the passive ability that creates it

Take into account that Active Abilities can have different targets. In which case in the Active Ability Creation mode, the creator can choose which primitive ability is targeted to whom of those targets he chose

Stay tuned for a list of "normal" abilities and how they are formed

Format of Active Ability: usability: primitive active ability AND (other primitive active ability)
Format of Create Passive Ability: PAA format -> life_expectancy: primitive passive ability AND (other primitive passive ability)
Format of Create Status: PAA format -> life_expectancy: primitive status
Format of Create Active Ability: PPA -> primitive active ability AND (other primitive active ability)
Format of primitive active ability: name_of_ability (target)
Format of primitive passive ability: [ActiveAbility_to_react]name_of_ability(possible_target), usability
Format of primitive status: [ActiveAbility_to_react]name_of_status(possible_parameters), usability


Active Abilities:

Vig Shot: 1-shot: Kill Power(target)
Role Cop/DT: Infinite: Role Check(target) (independent of sanity)
Alignment Cop/Cop: Infinite: Alignment Check(target) (independent of sanity)
1-shot cop: 1-shot: Alignment Check(target)
(Tracker and Watcher are trivial)
Medic: Infinite: Create Passive Ability(target) -> Current-night: [Kill Power] Protection, 1-shot
Jailkeeper: Infinite: Create Passive Ability(target)-> Current-night: [Kill Power] Protection, 1-shot; AND Create Status(target) -> Current-cycle: [Any]Roleblock, infinite
Mason (can PM one guy for the rest of the game): 1-shot: Create Passive Ability(target) -> Forever: Communication(self), infinite AND Create Passive Ability (self) -> Forever: Communication(target), infinite
Roleblocker: Create Status(target) -> Current-cycle: [Any]Roleblock, infinite
Framer: Infinite: Create Passive Ability(target) -> Current-cycle: [AlignmentCheck] ReturnAlignmentCheck(scum), infinite
Bus Driver: Infinite: Create Passive Ability(target_1) -> Current-cycle: [Any_except] Reflect(target_2), infinite; AND Create Passive Ability(target_2) -> Current-cycle: [Any_except] Reflect(target_1), infinite

Passive Abilities:

1-shot bulletproof vest: [Kill Power] Protection, 1-shot
Bulletproof:[Kill Power] Protection, infinite
Alignment-check immune:[Alignment Check] ReturnAlignmentCheck(town), infinite
Role-check immune:[Role Check]ReturnRoleCheck(elected_by_player), infinite
Tracker/Watcher immunity:[Tracker/Watcher] Ninja
Kill attacker and die:[Kill Power] Create Active Ability -> Kill Power(visitor)
Kill attacker but survive:[Kill Power] Protection, infinite AND Create Active Ability -> Kill Power(visitor) (is shot but bulletproof)
or [Kill Power] Ninja, infinite AND Create Active Ability -> Kill Power(visitor) (is never shot, kills attacker before the attacker shoots him)
Mason (masoned with a buddy):Communication(buddy), infinite
Mirror:[Any] Reflect(visitor), infinite
Miller:[Alignment Check] ReturnAlignmentCheck(scum), infinite


There are plenty more anybody can imagine, but those are the "standard" ones