Daniel Lepage on Tue, 27 Nov 2007 06:59:44 +0100 (CET)


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

Re: [s-d] [s-b] BobTHJ's Refresh Proposal


On Nov 26, 2007, at 7:03 PM, Ed Murphy wrote:

> BobTHJ wrote:
>
>> In converse, a "permissible unless regulated" rule is far easier to
>> maintain. The rules define a way for points to be gained? Then points
>> are regulated and no player may arbitrarily gain them. Simple, no  
>> room
>> for ambiguity. The only arbitrary actions that can be taken are in
>> relation to objects which have no bearing on the ruleset, and
>> therefore no real effect upon the game.
>
> Agora explicitly addresses this by defining "regulated" to include
> anything that would alter data contained in (their equivalent of)
> a Public Display.

Is there game information that's not part of the public displays?

I claim that "permissible unless regulated" is an unneeded and  
powerless clause.

Subclaim 1: Actions inside the game are regulated.
Unless you've got lots of game data that isn't displayed publicly,  
"anything that would alter data contained in a Public Display" is the  
same as "anything that is part of the game". But this is true by the  
very nature of a game - the state of the game changes according to the  
rules, no matter what else may happen outside of the rules.

Subclaim 2: Actions outside the game are permitted.
This is trivially true: If an action is outside the game, then the  
game has no control over it. Someone mentioned earlier that the game  
never permits us to use email clients, or to get up in the morning,  
and so on. But we don't need the game's permission to do these things,  
because they're part of the real world and as such are beyond the  
game's ability to control.

These two together amount to the following claim, that is true in any  
game by definition:

Claim: An action that changes the state of the game can only be taken  
when the rules of the game explicitly allow it, and an action that  
does not change the state of the game can be taken regardless of  
whether the rules permit it.

This renders Permissibility of the Unprohibited completely unnecessary.

Note that this only holds because B Nomic is an entirely abstract  
game. In a game such as soccer, there's no notion of permission at all  
- any action is *possible*, including stealing the ball and driving  
away or shooting all the players on the other team. But since the B  
Nomic gamestate is entirely abstract, it can only be changed according  
to its own rules. Any message you send declaring actions that aren't  
in accordance with B Nomic's rules simply don't happen. In other  
words, "illegal" and "impossible" are synonymous in B Nomic, unlike in  
soccer.

Note that if we had a notion of "illegal" actions in the real world  
sense, that is, if some actions were possible but penalized, then a  
"Permissibility of the Unprohibited" clause would make sense, saying  
something like "No player can incur punishment for anything except  
those actions explicitly made illegal by the rules".

>> Now, your second point (that every disputed action creates two
>> possible quantum gamestates) is a very valid one, and one that must  
>> be
>> addressed to avoid future issues. Agora's solution (which I hate) is
>> to track every possible gamestate that could exist, and seems to lead
>> to massive revisions to the gamestate, or else a general consensus to
>> ignore the past. I have an idea of how to address this issue, and I
>> will add it to the revised version of my refresh proposal.
>
> More accurately, Agora has a formal process for setting the gamestate
> to what it would be if a specified (equivalent of a) Public Display
> was accurate when it was published, thus effectively ignoring any
> errors overlooked up to that point.  Some things with high potential
> for requiring tedious recalculation (mainly voting results and  
> currency
> reports) do this automatically, unless challenged within a week.

B Nomic once had a clause like this. It was lost in one of our  
numerous "simplifications". A couple people have talked about this as  
the "Third Era" of B Nomic, but to be honest, it's really more like  
the sixth or seventh. We've crashed the game a LOT.

Basically, every Minister was required to make periodic proclamations  
that his/her Public Displays were "up-to-date". One week after such a  
proclamation, it was retroactively made true unless anyone had  
objected to it. This was of course open to abuse by the Ministers, but  
it was better than our first version, which legalized

One thing I'd like to see is a "Reparation" option for CFIs (or RFJs,  
or whatever they're called right now) to allow these situations to be  
avoided. The Reparations would be simple changes to the gamestate to  
try and roughly approximate what would have happened if we'd been  
playing the correct way. For example, image this scenario:
  * A Device is created that costs mackerel and allows the holder to  
automatically fail a single Open proposal.
  * Several players buy such Devices, and zap out various proposals.
  * Voting ends, and the few remaining proposals take effect. Some  
proposals only pass because their Conflicts got zapped.
  * Suddenly, somebody realizes that an odd wording in some random  
rule actually prohibited anyone from buying the Devices.
  * Rather than rolling back to pre-voting and redoing all the votes,  
the [CR](F[JI]|onsultation) can provide a reparation: "Destroy the  
Devices and refund those who bought them, but retain the canceling of  
proposals, and give each author who lost a proposal because of the bug  
one free proposal in the next nweek".

This is not at all in keeping with the rules, but is much simpler and  
easier on the admins. It's also closer to what you'd do in a real game  
like Monopoly - when you realize you've been doing something wrong,  
rather than restarting the game, you just make a few small gamestate  
tweaks to account for your mistakes and keep going.

-- 
Wonko

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