Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2004:
[freeciv-ai] Re: (PR#8778) New settler code

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory.Berkolaiko@xxxxxxxxxxxxx
Subject: [freeciv-ai] Re: (PR#8778) New settler code
From: "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>
Date: Sat, 22 May 2004 05:56:47 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: >

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.

This means that settler ferrying needs to understand that ferry service
can be "delayed" for any number of terms as a ferry completes a current
trade route or exploring cycle. Building a ferry should not be part of
the consideration, but is an independent task that gets a priority boost
every time a settler wants to travel, thus ferry building competes with
settler building or any other such, and settlers just do normal things
if there are no ferries currently available or not busy. In a few turns
the situation can change as a ferry is built, or comes free. The only
gotcha might be some sort of deferred or short time task that means a
settler is not always busy when a ferry is free for service, i.e. some
synchronization issues between the more loosely coupled actions.

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.

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.

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.

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.


Gregory Berkolaiko wrote:
> <URL: >
>>From: Per Inge Mathisen <per@xxxxxxxxxxx>
>>Here is an updated version of the patch. I have tested it, and it works.
>>Well, at least for some interpretations of 'works' ;). Coordination
>>between settlers wanting to go off-shore and ferries to take them is
>>(still) not good.
>>I had to turn off ferry-exploring, since this meant no ferries available
>>for ferrying anyone until map was fully explored.
> I tested it with and without exploring and it seems fine.  The only
> problem is a one-turn delay between ferry becoming available and
> prospective settlers getting this information.  Can you send me a
> savegame where exploring is a problem?
> Now to building _new_ ferries.  New code doesn't do that at all and it's
> the only thing missing.  Here are some thoughts:
> The old system was crude but it worked.  Here are the main features:
> 1. Inland cities don't even consider building settlers for overseas
>    travel.  
> 2. Coastal cities consider going overseas to settle.  If they choose
>    to do so, they look for a boat nearby.  If they don't find it,
>    instead of building a settler they start building a boat.
> One can also think of a centralized system, where a single function is
> run each turn to decide (basing on the number of prospective
> passengers both active and in production -- this info is now
> available) whether more boats are needed and which cities should build
> them.
> However, as a first approximation, I want to put a version of the
> present system in action.  Then we can introduce modifications: inland
> cities will be allowed to build settlers if they find a boat for it.
> Present find_ferry is powerful enough, but it might be too heavy.  We
> can restrict actual looking for boats to the turn before the
> production is finished.  This will lead to losing shields every now
> and then but is probably worthwhile.
> Eventually, if the centralized system is introduced, it will remove
> the necessity for expensive find_ferry-ing for each city.  Cities will
> just build settlers if there is a port nearby and the system will make
> sure boat are built too.

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