Re: [s-d] attributes redux

[Daniel Lepage <dpl33@xxxxxxxxxxx>]

This still seems unnecessarily formal, fairly redundant, and overly  
restrictive.

On Dec 5, 2006, at 7:00 PM, Chuck Adams wrote:

> How's this look for another treatment of Attributes?  The only major
> change is that any object can have attributes, not just Players, which
> was really the main reason.  That and wanting to head off any need for
> formalisms such as types or ranges, because Rules themselves already
> serve for constraints and interpretation on anything and everything.
>
> (Admin: not a proposal yet, just a discussion)
>
> {{
> Any Game Object may possess a non-negative, finite number of
> Attributes.  No Attribute may be created, assigned to an object, or
> removed from an object except as expressly permitted by the Rules.

I'd prefer a separate rule saying "The gamestate doesn't change  
except according to the rules". That would cover this, and a lot of  
other ambiguities.

> An Attribute is defined as a Game Object that contain the following  
> values:
> 	* A name.
> 	* A value.

It's a bit confusing that you refer to these both as values. Also,  
why require a value? E.g. "When a player is Hit with a Big Stick, e  
gains the attribute 'Stunned' for one nweek". No value, just a name  
to mark that it's there.

Obviously that wouldn't work as well in a programmatic nomic, where  
you'd probably give each player an "isStunned" attribute that could  
have the value 1 or 0.

Although if you're running a python nomic, you really could do it  
with existence only -
wonko.stunned = 0
del wonko.stunned

> An attribute's name shall consist only of alphanumeric characters.

Why restrict this? I'll vote against a prop that tries to define a '  
' attribute, but I don't see why punctuation etc. can't go in an  
attribute name.

> An attribute's value may potentially represent whatever its definition
> specifies.  The actual interpretation of an Attribute's value is
> specified by the rule that creates the Attribute or allows for its
> creation.

Isn't this paragraph redundant, if the rules are already going to  
tell you how to interpret attributes?

> [[Explanation: an attribute may be defined by anything such as "the
> integer 876", "the string ''foobar''", or "the essence of three
> turnings of Vanatu's aura".  The interpretation of what these values
> "mean" are up to the creator, then ultimately to the judges.
> Hopefully no one would vote for the creation of something as bizarre
> as the third unless they're up for some "interesting" RFJs]].
>
> No Attribute may be created that lacks either a name or a value.

But I could just as easily proclaim my valueless attribute using a  
term other than "Attribute".

> No Attribute may be given to a Game Object if the Game Object already
> possesses an attribute with an identical name.

This also comes automatically if you don't bother to define  
attributes. If one rule says "A player's score is the number of  
points e has", and another says "A player's score is the name of the  
last player e killed", then we'd use normal precedence methods to  
determine which was is actually the score.

> The Rules may specify constraints on an Attribute's value, such as
> what is considered a valid value, what Game Objects it may be applied
> to.  No change of an Attribute's value is permitted if it would would
> violate these constraints.
> [[ Technically this clause is redundant, because if you write a rule
> constraining the value, it already has a self-enforcing effect. ]]

Yes, it is redundant.

> No element of a Game Object shall be interpreted as an Attribute
> unless specifically referred to as an Attribute by the Rules.
> [[ Thus, player names aren't Attributes because nothing says it's an
> Attribute, nor are Properties attributes.  ]]

What is the point of Attributes, then? That is, if you're thinking of  
making X an Attribute, why not just make X an... aspect, or whatever  
"name" and Properties are? This has the added benefit of not  
reserving all the useful words - I can't say "attribute" or  
"property" without causing confusion.

-- 
Wonko


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