Re: [s-d] RFC: Devices

["Jamie Dallaire" <bad.leprechaun@xxxxxxxxx>]

Hey Hose,

Wow, really detailed document here. I generally quite like it, and address
what comments or gripes I do have below.

On a more general note than any of the comments below, I understand the need
for an order of precedence between rules and powers etc., but I do not think
it should be so absolute. Perhaps rules should take precedence over powers,
except when the game document describing a certain power explicitly names
certain rules that the power can override.

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...

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.

That said, great effort and I'm generally in favour of implementing this
idea once it's tinkered with some more. Comments below!

Billy Pilgrim

> A Device may also have a set of Powers.

Are Powers Attributes? Properties?

> 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"?

> The Production Count of the Blueprint is then decremented by one if its
value is
> not Infinite.

infinity - 1 = infinity
yes? :-D
But you might as well leave it like this, as doing so might avoid much
tangential discussion. AND it might even be possible to argue that, from the
way the production count definition is worded above, a value of "Infinite"
might just be a character string rather than an actual mathematical value,
in which case it wouldn't be compatible with subtraction of an integer, and
something confusing would happen.

> If a Blueprint has the Biddable Property, bidding for the Blueprint's
Device
> opens at the start of Breakday [[nday 1]] and the Blueprint's Price is set
> to the Starting Price. Any Player, as a Game Action, may submit a
> non-retractable bid, specifying a Biddable Blueprint and an amount of
> mackerel greater than the Blueprint's Price. The highest amount of
mackerel
> bid on a Blueprint becomes the Blueprint's Price.

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.

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.

> 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.

> 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?

> 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.

> 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.

> 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".
_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss