[Freeciv-Dev] Re: movement

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Wed, Aug 14, 2002 at 05:41:32PM -0500, Jason Short wrote:
> Christian Knoke wrote:
> 
> > Yes. - I've had the same idea like Brandon, with the goto. Implicit
> > goto for the last (incompleted) move. Only needs to save to MP rest
> > with the goto route. No need for extra grafic IMHO. Uhm, but we want
> > to remove that server goto, right?
> 
> I don't think an implicit GOTO is necessary.  I.e. the game should not 
> FORCE you to move in that direction at the start of the next turn. 
> However, you should only get the bonus movement points if you do move in 
> that direction.  I would think adding something like

Forcing is easier to code and present in the client. I don't know a
nice way to present "you have x bonus points if you move at this
direction".

>    int move_points;
>    enum direction8 move_dir;
> 
> to struct unit would be a good start.  This just stores the movement 
> points the unit has left over from the previous move, and in which 
> direction they apply.  This then needs to be updated every time the unit 
> moves (reset to 0 on a successful move; set to the appropriate values on 
> an incomplete move).
> 
> (But, I don't know how the server and client interface one this. 
> Someone more knowledgeable would have to write this code.  Also there's 
> a problem if you #include map.h (with enum direction8) from unit.h, 
> since map.h #includes unit.h as well.)
> 
> -----
> 
> The inverse system seems a little more fair, actually.  In that system 
> (from Ben Mazur's e-mail) if you don't have enough move points to move 
> from A to B, you get to make the move but lose the points from your next 
> move.  This is more fair for the opponents of the player moving, since 
> the "extra" move comes in at the end of this turn (when you're just 
> moving from tile to tile) rather than the next turn (when you could 
> actually move further than you normally would, *and attack*).

> The question is, how does this apply to a unit moving onto a tile that 
> requires more movement points than it's total?  If a musketeers 
> (movement 3) moves onto mountains (movement 9), does it lose 6 movement 
> points from its next turn?  If it does, do 3 of those carry over (so 
> that it, in effect, takes 3 turns to make the move)?  Obviously, having 
> this happen would be a major change to the game rules.

IMHO for capping all terrain move costs at the move rate. So the move
in the case above will cost 3.

> Note that all of these systems could use the above data structures for 
> storage, and could all be dealt with by the AI.  So it would be feasible 
> to have this be a ruleset/server variable:
> 
> 0 - Unused movement points get saved for next turn
> 1 - Moves that take too many movement points are not completed, but the
>      movement points will carry over for the same move next turn
>      (default)
> 2 - A move that takes too many movement points will be completed, but
>      the extra movement points will be taken from the next turn's moves.
>      A unit may still make any move so long as it has full movement.
> 3 - A move that takes too many movement points will be completed, but
>      the extra movement points will be taken from the next turn's moves.
> 
> Note also that it would probably be a *major pain* to have the AI deal 
> with all these systems.  But perhaps it would be productive to implement 
> them all so that players could try them out and decide what's best. 
> Actually implementing them should be pretty easy - it's getting the AI 
> (specifically warmap/pathfinding code) to work with all of them that 
> would be tricky (probably very ugly).

The warmap doesn't have the idea of time. It just adds the costs. The
path finding have the notion of time. But implementing the cases above
can't get much uglier than the current cases (update_min is for the
case where the user says that he will always be lucky with the current
rand() call, update_max is the case where the user plays safe and
don't use the rand() call at all):

static void update_min(int cost, int move_rate, int *moves_left, int *turns)
{
  assert(cost >= 0);
  assert(*moves_left >= 0 && *moves_left <= move_rate);

  if (*moves_left == 0) {
    (*turns)++;
    *moves_left = move_rate;
  }

  if (*moves_left >= cost) {
    *moves_left -= cost;
  } else {
    *moves_left = 0;
  }
}

static void update_max(int cost, int move_rate, int *moves_left, int *turns)
{
  assert(cost >= 0);
  assert(*moves_left >= 0 && *moves_left <= move_rate);

  if (*moves_left >= cost) {
    *moves_left -= cost;
  } else {
    if (*moves_left == move_rate) {
      *moves_left = 0;
    } else {
      (*turns)++;
      *moves_left = move_rate - cost;
      if (*moves_left < 0)
        *moves_left = 0;
    }
  }
}

Adding extra cases here isn't the problem (although Gregory may not
like them). The problem is that the AI doesn't use the path finding at
all but the warmap.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner