Ruleset 7

From BlogNomic Wiki
Jump to navigation Jump to search
Note: This is an archive.org copy of the ruleset from 1 October 2003, eleven days before the dynasty actually ended.

Ruleset and Gamestate

This is the Ruleset for BlogNomic; all Robots must obey it.

Any information which the Ruleset allows the creation or alteration of (such as Power, or the blog colour scheme) is considered to be part of the Gamestate.

The Ruleset and Gamestate can only be changed when a Rule specifically permits their being changed.

Admin Staff may correct obvious spelling and typographical mistakes in the Ruleset at any time, obvious typos can also be corrected in proposals at the request of the initial proposer. Undesired corrections may be challenged through a Call for Judgment.

Robots

Anybody may apply to join BlogNomic by contacting any of the Admin Staff, specifying the name they wish to use in the game and the URL or email address they want their name to link to in the Robot roster. They will be signed up as a member of the BlogNomic weblog, and will be considered a Robot from the moment that they first appear on the Robot roster in the sidebar.

The Admin who sets up a new Robot receives 10 Power. Within 24 hours of joining the game, and only once, a Robot may nominate a single (other) Robot as being responsible for their joining - the nominated Robot gains 50 Power, and the new Robot gains 25 as a reward for nominating.

Some Robots are Admin Staff, responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Any Admin Staff may confer Admin status onto another Robot at any time, and update the sidebar appropriately.

A Robot may leave the game at any time by declaring this intention in an entry.

Some Robots are Deactivated, and should be marked as such in the sidebar. For the purposes of all other rules, Deactivated Robots are not counted as Robots. Admin may render a Robot Deactivated if that Robot has failed to vote for more than a week, or if its Power is zero, or if it has asked to become Deactivated. Admin may Reactivate a Robot who has asked to become Reactivated.

Proposals

Any Robot may propose a change to the Ruleset or gamestate, provided that Robot has fewer than two non-trivial Proposals pending, by posting an entry which begins with the paragraph "Proposal : [Title]" in bold text (where [Title] is a title of their choosing), and describes the changes they wish to make.

A Robot can state in his Proposal that the Proposal is Trivial. Trivial Proposals score Power as if they were declared Trivial in voting. A Robot can submit any number of Trivial proposals at a time.

Proposals can either be Pending, Enacted, Failed or Expired. When a Proposal is first put forward, it is considered Pending.

Voting

Any Robot may cast their vote on a Pending Proposal by declaring it in the comments of the entry. Valid votes are FOR, AGAINST, and DEFERENTIAL, which may be represented by appropriate icons.

A vote of DEFERENTIAL is a vote of no opinion, or of faith in the decision of the Control Unit. The vote will count as the same as the Control Unit's vote. The Control Unit cannot cast a vote of DEFERENTIAL.

FOR Votes may be marked as 'Trivial' if the voter considers the Proposal to be of minor effect, or to make amendments already discussed by other Robots, or to be otherwise unworthy of reward.

If there exists more than one Vote from a single Robot on a single Proposal, only the most recent of those Votes is counted.

If the Robot who made a Proposal has not cast an explicit Vote on it, their Vote is counted as FOR.

Enactment

Quorum is equal to half the number of Robots, rounded down, plus one.

If the oldest pending Proposal's FOR votes exceed or equal Quorum, then any Admin Staff may update the Ruleset and/or Gamestate to include the specified effects of that Proposal, and mark that Proposal as Enacted.

If the oldest pending Proposal has enough AGAINST votes that it could not be Enacted without one of them being changed, or if all Robots have voted on it and it still cannot be Enacted, or if the Robot who proposed it has voted AGAINST it, then any Admin Staff may mark that Proposal as Failed.

For the purposes of the Enactment or Failure of a proposal, only Votes cast by current Robots are counted.

