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

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Sun, 6 Apr 2003, Ross Wetmore wrote:

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

This is precisely the same as I suggested in proposal 1 (+ extension 1)

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

Ah, so you volunteer! ;)

Do you want to do it as a patch to the present system or wait till 
somebody implements the new one and then you can improve it?

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

How do you define the "right direction"?

I plead to you give a step-by-step breakdown of your proposed solution to 
the problem, so I know what I am arguing against.  Right now I suspect you 
are considering various parts of it out of context.

Here is the setup:

Unit U on tile A on cont 1 wants to get to tile Z on cont 2 (possibly 
inland).  There are several idle ferryboats on the map and several boats 
B(i) going from S(i) to T(i).  Lets skip the "building for now".

G.