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]

pathfinding refueling 2 (was Re: pathfinding refueling)


On Sat, 20 Dec 2003, Peter Garrone wrote:

>I do not see it as the role of pathfinding to
> guarantee that all units remain in supply at all times.

So you then think it is OK for a unit following a path to get 
stranded or suicided in some cases?

> > Nor do I. I was simply pointing out that one fuel-material may be 
> > lower than another, even if the "full-tank" range of the lower 
> > fuel-material is greater.
> 
> Then I assume we agree that the pathfinding does not have to guarantee
> supply.

You assume incorrectly, insofar as pathfinding can guarantee 
supply.

> The pathfinding does not have to guarantee supply, as we agreed. 

We did not and do not agree.

>It is
> merely improving playability by reducing the number of clicks.

A laudable goal, but at what sacrifice? A stranded unit here, a 
dead unit there?

> On a side note I wish you would give those bellum materials proper
> names.

They have abbreviated names so that they will properly fit on some 
displays. However, the help for each material mentions what it is 
and what it is good for.

> c is not an issue, because any aircaft can fill up on c when it
> fills up on fuel.

Not necessarily. In a combat zone, the resupply point may have 
already been drained of c.

> An automobile service station usually supplies water air and oil
> as well as fuel. 

"Usually" is key here. A service station may be sold out of any of 
the above.
This working assumption that you keep making about the 
availability of supplies is dangerous and unrealistic.

> materials were supplied at different positions. Then the pathfinding
> would take care of the material having the shortest effective range, 

The scenarios I provided already demonstrate the fallacy of 
that approach. Unless by "effective", you mean material on hand, 
rather than assuming a full-tank supply.

> What example?

The one I gave where a unit runs out of c while in pursuit of f1 
or f2.

> > ?
> 
> Adhoc, sub-optimal. It is easy to provide cases where it would fail.

Please do. I had hoped that our discussion would have been more 
along these lines.

> It takes no advantage of the optimality of the astar pathfinding
> algorithm.

Maybe not from point A to final destination B, but from A to 
resupply destination C, it certainly does.

> My approach gives the player as much control as previously,

Sure, but previously a unit would not be endangered by movement 
unless the player explicitly told it to do the endangering 
movement.

> and freedom
> to kill off units, as is currently the case.

My approach preserves this freedom as well.

> But you do not address this issue.

How not?

> This is not a proper description for a workable algorithm.

It is not a detailed description, but it is a valid 
general description.

> It certainly does not address the termination problem.

How not?

> What if you run out of material A while going for material B. 

Most likely the unit would be going for material A rather than 
material B, if there was a danger of A running out before B.

By contrast, your answer to this case, which I have raised several 
times now, seems to be that you only care about B (assuming that 
it has the shorter full-tank range), and so it doesn't matter what 
happens with A.

>What if a
> later leg is found to be impassable.

A leg cannot be impassable or else it wouldn't be a leg. (Or does 
your implementation of Astar allow for impassable paths to be 
calculated? :-)
But, maybe you are wondering what if the unit cannot reach its 
final destination because of the chosen legs?
Well then, I guess it won't reach its final destination. At least 
the unit is still alive, and didn't die an automated death. It 
would be closer to the final destination.

> How do you determine the most
> suitable refueling hops.

I illustrated this in the scenarios I provided yesterday.

> I am not interested in implementing this approach myself, so would
> prefer not discussing it in this thread.

I renamed the thread....
I am not interested in having two competing approaches. I have 
demonstrated aspects of yours which are unsound. I have yet to be 
shown how mine is unsound.
 
> For all current games, if the unit takes on all possible fuels at each
> refueling point, the single fuel approach will work.

Sure. "If" it takes on. Even if a game is designed to provide all 
the possible fuels at one resupply point, that resupply point is 
not guaranteed to be able to provide them.

So even if someone doesn't design a "stupid" game, it is still 
possible for your approach to do something bad to a unit.

> different point to get c. There are several ways to handle this. If the
> pathfinding had to handle it, then the best way would be to extend the
> path node state to include two fuel quantities.

I have already stated that I think the best way would be to focus 
on whatever was the more critical fuel-material quantity.

Trying to create a path based on two or more fuel-materials 
simultaneously would be a computational nuisance, as I think both 
you and I agree.

> The best way to handle this hypothetical situation is to simply have the
> player ferry the aircraft between the points that supply c, and it will
> pick up ordinary fuel in intermediate hops. 

If it doesn't run out of c en route.

> > I agree, if the players are willing to occasionally have their 
> > units 100% automatically stranded or suicided....
> 
> Well units occasionally get stranded and suicided now.

Sometimes a unit may get stranded due to changing game 
circumstances (as Hans said, war is a dynamic situation), but 
there isn't a thing you can do about that (except possibly play 
better :-). And, of course, a player may choose to suicide a 
unit....

> has to think it out. I dont believe that the pathfinding should
> guarantee that no unit will ever be lost to lack of supply. 

It cannot guarantee that, but it should not be callous about it 
either.

>Rather it
> should automate the micromanagement (credit to Hans for this term) a bit.

Agreed.

Eric


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