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

["Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>]

<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.

> 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.

> 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.

> 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.

> 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).

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.

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.