Monday, January 20, 2025

Proposal: Can’t Take the Heat

Withdrawn. Failed by JonathanDark.

Adminned at 21 Jan 2025 04:12:22 UTC

In the rule “Heists {I}” add a subrule named “Heat {M}” with the following text:

Each Participant has a publicly tracked Heat, which may contain zero or more alphabetical characters, defaulting to zero characters.

As a Heist Action, a Participant can remove two or three alphabetical characters from a word in a Mutable rule and add those characters to their Heat, provided that all of the following are true after the removal:

* The word that was modified is still a word in the English language $$.
* The word that was modified is at least two letters in length.

As a Heist Action, a Participant can remove one or more of the alphabetical characters from their Heat and add those characters in any order to an existing word in a Mutable rule provided that all of the following are true after the addition:

* The word that was modified is still a word in the English language $$.

In the rule “Heat {M}” add a subrule named “Too Hot {I}” with the following text:

A Participant who has one or more characters in their Heat cannot have their Triumphs increased by any dynastic actions.

Heat becomes a “holding ground”, but you risk holding the characters too long and missing out on gaining Triumphs.

Comments

ais523: Mastermind

20-01-2025 04:32:33 UTC

I’d like a dollar or two in the “still a word” restrictions (they don’t need to be strongly protected, but the action is very powerful without them, so it should cost a little extra to open that particular floodgate). The ability to remove lots of letters at once is also somewhat powerful, and maybe should be limited to two or three letters at a time (but no dollars needed there – “two or more” could just be “two or three”).

There also seems to be a missing end-blockquote tag that’s causing this proposal to render incorrectly.

More generally, I’m wondering about how the precedence works here: we have precedence rules “can’t beat can” but “immutable beats mutable”, so when an immutable rule says the Triumphs can increase and a mutable rule says they can’t, which wins?

In general, though, I’m fine with this – the dynasty could do with the set of rule-editing powers becoming more powerful over time and this looks like a good basic idea for implementing that.

JonathanDark: he/him

20-01-2025 05:03:38 UTC

I added the dollar signs as recommended, and resolved the “Immutable beats Mutable” by simply requiring a Triumphs increase to have an equal decrease if that Participant has non-empty Heat so that there’s no conflict, just an additional modification.

JonathanDark: he/him

20-01-2025 05:05:26 UTC

Also changed it to “two or three”. That seems sensible and of course can be heisted later.

ais523: Mastermind

20-01-2025 05:34:48 UTC

I think the “decrease by the same amount” unambiguously doesn’t work because mutable rules can’t decrease immutable variables. (It would be something of a problem if mutable rules could directly increase Triumphs, after all.)

I think the best fix is to put the Heat check into an immutable rule?

JonathanDark: he/him

20-01-2025 05:46:03 UTC

Ok, yeah, that makes sense. For some reason in my head, I didn’t want to put an Immutable rule as a subrule of a Mutable one, but there’s no reason not to that I can see. Fixed.

Based on the experiences from the Snail Racing dynasty, I didn’t want to add the concept of Heat to the existing “Teams and Targets”. It’s easier to manage if the same concept is mentioned in rules close to where they were first mentioned rather than spread out.

ais523: Mastermind

20-01-2025 06:07:08 UTC

Almost looks good – “cannot have their Heat increased” isn’t quite right, though, it should be along the lines of “if their Heat would increase, it instead stays the same”. The current wording could be read as preventing the entire team from Triumphing, i.e. as “cannot perform actions that would increase Triumphs” rather than as “can perform actions that would increase Triumphs, but they don’t change”, and it’s probably best to be unambiguous about whether that works or not.

ais523: Mastermind

20-01-2025 06:19:48 UTC

(I am planning to vote for this with either wording, though – it may not become a problem, and if it does it can be fixed later.)

ais523: Mastermind

20-01-2025 08:36:36 UTC

for

SingularByte: he/him

20-01-2025 09:45:40 UTC

for

Brendan: he/him

20-01-2025 14:18:43 UTC

against A lot of power creep when we haven’t even really used the Roles yet, and there’s only been one successful heist.

Josh: Mastermind he/they

20-01-2025 14:21:07 UTC

against Think I agree with Brendan on this one.

Habanero:

20-01-2025 14:30:32 UTC

against Seems very strong, maybe a bit too strong

SingularByte: he/him

20-01-2025 14:47:38 UTC

CoV imperial  That’s true.

JonathanDark: he/him

21-01-2025 04:11:32 UTC

I’d still like a way to modify multiple arbitrary characters at a time, at some appropriate cost, but I can accept that the cost might not have been high enough here.

Withdrawn.  against