Complete.Org: Mailing Lists: Archives: freeciv-ai: September 2002:
[freeciv-ai] Re: [Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: [Freeciv-Dev] Re: [Patch] [RFC] Path finding version 14
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Fri, 13 Sep 2002 15:55:47 +0000 (GMT)

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.


"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

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