Seems reasonable.

This does seem like the least headachey way to deal with it, although a bit unintuitive to have it working differently from player stats. That an unidling player would get their old coins back if those coins were implemented as “a player has a number of coins”, but would lose them if they were “coins exist, each is held by a player”.

What could we do about situations where we can’t just detach and discard the corrupted gamestate? If we had a rule of “The Burgermeister is a player, tracked publicly” with (carelessly) no option for that role to be blank, what should happen if that player goes idle?

I don’t think we can eliminate each edge case; it’s always going to be possible to conceive of a dynastic configuration that would leave something that has to be handled by exception. For something like this I think a narrower, more predictable scope is better than something wider that could fire off haphazardly

I don’t think it’s an edge case, those seem like the three types of player-connected gamestate: it’s a variable attached to the player, or it’s a “token” with a player’s name on it where multiple copies can be created and destroyed, or it’s a single permanent variable.

I think the current ruleset can implicitly cope with a variable having an invalid value (it notes that “Invalid values for game variables can never be used”) - and that might actually be okay, if we flag it up a bit more and know to expect it. That if Jumble idles, their Farm remains on the board but is now owned by “Jumble, an invalid value”; if Hans the Burgermeister idles, the Burgermeister is now “Hans, an invalid value”. Both situations will be predictably restored if the player unidles, and any dynastic rules that care about who owns a Building or who the Burgermeister is in the mean time will fail: that may need an urgent CfJ to repair the game, or it may (as I think is the case right now?) actually be fine.

Another angle on it from that direction would be to say in the Appendix that any gamestate that tracks a player name can also track an idle player name - but that it can only be set to one through that player becoming idle.

because I’m not sure how this amendment would actually play out in “The Burgermeister is a player” situations. Is the Burgermeister an entity? Would this repeal the rule defining it?

I’ll take a run at the “can also track an idle player” approach when I’ve got some slots back.

I would argue that a status or characteristic does not meet the threshold of being an “entity” but I guess at this stage I know how these things go

What do you think of the idea of just saying that anything that tracks a player can automatically also track an idle player, as needed - but that it can only be changed to that through a player going idle?

The only wrinkles are that we wouldn’t want it to affect alphabetical default values, and that an action such as “For each Temple, grant its Owner 2 Piety” shouldn’t become impossible if there’s a Temple owned by a named, idle player whose Piety doesn’t exist. But with those exceptions added I think it does the job.

It seems a more intuitive way to handle it, I think, that an idling player will know that they’ll get all of their Temples and Livestock back when they unidle, but that since the Temples are “on the board” they might get stolen or knocked over in the mean time.

I’ll put a proposal up in an hour when the queue starts moving.

Personally I find it more messy - I think that when a player idles more often than not they don’t come back, and I’m adverse to tracking a bunch of defunct gamestate - but I see no issue with having the competing proposals up for review.