Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2005:
[Freeciv-Dev] (PR#12833) consider_settler_action simplification
Home

[Freeciv-Dev] (PR#12833) consider_settler_action simplification

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bdunstan149@xxxxxxxxx
Subject: [Freeciv-Dev] (PR#12833) consider_settler_action simplification
From: "James Canete" <use_less@xxxxxxxxxxx>
Date: Tue, 19 Apr 2005 03:06:03 -0700
Reply-to: bugs@xxxxxxxxxxx

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

I was under the impression that the AI still used
evaluate_improvements() to calculate city and settler desirability; this
is no longer true, and thus the perpetuity is no longer needed, either.

However, I believe this quibbling about amortization is wrong headed as
well.  Games are long enough that the time spent improving a worked tile
is miniscule compared to the value given in (almost) perpetuity after
the improvement.

Also, I'm of the opinion that a worker should stay fairly close to its
home city and concentrate on keeping that area improved and free from
pollution.  That means that travel times become immaterial as well,
unless citymap sizes are increased to hideous levels. :)

Anyway, solutions.

The best and most complicated solution would have the worker consider
what the city needs first, and try to do that.  For instance, if a city
were starving, an autosettler would want to irrigate a worked tile, or
clear up some pollution, to fix it.  This would be difficult to code,
though.

The simplest (and my preferred) solution would be to calculate an ideal
improvement path for every terrain type, before and after engineers. 
The autosettler then improves all the tiles around its home city, 
starting with worked tiles.  On this tile, it would pile on as many
improvements as it can, so it would not have to cover the same tile
twice.  After the home city's worked tiles are all improved, it would
then consider neighboring cities, but would not want to wander off too far.

I'll see if I can implement the second solution.

-James Canete



[Prev in Thread] Current Thread [Next in Thread]