Daniel Lepage on Tue, 8 Nov 2005 01:06:08 -0600 (CST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[s-d] Final thoughts

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.
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
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") and a note about using words like "has", "have", "gain", or "gains" to give abilities to an existing object. 


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. 


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.


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. 

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


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


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


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. 


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


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.


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. 

--
Wonko
Your food stamps will be stopped effective March 1992 because we received notice that you passed away. May God bless you. You may reapply if there is a change in your circumstances. 
  ---Department of Social Services,  Greenville, South Carolina

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