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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Wed, Jun 11, 2003 at 09:46:15AM -0700, Per I. Mathisen wrote:
> 
> 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.

The same could be said about combats.

>  - You can reliably show in the client the number of turns a goto will
> take.

You can reliably show the minimum 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".

So you start moving with the slowest unit and only if this unit moved
you move the other unit. This are 5 lines of code.

>  - 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.

You have to cope with such things anyway. Say you move through a
fogged tile with a road and the enemy has destroyed the road.

> > > 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.

If you want a deterministic pf you get it with TM_WORST_TIME. You may
now argue that this will be produce non-optimal results i.e. you may
be able to move your units faster. But for this the AI needs to be
more smart.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."