<URL: http://bugs.freeciv.org/Ticket/Display.html?id=37820 >

Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
>On Fri, 9 Mar 2007, (Eddie_Anderson) wrote:
>>    This is an experimental patch.  It replaces "real map distance"
>> (RMD) with pathfinder (PF) distance in the calculation of "waste /
>> corruption by distance from the capital".
>I like the idea, but the implementation (or any implementation) has these 
>  - It is strongly tied to a unit type, and changes to this unit type will 
>create colossal changes to waste levels, which may not be obvious or 

    I understand.  Are there many rulesets where these types of
units become obsolete early in the game?  If not, then it may not be
a big problem.

    Here are some of my other thoughts about it (using the Civ2
ruleset as a point of reference):

1) My choice of units for calculating distance was almost arbitrary.
   Feel free to change it if necessary.

   Caravans (IIRC, "wonder helpers") were used in the part of the
   code that I copied (from your Wonder city code); so I left it
   that way.  I didn't want to risk introducing any side effects in
   code that I didn't understand well.

2) Settlers might be a better choice because they are available
   throughout the game.

   And presumably every ruleset has at least one city-founder type
   unit in it.  But maybe other rulesets have multiple types of
   city-founder units (with different movement capabilities).

3) By the time a civ replaces its Caravans with Freights (which
   would cut its waste-by-distance costs in half), that civ is
   unlikely to still be governed by Despotism.

   IIRC, the change from Despotism to either Monarchy or Republic
   also causes a 50% reduction in waste-by-distance costs.

   And by the time a civ researches Corporation, they may have
   already researched Democracy and/or Communism too.  So waste-by-
   distance may not be a factor at all by then.

>  - Changing roads does not recalculate waste levels until end of turn,
>which changes the way this has been handled up until now. Currently we 
>guarantee that what you see in the city dialog as you press end turn is 
>what you will get on turn end. There are no surprises, which is probably a 
>good thing. We could recalculate all city distances every time a road is 
>built, but it would also be affected by moving units and their ZoC, and 
>we can't recalculate city distances for each unit movement.

    I'm not sure what you mean by "changing roads".  Do you mean
building roads or pillaging them?  or something else?

    I thought that road building didn't happen until the end of each
turn.  In contrast, pillaging happens immediately.  So the player
would see immediate changes (e.g. in a city display) due to
pillaging but not due to road building.  Is that not correct?

    I don't understand all the issues that are involved here.  So,
from my naive perspective, I propose this:

    Preserve WYSIWYG.  I agree that it is a good thing.

    To insulate the PF distance calculations from the effects of
unit activity, store the distances in a structure that is only
updated once per turn (or when a city is created).  Perhaps that
update could be done when the player presses "turn done".

    Use those stored distances for the waste calculation at the
beginning of the next turn.  In between the 'turn done' and the
beginning of the next turn, ignore the effects of other players'
units (newly pillaged roads, new ZOCs exerted by hostile units,
etc.) on this player's cities (unless the city is captured or

    And tell the player that any roads that he is constructing will
*not* affect the calculations on *this* turn.  Instead those effects
will start on the next turn.  Perhaps the city display should show
old values in parentheses if anything changes in mid turn.

    Is that feasible?

>Possible solutions:
>  * Perhaps a "standard unit" should be created for tracing distances, 
>which could be amphibious, now that we have such units.

    That sounds good.

    Or is there a way to measure distances without using units?
AIUI the need for a virtual unit (of any kind) is an artifact of
using PF.  I don't know enough about PF to know if there is a way
around that requirement.  But if PF can be used without units, then
that would solve that problem.

>I do not see how to solve the changing roads / moving units problem.
>>    Perhaps the biggest question I still have about this code is
>> about the form of the PF search.  AIUI the method used here is an
>> outward search of surrounding tiles that looks for cities.  But
>> since the locations of cities are *known*, wouldn't a PF search for
>> a path (between two known points) be more efficient?
>IIRC, no. Remember that the straight path may not be the longest, so we 
>need to do an exhaustive search to find the guaranteed shortest path.

    OK.  Here's another question (and maybe PF already does this):

    Do you know if PF prunes the search if the distance exceeds
a given value?  What I was thinking is this:  If the real map
distance (RMD) is 6, then we could pass that as a parameter to PF.
In effect, we tell PF that we don't care about any path that is
longer than RMD.

    E.g. assume that we ask PF to find a path from A to B.

         C |   |   |
         -   -   -   -
     C |   |   |   |   |   | A |   |   |   |   |   | B |
         -   -   -   -
         C |   |

    The RMD between A and B is 6.  Now PF starts its search.  Assume
that PF starts following a road the leads to the left of A (one that
takes it further away from B).

    Assuming that road movement is still 3 tiles/turn, then once PF
reaches a point 12 tiles away from B (represented by the C points),
then PF should stop evaluating that path (because the best possible
path (i.e. all road tiles) from that point would take the rest of
the 6 turns to get back to the destination).

    Until PF gets to one of the C points, it still might find a
path that way that takes less than 6 turns.  But once PF reaches a
C tile, is PF smart enough to abandon that path and look elsewhere?

    Of course, this assumes that no railroads have been built yet.
With railroads offering unlimited movement, PF pruning might be

>But let us take a step back and look at why there is waste in the first 
>place. I think the point is to give a penalty for building cities wide 
>apart - but why? It punishes bigpox much harder than smallpox, since 
>bigpox cities are generally further apart. Since there is less tiles 
>between smallpox cities, it will be far easier to connected smallpox 
>cities by road and avoid the waste distance penalty.

    If I understand you correctly, you're saying that the waste-by-
distance penalty encourages smallpox (and that this remedy also
favors smallpox).  If so, then I agree.

    But I feel that those side effects are collateral damage.  As a
means for discouraging smallpox, neither waste-by-distance nor this
proposed remedy for it are the right tools.  So they probably
shouldn't be faulted too much for that shortcoming.

>Though, it is good that there is an incentive to build a cohesive empire,
>rather than just a loose collection of cities around the globe, but this 
>can be accomplished in different ways.

    I'm interested.  What "different ways" do you have in mind?

>We could just retire the distance based waste penalty.

    Perhaps, but I would prefer to keep it and give players a way to
remedy it.  There are at least two reasons for keeping it:

1) Waste-by-Distance reflects (roughly) the real problems of
   governing (or managing) a remote location.  So it has a flavor of

2) Waste-by-Distance is the opposite side of the coin of trade
   routes (which are more valuable if they are distant).  That too
   has a flavor of realism - because goods that have to be imported
   from far away cities tend to cost more.

    And here's another idea.  Perhaps the new trade route formula
that you just created could incorporate an incentive for a road
network.  E.g. replace RMD with RMD/PFD.  That way, the better the
travel conditions between the trading cities, the greater the income
from the trade route.


Freeciv-dev mailing list

Reply via email to