BlogNomic: The First Dynasty of Desertfrog

The first two are unnecessary, as the relevant gamestate only changes through explicit actions; the first would allow a race between Jamming a Machine linked to a Jammed Machine and removing the link, and the second would allow some dubious sequences of actions if a Worker could perform them too quickly for anyone to notice and remove the stretched Power Links.

I think these kinds of changes are necessary to avoid us getting into an illegal gamestate due to a player’s oversight. Although the “Jams spread through Power Links” effect is mentioned immediately after the effect that makes a machine Jammed and we can probably rely on players to remember to do it, a player creating a new Power Link in a different rule may not notice it.

Won’t making these actions player-triggered help prevent problematic race conditions? If we build a ruleset with a lot of “when X is true, Y automatically changes” effects, we’re going to get into situations where there’s no clear order of resolution. Letting players pick the order in which they resolve seems the cleanest way to do it - if some “dubious” optimisations emerge, we can patch them easily enough.

as the first clause gives too much discretion to workers.

It does give more freedom (and should maybe be “remove all or no power links”), but we’re operating in something of a vacuum here, we haven’t yet described how big a deal it would be to be able to select from optional Jams and disconnections.

I personally am a fan of state machines.

[Clucky] Me too, just not when they’re being operated by a group of disparate and clumsy humans. The ClingBoom dynasty had similar problems when we were all sharing the same heavily connected gamestate.

[Clucky] Me too, just not when they’re being operated by a group of disparate and clumsy humans. The ClingBoom dynasty had similar problems when we were all sharing the same heavily connected gamestate.

I guess I just dislike how the players now have a choice in some of the order things happen. Perhaps if we did something like:

Workers may update the gamestate in the following ways at any time.

1) If there is ever a cycle of Power Links, a worker may set one of the machines in the cycle to Jammed and remove all Links to and form that Machine.

2) Otherwise, if a Machine has a Power Link to or from a Jammed Machine, any Worker may set that Machine to Jammed and remove all Links to and from the Machine.

3) Otherwise, if the Distance between the two Machines in a Power Link is ever more than five, any Worker may remove that Power Link and render Broken the Machine that the Link was from.

4) Otherwise, If no Worker has done so during the current week, then any Worker may Forgive the Workforce. Upon Forgiving the Workforce, each non-Reputable worker gains one Reputation.

or give each action a “priority” and say that no actions of priority X can be performed if there is an action of priority < X that could be performed.

That way, it still mostly functions as a state machine, it just doesn’t update automatically. Might make it a little easier to track…

(basically, the thinking is it turns it from “make sure you cleanup AFTER you do something” to “make sure you cleanup BEFORE you do something”. Which, while really people should clean up afterwards, assuming they don’t is the only way to keep the gamestate sane. If require them to do so, people will assume they have. If we give them the option of doing so, people will assume they haven’t and check first)

[Clucky] Nice solution. It does highlight the amount of work required to keep the state machine running, though, when seen as a list - once we have a few dozen Machines active and a lot of them Jammed, then checking the Jammed status of every Link will be a little boring, and measuring the distance of every Link will be absolutely exhausting.

I think that just shows *why* we should require it to be done before anything else happens. That keeps the corrections needed small. If we make it optional, it allows the machines to become increasingly messed up to the point where no one wants to spend the hour needed to untangle everything.

Maybe to make things easier I’ll write a script that points out all the long links / jams / whatnot.

We already have a (cheap!) action of “move an entire row to a different row”, though, which will require the rechecking of every Power Link on the board every time someone does it.

A script to do all the bookkeeping for us (and which spat out a simple “current factory invalid; please disconnect Machine 45, jam Machines 12 and 14 and render Machines 23 and 43 ‘Broken’ before taking a game action” report) would be fantastic, but in its absence I don’t think we should be too afraid of the network of machines becoming “messed up”. Non-compulsory untangling is just giving us a game mechanic of “decide to disconnect or destroy a machine, within these constraints”, which may be just as interesting a part of the gameplay as “decide to connect or unshroud a machine, within these constraints”.

true. I’ll CoV for now given that I agree this is better than what we currently have, but while I think the fact that it adds more decisions is an interesting gameplay mechanic, it doesn’t fit with the theme. Its not like a machine gets jammed when tries to link to another jammed machine because some worker is like “Oh look. You can’t do that, I’m going to jam you now”. Long links break because they are too long, not because some worker chooses to snap them.

I was picturing it all as overstretched cables, hissing steam and showers of sparks, with machines running outside of their normal operating parameters. It still works, but only so long as we all stay very still and don’t touch anything.