Nomicron.org / Comment

A game of nomic

Round 10
(ended)
Turn 10 - 15
(ended)
2009-09-20
20:32 CDT

Not logged in

Home
About
Calendar
Players
Public Forum ¤
Report Bug ¤

Books

GRID Grid Hubs

HEHE Heaven and Hell

LIFF Book of Liff

LORE Story of Nomicron

RING Book of Rings

Game Activity
RFC
Proposals
Judgments
Random Number
Rings ¤
Statements of Principle ¤
Static List ¤
The Afterlife ¤
The Grid ¤
Wiki ¤

History
Round 1 ¤
Round 2 ¤
Round 3 ¤
Round 4 ¤
Round 5 ¤
Round 6 ¤
Round 7 ¤
Round 8 ¤
Round 9 ¤
Current

Drafts
RFC

5.1 Updating Entities and Game State

Author Metaloop

Credit

Credit

Enact the following rule:

Updating Entities and Game State

Mutable Rule

Text All entities and the game state are updated only during periods of interim, between two consecutive turns.

For meaningful update of entities and game state, all rules are assumed to execute synchronously - that is they depend on the game state and the values of the entities at the end of turns.

Straw Poll

Undecided: 1
Yea: 1
Nay: 0

Player Comments

Player: Looney
Date: 2009-01-22 14:35

Synchronous execution is pretty much a guarantee of paradox. And there's no reason to require things to happen only at interim--just recognize that if you propose a rule that updates more frequently, you'd better be willing to take responsibility for such updates.

______________________________

Player: Metaloop
Date: 2009-01-22 15:03

The update policy in the previous round was also synchronous in the previous round. And there was indeed a paradox (the one involving temperature) that led the round to end. But in part it was because nothing specifically mentioned if there is an order or no order in executing the rules.

This particular proposal makes update rules depend only on the game state at the end of the turn and not on the values in the interim, after executing a few rules, and hence ensures that any order of execution of the rules gives the same state in the end.

I know all rules updating at the same time is sort of boring. In fact I wrote a long proposal allowing for ordered updates and streamlining the update process. But I ditched it in the end because there are different officers executing different rules and it is very easy to block the execution of many rules.

I prefer executing rules only in the interim because it clearly demarcates a game week for maintenance of the game state and game play.

______________________________

Player: Physics
Date: 2009-01-22 16:52

I actually like the idea of synchronous execution, but I'm not sure about only updating in the interim. Rule 201 defines the middle of a turn, so I figure things should be able to happen at the middle of a turn.

______________________________

Player: Metaloop
Date: 2009-01-22 17:12

I think I should be a little more clear with the reasons I want such a rule. I did talk about them when Round 9 ended but I'll repeat them.

In Round 9 there were several rules which updated entities. And they were worded like 1. "At the end of the turn ...." or 2. "At the beginning of the turn ..."
Now if rule 2 somehow depends on rule 1 then there is a specific order in which the rules need to be executed. But the officer responsible for rule 2 has to wait till the officer responsible for rule 1 executes it or wait till the interim gets over.

The second problem I have with wording like "At the beginning of the turn ..." is that unless the rule is automated it can cause problems. This is because manual updating always requires a window of time. So, again if you have inter-linked rules it is quite easy to have a paradox. This is also the reason why I prefer rules to be updated only in the interim as it is clearly defined window, specifically meant for maintenance.

______________________________

Player: Physics
Date: 2009-01-22 17:28

After thinking about this, I'll support this if you add an exception for RFJs. RFJs should take effect as soon as the judge submits a ruling.

______________________________

Player: Metaloop
Date: 2009-01-22 17:50

That is a good point.

______________________________

10_34