[s-d] Re: [auto] Peter submits p280

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

Daniel Lepage <dpl33@xxxxxxxxxxx> writes:
> Peter has submitted a new Motion, p280:
>>
>> ---------------------------------
>> Motion 280/0: Grand Reunification Of All Nomic Game Objects
>> A Proposal by Peter
>> Last modified on nweek 99, nday 9
>>
>> [[Acronym: GROAN GO]]
>>
>> [[
>> This makes all Game Objects into basically what are now tools. We have
>> talismans and rooms affecting the game, but the precedence and
>> ordering between them and the rules seems poorly defined at times. It
>> seems to me that this prop unifies everything and makes everything
>> clearer. But maybe it's just me.
>
> I'd love to see that done, though my past attempts to define such
> things have always failed.
>
>> Eventually, I'd also like to change all Game Actions to be activated
>> abilities. We can have voting just be an activated ability on a prop,
>> for example. We could have the Game holding the House, which holds
>> Rooms, which holds players, and the picking-up and using objects in
>> the house just becomes an inherent part of the game. Or something like
>> that.
>
> Confusion arises when one object can be held by multiple objects. For
> example, two subgames each hold a player.

I was thinking that if we went with something like that, the House
*would* be the main game, with everything in the game, including
subgames, inside it. Kind of like your city idea that you mention
later.

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

>> Then again, this may horribly and irreparably break the game. :)
>
> Always a plus :D

That's part of the fun, isn't it? :)

