Re: [s-d] attributes redux

["Chuck Adams" <cja987@xxxxxxxxx>]

On 12/5/06, Daniel Lepage <dpl33@xxxxxxxxxxx> wrote:
> 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.

mm yes, I like that much better.  I suppose the state of all Game
Objects (and specifically not External Forces such as Fora) counts as
the gamestate?  That's probably clear enough, even if "state" isn't
formally defined.

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

Oops, I meant to change it to "fields".

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

That's what I assumed Properties were about, though with Properties
like "Player", perhaps a Property is meant to describe what an object
*is* as opposed to what an object *has* (whether you consider that one
and the same depends entirely on your take on Plato I guess).

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

Ok by me, I dropped the restriction.  Should I allow for doublequotes
to be used to disambiguate a property name, or just leave that one up
to consensus?

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

Yeah, it started with some notion of types, then I pared it down to
effectively say "a value means what it means".  Not too useful now
that I think of it.

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

I'd argue that Property fills that bill.  I didn't feel like replacing
Property with Attribute.  Should I try to absorb it?

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

Well, we have Attribute objects already now.  Just right now, only
Players can have them.  There's also Properties, which would seem to
be valueless Attributes, but Properties wouldn't apparently be
affected by any rule respecting Attributes, and vice versa.

I guess once it's pared down to the core, there really isn't anything
at all to Attributes.  Nihilism wins another round.  At least there's
the "gamestate protection" proposal that comes out of it:

{{
No change to the gamestate may be made unless the Rules expressly permit it.
}}

One sentence.  You came up with the idea: you want to propose it?

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