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: pathfinding refueling


On Fri, Dec 19, 2003 at 02:42:58AM +0100, Hans Ronne wrote:
> I think we need to refocus this discussion on how to handle refueling in
> the best way. Peter's inital analysis had a lot of good points in it, but
> so do some of Eric's comments. Here are my own reflections:
> 
> >Refueling points are units whose capacity and current supply exceeds the
> >travelling units capacity, are either immobile or have a "refueling"
> >task.
> 
> I would consider anything that has excess fuel a refueling point, even if
> mobile and on a move-to task. Think of a carrier moving across the ocean on
> its way to the enemy shore. It must be able to launch combat air patrols
> while in transit and the latter must be able to find their way back to the
> carrier for refueling.
> 
> What should be considered excess fuel is the key question. In the standard
> game, I found some time ago that airplanes almost never resupplied from
> carriers, since the threshold was too high. I therefore lowered it. See
> ChangeLog 2003-08-17  for details.

What if the path was precalculated several turns before and the unit has
moved on. A plane could run out of fuel and crash. It becomes a
coordination problem if the carrier is moving. If you can tell me how to
solve this, I'll do it your way.

> 
> > > >1) The storage of that material is greater than zero
> > >
> > > Does this include treasury storage?
> >
> >Its not a fuel if it is not consumed every turn or hex.
> 
> I think Eric was making the point that it is possible for fuel to be
> consumed every turn or hex, but then filled up again at the start of each
> turn from the treasury. This is a valid point, but it should be relatively
> easy to handle.

I would not consider it a fuel for pathfinding purposes in that situation because
there is no need to go to a supply point and refill. I would assume
that the supply code would replenish each turn.

> 
> >Maybe we need to take a more piecewise approach to path-finding.
> > <snip>
> >So we don't try to calculate the entire path ab initio (which
> >would require considering multiple fuel types and would be messy),
> >but rather do it in segments....
> 
> This is an interesting point not only with respect to refueling, but for
> path finding in general. One problem with the new path code is that if a
> unit cannot find a path to its destination, it does not move at all. It
> just sits where it is and accumulates failed move-to tasks. With the old
> code, a unit would move in the direction of its target even if it could not
> get there. Problems such as blocking enemy units or a lack of transports
> (maybe because the necessary advances had not yet been researched) would
> frequently get solved while the unit was on its way, and the side would
> gain time, which is always important.

Segmentation makes the whole thing suboptimal. It is relatively
straightforward to allow ferries to be constructed and even developed in
the pathfinding code so I hope that addresses the situation.

> 
> The point here is that a war is a very dynamic situation. Tactical
> decisions, including path finding, should be reconsidered frequently since
> conditions may change rapidly. It could therefore make sense, as Eric
> suggests, to recompute paths on every leg of a journey, and also to
> reconsider what material is currently limiting the range (and thus to be
> considered as fuel) for this unit here and now. To this I would add that if
> a clear path to the destination cannot be found, any move that takes the
> unit closer to its destination should be considered.

I disagree somewhat. If there is no way, then that is simply that. The
ai or whatever should assign the unit a different task. What if a ferry
is assigned a hit-unit task on an enemy aircraft in the middle of a
continent?
> 
> The notion of precomputing a complex path involving perhaps both ferry
> tasks and visits to multiple resupply points is very neat. I am therefore
> not saying that one should not calculate the entire path ab initio (as Eric
> put it). What I am suggesting is that a unit should stop at each leg on its
> journey and dynamically reconsider how to best get where it wants to go,
> just like a human would do. This would not be overly burdensome and it
> would make path finding much more adaptive.

I would agree actually. Not every hex, perhaps every other turn or
something like that.

> 
> A final comment is that this is also how the combat code has evolved over
> the last few years. The strategy code was originally much more important. A
> unit would get assigned to a theater, move there, and hold a position, with
> no consideration for what would happen on the way. A unit in transit would
> not attack enemy units or come to the rescue of beleaguered cities. This
> lack of flexibility made it very easy to beat the mplayer. For this reason,
> we added the action-reaction code which dynamically reassesses what the
> unit should do.

The AI is preety interesting in that often extremely simple algorithms
have the best effect. It is somewhay beyond my conceptual capacities at
the moment though. Obviously we need to stop it losing aircraft etc to
lack of fuel.

> 
> I think that in general, an AI that dynamically recomputes its tasks
> (within reasonable limits) will do much better than a static AI which
> adheres to a precomputed grand plan for each of its units.
> 
> Hans

Agreed.

Peter
> 
> 
> 
> 
> 
> 


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