[s-d] Re: Final thoughts

["Peter Cooper Jr." <pete+bnomic@xxxxxxxxxxxxx>]

Daniel Lepage <dpl33@xxxxxxxxxxx> writes:
> Here are probably my last comments on this for a while. I just
> returned from a project meeting for one of my classes, and my group
> has concluded that we have more to do than we thought and less time to
> do it in, so I imagine I will not be contributing much to this
> discussion in the next month or so. I apologize for the inconvenient
> timing of my absence.

Well, Real Life(tm) does have a higher priority than Nomic,
unfortunately. Best wishes in your studies.

> I highly recommend the Magic: The Gathering ruleset as a reference for
> good wording advice, because much of the phrasing is similar -
> numerous objects each with a block of text specifying abilities,
> etc. - and the MtG ruleset has been worked over by people with a much
> greater interest in getting everything right than we have.
>
> http://www.wizards.com/default.asp?x=magic/rules/tourneyplayer

Peter Cooper, Tournament Organizer and DCI Certified Level 1 Magic
Judge, at your service. Pleased to meet you. :)

Yes, I was getting some inspiration from this from the Magic
Rules. Although even they distinguish between the Rules and the Cards,
whereas I'm trying to make them all one and the same here. But they
often know what they're doing.

> The important bits are all in section 4, where it defines
> abilities. Some key points in this ruleset that aren't in this
> proposal include that triggered abilities can start with "At" ("At the
> beginning of each nweek")

You know, I intentionally omitted "At", but I can't figure out why. I
guess I was thinking that B Nomic didn't have phases of a turn like
Magic did, so it didn't make any sense. But on further reflection, I
have no idea what I was thinking. I'll add "At" back in.

> and a note about using words like "has", "have", "gain", or "gains"
> to give abilities to an existing object.

I'm not sure that that's needed, but it might not be such a bad idea.

> On Nov 7, 2005, at 7:52 PM, Peter Cooper Jr. wrote:
>
>>>> Please provide feedback on what you like and don't like about this
>>>> proposal. In particular, I'm not sure exactly how the precedence
>>>> stuff
>>>> should work. (But I'm not sure how it currently works with non-rule
>>>> objects affecting the game, so I suspect that this attempt to define
>>>> it will be an improvement.)
>>>
>>> I think the historical precedent is that in the case of a conflict
>>> involving non-rule documents, the non-rule documents are treated as
>>> though they had the same precedence as the sentence in the rules
>>> specifying what they do. Conflicts between non-rules are usually
>>> settled in a "general defers to specific" manner unless some document
>>> provides a better method. Seeing that standardized would be nice.
>>
>> Well, that doesn't work when say, all talismans are defined by one
>> rule, and two talismans conflict.
>
> That's the "general defers to specific" bit. I think at one point we
> officially had "general statements defer to specific ones; with
> statements of equal specificity, the restrictive one wins". And if
> that didn't provide an obvious solution, somebody would CFI and the
> Judge would pick which one takes precedence.

Well, if we had two talismans, one of which said "The room the holder
of this talisman is in is dark, regardless of other effects", and
another of which said "The room the holder of this talisman is in is
lit, regardless of other effects", both held by people in the same
room, I'm not sure how any CFI judge could reasonably come to a
conclusion without applying timestamp of some sort (which isn't
specified by the rules) or flipping a coin. (Or maybe saying that both
are true, which could be more paradoxical in a different case.)

>>>> Then again, this may horribly and irreparably break the game. :)
>>>
>>> Always a plus :D
>>
>> That's part of the fun, isn't it? :)
>
> Much of the time, that *is* the fun.

Agreed. :) I do hope that this just gives us a basis for breaking the
game, and doesn't break the game itself.

>>> So I could name each of my Genechips "A Tweak", and by r0-0 every
>>> one would be a Motion.
>>
>> Nothing gives you the power to change an Genechip's name. Its name is
>> "Genechip".
>>
>> I guess what I really want to do is establish an Object Oriented
>> Programming-like hierarchy, which is kind of what we have. Genechip
>> extends Object. Proposal extends Motion extends Object. Wonko extends
>> Player extends Outsider extends Object. Something like that. I'm not
>> sure how well describing that will work, though.
>
> That model doesn't quite fit, though. Player extends Outsider extends
> Object, but Wonko is an instance of player, not a subclass.

Well for now. I was thinking maybe further down the road Players would
be complicated enough that each one would be a singleton subclass of
Player, each with their own crazy stuff (like those Superpowers we
tried earlier). But yeah, maybe we shouldn't start with that. :)

> How about this:
> Everything in the game is an Object. Every Object has a body of text
> (or maybe multiple bodies) describing its Abilities.
>
> Type Specifications are a type of Object; each Type Specification as
> its Ability describes a type of Object. There will be a Type
> Specification for Type Specifications; another for Rules, Sections,
> Rulebooks, Players, Talismans, etc. Inheritance is handled within
> these specs: the spec for Player begins
> "Players are Outsiders", for example. One special case Type
> Specification can handle all Objects with no special properties such
> as GeneChips.
>
> For each type so defined, instances can be created. Each instance has
> the Abilities field, and other fields according to the Type
> Specification. For Rules this means a title, a Chutzpah, etc.; for a
> player it means house stats, amplitude, etc.

I might go with something like that... I'll try to work something out.

>>>> In a Game Document, with the exception of this paragraph, text
>>>> between doubled square brackets (that is, text between "[[" and
>>>> "]]") shall be deemed Comment Text. Comment Text has no direct
>>>> effect on the state of the game, although Game Objects can read
>>>> it. Comment Text in a rule shall not be considered a part of that
>>>> rule.
>>>
>>> I'd say "In every Game Document"; also, "with the exception of this
>>> paragraph" implies that the paragraph is a Game Document, which I
>>> don't believe is the case.
>>
>> Well, the paragraph is in the text a rule, which makes it part of a
>> game document.
>
> It still seems a bit muddy to me.