>> Delete Rule 9-10.
>> Change Rule 1-2 to have the following text:
>> {{
>> === Game Objects ===
>>
>> The game of B Nomic consists entirely of Game Objects, which may be
>> known simply as Objects. Anything that exists in the game is an
>> Object, and anything that is not an Object is not in the game.
>
> Can it be an Object without existing in the game? The two clauses here
> are each others' contrapositives.

I was just trying to be extra explicit, since I was giving more
meaning to "object" than before. It's probably extra-redundant, yes.

>> Each Object has a name.
>
> This doesn't require uniqueness,

True.

> but does require me to name each of my Genechips.

How so?

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

But maybe if I say that each object has a name, I have to go through
and make sure it's clear what each object's name is?

>> === Outsiders ===
>>
>> An External Force is anything which exists independently of the
>> game. That is, it would still exist if the game stopped existing, and
>> would still exist if the game never started existing.
>
> I think that should be "would still exist if the game *had* never
> started existing". As it stands, it implies that "never starting to
> exist" is something the game might still do.
>
> Which actually might be possible, who knows?

I was laughing out loud when I read that last part. We don't have a
no-retroactive-changes rule anymore, do we?

I think I'll include that "had".

>> An Outsider is an External Force which is also an Object. [[ i.e.,
>> something that exists outside of the game but is also acknowledged by
>> the rules as influencing the state of the game, and thus exists within
>> the game as well, such as a player.]]
>>
>> === Game Documents ===
>>
>> Some objects are known as Game Documents. Game Documents include a
>> body of text.
>
> Game Documents include bodies of text, or each Game Document includes
> a body of text, but not one body of text for all Game Documents.
>

Nice catch. I'll fix that.

(inserting comments from your other email here)
> Thought: Every object has abilities, and the only way to define such
> abilities is via a block of text. So what makes a Game Document
> different from any other Object, and specifically, what is true of
> Rules as Game Documents that wouldn't be true if they weren't Game
> Documents?

Basically, I was trying to keep the name around so I wouldn't have to
change quite so many places. For instance, the revision and submission
rules talk about Game Documents, and I think there are other places as
well. I certainly have no problem with removing the concept later.

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

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

>> === Possessions ===
>>
>> Each object has a set of objects that it is said to hold.
>>
>> === Abilities ===
>>
>> Each object has a set of abilities. There are three types of
>> abilities, which are triggered, activated, and static.
>>
>> The use of the 2nd person (i.e., 'You', 'Yourself', 'Your', etc.) in
>> an ability is assumed to refer to the entity which holds that object,
>> except when describing activated effects, in which case it refers to
>> the object which activated the effect.
>>
>> ==== 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.
>>
>> ==== Activated Abilities ====
>>
>> Activated abilities are in the format "{cost}: {effect}". An object
>> allowed to play an activated ability does so as a Game Action by
>> paying {cost} to cause {effect} to happen. A {cost} may include one or
>> more Objects, and paying the cost means that those Objects are
>> destroyed unless otherwise stated. A {cost} could be 0, in which case
>> there is no cost to perform the action.
>
> It'd be better to say "may do so" instead of "does so" on the second
> line of this paragraph; otherwise, a room holding a Talisman will
> constantly activate its abilities.

That could be... interesting.

>> An object which holds an object with an activated ability is allowed
>> to play that ability.
>>
>> ==== Static Abilities ====
>>
>> All other abilities are static abilities. Static abilities describe
>> how they affect the game.
>>
>> === Other Attributes ===
>>
>> Objects may also have other attributes, as described in the definition
>> of each object.
>> }}
>>
>> Change the text of rule 1-4 to be
>> {{
>> A Forum is any External Force that allows Outsiders to
>> communicate. Each forum may be designated as one of the terms Private,
>> Public, or Discussion. All Fora are initially Private.
>> }}
>>
>> Change the text of rule 2-1 to be
>> {{
>> There is a Game Object named the Ruleset. The Ruleset holds Game
>> Objects which are named "Section". Each section holds Game Objects
>> which are named "Rule".
>>
>> Each section has a uniquely identifying Roman Numeral. If a section is
>> created that does not have such a Numeral, it is assigned the Roman
>> Numeral one higher than the current highest such Numeral. Each section
>> may also have a title.
>
> I'd rather say each section has a number; whether we choose to
> represent that number as a Roman Numeral is up to us.

I could go for 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.

>> Rules are Revisable Game Documents. The text of each rule defines that
>> rule's abilities. [[Most rules consist entirely of static abilities
>> that define how the game is played.]]
>> }}
>>
>> Change the text of rule 2-2 to be
>> {{
>> Should it happen that the text of one ability contradicts or otherwise
>> invalidates the text of another, the two abilities are considered to
>> be in conflict. If one of the abilities explicitly states that it
>> takes precedence over or defers to the other, and the other does not
>> make a contrary claim, these claims are used to determine which shall
>> take precedence.
>>
>> If this is not the case, then:
>>
>>  * 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?

>>  * If one of the abilities is on a Rule, and the other is not, then
>>    the one that is not on a Rule takes precedence.
>>
>>  * If both of the abilities are on a Rule, and those Rules are held by
>>    the same Section, then the Rule with the lower unique number within
>>    that section takes precedence over the Rule with the higher number.
>>
>>  * If both of the abilities are on a Rule, and those Rules are held by
>>    different Sections, then the Rule within the section with the lower
>>    section number takes precedence over the other.
>>
>>  * 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.

>> The abilities of this rule take precedence over all other abilities.
>> }}
>>
>> In rule 2-5, change "rules" to "abilities" and "rule" to "ability".
>>
>> [[How we could start changing things into activated abilities:]]
>> In rule 3-15 change
>> {{
>> A player who has a Clock Key may as a Game Action change eir Clock
>> Key's value from Off to On or from On to Off. This Game Action may be
>> performed regardless of the Clock state.
>> }}
>> to
>> {{
>> Clock Keys have the ability {{0: Change this Clock Key's value from
>> Off to On or from On to Off. This ability may be played regardless of
>> the state of the Clock.}}.
>> }}
>>
>> Change the text of rule 9-13 to
>> {{
>> Certain objects may be designated as Tools. Each Tool has a body of
>> text associated with it which define its abilities.
>>
>> Each Tool also has a Game Document associated with it called its
>> Appearance; this may be an empty text (and is if no Appearance has
>> been specified for that Tool), but in general it should be a
>> description of what the Tool looks like, either in plain text or via a
>> link to an existing image outside of the game (such as the url of a
>> gif or some such thing).
>
> Don't you need to specify that the Appearance has no effect on the
> gamestate? Or is that implicit in something I missed earlier?

Well, nothing says that the Appearance *would* have an effect on the
gamestate. Why would Appearance affect the game any more than the name
of my player or the value of my Amplitude would?

>> No Tool may ever be created that has the same name as an existing Tool
>> but a different Effects field (however, this does not limit the number
>> of identical copies of a given Tool that may exist).
>
> Also, you can't refer to the Effects field here, because you just
> repealed it two paragraphs earlier.

Whoops. Thanks for catching that.

> Overall, I like this, but I think there are some wording issues that
> very much need to be worked out before it'll be safe to pass this.

No doubt. That's why I wanted to give a full nweek of discussion on
it, and so I submitted it just after voting started instead of just
before. :)

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

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

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