https://web.archive.org/web/20070719031140/http://b.nomic.net/index.php/Rules
For the purposes of this rule, the term "Potential Emergency Participant" (or PEP) shall mean each of the current players of the game as defined by other rules. However, if who the current players are in the game is unclear, uncertain, or ambiguous, or if there are less than four such players, then it shall instead mean who the players were before such uncertainty or drop in player count.
Each PEP has in eir possession a Game Object called a Panic Button. If a PEP does not have such an object, a Panic Button is created and given to em. If a PEP has more than one Panic Button, all except one are destroyed. If an Object that is not a PEP has a Panic Button, eir Panic Button is destroyed.
Each Panic Button has a state of being Off or On. All Panic Buttons are initially Off.
A PEP may post a message to a Public Forum or any forum that within the past month was a Public Forum stating that e is Hitting eir Panic Button. If e does so, eir Panic Button becomes On.
A PEP may post a message to a Public Forum or any forum that within the past month was a Public Forum stating that e is Stopping eir Panic Button. If e does so, eir Panic Button becomes Off.
If there exist at least four Panic Buttons which are On, B Nomic becomes in a State Of Emergency. When this occurs, the following Procedure happens:
- Game time is stopped. Whatever means used in the Game to track time is stopped as of the beginning of the Emergency. Pending events and deadlines relative to Game time, with the exception of those specified in this rule, are postponed until Game time resumes. Pending events and deadlines with absolute dates and times do not occur.
- The PEP who most recently held the Minister of Ministries becomes the Emergency Coordinator. If this Emergency Coordinator does not exist, or it is unclear which PEP it is, or if the Administrator does not possess the Active property, then the PEP that first attempts to organize running this Procedure becomes the Emergency Coordinator.
- The Emergency Coordinator designates a means for PEPs to communicate as the Emergency Forum and makes a reasonable effort to notify other PEPs about the Forum's existence.
- The Emergency Coordinator makes a statement to the Emergency Forum that e is initializing the Pause. The Procedure tracks time spent using the Pause. When the Emergency Coordinator initializes the Pause it is zero. Thereafter, until the completion of the Procedure, the Pause is increased by one each day at 00:00:00 UTC.
- Refresh Proposals are submitted. The Forum will be used to submit, discuss, select and implement proposed changes to the state of the Game (hereafter in this rule known as "Refresh Proposals") for the purpose of either resuming or ending the Game. PEPs and the Emergency Coordinator may each submit a Refresh Proposal. A Refresh Proposal consists of a list of changes to the game which may affect any aspect of the Game or the state of the Game, including, but not limited to: rules, scores or other player attributes, the valid list of players, current holders of any Ministries, the legitimacy and/or actuality of any action taken in the context of the Game, etc.
- A first-round Ballot is formed. When the value of the Pause is 5, the Emergency Coordinator will gather all submitted Refresh Proposals into a Ballot on which PEPs will vote.
- First-round votes are cast. Each PEP casts a single vote to select one of the Refresh Proposals in the Ballot. Votes are cast by announcing them via the Forum.
- When the value of the Pause is 7, first-round votes are counted. The Emergency Coordinator will count all the submitted votes and announce to the Forum which Refresh Proposal received the largest number of votes. If only one Refresh Proposal received the largest number of votes, it is selected and the Procedure skips to step 12; otherwise the Procedure continues to Step 9.
- A second-round Ballot is formed. Refresh Proposals that tied for the largest number of votes received in the prior Ballot will be gathered into a second Ballot on which players will vote.
- Second-round votes are cast. Each PEP casts a single vote to select one of the Refresh Proposals in the second Ballot. Votes are cast by announcing them via the Forum.
- When the value of the Pause is 9, second-round votes are counted. The Emergency Coordinator will count all the submitted votes and announce to the Forum which Refresh Proposal in the second Ballot received the largest number of votes. If only one Refresh Proposal received the largest number of votes, it is selected; otherwise the Emergency Coordinator selects one of the Refresh Proposals.
- All changes listed in the selected Refresh Proposal occur, implemented by the Emergency Coordinator as needed. All Panic Buttons become Off. If at any point during the procedure, there are less than four Panic Buttons On, the procedure stops and B Nomic stops being in a State of Emergency, and normal Game time resumes.
The name of this game is B Nomic.
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.
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 had never started existing.
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.]]
A Player is an Outsider who consents to be governed by the rules, fulfills all requirements for continued playerhood specified by the rules, and has become a Player in a manner specified by the rules. An External Force may become a Player by posting a message to a Public Forum containing a request to become a Player and a uniquely identifying name that e wishes to be known by. E may do this if and only if e fulfills the following requirements:
- E is capable of passing a Membership Test, although E may not be required to take said test
- E is not currently a Player
- E has a working e-mail address
A Player may cease to be a Player by Forfeiting the game; this must be done in a Public Forum unless there are no working public fora, in which case e may notify the Player e most recently knew was Registrar privately instead.
No restrictions may be placed on when a player may forfeit; any player may forfeit the game at any time (regardless of any timekeeping device used in the game).
Player names must consist of between 1 and 64 characters from the following list:
- Letters of the alphabet
- Underscores (_), dashes (-), or apostrophes (')
- Decimal digits
- Spaces
For the purposes of identifying players, and determining uniqueness of names, the following conventions are to be used:
- Uppercase letters are to be considered equivalent to their lowercase counterparts, and vice-versa.
- Sequences of one or more consecutive spaces are to be considered identical.
- Leading or trailing sequences of spaces may be disregarded or introduced.
Where a player's name might be ambiguous with other grammatical forms, it may be surrounded by double quote characters (") to differentiate it from surrounding text.
A player may change eir name at any time, unless otherwise prohibited, by posting a message to a Public Forum, stating eir intent to do so, and clearly stating both eir "old" and "new" names. Such name changes take effect upon recognition by the Registrar.
The Registrar may refuse to allow any External Force to become a player, and may refuse to recognize any otherwise-legal name change, if e believes the External Force's proposed name (or existing player's new name) would be ambiguous or confusing, or could otherwise damage the integrity of this game. The Registrar is encouraged, but not required, to state the reason for such refusal.
In each Game Document, with the exception of this paragraph, text between a forward slash+asterisk character combination and an asterisk+forward slash character combination or between double square brackets (that is, text between "/" and "/" or between "[[" and "]]") shall be deemed Comment Text. Comment Text has no direct effect on the state of the game, although it can be read.
Rules are Game Documents that define how this game is played. Each Rule may have a Name and a Number. Rules may be contained in Sections, which may each have a Name and a Number.
The Rulekeeper may, as a Game Action, do any of the following:
- Add, change, or remove a Rule's Number.
- Create a Section.
- Add, change, or remove a Section's Number or Name.
- Remove a Section, causing all Rules in that section to no longer be contained by a Section.
- Move a Rule into a Section.
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.
A Game Action is defined as any activity specified by the rules to be a Game Action. Other Outsiders may also take Game Actions if explicitly permitted by the rules. To perform a Game Action, an Outsider must post a message to a Public Forum specifying that e is taking that action. E must also specify any targets and/or parameters necessary for that action [[for example, you must specify a proposal in order to vote against a proposal]]. E may list multiple actions that e wishes to take, in which case e takes them in the order e lists them. E may also state a specific positive integer to perform a particular action that many times (if legal, of course) sequentially. The Rules also have the power to cause an Outsider to take Game Actions whether e posts or not.
Game Actions occur upon reaching the appropriate fora, in the order they arrived, unless a rule states otherwise. A Game Action that is caused by a Rule instead of by a Forum Post takes place at the time specified by the rule. Text to the effect that "any player may do X" should be interpreted to mean that X is a Game Action; but such a declaration implies that only players may take the Game Action X (unless another declaration permits other Outsiders to as well).
The rules may state that it is legal for Outsiders to Submit certain document types as a Game Action. To Submit a Game Document, an Outsider must provide a full description of the Document in the Public Forum message where they take the Action of Submitting.
The First Era of B Nomic is the time starting with the creation of the game and ending immediately before the start of The Second Era of B Nomic.
The Second Era of B Nomic is the time starting with nweek 85 and ending immediately before the start of The Third Era of B Nomic.
The Third Era of B Nomic is the time starting with nweek 112.
Any Game Object may possess a non-negative, finite, number of Properties. A Property is described by a unique string of alphanumeric characters. Properties may only be granted or removed as described in the rules, or by proposal.
An Attribute is a game object, defined in the rules. Each Attribute has a Scope, a Range, and a Default Value. The Scope is a set of Game Objects to which the Attribute applies. The Range is the set of possible values for the Attribute. The Default Value is an element of the Range.
Each element of the Scope of an Attribute possesses an Instance of that Attribute. If the element in question does not possess such an Instance, one is created immediately. If a Game Object outside the Scope of an Attribute possesses an Instance of that Attribute, the Instance in question is destroyed immediately.
Instances of an Attribute are Game Objects which have a Value. The Value of an Attribute must be a member of the Range of the Attribute. When created, the Value of an Instance is its Attribute's Default Value, unless otherwise specified.
For brevity, the value of an instance of an attribute of some object may be referred to as the value of that attribute on the object in question. The Scope, Range, and Default Value of Attributes are static and defined in the Rules. The Value of Instances of Attributes can be changed only as specified in the Rules.
If a game action is not explicitly permitted in the rules, the game prohibits it.
As a Game Action, an Outsider can submit a Transaction. A Transaction consists of:
- A clear statement marking the Start of the Transaction, such as "BEGIN TRANSACTION".
- A list of Game Actions and assertions about the state of the game.
- A clear statement marking the End of the Transaction, such as "END TRANSACTION".
The list is considered in sequence. If it would be legal for the Outsider to take each Game Action within the Transaction exactly as specified, and each assertion would be true at the time it occurs within the list if the Game Actions were so taken, then the Transaction is said to Succeed. Otherwise, the Transaction is said to Fail. If it cannot be determined with finality and certainty whether or not a Transaction Succeeds, then the Transaction Fails.
The Game Actions in a Transaction that Succeeds occur just as though the Outsider had taken them individually. A Transaction that Fails has no effect.
A Membership Test shall consist of any or all of the following:
- Proof of uniqueness from all other known sentient beings [[Whether this is a physical difference, such as fingerprints on a human, or a different set of experiences, such as an Artificially Intelligent computer might possess, is up to the being wishing to become a member. However, a name alone is not enough to prove uniqueness.]]
- Refer to one's self in the first person singular without being awkward [[ I.E., "I think, therefore I am" rather than "We think, therefore we am" or "I am The World, I am The Children"]]
- Send, and receive a reply to, an email to another entity
- Be capable of thought as an individual. [[I.E. No Borg or Group consciousnesses.]]
There is a Game Object known as The Clock. The Clock consists of the following values:
- A positive integer known as the nweek
- A positive integer known as the nday
- A state of being Off or On
- A nonnegative integer known as the ndelay
At midnight (00:00:00) Coordinated Universal Time (UTC), if the Clock is On, then the nday is incremented by 1. Otherwise, the ndelay is incremented by 1. [[An online UTC clock is available at http://www.time.gov/.]]
If the nday would be set to a value greater than 12, instead it is set to 1, the nweek is incremented by 1, and the Clock becomes Off.
The Clock may be changed from On to Off as a Game Action by the MoM.
If there are no Vacant Ministries, the Clock may be changed from Off to On as a Game Action by the MoM. When the Clock is turned On, the ndelay is set to zero.
Each time that the Clock nday value changes a new nday begins. /* the previous nday ends in the moment immediately before the Clock change */ A period of one nday is the time intervening between two consecutive changes of the Clock nday value. Each time that the Clock nweek value changes a new nweek begins. /* the previous nweek ends in the moment immediately before the Clock change */ A period of one nweek is the time intervening between two consecutive changes of the Clock nweek value.
When the clock turns off, and each time that the Clock ndelay value changes to a value different from 0 a new ndelay begins. When the clock turns on, the current ndelay immediately ends. While the clock is off a period of one ndelay is the time intervening between two consecutive changes of the Clock ndelay value.
A duration to the effect of "X ndays", where X is a number, shall be interpreted to mean that the duration ends at the end of the nday after X consecutive changes of that value. [[Thus, if it is currently the middle of nday 2, something happening "in 2 ndays" will occur at the end of nday 4.]]
A duration to the effect of "X ndelays", where X is a number, shall be interpreted to mean that the duration ends at the end of the ndelay after X consecutive changes of that value. The resetting of an ndelay to 0 from the Clock being turned On does not count as a change for the purposes of this paragraph.
A duration to the effect of "X nweeks", where X is a number, shall be interpreted to mean that the duration ends at the end of the nday when the nday is the same value, but the nweek is increased by X.
A period of 10 nweeks is known as an nyear. Hence, the first 10 nweeks (1-10 on the Clock) comprise nyear 1, the second (11-20 on the Clock) comprise nyear 2, and so on.
All events occurring at the end of an nday occur before all events occurring at the beginning of the next nday.
Proposals are Game Documents. Each proposal has the following properties:
- 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 Chairman and the justice system. */
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, and is said to own that proposal.
When a new proposal is submitted, it is assigned the Status Pending, the Success state Undecided, and the Proposal Number null. The Chairman 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. */
As a Game Action a Player may withdraw a proposal with status Pending if they are the Author of that Proposal. A Proposal that is withdrawn has its Status set to Historical and its Success state set to Lost.
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 Open.
A Registered Voter is an Outsider that is allowed to vote on Proposals. There is an Attribute Vote Power with a Scope of Registered Voters, a Range of the nonnegative integers, and a Default Value of 0.
A Registered Voter 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 Registered Voter is called that Registered Voter's Final Vote on that proposal.
A proposal's Strength is equal to the sum of the Vote Power of the Registered Voters whose Final Vote on that proposal is FOR minus the sum of the Vote Power of the Registered Voters 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 gamestate occur.
Proposals that do not Pass are said to have Failed.
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.
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.
An Oracularity is a special type of Proposal. It may only be submitted by a Priest in the performance of eir duties. If there are limits on the submission of Proposals, Oracularities are exempt from, and do not count towards, such limits.
Trophies are Game Objects. The number of Trophies held by a player is known as that player's Win Count. Players may only receive Trophies in accordance with this rule. Each Trophy has a description, which is a block of text describing what the Trophy looks like.
Victory Conditions are Game Documents.
Each Victory Condition has four parts:
- A Trigger: The event that must happen to cause someone to win, plus any required conditions on the gamestate.
- Victors: A clause defining which player(s) win.
- A Cleanup: A set of gamestate changes that happen when this condition takes effect (presumably that make it so that the condition is no longer satisfied).
- A Prize: A description of the Trophy that is awarded to each Victor.
If the events in a Victory Condition's Trigger happen, then that Condition becomes Fulfilled, unless it already was. When a condition becomes Fulfilled, its Victors are each awarded a Trophy with the description given by its Prize, and then its Cleanup happens.
At the end of each nweek, every Fulfilled Victory Condition ceases to be Fulfilled.
/* In other words, you can't win the same way twice in an nweek. */
Any Game Object may have points. Points are Game Objects. The number of points an object possesses may also be referred to as that object's "score." An object's score cannot be less than zero.
There exists an Object called the staff of ZOT. The Oracle holds the staff of ZOT.
Any player may as a Game Action submit a Consultation.
Consultations are Game Documents that contain a Question that is to be Answered. The Question must be posed in such a form as to permit a yes or no reply. Consultations may also contain:
- Reasoning, meaning text that clarifies the intent of the Consultation.
- the name of a Player that is to be considered as the Unbeliever for that Consultation.
That player submitting the consultation will be known as Supplicant regarding that consultation.
Consultations automatically gain a Consultation Number upon submission. For each new Consultation, the Consultation number shall be equal to 1 or, if such Number is already in use, to the greatest existing Consultation Number incremented by one. The Oracle may arbitrarily override the normal assignment of Consultation numbers, and choose a number of his liking for a new Consultation.
A Consultation is in one of the states of Waiting, ZOTTED and Pondered. A Consultation is initially Waiting.
Upon submission of an Consultation the Oracle shall as a Game Action select a Priest for that Consultation. Alternatively the Oracle may wield the staff of ZOT and cause the Consultation to be ZOTTED, if in eir insight e considers the contained Question to be malformed, ambiguous, irrelevant or otherwise unworthy. ZOTTED consultations have no further effect.
The Oracle may also ZOT a Waiting Consultation if has not been Answered yet and its assigned Priest requests em to do so. In this case the Oracle is required to grant the request or immediately reassign the Consultation to a new Priest instead.
whenever a Priest is to be selected for a Consultation, the Oracle shall select one between the eligible Players. All Active Players, except the Supplicant, the Unbeliever if the Consultation names one, the Oracle and Players that have already been selected as Priests for that Consultation, are eligible for selection as Priests. If no Player is eligible, the Oracle is automatically selected as Priest.
The selected Priest shall find inspiration in eir knowledge of the Rules and, as a Game Action, Answer eir assigned Consultation YES or NO. The Priest may also submit his own Reasoning, explaining how eir mystical interpretation of the Rules has guided em in eir Answer. If e deems it necessary the Priest may also submit as a game action an Oracularity detailing changes needed to correct the state of the game.
At the beginning of the fourth nday (or ndelay if the clock is off) after the Answer has been submitted to a public forum, the state of the Consultation becomes Pondered.
For the purposes of answering Consultations the words "True", "Affirmative" and "Correct" are to be considered synonymous with "Yes", and the words "False", "Negative" and "Incorrect" are to be considered synonymous with "No".
Pondered Consultations shall guide further interpretation of the Rules.
At the beginning of each nweek, if a Consultation is Waiting and has not been Answered the Oracle shall select a new Priest for that Consultation. In the event that the clock is off, every 10 ndelays all Waiting Consultations that have not been Answered yet are reassigned to a new Priest.
When a Priest submits eir Answer to a Consultation, within three ndays (or ndelays if the clock is off) since its submission, any player except the Defendant and the Supplicant may, as a Game Action, make a Claim as to the Answer's Consistency with established doctrine. Such Claims will ultimately state that the player believes the answer to be Consistent or Inconsistent.
If a Player submits multiple Claims, only the last one submitted shall be counted. At the end of the third nday (or ndelay) since the Answer has been submitted the Oracle shall tally any such Claims. If a Quorum of Players has submitted Claims, and there exist more Claims of Inconsistency than claims of Consistency, the Oracle shall reverse the Answer for that Consultation [[that is if it was YES it becomes NO and vice versa]].
Whenever a Proposal becomes Historical,
- Each Player whose Final Vote on the Proposal was not ABSTAIN gains 1 point.
- If the Proposal Passed, its Author gains 1 point for each Player whose Final Vote on the proposal was FOR.
- If the Proposal was ever Won, its Author gains 1 point for each Player whose Final Vote on the proposal was FOR.
- If the Proposal Failed and was never Won, and at least 3 other proposals with the same Author have previously Failed and were never Won in the same nweek, then its Author loses 3 points.
All Players are Registered Voters.
At the beginning of Ballotday, each Player who Gave eir Allegiance to a Faction during that nweek has eir Vote Power set to 0. All other players have their Vote Power set to 1.
No rule or game action may require or force any retroactive changes to the game state. It is, however, permissible, to create rules or perform otherwise-legal game actions that simulate retroactive changes to the game state.
No text in any Rule shall be interpreted as a specific Player's name, unless that rule explicitly states that said text shall be interpreted as a specific Player's name.
The group of players that currently possess the Active property may be called the Active Players. At the beginning of each nweek, the players that voted in the previous nweek gain the "Active" property, the players that failed to vote in the previous nweek lose the "Active" property.
A Quorum is defined to be any number greater than half the number of Active Players.
For all game purposes the following phrases are defined to mean the indicated numbers.
- A Few = 4
- A Handful = 6
- An nDozen = 11
- A Thirnight = 12
- A Confused Baker's Dozen = 14
- A Bunch = 24
- A Metric Bunch = 25
- A Lot = 63
- A Bucketful = 96
- A Metric Bucketful = 100
- A Heck of a Lot = 365
- A Hell of a Lot = 366
- A Truckload = 960
- A Metric Truckload = 1000
- A Zillion = 100 000 000
- A Bajillion = 100 000 000 000 000
- An Insane Number = The number of players in the game
the ndays of the nweek have the following names:
- nday 1 = Breakday
- nday 2 = Winday
- nday 3 = Mulberry
- nday 4 = Tango
- nday 5 = Corvette
- nday 6 = Halfday
- nday 7 = Joel
- nday 8 = Rushnight
- nday 9 = Ballotday
- nday 10 = Teucer
- nday 11 = Zarpint
- nday 12 = Thirnight
- nday 13 = Armageddon
If the Rules contain errors of spelling, inconsistent capitalization, or other trivial errors, any Player may as a Game Action correct these errors by posting a Tidiness List on a public forum.
A Tidiness List is a Game Document that lists spelling errors in the rules, and the proposed corrections. The corrections contained in a Tidiness List do not take place immediately, but happen five ndays after the Tidiness List was submitted, unless in this period of time a player Objects to the Tidiness List.
Any player may as a Game Action Object to a Tidiness List, in this case the Tidiness List is discarded, and has no effect.
/* for practical purposes it is allowed to actually go on and make the changes to the wiki at the same time as posting the Tidiness List, but please mark your changes clearly so that they may be reverted easily */
If the corrections in a Tidiness List take place the Player that submitted the Tidiness List gains one point for every three errors corrected. Tidiness Lists correcting less than three errors give no points.
A "currency owning object", or COO, is a type of game object that can own currency (also called "money"). All players are currency owning objects.
The rule or rules defining a new currency will define an attribute the scope of which is all COOs. The value of this attribute shows how much of that currency the COO has.
A COO can give currency to another COO by a game action, as follows: ey specifies an amount (which cannot be greater than the value of eir currency attribute) and a currency; eir currency attribute for that currency goes down by the amount; the recieving COO's currency attribute for that currency goes up by the amount.
If the COO has a non-positive currency attribute for a given currency, then he cannot give that currency to another COO. If for any reason the receiving COOs currency attribute cannot go up, or the giving COOs currency attribute cannot go down, then nothing happens.
Players can, via game action, exchange points for currency. The rule or rules defining the currency will set the exchange rate. The player declares how many points ey wishes to exchange (which cannot be less than 0 or more points than ey has) and the currency ey wishes to recieve. Ey loses that many points and gains (exchange rate x points) in the currency. If for any reason the amount of eir points cannot go down or the amount of eir chosen currency cannot go up, then nothing happens.
The default currency of this game is mackerel. This can be shortened to a lowercase m. [[See below.]]
There is an attribute "mackerel": scope is all currency owning objects; range is decimal numbers; default value is 50. The value of this attribute should always be expressed starting with a lowercase m, for example, m50 or m10.15.
The points -> mackerel exchange rate is 5.0 - that is, 1 point may be exchanged for m5.
A "device" is a type of game object.
A "device owner object", or DOO, is a type of game object that may own devices. All players are device owner objects. There is an attribute "device owner": scope is all devices; range is all device owner objects. The default value is defined when the device is defined. The "owner" of any given device is the value of the device owner attribute of that device (that is, the owner is the DOO that the attribute points to).
A device is either "unique" or "non-unique". There cannot be more than one of each unique device in the game at any given time. When a non-unique device is defined, the definition must state how many such devices exist.
A device may have powers. Each power consists of an "effect" - what happens when the power is used; "conditions" - things that must be true for the effect to take place; and optionally a "trigger" - something that must happen to trigger the effect. The rule or rules defining a device detail the powers associated with it.
If there is any choice to be made about how a device is triggered or what objects it effects then the owner and only the owner of the device makes that decision; and must make it when it is triggered. The rules must explicitly state the nature of the choice. If there is any other ambiguity in the rules about how a power assigned to a device works, then that power has no effect.
The owner of a device may transfer ownership to another DOO. If the owner is a player, then this is done via a game action - the player declares who/what the new owner is. If the owner is not a player, then the rules must explicity state under what circumstances ownership changes and exactly what happens. In both cases the owner attribute changes to the new DOO.
Players have an attribute known as 'present'. Upon becoming a player, one automatically becomes present. A player may become present at any time by announcing their intent to do so on a public forum. Two nweeks after this rule is enacted, all players who are not present cease to be players, and this rule is repealed.
There is an attribute "element". Its scope is all RTOs; its range is the four values: "Earth", "Air", "Fire", "Water"; its default value is "Earth".
RTOs may change their element with an "element change" game action.
Only one element change game action can be made by an RTO in an nweek; subsequent such declarations in the same nweek will be ignored.
Element change game actions must be made before the end of nday 8. [[So that the rule tag moderator has a chance to do his thing.]]
[[DEFINITIONS]]
A "rule tag object" is a type of game object. It can be referred to as an "RTO". Each RTO has a unique name. All players have the property "Standing" and are RTOs.
There is an attribute "rule tag location". Its scope is all RTO's. Its range consists of the list of rule numbers, and the value "null". Its default value is null. The rule tag location may be referred to as the "RTL". The rule pointed to by an RTL may be referred to as the "RTL rule".
RTOs with an RTL of null cannot lose points as a result of rule tag actions or rule tag objects [[because they are not on the "game board"]].
[[GAME ACTIONS - GENERAL]]
A "rule tag action" is a game action which forms part of the game of rule tag.
All rule tag actions must be made before the end of nday 8. [[To give the rule tag moderator a chance.]]
All rule tag actions may be made by emailing the rule tag moderator with a subject line starting "[rule tag]". They may also be made by the normal method of declaring them on the public forum.
Each RTO may only make one rule tag action of each type in a single nweek. Only the last rule tag action ey makes of a given type in a given nweek shall be counted as having meaning in the rules.
The Rule Tag Moderator decides whether any given ruletag action is valid.
[[GAME ACTIONS - MOVE]]
RTOs may make a "rule tag move" action. This is a rule tag action [[obviously]]. Valid moves are as follows:
- (i) If eir current RTL is null, then ey may choose any rule number.
- (ii) Ey may choose the rule number of a rule that defines one of the game terms used in eir current RTL rule.
- (iii) Ey may choose the rule number of a rule that uses one of the game terms defined in the current RTL rule.
- (iv) Ey may choose null. [[But this costs you points, see below.]]
For the purposes of rule tag, a "game term" is a term used in the rules with one specific meaning within the game. A specific meaning can have more than one game term associated with it, but a game term can only have one specific meaning.
For the purposes of rule tag, a rule that defines a game term is a rule that explains what that specific meaning is. More than one rule can define a single game term.
As part of the rule tag move action, the RTO must clearly show eir current RTL, new RTL and the game term that links them.
[[GAME ACTIONS - GRAB/DROP]]
A Player may not make a rule tag grab in a rule tag turn if ey moved from RTL null in that rule tag turn.
An RTO may make a "rule tag grab" rule tag action on an RTO that is in the same RTL as it and without the property "Standing". This must include the name of the RTO ey wishes to grab and how many points ey wishes to spend. Ey may not declare more points than ey has. Ey may not declare less than 0 points.
If an RTO has been successfully grabbed by an RTO then it moves whenever the RTO moves, and to the same RTL. The RTO is said to be in "possession" of the RTO.
If the RTO has possession of an RTO then ey may make a "rule tag drop" rule tag action. Ey must name the object ey is dropping.
[[END OF TURN]]
At the end of the nweek, after passed proposals have been enacted into the rules, the rule tag moderator processes the end of the ruletag turn. Ey does the following, and in the order shown:
- "Move Actions": RTOs who made rule tag move actions have their RTL changed to their new location.
- "Drop Actions": RTOs who made rule tag drop actions are no longer in possession of the RTO that they dropped.
- "Basketball Resolve": If an RTO is in possession of the rule tag ball and in the same location as the rule tag goal, ey gains 25 points. Both objects are relocated randomly. [[See the rule "rule tag basketball".]]
- "Grab Actions": All rule tag grab actions are resolved. Firstly, any grab actions where the RTO and the RTO have different RTL's are declared invalid and play no more part in the game. Then, for each RTO in turn:
- (i) If the RTO is in possession, it is dropped, and nothing else happens to it this turn.
- (ii) Otherwise if there is only one grab action for the RTO, then the RTO making the grab action gains possession.
- (iii) Otherwise, if of all the RTOs who declared a grab action on this RTO, there is one RTO who declared more points than any other; and who has at least as many points as he declared; then that RTO gains possession and loses the number of points ey declared.
- (iv) Otherwise, nothing happens. [[So if two RTOs make a grab for the same, non-possessed RTO then the one that declared the most points gets the RTO and loses the points; and nothing happens to the other.]]
- "Elemental Tag Resolve": RTOs on the same (non-null) RTL as another RTO lose or gain points based on their elemental precedence. This works as follows: Earth beats Water; Water beats Fire; Fire beats Air; Air beats Earth; all other combinations are neutral. Whenever an RTO has a losing elemental precedence to another RTO then ey loses 15 points; these points go to the RTO with the winning elemental precedence. Where there are more than two RTOs on an RTL, each combination of RTOs is honoured. [[So given three RTOs with elements Earth, Air and Fire, on the same RTL: Air gives Fire 15 points; Earth gives Air 15 points.]]
- "Penalties": RTOs who moved to null this turn lose 10 points. RTOs whose RTL no longer points to a valid rule have their RTL set to null and lose 25 points. RTOs whose RTL points to a rule that has just changed lose 10 points.
[[MISCELANEOUS]]
Rule tag is a sub-game, if such a term has meaning in the Rules; but where this rule conflicts with any other rule regarding sub-games, then this rule takes precedence.
If an RTO is on a rule which is revoked, then the rule tag moderator changes its RTL to a random, non-null location.
The following game terms are not valid for use as game terms in the game of rule tag: "Object", "Game Object", "Player", "Action", Game Action".
The Rule Tag Moderator may also be known as "The Bearer of the Wobbly Hat of Justice," and has the following restrictions, responsibilities, and powers: Restrictions:
- The rule tag moderator may not make rule tag actions, except to rule tag move to null.
- Should the post holder ever have an RTL that is not null, ey must move to null as soon as possible.
Responsibilities:
- To post a notification to the public forum no earlier than nday 9 and no later than nday 2, showing:
- (i) valid rule tag actions made by each RTO.
- (ii) Each RTO's current RTL and element.
- To post a notification to the public forum no later than nday 2 showing:
- (i) The changes in score of each RTO due to rule tag.
- (ii) The location of each RTO and who, if anyone, is in possession of it.
- (iii) Any other rule tag specific changes of state.
- [[Note that (1) and (2) could be a single post.]]
Powers:
- The rule tag moderator is the arbiter as to who loses points and gains them as a result of the game of rule tag.
- The rule tag moderator is the arbiter of what constitutes a valid rule tag action and what the result of a rule tag action is.
- The rule tag moderator is the arbiter of any other game event or object solely regarding the sub-game of rule tag.
- The rule tag moderator does not pay points for moving to null. In the exectution of these powers ey must not break the Rules.
There is an RTO "rule tag ball".
There is an RTO "rule tag goal".
At the end of the ruletag turn, if a player is in possession of the ball and in the same RTL as the goal then the following things happen:
- The player in possession of the rule tag ball gains 25 points.
- Both the rule tag ball and the rule tag goal become no longer in possession of any player; they are relocated to two different (non-null) RTL's, chosen at random by the rule tag moderator.
A Pirate Rule is any rule that mentions Pirate Rules. Each Pirate Rule has a Pirate Rule Index, which is the number of occurrences of the string "Pirate Rule" in the text of the rule, including comments. /* For example, this comment increases the Pirate Rule Index of this rule by two, so that its Pirate Rule Index is seven */.
At the beginning of each nweek, Xd4 is rolled for each Pirate Rule containing a player, where X is the Pirate Rule Index of that rule. Each player on that Pirate Rule gains points equal to the value of the roll divided by the number of players on that rule, rounded down.
No player may move from null to any Pirate Rule.
No player may move to a Pirate Rule if the number of players occupying that Pirate Rule equals or exceeds that Pirate Rule's Pirate Rule Index.
An Agreement recognized by B Nomic is one that is between two or more External Forces called Parties that explicitly describes:
- The parties to the Agreement.
- How it is possible to change which parties are part of the agreement, if such changes are in fact possible.
- How any decisions that may need to be made on the agreement's behalf will be performed, including how and if any changes to the Agreement may occur.
In addition, an Agreement recognized by B Nomic must:
- Only have parties that have explicitly consented to being governed by the Agreement, and must allow any such party to leave the Agreement at any time.
- Have its Agreement publicly available in an easily accessible manner to all Players, such as on a web page.
While Agreements that do not comply with this rule may be recognized by other jurisdictions, B Nomic does not recognize them. However, an Agreement does not have to have been intended to comply with this rule in order to be considered recognized by B Nomic.
A Faction is an Agreement recognized by B Nomic that is a part of this game. An Agreement recognized by B Nomic may join the game as a Game Action if the following conditions are true:
- The Agreement is not already a Faction
- There exists at least one Player of B Nomic who is a party to the Agreement.
A Faction may cease to be a Faction at any time as a Game Action.
A Faction automatically ceases to be a Faction if any of the following events occur:
- The Faction ceases to be an Agreement recognized by B Nomic.
- The Faction ceases to have at least one Player of B Nomic as a party to the Agreement.
All Factions are Registered Voters.
At most once each nweek, between the start of Breakday and the end of Rushnight, a Player who is a party to a Faction may as a Game Action declare e is Giving eir Allegiance to that Faction. Doing so increases that Faction's Vote Power by 1.
At the beginning of each nweek, after Open proposals have become Historical, each Faction's Vote Power gets set to 75% of its prior value, rounded down to the integer closest to zero.
A Ministry is a Game Object that can be assigned to at most one Player. It represents the responsibility of that Player to keep Players aware of the state of a particular aspect of the game.
A Ministry that is not assigned to a player is Vacant.
The terms "post holder", "pot holster", "post holder designate", and "Minister" refer to the Player in possession of a given Ministry. This can be abbreviated "PHD".
A Player may, as a Game Action, assign a Vacant Ministry to emself.
A Minister may Resign from eir Ministry via Game Action. At that time, the Ministry becomes Vacant.
A Player may, as a Game Action, declare eir intent to Usurp a non-Vacant Ministry. Each time this happens, Players other than the current Minister of that Ministry have until the second time midnight UTC occurs afterward to Object to that action. If no player does so, at that time the Ministry is no longer assigned to the previous Minister and is assigned to the Usurper instead.
At the end of each nweek, each player who is a Minister gains 10 points. Then, all Ministries become Vacant.
A Public Display is a display of an aspect of the current state of the game in a form easily accessible to all Players. Good Public Displays can include the B Nomic Wiki or posting on a regular basis to a Public Forum.
The following Ministries exist:
- The Minister of Law, also known as the Rulekeeper, is responsible for maintaining a Public Display of the current Rules and Victory Conditions.
- The Minister of Change, also known as the Chairman, is responsible for maintaining a Public Display of the current Proposals, including whether they have passed or failed if applicable.
- The Minister of Questions, also known as the Oracle, is responsible for maintaining a Public Display of the current Consultations.
- The Minister of Society, also known as the Registrar, is responsible for maintaining a Public Display of the current Players and Factions and eir Attributes and Properties, as well as a Public Display of the current Public and Discussion Fora.
- The Minister of Rule Tag, also known as the Rule Tag Moderator, is responsible for maintaining a Public Display of the current Rule Tag Locations of all Rule Tag Objects
- The Minister of Ministries, also known as Kurt Gödel or the MoM, is responsible for maintaining a Public Display of the current Ministries and their Ministers, as well as maintaining a Public Display of the current state of the Clock. E is also responsible for tracking any state of the game that isn't covered by some other Ministry.