Re: [s-d] RFC: Devices

["Mike McGann" <mike.mcgann@xxxxxxxxx>]

On Nov 8, 2007 7:19 PM, Jamie Dallaire <bad.leprechaun@xxxxxxxxx> wrote:

> To give an example (and I can't come up with the actual rule number
> because
> the wiki seems to be down, so let's just call it rule 9-9....), it would
> be
> entirely reasonable to have a power on a device in existence that gives
> its
> owner a more solid grip on ministries than is offered by the rules. If I
> remember rule "9-9" correctly, a player can usurp a ministry as a game
> action with a single supporter. Suppose a power exists that, when
> activated,
> makes a target ministry held by the device owner usurpable only with 3
> supporters and with no objections. If rules have absolute precedence over
> powers, my reading is that anyone could simply refer to rule 9-9 and
> invalidate this power entirely. In other words, it would be impossible for
> such a power to exist or at least be effective. Perhaps we should allow
> the
> power to specify that it overrules rule 9-9...
>

While the rules, as they stand, would prohibit that action, the rule could
be changed to allow that action by a device. Since Blueprints basically have
to be created by proposal, you could roll it up into the same proposal. I
think it would be better if the rules explicitly give permission when needed
than to allow devices to change things at will.

Some rules probably have good reasons for it. Requiring only one supporter
for an usurp is probably a good idea if the active number of players is low.
You wouldn't want the Chariman and MoM to go AWOL holding this device and
not being able to muster enough support to wrest control and turn the clock
on.

On another general note, I do not think it is, but is it possible in the
> framework you have here for a device to have powers that are constantly in
> effect, simply by virtue of being the device owner, and need to specific
> activation or costs in order to work? I'm thinking of things akin to
> enchanted armor, here, just to get back into the RPG idea. Just wearing it
> gives you the bonus, you don't have to do anything special with it. It
> could
> be a device that, for example, is a "Bargainer's Handbook" and gives its
> owner a preferential 1 to 6 exchange rate on points to mackerel, always,
> doesn't have to be activated every time. It could be a device that makes
> one
> regenerate a couple hit points at regular intervals. Anything like that.
>

You could do it this way:

Bargainer's Handbook:
Tap: Owner gains the Bargaining Property.
Tap: Owner loses the Bargaining Property.

And then add a Device Regulation:

If a Player trades a Point for mackerel and they have the Barganing
Property, they shall gain an additional mackerel.

This allows an effect to stay active for an extended period of time and
allows the Owner to turn it on and off if they desire. With the proposed Tin
Foil hat, once you got it, that was it. You couldn't use all the other
devices that were proposed since there was no way to put the hat on or take
the hat off.

Are Powers Attributes? Properties?


Neither. A Power is a series of one or more Game Actions that are performed
when activated.

>
> > No two Blueprints must ever have the same Blueprint Name. If at any time
> a
> > Blueprint has a Production Count of one, it shall gain the Biddable
> > Property. If at any time a Blueprint has a Production Count of zero,
> that
> > Blueprint shall immediately cease to exist.
>
> First sentence here is ambiguous. If a Blueprint has the name "xyz" and is
> subsequently destroyed, can a future Blueprint have the name "xyz"?
>

If Blueprint "xyz" is destroyed, it ceases to exist, is no longer a
Blueprint, and cannot conflict with a future Blueprint that may be called
"xyz"


>
> How about this, changes in italics:
>
> If a Blueprint has the Biddable Property, bidding for the *Device defined
> by
> the Blueprint begins* at the start of Breakday [[nday 1]] and the
> Blueprint's Price is set to *the Blueprint's* Starting Price. Any Player,
> as
> a Game Action, may submit a non-retractable bid, specifying a Biddable
> Blueprint and an amount of *currency* greater than the Blueprint's Price,
> *in
> the same type of currency as the Blueprint's Price*. *Any amount of
> currency
> bid* becomes the Blueprint's Price.
>
> a) This is just one section but it might be good to rework this text, in
> general, to take out the specific reference to mackerel, and just speak of
> currency instead. We can, of course, leave m50 as the default price. But
> talking about currency in general terms would make this easier to deal
> with
> in the future if new currencies come into being. PS I'm not sure whether
> the
> phrase "in the same type of currency as the Blueprint's Price" is
> well-worded but I can't check the vocabulary the currency rule uses right
> now as the wiki isn't loading.


Using the general term works--I'll put those changes in. Also, I don't think
it would be necessary to say in the same type of currency. The rules of the
currency can decide that out when a new currency is introduced. You may want
to have a currency that is not compatible with mackerel, but you may want to
have one that is compatible or equivalent to mackerel (for example, 1 trout
= 1000 mackerel)