When a Proposal is enacted, its proposer (if a current Robot) gains 10 Power plus 1 Power for each efficiency point they possess (or 2 Power, if most of that Proposal's FOR votes were marked Trivial). When a Proposal fails, its proposer loses 5 Power.

Whenever an Admin Enacts a non-Trivial Proposal, they may claim 5 Power. Whenever they Fail a Proposal or Enact a Trivial Proposal, they may claim 2 Power.

Calls for Judgment

If two or more Robots actively disagree as to the interpretation of the Ruleset, any Robot may raise a Call for Judgment by posting an entry which begins with the paragraph "Call for Judgment" in bold text, and goes on to describe the disagreement, and measures that should be taken to correct it.

All Robots may add votes of agreement or disagreement in comments to this entry, using appropriate voting icons. If more than half of the Robots' votes (their later votes overriding their earlier) are in favour, the Gamestate and Ruleset should be amended as was specified. If more than half disagree, the CFJ fails and may have no further effect.

Time Out

If a proposal has been pending for longer than 48 hours, an admin may enact it if greater than half of the current votes on it are FOR; otherwise, he/she may fail it. If the Control Unit has not yet cast a vote, all DEFERENTIAL votes are ignored.

The GNDT

Specific parts of the Gamestate data shall be tracked by the Generic Nomic Data Tracker at http://kevan.org/generic?nomic=blog. Any Robot may update any Robot's data via the GNDT, whenever the Ruleset permits it.

All updates to the GNDT are logged - if a Robot feels that an alteration goes against the Rules (as they were at the time of the alteration), he or she may simply undo the effects of that alteration. If such an undoing is disputed, a Call for Judgment should be raised.

Robots shall be assigned a password for the GNDT when they join the Nomic.

Power

A Robot's Power rating is a measure of the electrical power remaining in its battery. Some game actions require expenditure of Power; if a Robot has insufficient Power for an action, it cannot perform it.

New Robots start with the highest Power rating amongst the active Robots. Returning Robots continue with the Power rating they had when they left.

Any Robot with a positive amount of Power may give any number of those Power to another Robot, provided it does not take the giving Robot below 0.

A Robot may award themselves five Power for the first entry they post to their weblog, for a given day (this Power must be claimed within 12 hours of the entry being posted).

Spare Parts

Robots can lose or break their component parts. They may purchase replacement parts with their hard-earned power. The component parts list and their corresponding power prices are as follows:

  • AI -- 50 PU
  • Motherboard -- 40 PU
  • Memory Unit -- 45 PU
  • Motary Equipment (i.e. legs, arms) -- 10 PU
  • Sensory Equipment (i.e. optical, olfactory) -- 20 PU

The Master Control Program

Each Robot has an identical copy of the Master Control Program installed, and may run it no more than once per day. Upon running the MCP, the Robot should process each of its lines in sequence, until it reaches the end.

The Master Control Program is written in a vague and dynamic language resembling simple English, but uses a few specific terms:-

  • self. "self" represents the Robot calling the program; any gamestate data that applies to a Robot may be measured or altered.
  • if. If statements depend on a specific condition - if that condition is true, the bracketed statements immediately following the "if" are processed. If it is false, the bracketed statements are skipped.
  • loop (robots). The bracketed statements immediately following this statement should be processed once for each Robot (in alphabetical order). Within the loop, "loop_robot" represents the Robot being processed during that loop cycle.
  • keyword. When a Robot calls the MCP, it may optionally include a single keyword of its choice (eg. "PRODUCT").
  • other. "other" represents any other Robot in the Factory; the Robot calling the MCP should choose a single Robot at the start of the program.
  • //. Lines beginning "//" are comments, and have no effect.

Where there is any disagreement over the execution of the MCP, the Control Unit may settle the matter and modify the source code to remove any ambiguity.

Master Control Program Source Code

// Master Control Program 

// Create a single item of Product
if (efficiency(self) > 3)
{
  X=10
}

if (efficiency(self) < 4)
{
  X=15
}

if (power(self) > 50 && keyword = "PRODUCT")
{ 
  power(self) = power(self)-X; 
  inventory(self) = inventory(self) + product_object
}


// Create a supplementary battery.


if (power(self)>50 && keyword = "BATTERY") 
{ 
  power(self) = power(self)-50; 
  inventory(self) = inventory(self) + battery_object 
}

// Check to see if the Robot running the program is the Control Unit. 
if (self = the_control_unit && keyword ="RECHARGE")
{ 
  // Loop through the robots and add 50 to all Power ratings. 
  loop (robots) 
  { 
    power(loop_robot) = power(loop_robot) + 50; 
  } 
} 

// Robots may hand off Product to other Robots to increase their efficiency.
if (keyword = "HANDOFF" && inventory(self) contains product_object) 
{ 
  inventory(self) = inventory(self) - product_object
  inventory(other) = inventory(other) + product_object
  efficiency(self) = efficiency(self) + 1
}

// Vent excess power. 
if (power(self) > (100*(1+number_of_batteries(self))))
{ 
  power(self) = (100*(1+number_of_batteries(self))); 
}

Inventory

Each Robot has a hollow casing which they can store items inside; this Inventory is tracked as a single GNDT text field (eg. "3 Product, 1 Box, 2 Fuel").

Virus!

The Ruleset has been infected with a corrupting virus! At some point each Monday, the Control Unit must select a random rule, then select a random number within that rule (if any are there). That number has a 50% chance of being halved (rounding up); if it is not halved, it is doubled.

Malfunction

Should the Control Unit's liquid power fall below that of the liquid power of the Robot that has the least quantity of liquid power then the control unit shall short circuit and the Robot with the highest quantity of liquid power shall become the new Control Unit.

Dynasties

BlogNomic is divided into a number of Rounds, referred to as Dynasties.

Each Dynasty has a single Control Unit or Empress (the two terms may be used interchangeably, although the Ruleset may be updated to reflect the gender of the new leader, at the dawn of a new Dynasty), and is named according to the number of times which that Robot has been Control Unit (eg. "The First Dynasty of Myke").

Robots other than the Control Unit are known as Subjects.

The Control Unit may veto any Proposal, provided that there is at least one Robot voting AGAINST a given proposal. A vetoed Proposal immediately fails.

However, a veto may be overturned if a request for veto annulment is declared. Requests for veto annulment may not be vetoed by the Control Unit; as they aren't traditional, rule changing propositions.

If the consensus on the request for veto annulment results in a FOR count of two-thirds of active robots or greater, one strike is placed upon the Control Unit. If three such requests are successfully put forth in one dynasty, the Control Unit will be removed and nominations for a new Control Unit may be posted.

Imperial efficiency is a numerical rating that reflects the current Control Unit's view of an individual Subject. The Control Unit may update any Subject's "Imperial efficiency" rating, at his or her whim. Values may range from negative six (-6) to positive six (+6). (The Control Unit's Imperial efficiency is always +6.)

Ascension

At the beginning of each Dynasty, each Robot's (including Deactivated Robots') GNDT stats are reset to zero or blank. Any Robots who were Deactivated throughout the previous Dynasty are removed from the game. They may rejoin as a new Robot at any point.

The Control Unit is then awarded an initial sum of 50 Power, and any Admin may update the BlogNomic header to reflect the title of the new Dynasty. The new Control Unit may perform the following actions within the first three days of their Dynasty:-

  • They may post an Ascension Address to the BlogNomic blog. (These addresses will be linked historically from the sidebar.)
  • They may change the BlogNomic header and color scheme to reflect their new Dynasty.
  • Create a new Imperial Seal for use in the header and as the graphic for an Imperial Veto.
  • Repeal any number of Rules (excluding Rules 1-8 and the Glossary) by proclamation.

Glossary

This Rule is always at the end of the Ruleset. Its only effect can be to clarify ambiguity. When a Call for Judgement is resolved, any Admin may make an appropriate addition or alteration to this rule based on the result of the Call for Judgment.

  • The terms "weblog", "blog" or "journal" shall be taken to mean "weblog or journal" throughout the Ruleset.
  • For the purposes of the game, a Robot's weblog is the one that their name links to in the Robot roster (if it doesn't link to a weblog, they are considered to have no weblog).
  • References to "a day" (as an entity rather than a duration, eg. "Sunday") refer to that day in the timezone to which the Robot's blog conforms, if blog-related; otherwise to the timezone of the BlogNomic blog.
  • References to a "week" refer to the period of time between the start of a Monday and the end of the following Sunday.
  • Any Rules based on the text of a blog entry refer only to the always-visible and non-automated text, ie. excluding mouseover text, datestamps, comment links and similar constructions.
  • It is noted that where a Proposal would amend the effects of Proposal Enactment, this does not apply to its own enactment unless explicitly stated (eg. a proposal proposing that enacted proposals earn their writer a banana when enacted would not earn a banana for its own writer, when enacted).
  • Appropriate Icons: For use in voting, a check box shall represent a vote FOR, an X shall represent a vote AGAINST, an I shall represent a vote of DEFERENTIAL, and an Imperial Seal (currently ) shall represent the Imperial Veto.
  • When the game refers to the "subject" of a blog entry, blogs which do not normally support subject lines shall have the first sentence of an entry treated as that entry's subject.
  • Liquid Power - Liquid power is the total power a robot would have if their entire assets were liquidated at the same value at which they were originally produced plus the power they already have stored away as noted by the GNDT.
Retrieved from "https://wiki.blognomic.com/index.php?title=Ruleset_7&oldid=15752"