Proposal: Factory Pixies
Timed out 5 votes to 3. Enacted by Kevan.
Adminned at 27 Jun 2012 09:19:10 UTC
In the rule “Power Links”, replace “If a Machine ever has a Power Link to or from a Jammed Machine, it becomes Jammed. Whenever a Machine becomes Jammed, immediately remove all Power Links to or from the Machine without making any of the Machines linking to or from it Jammed.” with:-
If a Machine has a Power Link to or from a Jammed Machine, any Worker may set that Machine to Jammed. If a Machine is Jammed, any Worker may remove a Power Link to or from that Machine.
And replace “If the Distance between the two Machines in a Power Link is ever more than five, the Power Link is removed and the Machine the Link was from becomes Broken.” with:-
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.
In the rule “Forgiveness” (if it exists), replace “At the start of each week, any non-Reputable worker gains one Reputation.” with:-
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.
In the rule “Robots”, replace “The available Robots are listed in the subrules to this rule.” with:-
The available Robots are listed in the subrules to this rule, with the name of the rule being the name of the Robot.
In the rule “Machines”, replace “non-Dismantled Machine” with “non-Shrouded Machine”.
Rename the rule “Timeline Repaired!” to “Factory Repaired!”
Rename the rule “Navigation” to “Activation”, and replace the word “navigate” with “activate” and “navigation” with “activation” throughout that rule.
Replacing a few “this happens automatically even if nobody remembers to do it” gamestate-confusing effects with player-triggered choices, and making some minor fixes (including Koen’s belatedly-explained point about Robot names).

Comments
omd:
Kevan:
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.
Henri:
Bucky:
scshunt:
moonroof:
Kevan:
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.
Clucky:
Kevan:
[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.
Kevan:
[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:
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…
Clucky:
(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)
quirck:
Kevan:
[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.
Clucky:
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.
Kevan:
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”.
Clucky:
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.
Kevan:
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.