[Freeciv-Dev] Re: movement

[Davide Pagnin <nightmare@xxxxxxxxxx>]

        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.

        Ciao, Davide