[Freeciv-Dev] Re: movement

[rf13@xxxxxxxxxxxxxxxxxxxxxx]

On Mon, Aug 19, 2002 at 07:17:41PM +0200, Davide Pagnin wrote:
>       Hi all!
> 
> I've just returned from home at the end of my holidays, and found that
> an interesting and somewhat dangerous thread has started here in the ML.
> 
> Many of you knows that I'm a "civ 2 compatibility fool", so Imagine my
> disappointment when I see that there is a "clear consensus" about
> eliminating randomness in the movement code.
> 
> After a long IRC discussion I find out that this "clear consensus" is
> not so clear, at least ChaosE wants rand() in its place and also nouja
> expressed is doubts that eliminating rand() will do any help in the AI
> goto code.
> 
> Per said that with rand() in place is not possible or over-complex or
> over-time-consuming to coordinate an attack with multiple units and
> having them arrive in the same turn.
> 
> Per has good reasons to said this, but perhaps there are many other
> things that give troubles for this calculation task (I imagine also that
> sneak attacks from other players and changing of ZOC will interfere
> deeply with the task of coordinate such an attacks).
> 
> Yes, I know that perhaps rand() movement means another cause of trouble
> and eliminating it is not THE solution but is a good help. And I
> understand this because I like developing and developing problems,
> sometimes, ask for compromises solution.
> 
> I don't want to increase the complexity of the code that rules AI, but
> If I don't want either to have to accept bad compromises.
> 
> After this introduction, I will make my proposal, that is not simple and
> perhaps neither intuitive, so Per will be against, but It seems clear to
> me that Per point of view doesn't conciliate with mine.
> 
> If there is the STRONG need to change anything (And I vote to stay as we
> stay now) I suggest to make this a server option, there should be at
> least four choices, and one of them has to be rand() as we have it now.
> (In the case that this will make the AI behave ugly or not as good as
> wanted, we can state clearly that this rand() choice is deprecated in
> the case that AI is involved in the game)
> 
> For the other three option we should have:
> 
> 1. Behave like rand() == TRUE, like civ3 If I remember well, this is an
> advantage for aggressive player and movement, and let units always enter
> the attacked spot if it is free. This option can be seen also in another
> way, you will move in the free square if you have any remaining Move
> Point or fractions of them.
> 
> 2. Behave like rand() == FALSE, this will help defensive player, because
> there won't be surprises attack from the unknown. This option is like
> saying that the unit will move in the free square only if it has AT
> LEAST the whole Move points needed for enter that square.
> 
> 3. (This seems to me the same of COEFF=1/2 suggested by Gregory, but
> perhaps I'm wrong so I restate this in my words). If you want to enter a
> free square you need AT LEAST half the Move points needed for enter that
> square. 
> 
> Some side noted of this option, are what HALF means, in fact I don't
> want to make impossible for a warrior to climb a mountain nor I want a
> with 2/3 residue Move Points to climb ALWAYS a mountain! So we need to
> consider the maximum move point that the units get at the beginning of
> the turn AND the capping the move point costs for any terrain BUT (as
> suggestd by Pille) considering in this that it need only HALF of the MP
> for entering the square. This in practice means that we need to cap
> square move costs to the double of the maximum of the MP of the units!
> 
> Gregory and Per (strongly) suggested that making this a server side
> option will make things worse than now. 
> 
> I have not the knowledge of the problem that Gregory, Per and other may
> have, but thinking of this theoretically I can't imagine how having the
> 1, 2 and 3 solution in place will make things worse, all of them are
> deterministic and thus all that is needed is to have a function (call
> this move_point_cost_to_reach_tile) that returns a value (this function
> is the only one that has an increased complexity because of the presence
> of many switches). 
> 
> Perhaps I'm oversimplifying or perhaps THAT function is the REAL
> nightmare, but only the experts can say which is the truth.
> 
> The simplification above won't work for the rand() case, which remains
> unpredictable, but a, more or less, working solution is to make AI
> calculation for movement as the rand() has always FALSE result (option
> 2). (This can make AI less good than wanted, so it may be tried to
> considered option 3 for AI calculation when random is in place and
> coping obviously with some wrong calculation turn by turn).
> 
> A final note, I think that considering possible enemy units thus ZOC and
> attacks, will result to mitigate the help of deterministic calculation,
> that needs to be made every turn (or worse more time for the same turn),
> thus all the initial problem, thus having the possibility to indicate to
> a player how many moves will take to go in a square, is quite
> misleading...
> 
> I think that how the various options work are quite straightforward so I
> have not make any rrpmrrrrr like example, but I can make them if it is
> needed or wanted.

My option: the warmap code can't handle this. The path finding code
will cope with it. The path finding interface is IMHO stable enough
that code can be adopted to it. Since path finding code also has the
notion of turns other modes can be added to the current TM_LUCKY
(assume we are lucky at the rand()) and TM_SAFE (you guess the
semantic).

So I think that we should change the code only if the path finding is
in place and than however allow full customization.

        Raimar