[Freeciv-Dev] Re: nation.ruleset terrain bug (PR#1554)
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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.
(Err, this should have been sent to bugs@freeciv, not (just) freeciv-dev.)
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
- [Freeciv-Dev] Re: nation.ruleset terrain bug (PR#1554),
Jason Short <=
|
|