Talk:Imperative Rework

May

Worth noting that we dropped the word "may" from the glossary in 2018 for actually having two different natural meanings, both of which crop up: "to express possibility" and "to express opportunity or permission". This was partly after repeated attempted scams from Cuddlebeam along the lines of "the rule says that players may be injured, and that falling over causes injury - after falling over last week I now choose not to exercise my option to be injured, and ignore it!".

This kind of problem seems hard to avoid without going down Agora's strict capslock legalese "a player MAY" route, which feels like an unnecessary gear change for BlogNomic, and one that might diminish the Nomic ecosystem. --Kevan (talk) 14:17, 15 May 2020 (UTC)

I agree, no interest at all in making it too aggressively legalistic. Josh (talk) 14:33, 15 May 2020 (UTC)

Limiting the scope of imperatives to "actions" looks like it fixes this, but maybe the problem is there as much as it was in 2018. If we have a rule of "A player may be unhappy.", intended to be read as "being unhappy is gamestate" (with other rules that make you unhappy), can someone still plausibly argue that no, it's giving permission to take the decision of "having the state of being unhappy" and - despite a rule telling them to become unhappy - they are choosing not to possess that state. --Kevan (talk) 08:48, 22 August 2020 (UTC)

Implied imperatives

It does feel like this rework should catch the wider issue of imperatives which aren't clearly expressed as "the player must do the thing". As well as using other terms like "shall" or "will", rules often have some variant on "when this happens...", requiring that when one action occurs, a variable gets updated. It always bothers me that the ruleset doesn't address how to handle this. It feels like it breaks down into three situations:-

• "A Spy may Shout at any time. A Spy may Surprise another Spy at any time, causing them to Shout. When a Spy Shouts, their Stealth becomes zero." - implying that if you choose to Shout, you're meant to update your own Stealth; if you cause someone else to, you update theirs. But in both cases it feels like a half-completed action is valid, and it's okay for an unrelated player to step in and say "hey, you forgot to reduce the Stealth" and apply the change.
• "A Spy may gain 1 Intel as a daily action. For each Intel gained by a Spy, 1 Intel is removed from their choice of Embassy." - again implicit that the actioning player is meant to do the update, but in this case a second player can't finish the action for them, because they don't know what choice would be made. Here, a half-completed action feels invalid - if I return the next day and say "oh yeah, I meant Bolivia" and go ahead with my next action, that's unfair on other players who've had to react to incomplete information in the mean time.
• "Every Monday at 2pm, every Spy loses 1 Intel." - the expectation is that the gamestate updates itself silently and anyone can manually update it afterwards. (Although this is poor rule-writing.)

Maybe there's some useful mileage in defining some of these cases and how to react to them ("if an event is said to occur as a result of an action, the player who performed the action must also apply the effects of the event; if they fail to do so, then..."), so that variations on may ("a player may be hungry" vs "a player may eat cake") and must ("a hungry player must eat" vs "cake must be eaten within three days of purchase") are interpreted as plain English rather than requiring players to always use the correct legal terms, and be alert for unintuitive scams that rely on them. --Kevan (talk) 16:43, 20 May 2020 (UTC)

Shoulds and musts

Looking at this with fresh eyes five years on, a few thoughts:-

• Unpacking the new should, what does this actually amount to? If a rule says I "should sleep", then I'm "required" to sleep, I must treat the rule as if it said I "must sleep" (which means I can't take other actions until I sleep) - and yet "[my] failure to do so does not put the gamestate into an illegal state". If I ignore the "should sleep" rule and travel to Brooklyn, the resultant gamestate is legal (I am now in Brooklyn) but I've broken a rule? What are players supposed to do next, about that?
• Checking the current ruleset's use of "must", to see how people use it informally, we've got "An Accusation must be sent within 24 hours of the original action being performed" - which is intended to mean "if it happens, this is the only way it can happen", but under this rework would become "somebody must accuse in response to every action". Perhaps restricting the enforcement to cases where "a player must" do something would be enough. (Off the back of "an accusation must be sent", it could also use adjusting to cover phrasings like "if the room is on fire, a player must extinguish the blaze" - where once one player has done this, other players cease to be bound by the must.)
• I feel like the "strictly forbidden under the stated circumstances" inversion shouldn't apply to shoulds. Saying "a player should not enter the warehouse" reads more like a breakable guideline than a declaration that doing so would be impossible. --Kevan (talk) 10:57, 17 May 2020 (UTC)

