[Freeciv-Dev] Re: nation.ruleset terrain bug (PR#1554)

[Christian Knoke <chrisk@xxxxxxxx>]

On Tue, Jun 11, 2002 at 11:07:41AM -0700, Jason Short wrote:
> Christian Knoke wrote:
> >
> >Here's my suggestion:
> >
> >Give points to cities.
> >
> >  Give  +2 points for an adjacent tiles which matches a  predicate.
> >  Give  -6 points for an adjacent tiles which matches a -predicate.
> >  Give  +4 points for a center tile     which matches a  predicate.
> >  Give -10 points for a center tile     which matches a -predicate
> >
> >                             +river   -river
> >     river on center tile      +10      -10
> >  no river on center tile       -4       +4
> >
> >  (This is representing the fact that rivers tiles are rare.)
> >
> >If several names get the most points, take the first from the list.

Doh, I forgot the most important rule:

  Give +1 point for any tile not yet counted as above.

> The idea of having the penalty be larger than the bonus is a good one. 
> When I initially implemented things there was no "penalty", just a large 
> bonus (factor of 2) if the label matched.  I quickly realized this meant 
> the more labels you added, the higher the city would be in the list.  So 
> I move to a bonus vs penalty system of sqrt(2) (which was later just 
> simplified to 1.4).  It could go:
> 
>    "predicate" :  *1.4, /1.4
>    "!predicate" : *1.6, /1.3
>    "river": *1.3, /1.6
>    "!river": *1.3, /1.6
> 
> although this would make the code flow much uglier.  (Remember that 
> there are matching and non-matching labels...your example above just 
> describes a matching predicate and a non-matching -predicate.)

With the added rule, I think this point is adressed. Each tile is counted
once, except a centered river tile.

> 
> We could also introduce a higher bonus/penalty if the center tile 
> matches, but I don't think that's necessary.
> 
> >>On a more technical note, this is in large part intentional - the idea 
> >>is that cities higher up on the list should generally be chosen first. 
> >
> >
> >But the idea is, to give terrain-specific suggestions ...
> 
> Well, they are terrain-specific.  The problem, here, is that you think 
> that "!mountain" should be given much more weight than "grassland".  And 
> you're right.

You think that the order of the cities in the list matters. I do not.
I think that we have to decide: either a fixed priority for city names
by means of a list _or_ terrain-specific suggestions. To get the first
you can switch the stuff off (set naturalcitynames 0). 

As a wild guess, no more than half of the rulesets have the cities
sorted. Are the first cities you build really the biggest later on
in the game? Rather not. I once sorted the german cities and was always
wondering which criteria should be taken. Size? Age? How Boring!

> 
> >>However, I also chose to give a 40% bonus for a matching terrain (i.e. 
> >>"mountain" when there's a mountain nearby or "-mountain" when there's 
> >>no) and a 40% penalty for non-matching terrain (i.e. "mountain" when 
> >>there's no mountain nearby or "-mountain" when there is).  In general 
> >>this is good since adding more labels will have a nearly neutral effect 
> >>on a city's overall priority, but "grassland" is a bit imbalancing since 
> >>the odds of a tile bordering it are way higher than 50%.  In the future, 
> >>it might be feasible to have the bonus and penalty factors for each 
> >>terrain to be chosen so that the *expectation* of bonus is equal to the 
> >>*expectation* of penalty for each terrain label.  At the minimum, this 
> >>would involve looking at how common each terrain type is on the current 
> >>map.  But I think this is a bit infeasible for the near-term.
> >
> >
> >That's a good way to go.
> 
> I will give some thought to it.  Do I need to calculate the number of 
> global terrain types, or has this already been done somewhere?

Well, there are those terrain options ... I don't know.

> jason

Christian

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.