Re: "Smart" movement

[bob at fla dot fujitsu dot com (Bob Carragher)]

> You're quite right that units can be trapped in local minima.
> I'm skeptical about your observation of congestion points,
> because there isn't anything in the code that treats towns
> differently - if the only option to get somewhere is to enter a
> town, the unit will just do it.  Just to be sure, I tried out
> a case similar to yours, and the infantry strolled right through.

I think I understand more clearly what I was observing, however,
thanks to your explanations about movement.

One quick question about towns:  will units continue to enter
towns, unless the towns are full?  Let's say that you have a
town which is the "pass" for a mountain range, and you have a
bunch of armor on one side trying to make their way to the
other side.  Will 2 armor enter (or pass through) the town in
one turn?  Or will only 1 armor enter the town in one turn (and
leave it the next)?

> The routefinding algorithm right now is purposefully minimal;
> this is so units don't go off and do something really stupid
> while you're not looking.  It identifies two classes of directions,
> the 1 or 2 directions that get the unit 1 cell closer to its
> destination, and the 2 directions that don't change the distance.
> The algorithm will fail rather than let the unit move further away,
> since without a path plotted all the way to the destination,
> there's no assurance that the unit will get there.

How is distance defined?  Is it the number of cells separating
the unit from the destination, regardless of terrain or unit
occupation in the intervening cells?  Or are terrain and unit
occupation taken into account?

If it's the former, then in the example I showed (where an armor
was sitting on a peninsula that jutted towards the destination,
but was a dead-end), there is no direction that brings the unit
closer to its destination.  If it's the latter, then it depends
upon whether unit occupation is also taken in to account, because
there were armor that were sometimes moved (temporarily) into the
cells around the stalled unit.

> So first the unit tests the 1 or 2 directions and if there is
> a choice, it randomly chooses (with weighting as described above)
> one of them to try first, but eventually tries all if the actual
> move action doesn't work.

I guess this also depends upon the algorithm that sequentially
picks units.  I know you have an algorithm which tries to pick
units that are in a general area before moving on to another
general area.  Is it possible for one unit to always be picked
as one of the last ones in an area?

> If all this seems lame, well it is.  There should be a maze-solving
> algorithm that sits over this.  Maze-solving may result in a
> complicated path that takes too long - perhaps you just want to
> get a unit to the closest shoreline so it can get picked up by
> a transport that's almost done building - so there needs to be
> some player control over when it's used.  (If anybody wants to
> code this, use the distance-mapping algorithm as described in
> various books; scratch memory layers are available for this.)

Is it possible to implement a maze-tracing scheme?  That is,
one could conceivably imagine turning on a maze-tracing option
where if you click on a destination, then a route is traced and
highlighted.  You then click again to "accept" the route for the
unit.  Or, you can try to modify the route.  The point is that
the unit does its best to trace this route, deviating from it
only when it absolutely must.  (E.g. the unit will stall rather
than continue on the path if a unit blocks its path, unless the
cell in which it is stalled causes it to lose fuel, etc.)

This option could also be tailored so that it doesn't activate
unless at least n cells separates the unit from its destination
(as the armor rolls) -- and that preference could be set up on
a unit-type basis or in general.  (E.g. an infantry moves only
1 cell at a time, so you might want to trace this for distances
greater than 10 cells, but a jeep [used in my "abstract" period
world for transporting ground troops] moves 3 cells at a time,
so this might be activated only for distances greater than 20
cells.)

Is this already implemented?  Is it too much hassle, or would
cause a blow-up in memory?

				Bob