[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:
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).
Picking the name with the most fitting attributes degrades badly.
Suppose you make a list of 1000 cities; do you pick the 997th one as the
name for your second city if the attributes match right? Nobody will
have heard of it.
The current system multiplies the priority by a given factor, 1.4. In
most cases this is comparable to moving the city up or down in the list
by 40% - except that we reduce the bonus of the top cities because the
numbering in the list starts from 10 instead of from 1 (i.e. the
numbering goes 10, 11, 12, 13...). All of this is intentional - it is
designed to work in the common case as well as to degrade smoothly.
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.
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.)
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.
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?
jason
|
|
