[freeciv-ai] Re: [Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14

["Per I. Mathisen" <per@xxxxxxxxxxx>]

On Fri, 13 Sep 2002, Raimar Falke wrote:
> > But if you wish to use this in your agent code there are no objections.
>
> > Hopefully it will never be used in the core AI routines where speed and
> > flexibility are stronger requirements.
>
> Per thinks about using the path finding for the server AI.

I don't think speed is a big issue. If we use the iterator to restrict the
range of the search, we often need to generate smaller maps. We can also
cache more aggressively with Raimar's new toy than the warmap does now.

My biggest complaint about the path finding is and has been the API. I
will submit a few change request to it when I get the time, mostly
renaming stuff.

In any case, I plan to make a wrapper set for the path finding code for
the server AI where the use of ferries is included in some
functions/macros. Here is a draft suggestion for such wrappers:

void ai_unit_do_goto(punit, x, y) {
        moves a unit to (x, y) and finds a ferry if necessary (this is
        both a replacement for current ai_military_gothere(), which is
        unfortunately completely unsalvagable code, and for all
        do_unit_goto() calls.
}

simple_city_path_iterator(punit, x, y, movecost) {
        simple danger calculation iterator (we should also make a more
        advanced version that looks at enemy ferries and looks where they
        could beachhead, the current AI doesn't)
} simple_city_path_iterator_end;

simple_unit_path_iterator(punit, x, y, movecost) {
        simple target selection iterator
} simple_unit_path_iterator_end;

unit_path_iterator(punit, x, y, movecost) {
        unlike the iterator above, this will have to use higher-level AI
        code to report wild ass goto guesstimates for ferries as well,
        leaning towards worst-case, and calculating in stuff like ferry
        time, how long it will take to acquire a ferry, etc. It should
        give a rough idea of the time it will take, not precise time.
} unit_path_iterator_end;

If we wrap the use of path finding in the server AI behind a good and
limited set of functions and macros, then we can easily change the path
finding implementation behind them if someone produces a faster/better one
in the future. Or if we decide - heavens forbid - to go back to warmaps.

In any case, I don't want the server-AI to use the API of the new path
finding code directly. We need some mediating code.

Yours
Per

"I don't see why people are so upset about cloning sheep. American
television networks have been doing that to their audiences for years."
-- Jello Biafra