> b) The change to the last sentence isn't entirely necessary but just takes
> out some redundancy in my opinion. Since a bid can't be submitted unless
> it's a higher amount of currency or mackerel anyway, we don't need to
> refer
> to the highest bid submitted. A bid becomes the price at the time of its
> submission.


Correct, no need for redundancy.

> Bidding ends at the start
> > of Ballotday [[nday 9]], and the Player with the highest bid is the
> winner.
> > At the end of Thirnight [[nday 12]], if the winning Player has a
> sufficient
> > amount of mackerel, the Device for the Blueprint is Produced for the
> winning Player.
>
> Is the 3 nday period between winning and receiving the device necessary? I
> like how long the bidding period becomes in this framework, but the whole
> process, to me, becomes prohibitively long when a proposal needs to be
> submitted in nweek *x* and passed, then the device (for biddable
> blueprints)
> is bid on during nweek *x + 1*, and finally cannot be used until nweek *x
> +
> 2*. Could we shorten the period between bidding ending and device being
> produced, so that it could potentially be used within the same nweek it
> was
> bid on? I think this might add excitement and incentive to outbid others,
> especially with concern to devices that could affect the voting process or
> outcome, if players have concrete proposals that are being voted on in the
> next ndays and could be affected by one acquiring the device or not.
>

How about bidding starts on Breakday, ends at the end of Tango, you have
until the end of Ballotday to come up with the macks?


> > If the winning Player does not have a sufficient amount of mackerel,
> > the winning Player automatically and repeatedly converts one Point into
> > mackerels until the winning Player has a sufficient amount of mackerel
> (and
> > the Device for the Blueprint is Produced for the winning Player) or
> until
> > the Player has zero points. If the winning Player still does not have a
> > sufficient amount of mackerel, their mackerel is set to zero.
>
> Very harsh punishment for foolish bidding, excellent. But what happens to
> the Blueprint? Is it bid on once again in the next nweek? Is it destroyed?
> Is the device produced at all? Does anyone else get a crack at it if they
> have the money?


The Production Count does not decrement, it is still Biddable, so it opens
up again for bidding on Breakday. Might need to put in someway to prevent
someone who has no mackerel and no points to keep putting in a bid of a
zillion to prevent it from ever being bought.


> > Objects as targets. A Cost is one or more Game Actions the Owner must
> > perform to activate the item.
>
> OK. Can this rule mention that activating a power leads to all game
> actions
> specified by the cost (if it can be completely fulfilled) being performed
> automatically by the player? Because right now it sounds like if I want to
> use my device that has spend m10 as a cost, I need to perform the action
> of
> spending 10 mackerel myself by posting to a public forum.
>

Good point. It looks like my usage of Game Action all over is not what I
intended. I'll have to reword that.


> > For brevity, the following can be used as a Cost:
> >
> > * Zero: A Game Action that does nothing.
> > * Spend mX: The Owner has an amount of X subtracted from his mackerel.
> This
> > Cost can only be fulfilled if the Owner has an amount of mackerel equal
> to
> > or greater than X.
> > * Lose X: The Owner has an amount of X subtracted from his Score. This
> Cost
> > can only be fulfilled if the Owner has an amount of Points equal to or
> > greater than X.
> > * Tap: After this Device's Power Resolves, this Device gains the Tapped
> > Property.
> > * Sacrifice: After this Device's Power Resolves, this Device ceases to
> > exist.
> > * Requires X: The Owner must own a Device with the Device Name of X or
> this
> > Cost cannot be fulfilled.
>
> Perhaps, in addition to "cost", we should retain something similar to
> "conditions" in the current ruleset, which could include some of the
> things
> that are cost types right now in this text (such as tapping, e.g. a
> condition could state "power has not previously been activated during the
> current nweek" or, for more flexibility than tapping seems to offer,
> "power
> has not previously been activated more than 4 times during the current
> nweek" or "blablabla during the 2 previous nweeks". The conditions, I
> think,
> can add other important dimensions to using a device or power, that can't
> really be addressed by "costs" if I understand them right. e.g. "5 or more
> players have voted, either for or against, on the target proposal" or
> "target player is currently post-holder for more than one ministry" or
> anything like that.
>
> Cost would be an actual game ACTION that must be taken for the power to be
> activated, while Condition would be something that simply has to be true
> for
> the power to be activate-able.
>

Yeah, conditions do need to be in there. I'll rework that back in.


> > Powers cannot be activated when the Clock is Off.
>
> Why not? There could be interesting powers that would work with the clock
> off or regardless of the clock. Clock state could be specified as a
> condition. "Clock is Off" or "Clock is On".
>

The clock turns off so that adminstrivial duties can be done and it is
probably best to not change game state during that period. It is a device
regulation though so it can be easily overridden by a device. Of course, it
could be made as a rule instead if we really don't want devices to work when
the clock is off.

- Hose
_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss