Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2003:
[freeciv-ai] Re: [RFC] Ferry code

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: [RFC] Ferry code
From: Ross Wetmore <rwetmore@xxxxxxxxxxxx>
Date: Sun, 06 Apr 2003 17:08:12 -0400

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.



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