Daniel Lepage on Mon, 18 Dec 2006 21:23:09 -0700 (MST)

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

[s-d] Refresh Prop, take 2

Ok, here's a much-revised draft of a Refresh prop. This one  
completely rewrites the Proposal rule, but does so in a way that I  
believe preserves the "proper" behavior. I also changed the  
dependency culling and conflict culling mechanism to prevent the case  
where a proposal A with high strength conflicts with many proposals  
but also depends on a proposal that is Lost. Under the current rules,  
all of the conflicts with A would become Lost because A has high  
strength, but then A itself would become lost because it depends on a  
lost proposal. The solution is to do dependency culling twice, once  
before and once after the conflict culling.

Draft for Refresh Prop:

__Fixing the World__

Replace the text of rule 2-2 with:
== Proposals ==

=== Definition ===

Proposals are Game Documents. Each Proposal has the following  
* A Title, which is a string
* A Body, which is a block of text that contains a list of changes to  
be made to the gamestate
* A Status, which is one of Pending, Open, or Historical
* A Success state, which is one of Won, Lost or Undecided
* A Proposal Number, which is an integer or null
* A set of Conflicts, which are other proposals
* A set of Dependencies, which are other proposals

If, in a set of two Proposals, either lists the other as a Conflict,  
those Proposals are said to Conflict with each other.

If one proposal lists another on its list of Dependencies, then the  
first is said to Depend on the second.

/* Note that a proposal may contain text in addition to its list of  
gamestate changes, but this text is generally ignored. It may be  
unclear whether or not a particular part of the text is a gamestate  
change; determining this is left to the Administrator and the justice  
system. */

=== Submission and Revision ===

Any player may submit a Proposal at any time, or may revise a Pending  
Proposal e owns by resubmitting it, unless a rule says otherwise. To  
submit a proposal, a player need only specify its Body. E may  
optionally also specify its Title, Conflicts, and Dependencies; if  
any of these are not specified, they default to being empty.

The player who submits a Proposal is known as the Proposal's Author.

When a new proposal is submitted, it is assigned the Status Pending,  
the Success state Undecided, and the Proposal Number null. The  
Administrator must then assign it a new Proposal number that is  
greater than all previously used proposal numbers as soon as e can.

/* Note that this doesn't include other things called Proposal  
Numbers from the distant past; the fact that five years ago there  
were proposals numbered in the thousands is irrelevant. */

=== Voting ===

The Voting Period for a given nweek, or just "Voting" is defined as  
the period of time from the beginning of nday 9 of that nweek until  
the end of that nweek.

At the beginning of each Voting Period, all Pending Proposals become  

Any Player may submit a Vote on an Open Proposal at any time. The  
Vote must be one of the words FOR, AGAINST, or ABSTAIN; other words  
are ignored.

The most recent Vote on a Proposal by a Player is called that  
player's Final Vote on that Proposal.

=== Tallying the votes ===

A Proposal's Strength is equal to the difference between the number  
of players whose Final Vote on that proposal is FOR and the number of  
players whose Final Vote on that proposal is AGAINST.

When Voting ends, the following events happen, in order:
   * Each Open Proposal with positive Strength becomes Won; all other  
Open Proposals become Lost.
   * Dependency Culling occurs (see below).
   * Conflict Culling occurs (see below).
   * Dependency Culling occurs again.
   * All Open Proposals that are Won Pass, in order by Proposal Number.
   * All Open Proposals become Historical

When a Proposal Passes, its list of changes to the game occur.

Proposals that do not Pass are said to have Failed.

=== Dependency Culling ===
When Dependency Culling occurs, every Open Proposal is processed in  
ascending order by Proposal Number. When a proposal is processed in  
this manner, if it Depends on a proposal that is Lost, then it  
becomes Lost itself. This process is repeated as long as there is any  
Open Proposal that Depends on a Lost proposal and is not Lost itself.

=== Conflict Culling ===
When Conflict Culling occurs, every Open Proposal is processed in  
descending order of Strength, and of Proposal Number when Strength is  
equal. When a proposal is processed in this manner, if it is Won,  
then every Proposal that Conflicts with it becomes Lost.


Give Peter 5 points.


spoon-discuss mailing list