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

[Christian Knoke <chrisk@xxxxxxxx>]

On Mon, Jun 10, 2002 at 11:33:14PM -0700, Jason Short wrote:
> 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.

Ok, it's not a bug.

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

I think this is suboptimal in two ways:

  1. penalties should have a higher value than bonuses. Think from
     the point of a ruleset writer. If I put -mountain after the city
     name, it is because the next mountain is hundreds of miles away.

  2. If you give preference to cities higher up in the list, you'll
     seldom get terrain-corresponding suggestions. Rather, I'd pick
     up the name with the most fitting attributes, and if there
     is more than one, I'd pick the highest ranking in the list.

     You still can make an exception for the capital, though (take
     the first one of the list).

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

Yes, I've seen that.

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

Good.

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

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.


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

That's not so good, I think.

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

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

> jason

Christian

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