On September 16 2013 14:38 gonzaw wrote:Show nested quote +On September 16 2013 12:34 GreYMisT wrote:
The Banlist was talking about it, so here is my typical night action resolution chart taken from parallel worlds mafia
Night Action resolution
Night actions will typically resolve in the following manner.
1. Anything with “ First Priority” specifiers
2. Roleblocks (2 roleblockers actioning on each other will both be roleblocked and notified)
3. Any Redirection abilities
4. Everything else
5. Anything with "Last Priority" specifiers
It's not so easy. Some redirection actions affect other redirection actions, which in turn affect other stuff, etc.
I think the best way to envision it would be creating a "graph" of dependent actions. I.e every night action is a node in the graph. If that action modifies another action in any way, you link that action to the other one.
So if (1)="Player A RBs Player B" and (2)="Player B Checks Player A", then the dependency graph would be (1)->(2).
This means you first execute (1), and THEN execute (2). Basically you follow the graph.
But shit like bus drivers and redirection make this shit hard, because it changes the graph as you execute it.
For instance, if (1)="Player A busses Player B and Player C", and (2)="Player D RBs Player B" and (3)="Player C Checks Player A", then at first, you construct the graph like this:
(1)->(2) ; (3) (3 is independent)
So you execute (1), but oh! It turns out that now B and C are bussed, so D actually RBs C. This means the graph changes to (2)->(3), since Player D is RBing Player C.
This means C never gets his check. However if you had followed the initial graph C would have gotten his check.
You can say "But by making all RBs happen first, this doesn't happen!". Well I think this shouldn't be the case. Why? Because the above case is legit. If I buss 2 players and a 3rd player RBs one of them, he should instead RB the one that was bussed. This is the core of redirection, and it shouldn't apply to every other action, yet stop with roleblocks just because.
One way to mitigate this is to "simulate" graph executions. You first take all dependencies, then "simulate" executing the 1st one in the chain (if the chain is (1)->(2), you simulate (1) first). After this, you see if any dependencies changed. With lots of actions with lots of dependencies which change lots of stuff this may pose a problem.
There's also the problem that the chains must be acyclic. So if you encounter a cycle (for instance 2 players RBing each other) you do have to break the cycle.
However it goes beyond that. You can have ANY cycle. What if Player A RBs Player B, Player B RBs Player C, and Player C RBs Player A? This is different than the "2 RBs RB each other" case, yet it is another cyclic problem.
You can say "Just RB all 3", but there can be other cycles that not only have to do with RBers. For instance bus drivers bussing each other, and of course other "insane" mechanics with mind controllers and stuff.
But again just making one role have priority over "everything else in the universe" defeats the purpose of some of these roles, and makes certain scenarios (which would have been possible and valid previously) invalid (like the bus->RB one I mentioned first).
Meh. Surely we could convince some mathematician and/or computer scientist to give us a nice perfect computing model for this shit.
EPT
