Subject: Directive: Dun that

From: [email-masked]
Date: 13 Jun 2002 11:32:40 -0400

Rule 10 reads:

All spans of time are measured in DocNomic Units (duns). The length
of a dun is part of the gamestate, and shall be equal to 48 hours
unless Doc proclaims otherwise.

The intent of this was to make it easy for Doc to tune the pace of the
game. If e found emself unusually busy with Real World activities, e
could e.g. change the length of a dun to 7 days.

One problem with this is that a dun is a measure of time span, and
when it changes, what happens to time spans that include the moment of
change? For example, if a dun is 48 hours at the start of a time span
that's 3 duns long, and 59.4 hours later the length of a dun changes
to 96 hours, then when does the 3-dun time span end?

(There actually is a similar problem in real-world time span
measurements: What is the date exactly one month after January 30?
This is why we specify "90 days" instead of "3 months" when we want to
be precise.)

Another problem is that by putting all time references in terms of
time spans (duns) one becomes decoupled from the calendar. Instead of
things happening "once a week, on Tuesday at 12:00:00 GMT" one has
"every four duns after Tuesday, 11 Jan 2002 at 12:00:00 GMT" -- which
is on a Wednesday the following week, Thursday the week after that,
etc. -- assuming the dun length does NOT change! This allows for more
flexibility of pacing but is more inconvenient to keep track of.

With the above points in mind, Doc calls for proposals (no particular
rush, though, and don't get too distracted from developing this
round's theme) to amend or replace Rule 10, and amend any rules that
depend on Rule 10, to implement a better way of dealing with time in
DocNomic. 

-- 
- Doc

---

From: Sir Toby <[email-masked]>
Date: Thu, 13 Jun 2002 11:51:37 -0700 (PDT)

> to 96 hours, then when does the 3-dun time span end?

Another problem of time measured as duns is that you have multiple methods
of referring to it. Something like "every 2 duns, xyz takes place" is
very different from "2 duns after abc takes place, xyz takes place." The
first assumes that duns are tracked much like days, such that when one dun
ends, another begins. As long as duns are integer mutliples of days, this
isn't a big deal, but imagine trying to figure out how often something
happens if a dun is 20 hours. The second approach assumes that duns are a
period of time, tracked much like minutes and seconds are tracked. Given a
situation where "1 dun after abc takes place, xyz takes place", every time
abc takes place, a time period of 1 dun starts. After that time period
ends, xyz takes place. If abc is happening fairly often, there could be
several time periods being tracked simultaneosuly to determine each time
xyz needs to happen.

I might suggest the following: Whenever the definition of dun changes, the 
current dun is considered to have ended and a new dun begins using the new 
defenition of dun. Also, any time periods that are currently being tracked 
that are measured in duns are considered to have ended.

> flexibility of pacing but is more inconvenient to keep track of.

Well, we could give Doc ultimate flexibility and ease of tracking by
saying that one dun ends and a new one begins whenever Doc declares it
does. That way, the length of time for one dun compared to another dun may
be totally different. If Doc suddenly finds emself really busy one week,
the current dun may last for a whole week, whereas if Doc has lots of time
the next week, the next several duns could last for one day, or so. Of
course this approach might annoy the players who wouldn't know whether or
not they can check their DocNomic email once a week, or if they have to
check it every few hours.

-- 
Jeff Weston (Sir Toby)

---

From: fnord <[email-masked]>
Date: Thu, 13 Jun 2002 15:22:24 -0700 (PDT)

--- Sir Toby <[email-masked]> wrote:
> 
> I might suggest the following: Whenever the
> definition of dun changes, the current dun is
> considered to have ended and a new dun begins
> using the new defenition of dun. Also, any
> time periods that are currently being tracked 

Sounds like a good idea, but I see a minor problem 
with that last sentence.

What happens if, say, an auction starts, that is
supposed to last 4 duns. Halfway through the first
dun, Doc decides to change the length of a dun.
The time period for the auction is considered to
have ended, therefore the auction is over. Any 
player lucky (or smart) enough to have gotten a
first bid in early will win the auction before any
others get a chance to participate.

A possibility combines a previously mentioned idea
with a twist. 

(proposal start)
In the event of a change in dun length, the change
in dun length will be handled according to the 
following procedure.

Calculate the change that would occur to the 
length of the dun.

If the change is to increase the dun length, then 
the current dun is allowed to finish. Then, the 
length of the dun increases, and the next dun 
starts.

If the change is to decrease the dun length, then
the following occurs. If the amount of time that
has passed in the current dun is greater than or
equal to the amount of time in the new dun length,
then the current dun ends, the length of the dun 
decreases and the next dun begins. If the amount
of time that passed in the current dun is less 
than the amount of time in the new dun length, 
then the current dun changes its expected endtime
to behave as if it had started with the new dun
length, and then the dun length is decreased. 

If the change is to leave the dun at exactly the
same length, then nothing occurs.

In all of these cases, there would be no change 
in the number of duns that have passed.
(proposal end)

Hey, that sounds like a proposal to me.

I propose that Rule 10 be modified by appending 
the text of this message between the markers 
(proposal start) and (proposal end).

Micheal

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: [email-masked]
Date: 14 Jun 2002 10:35:26 -0400

> in the number of duns that have passed.

Sigh. Much as I hate to start a round with three consecutive REJECTs,
I really must.

The whole point of my Directive, which evidently was so badly worded
as to have misled everyone, was to request ways, not of disambiguating
duns, but of constructing an easier and less cumbersome way of
reckoning time around here, while preferably maintaining the present
system's feature of allowing game pacing to be tuned easily.

The above does not, by a long shot, constitute easier and less
cumbersome. 

-- 
- Doc

---

From: Sir Toby <[email-masked]>
Date: Fri, 14 Jun 2002 08:26:22 -0700 (PDT)

> Sigh. Much as I hate to start a round with three consecutive REJECTs,

Hmm... I feel as if I'm coming down with a touch of Fear of Rejection.

*cough* *cough*

:)

