Friday, January 30, 2015

Proposal: A reasonable limitation on their sabotage power

Cannot be enacted with a quorum of votes AGAINST, 0-9. Josh

Adminned at 01 Feb 2015 08:43:22 UTC

Add the following text to the rule “Sabotage”:

Demand Proposals cannot be Sabotaged.

Comments

Josh: Observer he/they

30-01-2015 18:17:46 UTC

Why would they be? What is this guarding against?

Bucky:

30-01-2015 18:43:37 UTC

Given several players’ current policy of voting against all unilateral Demands, I expect future Demands to be compromise proposals that have separate pro-Human and pro-Android components.  This would keep the Androids from setting up a trial compromise, watching how much it’d pass by, and switching it for a slightly less generous one if the margin is large.

It also puts a damper on private Android infighting, but I think that’s minor.

Josh: Observer he/they

30-01-2015 18:48:05 UTC

I think I’d prefer to encourage private Android infighting, as that tends to be one of the easiest ways for humans to win games of werewolf.

But really,  imperial I suspect this will have little actual impact.

Brendan: he/him

30-01-2015 18:49:07 UTC

“A Demand Proposal may not be made if another Demand Proposal is Pending.” How would that switch go exactly?  against

Bucky:

30-01-2015 18:52:30 UTC

They veto the existing (otherwise passing) demand proposal, wait for it to fall off the queue and demand the less generous version.

Bucky:

30-01-2015 18:56:04 UTC

Or they even wait for it to pass, propose the replacement and sabotage it retroactively.

Brendan: he/him

30-01-2015 19:06:51 UTC

Hmmmmmm. Fair point about the retroactive sabotage, though it still seems unlikely. This seems more useful to older Androids who want to have an advantage against newly scanned ones, which is something you’ve been staunchly against in the past.

Bucky:

30-01-2015 19:09:15 UTC

I don’t see where that advantage would come from.

Brendan: he/him

30-01-2015 19:15:22 UTC

Just off the top of my head: “DEMAND: no Android may [achieve victory, make a demand, inject a Crewmember with saline] if another active player has been an Android longer than they have.” Humans have no reason not to vote for this, as it encourages Android infighting. New Androids would struggle to justify voting against it. I am sure a smarter player could come up with other exploits.

Bucky:

30-01-2015 19:22:04 UTC

How about “DEMAND: The computer shall reveal the identities of all Androids to all other Androids.  Add a rule {irrelevant pro-human/new-Android blob}.”  And then retroactively sabotage the rule change after the information is revealed.

Currently, retroactive sabotage keeps this proposal from being viable, no matter who proposes it, even if everyone would rather it happen than nothing happen.  This would at least let someone openly say ‘Hey Androids, please Demand this’ and guarantee it will work as intended.

Brendan: he/him

30-01-2015 19:23:45 UTC

Okay, I can see that scenario. But pointing it out in the comments seems like it would be more than enough to get it voted down.

imperial, anyway.

Kevan: he/him

30-01-2015 20:12:53 UTC

against

Android infighting seems interesting, and players being aware of the reveal-then-sabotage trick is enough to discourage a Demand from ever revealing secret information.

I don’t see any inherent problem in Androids burning through proposal slots and goodwill to find out just how low they can scrape a compromise - every time they pull back the fake handshake and thumb their nose, that compromise point is going to move further away from their favour.

Bucky:

30-01-2015 20:21:58 UTC

Kevan - I’m claiming the reveal-then-sabatoge trick is enough to keep any proposal, demand or not, from revealing secret information.  This can only be fixed by having a non-Sabotagable proposal, and Demands seem to be the only possibly-acceptable-to-Androids channel for one.

Kevan: he/him

30-01-2015 20:52:23 UTC

A Demand (or Proposal) could just phrase it as a rule of “After 24 hours, reveal secret information then repeal this rule.”

Darknight: he/him

30-01-2015 23:12:26 UTC

against

RaichuKFM: she/her

30-01-2015 23:42:43 UTC

against

ayesdeeef:

31-01-2015 00:10:42 UTC

against

Skju:

31-01-2015 01:25:08 UTC

against

_Fox_:

31-01-2015 05:09:39 UTC

against
I’m voting against based on the title, “A reasonable limitation on their sabotage power”. Not convinced…

RaichuKFM: she/her

31-01-2015 08:23:48 UTC

I swear _Fox_ is trying to bluff us. Or… double bluff…