Re: [glob2-devel] concept for building priorities

[Joe Wells]

"Kai Antweiler" <address@hidden> writes:

> You need initial values for AT and HT.
>
>
>> If usage continues as before, the inn could use up all of its current
>> food after roughly AUT ("average utilization time") time units:
>>
>>   AUT = (W / G) * FT
>
> If G==0, then AUT = ?

AUT is *big* in this case.  The food at the inn will last a _long_,
_long_, _long_ time if no globules are eating it.  :-) ☺

> If W==0 (and therefore G==0), the AUT = ?

There is no food at the inn in this case.  Therefore, the amount of
time the food at the inn will last (AUT) is zero.  :-) ☺

> There have to be values for these cases as well.
> Something like:
> If G==0, act as if G were 1 (or 1/2).

We could set the minimum for G to 0.1.

> If W==0, act as if W were 1 (or 1/2).

Nothing goes wrong in this case, so we can safely use a value of
W = 0.

> We probably have to experiment here.

Lots of experimentation will be needed!

>> This is an oversimplification.  We should in fact consider that the
>> globules already allocated to the inn for feeding will take on average
>> only FT / 2 units of time:
>>
>>   AUT = FT / 2 + ((W - G) / G) * FT
>>
>> This simplifies to:
>>
>>   AUT = ((W / G) - 0.5) * FT
>>
>> (If usage suddenly goes to maximum capacity, the inn's supply might
>> last roughly MUT ("maximum utilization time") units of time: MUT = ((W
>> / C) - 0.5) * FT.)
>
> More like:
> MUT = ( (W - (G / 2) ) / C ) * FT
> Because (for simplicity we can assume) half of the G globs are about
> to finish and
> the other half has just signed up for a meal.

(I deliberately decided to simplify by assuming for MUT that CG goes
immediately to C and then not distinguishing which globules in the C
amount were already there for some time.  In any case, I'm not
proposing using MUT for anything.  I just mentioned it as a side
comment.)

> And AUT corresponds to a special case of MUT where C==G.
>
>> The calculation of the decaying averages AT, HT, and G should probably
>> use factors other than 0.9.  Determining the best factors to use will
>> require experimentation.
>
> We could also experiment with other control structures.
> Steph mentioned a PID controller (for something else) a while ago.
> http://en.wikipedia.org/wiki/PID_controller

Do we have someone available to program such things who would
understand them?  I worry about the maintainability of the extra
program complexity.  Would the improvement in the calculated values
make a big enough difference to justify the extra program complexity?

> Right now the values might jump a bit depending on how high the "running" 
> levels
> are for the arriving glob.  (Especially when a few explorers get hungry.)
> We could flatten this a bit by using the globs speed as well as time.
> (And the average running level for workers, or globs)

I don't understand the previous paragraph.  Can you explain?

>> By the way, there is a complication that is not handled.  Both AT and
>> HT should somehow also include the time taken by globules assigned to
>> the inn who give up before they succeed.  This generally happens due
>> to congestion and sometimes is due to hunger while harvesting.  I
>> don't have a specific proposal for how to handle this complication.
>
> We could add these times to the time of the next arriving glob.

Yes, I think that will work correctly for HT (harvesting time).  I
think it is not quite right in the case of AT (feeding arrival time).
(Sorry, too complicated to explain right now.  Got to go to work.)

> Or we could let an imaginary glob arrive, which took current average time +
> the time that the other glob walked in vain.

I think it is harder to get this correct than the above idea of adding
the time to that of the next arriving globule.

>> Basically, what I think we want is to completely replace the current
>> system where we specify a maximum number of requested globules for
>> each building/flag by a priority for each building/flag.  Usually, you
>> would leave the priority alone and the right thing should happen.  For
>> example, for inns the above method would be used and the
>> player-supplied priority would be used as some kind of multiplier.
>
> Basically I would prefer an market economy style system, where every glob
> has to work for its money and also buildings compete with each other
> in their wages.
> The amount of social welfare would be up to the player.  And globs
> with low money
> might get only small amount of food back in restaurants and of health
> in hospitals.
> The player would have to care about debts, inflation, subventions and taxes.

I'm not sure what you are proposing.  Do you want to write a concrete
proposal?

>> I think there should also be various global settings to shift
>> priorities between categories (e.g., "more food" vs. "more globules"
>> vs. "construct buildings").
>
> Yes.  But Steph warned that glob1 was less fun, because global settings
> took away too much influence from the player.  We would probably need
> settings-flags to compensate.

Can you give more details?

> (In the marketing model, this would correspond to township.)

I don't understand the above sentence.

-- 
Joe