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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Jun 12, 2003 at 02:32:13AM -0700, Per I. Mathisen wrote:
> 
> On Thu, 12 Jun 2003, Raimar Falke wrote:
> > >- It is wrong in principle to have randomness in movement. Very frequent
> > > atomic actions should be reliable.
> >
> > The same could be said about combats.
> 
> Combat is less frequent by some order of magnitude.

I agree.

> Also, AFAIK, combat is usually less random than rand() moves.

> > >- 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.
>                             ^^^^^^^
> Yes, my point exactly.

It is up to the players what they want. Remember previously we can't
show the turn number. And even the current code don't show it.

> > >- 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.
> 
> You assume there is a faster unit, whose moves_left > tile's move_cost.
> 
> Usually freeciv units have 1 MP (3 move_rate).

Ah I see. Two units with the same move rate which is less then
move_cost. The first one moves and succeeded and the second one fails.

In this case you can play safe and wait a turn for move points
recharge.

> > 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.
> 
> True, there are several such rare cases.

So will the AI cope with these?

> > 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.
> 
> TM_WORST_TIME is not deterministic. Some units may get there faster than
> worst time. We may throttle them, however.

I assumed that the path execution will follow the plan of the
path-finding hence will throttle it.

> Raimar, is it okay with you that rand() moves is made a server option, and
> that it defaults to off in the default ruleset?

I just don't see what it buys us.

The only point I see is that the AI can be more optimal in the
non-random case. However I think that the AI movement speed doesn't
have this much impact on the general performance of the AI that it
would be worth it.

What about a cheat (non-handicap) for this? So with this cheat the AI
will always win this random decision.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Of course, someone who knows more about this will correct me if I'm
  wrong, and someone who knows less will correct me if I'm right."
    -- David Palmer (palmer@xxxxxxxxxxxxxxxxxx)