[freeciv-ai] Re: [RFC] Ferry code

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

Gregory Berkolaiko wrote:
> On Sun, 6 Apr 2003, Ross Wetmore wrote:
>
>
> > Several suggestions:
> >
> > 1)  Don't confuse the situation by mixing build boat and travel by boat.
> >     If you need boats, then increase the want for boats and the locations
> > where they are most useful. It is stupid to build a boat for a single
> > ferry operation - boats need to be built for longer term reasons, and boat
> > building suppressed if you have enough even if there is a given ferry
> > operation that needs to wait for a free boat.
>
> While operating via want is more elegant in principle, I don't know how 
> to do it well in practice.  Do I bump up the want in several coastal 
> cities?  Then they might all build boats.  Bump it up by a smaller amount?  
> Then I will end up with throngs of units milling around waiting for te 
> want to accumulate.  I think it's more sound just to build a boat.  If 
> there are enough boats, the chances are that the boat will never be built: 
> the unit will check every turn if it can book a free boat and only then 
> renew request for one to be built.
If you need "a" boat with want "n1" in city 1, "n2" in city 2, etc, pick
the city with the highest want to build the boat.

If you need more than one boat and it is reasonable to build more than
one at this time, then pick the top "n" cities.

You may want to factor in sea coastline concepts with perhaps a check on
accessibility, i.e. build one on each sea coast or within a given region,
tweaking want accordingly.

If the unit cannot find a boat, then it should choose its next best move
which may be to go overland in the right direction if a boat exists and
may come available in a reasonable time. Or it may be to do something
else more useful in the meantime (e.g. settler can improve or unit patrol).

If/when a boat becomes available, then the ferry check will allow it
to book and continue with the boat move if it still seems reasonable.

> > 2)  Book boat travel on an efficiency basis. Find the nearest boat and
> >     have the unit an boat meet up as with bodyguarding, but perhaps taking
> > advantage of cities for boading and unloading efficiencies. If a boat is
> > already booked but the current request is en-route or closer, then switch
> > the booking or divert it to make multiple pickups and drop offs on a
> > closest goes first basis. In general penalize stalling boat movement or
> > undue diversion/backtracking to pickup passengers, but don't necessarily
> > block it. A boat that follows a "ferry-route" picking up and dropping off
> > units along the way is the optimal goal.
> While it all may sound very nice, I, personally, don't want to start
> writing code to estimate the time to get from A to B by hitching rides.  
> Any volunteers?
I already did something along this line. It is really rather trivial.

> > Summary, don't micromanage the boat pickup and dropoff but let it happen
> > under tactical, i.e. immediate situational rules. Micromanaging end-to-end
> > single boat operations is both less efficient and more dangerous as you
> > are liable to land single units too be easily be picked off, rather than
> > armies that have a fighting chance to survive until the next trip can
> > bring reinforcements. Micromanaging except in limited one (maybe two) turn
> > tactical situations is in general a very poor strategy for any actions.
> Sorry, but this is talk of little substance.
I'm sorry you don't understand, but your conclusion is perhaps misplaced
and you should look a little harder before giving up on a solution.

> You want to get unit U from A (cont 1) to Z (cont 2).  What do you do?  
> What's "macromanagement" in this situation?  Brownian motion?  Walking 
> to the nearest coastal city and hoping for the best?  Hijacking nearest 
> boat no matter where it goes now?
Actually, brownian motion may not be that far off :-)

You do need to decide if it is possible, but after that you should bias
the choices of the components involved with very short-range objectives.
In the case of hijacking a boat, you should certainly jump on board if it
is going in the right direction and a small tweak to its path will
accomplish both its initial and hijack purposes. The nearest first should
be a good way to decide which destination gets preference.

> I feel that moving one unit from A to Z is the atom, the basic operation.  
> You can't do it by statistical management.
That is the problem with micromanagement approaches, they only consider
single end-to-end atom motion and can't deal with situations that involve
more complex real situations.

Break the problems down into smaller steps and assign rules and weights
to determine where to share or who wins in competing instances. Don't
worry about locking in some micromanaged end-to-end process over many
turns duration but let the situation evolve in response to the changing
environment under given rules/biases.

> G.
Cheers,
RossW
=====