-- 
Jeff Weston (Sir Toby)

---

From: "Goateus" <[email-masked]>
Date: Fri, 14 Jun 2002 17:04:08 -0000

Brain is too fried right now to put this into a proposal, but how's 
this for a rough stab at a simpler idea?

A DUN is a day.
A new element is created to represent the Doc's waiting list (Being 
from the UK this is a very familiar concept to me). The purpose of 
the waiting list is to give a "factor" by which all measurements of 
times are multiplied.

The Doc will periodically publish what this factor is.

Whenever anything that happens that is time dependent the usual DUN 
amount is multiplied by the waiting list. The factored date is then 
included WITH THAT PROPOSAL (or whatever) to give the final time.

This means that if the waiting list factor changes again previously 
calculated times do not need to change.

Hope that this makes some sort of sense. I think that I have made it 
sound more complicated than it really is. Fridays do that to me.

---

From: fnord <[email-masked]>
Date: Fri, 14 Jun 2002 11:37:43 -0700 (PDT)

--- Goateus <[email-masked]> wrote:
> A DUN is a day.
> A new element is created to represent the Doc's
> waiting list (Being from the UK this is a very
> familiar concept to me). The purpose of the
> waiting list is to give a "factor" by which all
> measurements of times are multiplied.
> 
> Whenever anything that happens that is time
> dependent the usual DUN amount is multiplied by
> the waiting list.

I assume here you meant to add the word "factor" 
after "waiting list", correct?

> The factored date is then 

So, whenever a time duration is expressed, it first
gets modified by the factor, and then expressly
written down as a specific datetime. Very intriguing.

> This means that if the waiting list factor changes
> again previously calculated times do not need
> to change.

Fascinating idea. It requires just one calculation of
time, while still allowing some flexibility in pacing.
Pretty good, I think.

However, I think this would only work for situations
where time is a duration, i.e. this auction will end
in 4 days, you have 3 weeks to submit a claim of
damage,
etc. I don't think it would cover cases where time 
is a period, i.e. you can only submit one proposal 
per dun, a player can only transfer juice cans to
another player once every 3 duns, etc. Something
would still need to keep track of when the dun
changed,
or provide for measuring the time-between-things time.

fnord

---

From: [email-masked]
Date: 14 Jun 2002 16:58:58 -0400

> sound more complicated than it really is. Fridays do that to me.

I concur with some of the discussion so far. There are still some
problems. For instance, if a rule says e.g. "Such-and-such will
happen if any players wearing orange t-shirts post a message
containing the word "interrogate" within 3 duns of the posting of any
proposal", then must all proposals contain text like "Such-and-such will
happen if any players wearing orange t-shirts post a message
containing the word "interrogate" before 16:59:28 20 Jun 2002"?

-- 
- Doc