Reasonable Action Resolution

[callforjudgement]

By now, many of us are aware of the problems that NAR has: it doesn't solve some common modding issues such as RB/JK loops, and it keeps getting misinterpreted by new (and even experienced) mods. That said, it IMO produces better results than list-based methods, so I'd like to try to salvage it.

As a result, I've been working on Reasonable Action Resolution, a scheme that produces the same results as NAR in nearly all cases, but also holds opinions about pretty much any action resolution situation that could come up (whether it's something simple that NAR doesn't handle, like the RB/JK loop, or something complex like multiple Bus Drivers). Even better, it doesn't rely on lists, special cases for each role, or anything like that; it's a set of four consistent rules that can (hopefully) be applied to any set of roles to produce a deterministic outcome (and thus players can calculate role interactions themselves without needing to ask the mod for help). See the wiki page Reasonable Action Resolution for full details and plenty of examples.

However, the tl;dr version is: instead of looking at which actions succeed, look at the effects they have. An effect happens if some action tries to make it happen, and isn't counteracted by another action (or is, but that action is in turn counteracted by another action, and so on). In the case of modified (e.g. redirected) or triggered (e.g. PGO) actions, the effect of that action can be stopped in two ways: by preventing it triggering/having something to modify, or by preventing the resulting action after the trigger. And in order to stop infinite regresses, the same night action can't have its effects twice in a dependency chain.

I'm pretty happy with the algorithm itself (I've been thinking about it for months at this point). I'm a little less happy with the way I've presented it, and would be happy to hear suggestions about how to explain the algorithm; it's pretty simple, but looks more complicated on paper than I feel it is in practice.

I'd like to eventually see the algorithm widely adopted (although I guess convincing anyone to use it would be a good first step…), although it will need testing first. In addition to the presentation issues, I'm interested in feedback about the algorithm itself: does it produce the results you'd expect? Does it have balance issues (i.e. produces a defined result, but one that's bad for typical setups)? Are there any role interactions that are impossible or unreasonably difficult to calculate?

[quadz08]

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, and the 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.

This case has no actual resolution listed - who dies? All we know now is that B doesn't die.



My general impression of the whole thing is that it's A) well thought-out and B) difficult to utilize in practice. Resolving actions by starting from the end effect means that you're starting with a Very Large Number of interactions in role madness games (which is where most role resolution issues come into play). Is there a reason that simply applying rule 4 to NAR wouldn't resolve pretty much all the issues we have?

[Davsto]

I think that it actually says B is killed. See...

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.

And the last resolution is a "Reason for yes:", so B is killed.

Basically, two buses cancel each other out so as a result the kill is just unaffected by them. I mean frankly putting two Bus Drivers in one game is a terrible idea in the first place, but you know.

[quadz08]

Right, ok. But now you have a logical issue with both redirects somehow failing to occur because they both cancel each other out? That doesn't make any sense at all.

[quadz08]

I mean, yes, obviously there are design issues here, but I don't see how you can possibly resolve a dual-redirector situation like this successfully without list-based resolution at least in some small measure.

[Davsto]

I think the logic is that:

The vigilante shot cannot be redirected by both buses,
You can't decide a single bus to redirect it,
Thus, the shot is not redirected.

The buses still happen, but they don't affect the vigilante's shot.

[Sajin]

I mean, yes, obviously there are design issues here, but I don't see how you can possibly resolve a dual-redirector situation like this successfully without list-based resolution at least in some small measure.

There are many odd roles it does not cover well. The entire point of NAR is to give players a guide for how roles interact in your game. I would fully expect a well designed game to put a resolution for 2x bus driver in the game in one or both of the role PMs (Ex: This action happens before any other non roleblocking actions). If there was not I would expect actions on A redirected to C, actions on C are redirected to A and actions on B to resolve on B. In effect the two bus drivers form a bigger loop. If you resolve it any other way it would not make sense if you scale it to 3 bus drivers (A and B, B and C, C and D: actions on A and D are swapped, actions on B and C occur normally). That said, I would never put 2 bus drivers in the same setup, or if I did, I would put some sort of resolution guideline in their role PM.

There are a multitude of roles that would not be covered under NAR. Roles that copied another players action they were using that night along with redirectors or blockers. A role which transforms an action into another type of action would also have some grey area resolutions that would not be clear to the players if they had a copy of the role PMs. I don't think the solution is to come up with more things to tack onto NAR though because there will be a large amount of edge cases with odd resolutions.

The general rule for setup design should be: If someone else had access to all role PMs in the setup, could they accurately resolve all actions for you the same way you would do so? If not, something should change in the role PMs, the rules or the setup to allow for a better design.

[Untrod Tripod]

another good thing to do is check all possible interactions and then sort them out pregame!

and maybe even change your setup based on bad interactions!

[callforjudgement]

Right, ok. But now you have a logical issue with both redirects somehow failing to occur because they both cancel each other out? That doesn't make any sense at all.

You don't look at whether an action occurs or not in the abstract, just whether an end result happens.

In this case, you can't construct a consistent situation in which either bus-drive blocks the kill. So neither of them does.

My general impression of the whole thing is that it's A) well thought-out and B) difficult to utilize in practice. Resolving actions by starting from the end effect means that you're starting with a Very Large Number of interactions in role madness games (which is where most role resolution issues come into play). Is there a reason that simply applying rule 4 to NAR wouldn't resolve pretty much all the issues we have?

I like the idea of trying to fit rule 4 onto NAR (it'd probably end up equivalent, which would be great as the current presentation is quite complex and hard to work through), but it'd hard to define it in a precise way.

[chamber]

The kill hitting both A and C seems at least as consistent as it hitting B

[callforjudgement]

Not in terms of looking at individual end results, unless you assume that shooting C would hit both A and B. In RAR and NAR, shooting C in this situation hits A, and I think that's what most people would expect.

[Sajin]

The kill hitting both A and C seems at least as consistent as it hitting B

So 2 redirector roles creating a new kill action from thin air makes sense? No...that interpretation does not scale well to more complex situations as well. Lets say a watcher was on A or C or a tracker was tracking the vig shot. In the case of the tracker would you really give the result that the vig visited A and C?

This is why that situation must be resolved as the vig hitting B. However, I agree it is unclear and the situation would be better resolved by adding things into the role PMs in the setup stage.

[Davsto]

The kill hitting both A and C seems at least as consistent as it hitting B

Just as consistent, maybe, but setup-wise, do you

really

want a pair of bus drivers to be able to double the vig's shots, to summon a shot from nowhere?