Re: [glob2-devel] concept for building priorities

[Joe Wells]

"Kai Antweiler" <address@hidden> writes:

>> >> > 1st group should get lower priority the higher it is filled (to
>> >> > bring prunes when there are already 180 is a task that can wait at
>> >> > least one minute (2 units fed / s = 180/2 s = 1.5 min.))
>> >>
>> >> Agreed.  Inns with more supply already in them should have lower
>> >> priority.  (By the way, the amount of food that number of workers
>> >> already inside the inn or booked to arrive at the inn will eat should
>> >> be subtracted from its supply for purposes of deciding priority.)
>> >
>> > Thinking about this, we should weight the customers some more, so
>> > that inns at good locations get higher priority than the once far off.
>>
>> Inns at good locations tend to have less extra food (after subtracting
>> current customers), so I think this would happen automatically if my
>> suggestion were implemented.
>
> It does somewhat.  But I think there is a bias left that could be
> straightened up.
> I'm not sure about this, but I think that the number of globs that are
> allowed to sign up for
> a meal is lower or equal to the amount stored food.

This is correct.  A globule will not be allowed to book a place at an
inn unless the inn has an item of wheat to dedicate to that globule.

(By the way, this is why I suggested a while back that the visual
display of the amount of wheat in an inn was misleading and that items
of wheat dedicated to particular feeding globules should be indicated
with dots of a different color.)

> So an Inn that
> would be in a good position to feed many globs won't stock up more
> food unless every other Inn has a positive
> "food stock minus customers" number.

Sometimes that is bad and sometimes it is not necessarily bad.
Sometimes it reduces globule traffic congestion to spread the
feeding/harvesting burden out among many inns, while sometimes it
makes congestion worse.  We need to consider overall feeding time,
harvest time, etc.  The effects of congestion need to be measured in
order to be handled.

Here is my proposal (which can be usefully combined with Leo's idea of
giving a bonus that rises with the amount of time waiting spent
waiting to hire a globule).

For each inn, maintain the following values.  Let ET (“eating time”)
be the time it takes for a globule to feed at the inn (this varies by
level of the inn).  Let AT (“arrival time”) be the average time each
globule previously using the inn has taken to arrive at the inn.
(Each time a globule arrives at an inn, we calculate the new value of
AT as follows.  Let AT0 be the old value of AT, let ATG be the time
the globule took, and let AT1 be the new value of AT.  Let AT1 = (AT0
* 0.9) + (ATG * 0.1).)  Let FT (“feeding time”) be ET + AT.  Let HT
(“harvest time”) be the average time it has taken for each previous
supply run by a globule.  (This is calculated the same way as AT.
This includes the time to get the wheat and the time to bring it to
the inn.)  Let W (“wheat”) be the amount of wheat in the inn.  Let G
(“globules”) be the average number of globules feeding at the inn or
on their way to the inn to feed.  (Update G every X time units as
follows.  Let G0 be the old value of G, let CG (“current globules”) be
the number of globules currently allocated to the inn for feeding, and
let G1 be the new value of G, calculated as G1 = (G0 * 0.9) + (CG *
0.1).)  Let C (“capacity”) be the number of globules the inn can
accommodate for feeding.

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

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.)

What we want to know is how long before the inn has an slot that is
unbookable because there is no corresponding item of wheat.  Let UT
(“utilization time”) be as follows:

  UT = AUT if C < W
  UT = 0 if C >= W

Now we compare HT and UT.  If HT is greater than UT, the inn is more
likely to have unbookable slots in the future.

Resupply priority should be driven by some function of HT and UT.
(Maybe HT / UT (or some high number if UT = 0)?  Or HT - UT?  Or
something else?)

We also want to somehow give more priority to inns with low FT.  Lower
FT means the globules spend more time working or fighting, and less
time feeding.

Basically, I think HT, UT, and FT are the numbers we need for each inn
to make the right decision, although I'm not quite certain how the
final priority should be set from them.  They should also be combined
with the idea of boosting priority as time goes on without succeeding
in hiring a worker.

As a player, I would very much like to see the average value of UT
displayed.  I'd like to know how many seconds/minutes my current food
supply will last.  That way I could react to starvation threats
_before_ my globules start starving.

Notice that UT and HT will automatically take into account the effects
of traffic congestion and measure which inns are in the “best
location”.  (Although in the case of HT, use of this number might
perversely make congestion worse by leading to more workers being
allocated to resupply an inn instead of shifting usage to more easily
reached inns.  This will need to be checked in practice.)

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.

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.

> On the other hand, if Inns without food get very low priority, they
> will never get popular.
> Empty Inns would need a compensate amount of priority.

Thanks for pointing this out.  I have tried to take this point into
account in how I calculate UT from AUT above.  But maybe an even
better scheme is needed.

>> > For war preparations we could give each Inn a priority boost toggle.
>>
>> How would this work?
>
> Well lets say, we put a toggle under the amount of worker adjustment
> bar for inns.
> If it is on, then the inn gets an extra amount of priority.
>
> So when you want a few filled Inns near your enemy: build them, toggle
> them, (probably wait) and then attack.

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.

I think there should also be various global settings to shift
priorities between categories (e.g., “more food” vs. “more globules”
vs. “construct buildings”).

(And I think the hive production controls should be based on the
_desired_ percentage of workers/warriors/explorers in your globule
_population_, not on the desired proportions of _production_.  And
there should just be one control for all hives for which kinds of
globule to produce.)

-- 
Joe