This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Maze routing (was '"Smart" movement')


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]