It doesn't feel any muddier to me than it currently is... I think that
I'm not actually changing the text of that paragraph much.

>>> Also, a block of comment text is still part of the rule; otherwise
>>> it's not part of anything, which violates the first rule's claim
>>> that "anything that exists in the Game is an Object".
>>
>> Hmmm... Okay.
>
> You might use the MtG phrasing, which is "An ability is text on an
> object that.s not reminder text or flavor text", and also redundantly
> in another rule "Reminder text and flavor text are not
> abilities. Reminder text and flavor text always appear in italics."

I think I might want abilities to be something separate from the body
of text on an object. The body of text making up proposal Game
Documents is a list of changes to the state of the game, but they have
no abilites. (Yet. I see something like "0: Change your Current
Vote on this proposal. Any Voting Entity may play this ability." being
reasonable in the future.)

>>>> ==== Triggered Abilities ====
>>>>
>>>> Triggered abilities start with the word "when" or "whenever", in the
>>>> format "When X happens, Y happens". A triggered ability continually
>>>> watches the game, and causes Y to happen whenever X does.
>
> Again referring to the Magic ruleset, Triggered abilities can also
> start with "at", such as "At the beginning of each nweek, X happens".

Yeah... I don't know how I missed that.

>>>> Each rule has a number given by the number of the section which holds
>>>> it (converted to a normal Arabic numeral), a hyphen, and a number
>>>> which is unique within its section. If a rule is created that does
>>>> not
>>>> have such a unique number, it is assigned the number one higher than
>>>> the current highest number in the section which it is in, or 1 if
>>>> there are no others. Each rule may also have a title.
>>>
>>> Likewise, I don't think the hyphen format should be explicitly put in
>>> the rules, since it's a form issue, not a content issue.
>>
>> Well, but when game objects (like proposals) refer to rule 2-1, I
>> think it'd be nice to have that defined as the first rule of the
>> second section and not the other way around.
>
> Good point.
>
>>>>  * If both of the abilities are on the same object, then the one
>>>> defined by later text will take precedence over the earlier text.
>>>
>>> What about objects with multiple text fields? I could create an object
>>> type called an "Enchanted Amulet"; each object of the type has two
>>> fields, called the Aura and the Power, which define different
>>> abilities. If, due to poor wording on my part, I create an Amulet
>>> whose Aura and Power conflict, there's no notion of "later text" or
>>> "earlier text", they're just two different texts of the same object.
>>
>> Hmmm... Well, I was trying to convert the current rule that says text
>> later in a rule supersedes earlier text. What do you suggest?
>
> Under my Type Specification setup above, the order in which the spec
> lists the fields could be used to order the fields. Or we could just
> leave it to CFI judges to make the final call.

Hmmm... Yeah, I might not have anything specifically for abilities on
the same object, since hopefully they won't conflict with each other
too often. But if we have a lot of objects giving abilities to other
objects, it might be a bit of a headache.

>>>>  * If neither of the abilities is on a Rule, then the object created
>>>>    later has precedence over the other.
>>>
>>> And if both were created at once?
>>
>> Ummm... Hmmm. I suppose we could try to stop simultaneous actions. Or
>> we need to assign a serial number somehow to every ability as it is
>> created. That would probably also require clearly delimiting one
>> ability from another.
>>
>> I don't think that just going by "the rule that defines it" works,
>> since we have rooms and talismans that are defined by just one rule
>> each, and yet have effects just as much as the rules do. I was kind of
>> hoping to not have the rules really be any different than any other
>> kind of object.
>
> I very much like "general defers to specific", and "restrictions beat
> permissions" for ties; the CFI system can take care of the remaining
> cases.

I think I'm leaning toward Antonio's idea that type specifications
have to be in a Rule. Since Rules are the only things we have that are
numbered, if we want to have some sort of ordering on abilities, we
need to either use the numbering system we have or assign a number to
every object. And I don't want to assign a number to every last
Genechip. (Which might not be needed now, but would be if we start
giving them abilities, particularly if they're not all the *same*
ability.)

>>> What would be *really* cool would be an integrated system for storing
>>> Objects and their abilities in a database, automatically linking
>>> titles of objects to description pages, and stuff like that. That'd be
>>> pretty awesome. Then Clock Keys, for example, could just be a type of
>>> object, not defined explicitly by the rules, though the rules would
>>> determine how they get distributed amongst the players, and it'd be
>>> easy to read because the rule would automatically link to the
>>> definition of a Clock Key.
>>
>> Well, that's close to what our wiki is... It probably wouldn't be too
>> hard to adapt a wiki-like system to deal with our game if we manage to
>> change it like this.
>
> A database-driven system would be faster, though.

Hmm. I might try putting something together in my rare spare time.

>>> This also makes me think of something Glotmorf suggested years ago,
>>> where the game is set in a city and each rule exists somewhere in the
>>> city; in order to change a rule, you have to hunt it down, possibly
>>> fighting your way through guards and/or other players to get it. We
>>> dismissed it as a good idea, but one that didn't fit with the way B
>>> Nomic was working... but maybe with this we could actually do it...
>>
>> That's kind of what I was saying earlier we could do with the House,
>> although I didn't do a good job explaining it. If everything was
>> *really* an object, and in the House, then we can go around, pick up
>> Rules, throw them at people, and just generally cause Mayhem and
>> Delight.
>
> That brings back memories of fighting on the Grid with Insta-Rules and
> Cans of Whoopass... I really miss Insta-Rules.

I just did some searching of the historical rules archive, and those
do sound interesting...

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