For reference, Agora's definitions of the words:

• can: if you try to do this, it works; however, this does not force you to try
• may: if you attempt to do this, you will not be punished for doing so; however there is not necessarily a guarantee that it works (normally used to override punishments elsewhere in the rules)
• should: you need a reason to not do this, and must be prepared to give the reason if challenged (such challenges hardly ever happen)
• shall/must (equivalent): if you fail to do this, the other players should punish you for the failure (comparable to a Fair Play breach in BlogNomic if intentional, often a slap on the wrist if accidental); however, the action does not automatically occur, not prevent you from doing other things, if you do in fact fail to do it

There's a category above this, where the rules describe that something happens without specifying anyone as responsible for it; in such a case, the changes in question automatically happen (causing a discrepancy between gamestate-tracking documents and the gamestate, which anyone can fix when they become aware of it via changing the gamestate-tracking documents).

The definitions on the main page are very different from this, and I don't think the differences are a good thing. For what it's worth, I would strongly caution against any "you're automatically locked out if you fail to do this 'must' action" rule, because it could lead to people being locked out for a long period of time with nobody noticing and causing huge mismatches between the actual gamestate and people's view of it; about the furthest I'd go would be recommending that players apply punishment (e.g. by CfJ) if done deliberately, and vote down any DoVs that became possible only as a consequence of a failure to perform such an action. Ais523 (talk) 11:34, 19 May 2020 (UTC)

Fail states

A big stumbling block here seems to be what happens when an action that the ruleset mandates be completed isn't.

Culturally, BN isn't very legalistic - when we notice that something has been done wrong, the first impulse is usually to retcon it rather than bringing the game to a half and reverting back to the last known good state. This proposal's ambition is to make that explicit - to reduce the number of situations where an action can make the gamestate explicitly illegal and to be permissive of adjusting the gamestate post-hoc rather than forcing us to revert things.

Is that a good assumption to work from? Josh (talk) 12:09, 19 May 2020 (UTC)

I believe the best solution here is to retcon via CfJ, or some similar mechanism that has the power to change things in the gamestate directly (rather than having an "automatic retcon"). My understanding is that this is the primary purpose of CfJs in BlogNomic, and (in my experience) what they were mostly used for when I was playing. That way, no matter how legalistic or pragmatic a player is, they all agree on the resulting gamestate. Besides, if there's a culture of "legal retcons" when something goes wrong, it means you have no reason to ever bring gameplay to a halt, because all the additional gameplay will end up extending the retcon and becoming legal.

I don't think there's such a thing as an "illegal gamestate". If you do decide to introduce such a concept, then either actions can be performed based on the resulting gamestate, or they can't be. If they can be, this opens up a trivial core rules scam (have a confederate create an illegal gamestate which allows you to win instantly, then DoV); due to a wording mistake in "Fair Play", this isn't even technically unfair play. If they can't be, then this seems to make things more complex, rather than less complex, because we end up with a Hiatus-like pause in gameplay that most players may not realise exists. Ais523 (talk) 22:27, 19 May 2020 (UTC)

Representations of the Gamestate

There's another core problem here, which is this:

The rule Representations of the Gamestate says that "The wiki merely represents the Gamestate tracked there, and is not the same thing". ais made a similar point in their comments on the main page. It's not, in and of itself, a controversial statement. It is, however, only semi-true, as we frequently have actions that specify that the player carrying them out should directly change the values in the wiki page, making the wiki page a game board rather than a representation of something abstract and otherwise unseen. Josh (talk) 15:04, 19 May 2020 (UTC)

