This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Possible movement improvement
- From: Hans Ronne <hronne at comhem dot se>
- To: bd1 at sysmatrix dot net
- Cc: xconq7 at sources dot redhat dot com
- Date: Mon, 5 Jul 2004 19:54:20 +0200
- Subject: Re: Possible movement improvement
- References: <40E911F4.5090704@phy.cmich.edu>
>If I read the code correctly, it seems to only allow two of the possible
>four directions to be tried.
>I have seen units get stuck behind 'C' shaped obstacles, and this may
>partly explain why. A proposed change would be:
Right. Units getting stuck behind obstacles was a well-known problem with
the old move code. This was fixed by Peter Garrone's path-finding patch,
but since we reverted it (because of sync problems) we are now back to
square one :-/.
> fact = (flip_coin() ? 50 : -50);
> x1 = unit->x - ((fact * dy) / 100);
>fact = (flip_coin() ? 50 : -50); /* this line is new */
> y1 = unit->y + ((fact * dx) / 100);
>
>This may allow the unit to try any of four directions randomly.
>
>If this change makes sense, it will need to be in both mplayer.c and
>iplayer.c.
The reason for trying only two directions, if I remember Stan's argument
correctly (this has been discussed on the list before) is that he wanted to
keep the general move direction forward. So units can sidestep but not
backtrack. Which will trap them behind a C-shaped obstacle, as you noted. I
see no strong reason not to try out your patch, however. Have you tested it
yourself (in more than one game) and were you happy with the results?
Hans