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

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Christian Knoke wrote:
> CVS 10 JUNE 2002 unpatched GTK+ 1.2
>
> The name selction code doesn't work as explained in
> README.rulesets. I tested with a modified german.ruleset
> with entries like this:
>
> "Berlin (grassland, -mountains)", 
> "Hamburg(river, -mountains, grassland, ocean)"
> but "Berlin" was suggested adjacent to a mountain, and
> "Hamburg" was suggested on a tile w/o river.
This can happen if the numbers work out right.

Unlike the "original" natural city naming system, the "new" natural city 
naming system does not enforce absolutes by saying that a city labeled 
"-mountain" cannot occur near to a mountain.  In the "original" system, 
something like this was done and it made the system degrade badly in 
certain situations: for instance Riverside was often the default 
captital of America.
Generally, although you might get a penalty because one terrain label 
doesn't match you can also get a bonus if another one does - the two 
will cancel.  Since preference is given to cities higher up in the list 
(as it always has been), "capital" cities are likely to remain the capital.
In the README.rulesets, the documentation says "Cities can be labeled as 
matching or not matching a particular type of terrain, which will make 
them more (or less) likely to show up as the "default" name."  Note that 
it just speaks of likelihood; the algorithm isn't discussed at all.
For nation ruleset writers, it may be useful to know the algorithm so 
you can verify that things are working correctly.  However the code to 
parse the ruleset is very specific and will give an error if anything 
doesn't parse correctly, so it's not likely that an error will occur 
without your knowing it.

More specifically...

Under the "new" natural city naming system a base priority is assigned 
to the city name (dependent on how high up it is in the name list), and 
this priority is modified if it has (un)matching terrain labels (there 
is also a small random factor, ignored here).  In the above case, Berlin 
will have a base priority of 100, Hamburg will be 110, and Muchen (with 
no terrain labels) will be 120 (lower is "better").  If you build next 
to a mountain, Berlin and Hamburg will get a 40% penalty to their 
priority (priority *= 1.4), but if the tile borders grassland (as it 
usually does) there will be a 40% bonus (priority /= 1.4) that cancels 
it out exactly.  Hamburg may get an additional bonus/penalty depending 
on whether the tile is on a river and borders ocean - any time you build 
on the mouth of a river you are probably guaranteed to get Hamburg.
Note that if you give Munchen a complementary terrain label (forest?) it 
may get a bonus for a matching terrain and be pushed up above Berlin and 
Hamburg.  Otherwise, as long as half of the terrain labels match for 
Hamburg and Berlin the penalties will cancel the bonuses and they will 
always be chosen before Munchen.

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