[freeciv-ai] Re: (PR#8778) New settler code

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8778 >


Gregory Berkolaiko wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8778 >
> 
> On Sat, 22 May 2004, rwetmore@xxxxxxxxxxxx wrote:
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8778 >
>>
>>Ferry building requires a global oversight component. Simply counting
>>ferries and cities with possibly some fudge for sea regions, i.e. ferries
>>are restricted to a given area by physical or policy requirements can be
>>as trivial as a 1 ferry per 3 cities cutoff. Ferry "building" should not
>>be something that is a purely local or instantaneous option like needing
>>a defender. It should *never* be tightly coupled with another task, but
>>always be one of the build options possible in competition with all others.
> 
> I agree that embedding ferry-building in other tasks is not the most 
> correct thing to do.  However, it is easy and it gives satisfactory 
> results.  More on "correct" system below.

Since it is a bad way to go, it should not even be started. And since the
code to build ferries is already there in the general choice options, one
has at most to add an if clause to count and cutoff the choice option to
remove a lot of the current silly behaviour. This is a needed bugfix anyway.

Code to do this is already in place. Instead of calling ferry building
as a sub option, just flag the cutoff or priority parameters for whenever
this evaluation is next run, i.e. do the ferry building as a loosely related
option where everyone that builds ferries gets the full, smart choices.

>>Ferries need to understand a "ticket booking" system where passengers
>>request and maintain a request for source-destination travel which the
>>ferry optimizes by picking up and dropping off passengers along an
>>optimized route.
> 
> Multi-passenger optimization is an interesting but hard problem.  There 
> are other more pressing issues for me, but if someone wishes to write a 
> patch, I will definitely spend time reading it.

Also a solved problem with full working code. It is actually not that hard
once you see how to do it in a minimalist way. It is really neat to see a
ship pickup explorers, caravans, defenders and settlers in a sweep and
drop them off in a continued loop that brings the ship back to its regular
staging area where it is close to unit generation areas for future pickups.

>>Exploring ferries should return home if there are passengers waiting, and
>>always have their fallback explore mode preempted by ferry needs, i.e. this
>>is the lowest priority request in their booking algorithm.
> 
> This is the case now.

For various reasons, it was always tricky to keep a ferry's mind on a long
term task. Going exploring as a final option when it couldn't actually do
some part of its current task was a goofy way to get side tracked and for
some reason (Murphy) always the choice it fell into and stuck at :-).

>>When there are multiple ferries possible for service, the *closest* needs
>>to hold the ticket, though over turns tickets might be reassigned to other
>>ferries as such conditions change.
> 
> The tools for this behaviour are available (find_ferry function).  
> However, if there are more tasks then ferries, a ferry should choose the
> closest task.  Overall optimization is also possible, but requires all
> pair-wise distances and therefore expnsive in both code and CPU time.

Crude estimates are not unreasonable. One wants to be sure to avoid
flip-flop and gross mismanagement problems, but getting the second or third
best ordering rather than the first everytime is just not an issue. One can
use line-of-sight if necessary as an ordering parameter, but of course need
to make sure that both units can move from current positions to any boarding
tile.

In general, all units should move toward their ticketed ferry and the
ferry move toward its current dropoff destination (i.e. active passenger's
destination), or closest ticketed but not yet loaded passenger.

Apart from loading and unloading mechanics (including bodyguards) on the
fly, this is about all one needs to do.  The main approach - KISS.

>>There is a reasonably complete prototype of this sort of system coded and
>>working. Mostly it is just making sure that normal code flow has the
>>appropriate checks and options rather than that there is a dedicated piece
>>of settler code that hardwires some stupid algorithm that interacts with a
>>lot of unrelated concepts and areas of the code by combining subtasks that
>>should just be left to compete independently. Instead use loose interactions
>>like changing priority boost parameters each subtask uses in its private
>>decision making process.
> 
> This is a more detailed view of what should be done to separate 
> ferry-building from other productions.
> 
> Let's consider only settlers for now.
> 
> 1. Existing settler should:
>   (a) look for a job on the continent
>   (b) look for a job overseas
>   (c) if (b) gave better results, try finding a ferry
>   (d) if a ferry found, proceed overseas
>   (e) if no ferry found, record at the nearest port a desire for ferry and 
>       proceed to the (worse) job found in (a)
> 
> 2. Virtual (i.e. one considered for construction) settler should:
>   (a) look for a job on the continent
>   (b) look for a job overseas
>   (c) judging on the best result ask to be built
>   (d) if the settler is chosen to be built and (b) gave better results, 
>       try finding a ferry
>   (e) if no ferry found, record at the nearest port a desire for ferry
> 
> 3. Ferry building module should:
>   (a) find the port with most desire for ferries
>   (b) starting from this port do a sea search for other ports which can 
>       build a ferry
>   (c) if found, return to (a).

Sounds good. Note still add cutoffs or priority scaling for the case that
oodles of ferries currently exist (or none) but for some reason are not
available. Deferring by this check over several turns with an increasing
priority bump is not a bad way to manage the overall process, as opposed
to instantaneous need.

> Notes:
> 1. In 1e and 2e above the nearest port should be chosen among those from 
> which the job location is reachable (i.e. exclude ports on internal 
> lakes).  Ocean numbers would be helpful here, although they might not take 
> connector cities (like Panama) into account.

Adding refinements past the initial robust solution should be viewed as an
ongoing followon task.

> 2. Using, instead of want based at a port, a global want might lead to the
> situation when either noone is building ferries or everyone is.

Just add "ferries underconstruction" to the count or the like to solve the
hysteresis problem. If underconstruction unit types are reasonably mobile,
then count ferries only after they are 50% built or the like. Assume that
excess ferries will be converted to other unit types once the cutoff quotas
are met during the standard review of current production needs.

Cheers,
RossW
=====