This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Revised exploring_worth function


>Maybe as Bob said, there should be a short-range exploratory plan (for
>esp. fighters) and a long-range exploratory plan (for esp. armor,
>battleships, et al.).  Or maybe the city/town should have a goal in mind
>when building exploratory units and then build a unit with an
>appropriate range, and so if the built unit inherited the city/town's
>plan, only one exploratory plan would be needed.

Actually, the whole concept that cities have "exploratory" plans etc. is
kind of flawed, and makes the AI code extremely complicated (take a look at
how plan_exploration_support etc. actually work). What we would need
instead is a PLAN_BUILD, and a unified building code for the AI. Kind of
how it already works for the acp-independent units.

>Maybe there should also be a reconnaissance plan that tries to ensure
>that certain known cells are re-visited every so often.  It seems to me
>that it would be fairly easy to decide out which parts of the map should
>be subject to reconnaissance (a certain radius around each town and
>city, at least), but an obvious problem would be to ensure that it is
>done as efficiently as possible (i.e. don't have two airplanes
>performing recon on the same area; ensure that units cover as much area
>as possible before they would have to resupply, etc.).

Exploration, like all other activities, is divided into theaters. Which is
sometimes good and sometimes bad. Within a theater, I think it would be
difficult to come up with an algorithm that works better than random walk.
One could of course try to write some kind of "lawn-moving" algorithm, but
since each theater has a unique shape, this would not be easy.

>Another issue I see is that the motion algorithm not only has difficulty
>with maze terrain (as I noted when debugging cave2.g), but it also seems
>unable to let units know when they're trying to go somewhere that they
>can't go.  One thing I saw while testing was that an infantry unit was
>trying to march to an independent town and capture it, but they were
>separated by an ocean!

This is as it should be. When the infantry cannot reach it target, it will
call for a transport. That part of the transport code usually works (if
there are any transports around). The problem comes when the infantry has
been picked up. Instead of heading for the target, the transport goofs
around, and then heads pack to pick up another unit. At which point the
first infantry usually disembarks.

As for the maze etc., the pathfinding algorithm could certainly be
improved. Somebody (I think it was Ed) had some ideas about this last year,
but they were never implemented.

Hans

Hans Ronne

hronne@pp.sbbs.se



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]