Changing the values on the wiki page is how you change the values in the gamestate, but it's not like you're editing them directly; rather, the act of editing the wiki page is typically what triggers the change to the gamestate. (Sometimes rules define a different way to do it, such as writing a Story Post, but that's rare.)

This is one of BlogNomic's main innovations/advantages compared to email nomics; it means that the records of the gamestate tend to update themselves, because updating the record is how you take the actions in the first place. So there's much less "admin load" than there is in the other nomics I've played in.

As a side note, there is one case in the current rules in which this isn't the case – the gamestate-tracking device is the gamestate directly rather than merely reflecting it – which leads to a trivial core-rules scam to gain a dictatorship. Doing so involves intentionally performing an action that is illegal (or at least not explicitly legal), would be massively unpopular and contrary to the spirit of BlogNomic, and would almost certainly lead players ignoring the whole thing and banning the perpetrator, and so I have no intention of trying. It might be worth fixing, though given the likely huge consequences for someone who attempted it, it's probable that we'd decide that it isn't actually a problem. If Cuddlebeam were around, I'd be more concerned. Ais523 (talk) 22:16, 19 May 2020 (UTC)

(Historical note: Kevan covertly fixed the scam using the same CfJ that was used to fix the "everybody is idle" issue we just had, so that dicatorship scam is no longer available.) Ais523 (talk) 13:23, 21 May 2020 (UTC)

https://www.youtube.com/watch?v=4ZGiqWIhw94 But anyways, for the record I don't think that such a scam would be possible, because of the ancient "The Ruleset and Gamestate can only be altered in manners specified by the Ruleset.", so you can't just do something illegal to change the rules in the first place, even if you could toy with the Ruleset-Gamestate directly. Yes, it's a bit weird, but it's what the rules say. --Cuddlebeam (talk) 13:12, 22 May 2020 (UTC)

BlogNomic doesn't have a comprehensive framework for dealing with situations in which the rules contain a false statement, but I think we generally consider it as flavour text rather than as creating some sort of legal fiction. (The legal-fiction concept, whilst used heavily in some nomics, is pretty alien to BlogNomic.) Ais523 (talk) 18:33, 22 May 2020 (UTC)

I assume reality of that situation will depend on who you play with, because there is hardly any precedent system to decide these kind of things here, just the sum of our individual views. And I, well, stated mine. No intent to speak for others. --Cuddlebeam (talk) 21:44, 22 May 2020 (UTC)

The v3 "must"

"chronological order of the requirement arising" is a good call.

A must-locked player being denied all core actions seems too far, though - it's dangerous if players are ever blocked from voting on CfJs or DoVs, and bad for the game if must-locked admins and mentors can no longer perform their duties. Limiting a must-lock to dynastic actions and declaring victory seems like it'd be enough. (A block on declaring victory is maybe fair for situations where there's an action chain of "player gets 100 points but must then do something which is unintentionally impossible", where the victory condition is 100 points - performing half of that chain should not result in victory. Although I guess there are variations like "generate 100 points for someone else and then do something impossible", where my accomplice would win even though I became must-locked.) --Kevan (talk) 10:31, 23 August 2020 (UTC)

I've made a change along that line. How do you feel about players being able to idle themselves? Josh (talk) 20:27, 23 August 2020 (UTC)

Probably okay, I think, for players who are stuck in a situation where they'd rather forfeit the game than continue. Doesn't seem that big a deal when they also have the option of just walking away from the game and idling out a week later. If someone tactically idles to avoid a "must", then the remaining players will, as usual, sort it out for them, probably to that player's detriment. --Kevan (talk) 20:48, 23 August 2020 (UTC)

The v3 "shall"

"A Pathfinder is required to carry out this Action but has some flexibility over when and in what order should be carried out, within reason." - this is pretty vague. Is it a placeholder? I didn't see any problem with the v2 approach of making shall and must synonyms. --Kevan (talk) 10:34, 23 August 2020 (UTC)

It's really vague. I'm torn between trying to define all of the cases carefully and leaving it open enough to be interpreted through use. As discussed in the thread I think that there is a need for a more general-use midground between may and must (a lot of derrick's objections can be resolved this way, as well as a few of my own reservations, and the list of cases that you posted in your comment here - timestamp 11:46:24). Josh (talk) 20:27, 23 August 2020 (UTC)

the addition to Fair Play

I'm concerned about forbidding this delay, especially when it is waiting on a time-sensitive action by someone else, such as a proposal/cfj passing, or an ally undertaking an action. Perhaps reserve this for tasks that say "must immediately" — Preceding unsigned comment added by Derrickthewhite (talk • contribs)