Difference between revisions of "Talk:Imperative Rework"

From BlogNomic Wiki
Jump to navigation Jump to search
(→‎Representations of the Gamestate: to change the gamestate, you change the wiki page, but that's because the one edit does two things)
(→‎Fail states: can't we just fix these via CfJ (retconning if necessary); it's what we always used to do and it seems to work just fine)
Line 29: Line 29:
  
 
Is that a good assumption to work from? [[User:Josh|Josh]] ([[User talk:Josh|talk]]) 12:09, 19 May 2020 (UTC)
 
Is that a good assumption to work from? [[User:Josh|Josh]] ([[User talk: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. [[User:Ais523|Ais523]] ([[User talk:Ais523|talk]]) 22:27, 19 May 2020 (UTC)
  
 
==Representations of the Gamestate==
 
==Representations of the Gamestate==

Revision as of 22:27, 19 May 2020

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)

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)