[Freeciv-Dev] Re: (PR#4387) The Return of the Rand() Moves

["Per I. Mathisen" <per@xxxxxxxxxxx>]

On Wed, 11 Jun 2003, Raimar Falke wrote:
> Maybe you can give 2-3 short hints since the archives are big.

Ok:
 - It is wrong in principle to have randomness in movement. Very frequent
atomic actions should be reliable.
 - You can reliably show in the client the number of turns a goto will
take.
 - If you move a "stack" of units, say a charge and a bodyguard, you may
end up with one of them being allowed to move while the other won't, thus
splitting the "stack".
 - Unit rendezvous (eg charge & bodyguard) may fail.
 - It becomes quite hard for an AI to plan coordinated attacks when the
ETA of units is not known. A human player can easily improvise, an AI
player cannot. For example, if the offensive units get there faster than
the defensive units, you have a problem. This can happen with all of
best-case, average-case and worst-case pf methods.

> > As a last resort, I am for making rand() moves a server option, as long as
> > it defaults to off and the rand() move code path does not add complexity
> > to or slows down the non-rand() code path.
>
> IMHO it should be done the other way around: the ai code gets
> converted to the new path-finding and then we test how it performs
> with different cost models (TM_*). I think Ross will predict that the
> cost model won't matter. If this is the case this means that
> TM_STATISTICAL_WEIGHTS is only useful for humans.

It won't matter _now_ since the AI is incapable of coordinating much of
anything. But that is what we must change. pf should be part of the
solution, not the problem.

  - Per