This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Maze routing (was '"Smart" movement')
- To: Bob Carragher <bob at fla dot fujitsu dot com>
- Subject: Re: Maze routing (was '"Smart" movement')
- From: Stan Shebs <shebs at shebs dot cnchost dot com>
- Date: Sun, 09 Jul 2000 22:59:26 -0700
- CC: xconq7 at sourceware dot cygnus dot com
- References: <200007082243.PAA15635@prodigy.fujitsu.com>
- Reply-To: shebs at shebs dot cnchost dot com
Bob Carragher wrote:
>
> In any case, the user might still cause a lot of CPU time to
> be consumed. The game could through up another dialog box which
> contains a button to stop calculations. Then, whatever "best"
> route that was found would be displayed. (If none were available,
> then maybe a message would be printed in the messages area stating
> that this was the case.)
I'm not sure that this could be done with the distance-mapping
algorithm, because it works backward from the destination. But
it does stop when the unit is reached, so if the straight-line
distance is small, the process will be fast. For all I know, this
will always be fast, so may not be any need for special opts.
> But these strike me as relatively easy things to do. The harder
> task would be implementing the maze routing and the display
> aspects. Do you agree?
Actually I'd say the opposite. A routing algorithm is just a little
piece of self-contained computation, since all the infrastructure
is there, and display is mostly a matter of cloning existing code
and tweaking it to display the new images. Dialogs are more complicated
because each one is different, they can interfere with networking
(because of modality), and they can make game play very clunky if
they're popping up every two seconds.
Stan