[Freeciv-Dev] Re: [PATCH] city_map_size fix and idea

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

The movement system does not use Pythagorean distances, and the "size"
of a city radius probably needs to be more closely associated with the
number of moves rather than an absolute distance.

While generalizing the city size to one which has an arbitrary radius
seems nice, I suspect that the myriad places where you need to do a fast 
check to determine which of the [CITY_MAP_SIZE][CITY_MAP_SIZE] locations
is valid might become tricky.

Also, I doubt whether city sizes will ever be more than 3 and even this 
would be a difficult sell because of the incompatibility with stock CIV 
rules. Note increasing the upper bound on a city's size/productivity has 
impact on a lot of game balance aspects like the value of a marketplace.

Cheers,
RossW
=====

At 01:10 AM 01/08/22 -0400, Jason Dorje Short wrote:
>The attached patch fixes all incorrect uses of "2" by replacing it with
>CITY_MAP_SIZE/2.  Note that this is just a very simple correctness fix
>and doesn't address any of the other outstanding issues with the current
>system (namely: city_map_iterate really sucks, and pcity->x + x +
>CITY_MAP_SIZE/2 could be replaced with a macro).
>
>Now, here's my idea: define a tile "workable" by the city to be one
>within CITY_MAP_SIZE/2 (real division, not integer division) distance
>from the city, as the crow flies (i.e. using the Pythagorean formula to
>determine distance).  For instance, with CITY_MAP_SIZE=5 the following
>tiles will be workable by a city (listed by distance):
>
>     2.2  2.0  2.2
>2.2  1.4  1.0  1.4  2.2
>2.0  1.0  0.0  1.0  2.0
>2.2  1.4  1.0  1.4  2.2
>     2.2  2.0  2.2
>
>Which is exactly what we have now.  However, increasing or decreasing
>the value of CITY_MAP_SIZE would give different circular-looking
>objects.  Later, this variable could be made a server option or put into
>the rulesets.
>
>I see two reasons to do this:
>  1.  It looks like it'd be a really easy change to make.
>  2.  It would give slightly more flexibility to the rules.
>
>I see only two problems:
>  1.  Different values may not be supported 
>      by the current graphical routines.
>  2.  There may be rogue code somewhere that 
>      will not be easy to fix.
>
>jason