Re: [s-d] [s-b] Proposal: Devices, hey!

[Daniel Lepage <dplepage@xxxxxxxxx>]

Here are my justifications for each change:

> For 3-12:
> * Remove the distinction between uniqueness and non-uniqueness.

I can put this back in if you'd like. I was trying to make the rule  
simpler.

> * Rename DOO to Deviceholder.

I've always hated "Device Owning Object" and "Currency Owning  
Object". They're just ugly phrases. Really I'd like to write a  
standard framework for objects owning each other, but I don't have time.

> * Remove the "device owner" attribute and simply have a device owner.

I've also never cared for "attributes" - things have attributes  
already, you don't need to formalize it, and when it's used all it  
seems to do is make the rules longer and uglier.

> * Allow a Player to refuse a transfer of a device. This is an
> important addition because there doesn't seem to be a way to refuse a
> transfer or a way to destroy or dispose of an unwanted device. Could
> lead to a very interesting hot potato situation if the current rule
> isn't amended.

This maybe should be more general - other transferable objects  
(including currency, points, etc.) ought to be optional.

> * Add the mechanic for <cost>:<effect> and the term Sacrifice. This
> could just be added using the existing framework of "effect",
> "conditions", and "triggers" and defined in addition to the current
> rules.

The current phrasing only allows powers that are "used", so I needed  
to change it anyway to allow static abilities. A rewrite seemed cleaner.

> * Remove the "power has no effect" rule if ambiguous.

We have a complicated justice system precisely for resolving this  
sort of ambiguity; we don't need a separate system. Also, we'd  
probably need to invoke the justice system anyway in order to decide  
that there really was an ambiguity.
	I am especially wary of the current clause, which says that the  
owner of the device decides how ambiguities are resolved. This  
implies that A) ambiguous objects may behave differently for  
different players, and B) if I feel there is ambiguity about how an  
object works, I can legitimately decide that it works by making me Win.

> Other comments:
> Current reading of Sacrifice seems that a Player may destroy the
> object but is not required to do so since the wording says "implicitly
> permits the deviceholder to do so"

The implicit permission is because having an action in a cost doesn't  
necessarily empower you do to perform that action. For example, a  
power that read "Win the game: Lose 5 points" shouldn't implicitly  
allow the holder to Win the game by activating that power. However,  
sacrificing an object is generally not permitted, but a power that  
reads "Sacrifice: do X" should be interpreted to mean that you can  
sacrifice the object in order to activate that power, even though you  
may not be able to otherwise.

> For 3-14:
> * Remove distinction between uniqueness and non-uniqueness.
Again, it could be put back. Or it could be specified within a  
blueprint that only X copies may exist at a time.

> * Remove the ability of the Artisan to change the price of a  
> blueprint.
Yes.

> * Add that the price can be in any combination of currencies.
Maybe we need a general syntax for prices in general.

> * Add a rule precedence
In general I think it makes sense for the powers to be able to  
override the rules. For example, a blueprint could explicitly forbid  
multiple copies of the object it defines; this would override the  
rule's mechanisms for creating new ones.

> Other comments:
> Current amendment seems to use the term "price" and "cost"
> interchangeably when they shouldn't be. The phrase: "the Ministry
> immediately instantiates that blueprint and gives a copy to that
> player" is confusing. A copy of the blueprint or the device? Nothing
> is copied. A device is simply created from the blueprint.

Sorry, my mistake. A previous draft (actually, a very old draft that  
I never proposed months ago) had the shop hold a sort of 'fake copy'  
of each object, and real copies were created when needed.

Fixing these props is on my to-do list; if I don't get to it before  
voting I'll rescind them and try again next nweek.

-- 
Wonko

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