[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] concept for building priorities
From: |
Joe Wells |
Subject: |
Re: [glob2-devel] concept for building priorities |
Date: |
Thu, 23 Aug 2007 14:24:31 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
"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
- [glob2-devel] concept for building priorities, Leo Wandersleb, 2007/08/21
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Leo Wandersleb, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/22
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/23
- Re: [glob2-devel] concept for building priorities,
Joe Wells <=
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/23
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/23
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/24
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/24
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/24
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/24
- Re: [glob2-devel] concept for building priorities, Kai Antweiler, 2007/08/24
- Re: [glob2-devel] concept for building priorities, Joe Wells, 2007/08/26
- Re: [glob2-devel] concept for building priorities, Bradley Arsenault, 2007/08/26
- Re: [glob2-devel] concept for building priorities, Stéphane Magnenat, 2007/08/26