spoon-discuss: Rethinking bandwidth pools

["Glotmorf" <glotmorf@xxxxxxxxxxxxx>]

On 5/23/02 at 9:11 PM Wonko wrote:

>How's this for Bandwidth Pooling? They're similar to Clubs, but only meant
>to be use for Bandwidth loans.
>
>{{
>__Bandwidth Pools__
>
>A. Definition
>
>Bandwidth Collectives, or Pools, are groups of players sharing eir
>bandwidth. A Pool may be created by a group of three to six players, using
>the following procedure:
>
>1) One player issues, in a Public Forum, a Declaration of Intent to Pool,
>or
>a DIP. A DIP must include:
>    i) the name of the Pool to be created
>    ii) the names of all other players who are to be members of the Pool.
>    iii) a statement indicating whether the Pool is Open or Closed.
>2) Each player named to be part of the Pool affirms, within three ndays of
>the issuance of the DIP, their willingness to join the Pool. If any named
>player fails to do this, the DIP is void and the Pool is not created.
>
>B. Admittance and Rejection
>
>All Pools must have one of two leniencies Open or Closed. A Pool is assumed
>to be Open if it's leniency is unspecified.
>Any member of a Pool may remove emself from that Pool by declaring their
>intention to leave the Pool in a Public Forum. Such removals take effect at
>the beginning of the next Voting Period.
>
>B.1. Open Pools
>
>The following two paragraphs apply only to Open Pools:
>
>Any player who is not a member of a Pool may issue a Request for Admittance
>(RFA). If a majority of the members of the Pool deny the RFA within four
>ndays of its issuance, then the RFA is destroyed and has no effect.
>Otherwise, the player who issued the RFA becomes a member of the Pool.
>
>Any player who is a member of a Pool may issue a Writ of Exclusion (WOE)
>towards any other member of the same Pool. If a majority of the members of
>the Pool other than the target of the WOE deny the WOE within four ndays of
>its issuance, then the WOE is destroyed and has no effect. Otherwise, the
>player who was targeted by the WOE ceases to be a member of the Pool. Such
>oustings take effect at the beginning of the next Voting Period.
>
>B.2. Closed Pools
>
>The following two paragraphs apply only to Closed Pools:
>
>Any player who is not a member of a Pool may issue a Request for Admittance
>(RFA). If any member of the Pool denies the RFA within four ndays of its
>issuance, then the RFA is destroyed and has no effect. Otherwise, the
>player
>who issued the RFA becomes a member of the Pool.
>
>Any player who is a member of a Pool may issue a Writ of Exclusion (WOE)
>towards any other member of the same Pool. If any member of the Pool other
>than the target of the WOE denies the WOE within four ndays of its
>issuance,
>then the WOE is destroyed and has no effect. Otherwise, the player who was
>targeted by the WOE ceases to be a member of the Pool. Such evictions take
>effect at the beginning of the next Voting Period.
>
>C. Pooled Proposals
>
>C.1. Definition
>
>A Pool may submit Pooled Proposals. Pooled proposals are proposals, but
>with
>the following properties:
>
>*They count as 1/(number of Players in the Pool) units of bandwidth towards
>each member's Bandwidth.
>
>*When a Pooled Proposal passes or fails, the dimensions of each member of
>the Pool shall change by (the amount the eir dimensions would have changed
>had e issued the proposal emself) / (the number of players in the Pool),
>rounded up.
>
>*When a Pooled Proposal is Shelved, it is immediately removed from the
>Ballot and destroyed.
>[[To deal with possible changes in the size of the Club between nweeks]]
>
>C.2. Issuance
>
>Any player in a Pool may issue a Pooled Proposal on behalf of eir Pool
>provided that each Pool member has enough Bandwidth that eir Bandwidth will
>not drop below zero.
>
>Before Voting begins, each Pooled Proposal that would be on the Ballot must
>be Ratified by its Pool, or it is destroyed. An Open Pool Ratifies a Pooled
>Proposal when at least half of its members, not counting the member who
>issued proposal, affirm it in a Public Forum. A Closed Pool Ratifies a
>Pooled Proposal when all of its members, not counting the member who issued
>the proposal, affirm it in a Public Forum.
>
>D. Destruction of Pools
>
>If at any time a Pool has fewer than two members, or more than two-thirds
>of
>all players are members, the Pool is immediately dissolved, and it and all
>Pooled Proposals, WOEs, and RFA's associated with it cease to exist.
>
>}}
>
>--
>Wonko

Okay...I gave it some more thought, and I think we're trying to accomplish the same thing here.  You want there to be a means to pool bandwidth without it being tied to the proposal process, because you see the proposal process as having the means to damage the ruleset and gamestate.  I thought I'd achieved it with charter props by isolating them from actual proposals and the power they contain, but you want to make sure accidents don't happen.

The only problem I have with this is that, hypothetically speaking, if there was someone like, oh, I don't know, you, who, for whatever reason, perhaps because, just off the top of my head, you were closer to winning than I was and I didn't want you to have that much more of an advantage if I could help it, I wanted to be able to do something to prevent you from setting up an organization with proposal-making capability.  Perhaps, dare I say, everyone but you and your potential draftee felt this way, and therefore would vote against the formation of the organization if they were able to do so.

This is where I'm coming from.  Yes, it's another tax-the-rich scheme, which may in fact be used against me some day.  Personally I feel games are supposed to get harder as one is more successful in them.  So if, for some reason, most of the players would like to keep a particular player, or a particular group of players, from pooling resources, I think there should be a mechanism available, even if it's not an easy one to use.

Aside from that...

I'd like to see Bandwidth Pools made an object under the Society class, to keep Societies relatively consolidated, and because there's mechanisms in place for Societies to submit proposals.  This'll just be a means of setting up a Society without a proposal.

I think they should be called Proposal Pools rather than Bandwidth Pools, because bandwidth isn't the only thing the members are sharing.  Some of those other things are missing from your Bandwidth Pools.

I'd like to see the means of joining and ousting, plus whatever other internal rules desired, as a lower-down layer, either being able to specify them all at once and establishing a charter, or setting up subclasses of Proposal Pools that can be used to create multiple customized Societies.

Do you really want to go through with this now?  Or perhaps split the points on a class-structured Society def?  Another Less-is-More attempt.

						Glotmorf