[MUD-Dev] Re: AFAP: As fast as possible, non linear...

Mik Clarke mikclrk at ibm.net
Mon Dec 14 21:38:42 CET 1998


Hmmm. A few years ago (quite a few) I had a maze generator running on a
lowly 0.7Mhz Dragon micro-computer, written in basic.  It was generating
2D mazes on a 12 x 40 grid. Took about 5 seconds to run.  C on a
sensible PC should be a lot faster.  The baic algorythm was to generate
the maze by moving from the end of the path to a randomly picked
adjacent cell that the maze didn't already reach.  When it got stuck (a
square where all adjacent squares were already on the path) it would
backup to find a cell that it could branch from.  The code is guarenteed
to cover every cell in the maze, including the one that leads to the
exit, and for them all to be interconnected.  As with all random things,
it is possible for it to generate mazes with very simple solutions.

Mik

quzah [softhome] wrote:
> 
> Hiya all.
> 
> I'm finishing up a tiny maze generator, and all I need is a
> tad bit of a speed gain. (Or more than a tad. :) I'm using
> a 10x10x10 cube, generated a plane at a time (10x10). I am
> linking them through one exit per plane (up/down), with the
> bottom level's exit leading "out". Here's the basic rundown:

> That about does it. The only thing I don't like about it is that
> that I have a crappy way of getting the new coords for the next
> recursive call. I'm currently using:
> 
>    mazePunch( number_range(0,9), number_range(0,9), FALSE );

Try an 8x8 or 16x16 maze and use number_mm() & 7 or 15. It's a little
faster (Sunder/ROM/Merc?/Diku?).

Mik
--
http://www.geocities.com/SoHo/Cafe/2260




More information about the mud-dev-archive mailing list