[Freeciv-Dev] Re: Patch: generalized granary size (PR#635)

[Andrew McGuinness <andrew_mcguinness@xxxxxxxxxxx>]

On Mon, Dec 25, 2000 at 08:28:04PM +0100, Thue wrote:
> On Sunday 24 December 2000 22:49, Andrew McGuinness wrote:
> > The values fixed in correspond to 76 / city_size, except that the value
> > for size 1 is 57 instead of 76.  This looks like a manual tweak.
> > 
> > As Thue points out, prior to May 1999, fooxbox_width was = city_size.
> > (instead of city_size+1)
> >
> > What this means is that prior to the May 1999 change,
> > the AI valued each unit of city growth the same, except that
> > getting size 2 was worth only 3/4 as much
> > (because of the first value being 57 instead of 76).
> >
> > Also, the value for city size 1 is not used much in the code.
> > The only places where it is used are for settler actions and
> > for setting tax and luxury rates.  Everywhere else food_weighting
> > is called with food_weighting( MAX( 2, citysize)) or
> > food_weighting( MAX( 3, citysize )).  So, the AI seems to be
> > assuming for most purposes that the city will grow to size 2
> > or 3 soon anyway.  This makes the 57 instead of 76 of less
> > significance.
> >
> > So, it is consistent with how the code originally was to make
> > food_weighting(cs) return (5*FOOD_WEIGHTING)/(cs+1), exactly as
> > Thue said, except that food_weighting(1) should be 36 instead
> > of 48, for what it's worth.
> 
> Well, actually the code was optimized for size 4 cities, which then had a 
> food_box width of 4, so that would be better to use than 5...
> And it would not be correct just to copy the way to handle size 1 cities 
> relative to size 2 cities, since that relationship have changed. Actually I 
> think we need some way to weight food value as a composite of the value in 
> the city immediately and how much it will be worth later. That would include 
> the special case of size 1 cities that didn't stay size one very long.
> 
> And finally, the code I posted (which was just a schetch) need to use 
> floating point numbers to handle that division correct.
> 


This looks like an area ripe for fiddling with the AI anyway.  I am not
sure about the assumption that each unit of city size is worth the same
amount to the AI for a start.  


I suppose, as far as the granary patch is concerned, the
requirement must be to

a) make the AI no worse for the current default rulesets
b) allow the AI to deal with variants in a reasonably sane way.

"Correcting" an error that seems to have been in the code for over
18 months, by changing or removing the 3/4 multiplier for city size 1,
is probably a separate job.

So if we take:

int food_weighting_is_for = 4; /* FOOD_WEIGHTING applies to city with
                                  foodbox width of 4 */
x = ((food_weighting_is_for * FOOD_WEIGHTING) 
        / (granary_food_ini+(city_size*granary_food_inc/100));
if ( city_size == 1 ) return ((x*3)/4);
else return x;

This will produce the same AI behaviour as now for the default ruleset, 
while extending the same principles if the new options are used.

Meanwhile, we can take a look at whether we can improve the AI, either
for (food_ini=1,food_inc=1), or for the variation cases, possibly by
changing the principles the AI is using, or by restoring them to what
they were 18-odd months ago (when food_ini=0,food_inc=1)

I quite fancy:

int food_weighting_is_for = 4; /* FOOD_WEIGHTING applies to city size 4 */
x = (((granary_food_ini+(food_weighting_is_for*granary_food_inc)/100)) 
       * FOOD_WEIGHTING ) /
     (granary_food_ini+(city_size*granary_food_inc)/100);
return x;

But we can only tell if it's an improvement by trying it.

Oh, and it should probably take note of the existing foodbox ruleset
variable while we're at it.
-- 
Andrew McGuinness     Luton, UK        andrew_mcguinness@xxxxxxxxxxx