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

[quzah]

From: Mik Clarke <mikclrk at ibm.net>
Date: Tuesday, December 15, 1998 3:56 PM
Subject: [MUD-Dev] Re: AFAP: As fast as possible, non linear...


>quzah [softhome] wrote:

[snipped would-be maze maker]
>> 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 );
>
>Thinking about it, I'm not convinced that your algorythm will always
>generate a solvable maze.  Condiser:
>
> A-O-O-O O-O
>   | | | | |
>   O-O-O O-O
>   |     | 
>   O-O O-O-O
>   | | | | |
>   O-O O-O-O-B
>
>I think this would meet your loop exit crietria (used = 100), but it is
>not possible to get from A to B.  This could pose something of a problem
>for your players...
>
>Mik

If the cell was empty, and all its neighbors were empty, and it was not
the very first call to the function, it was supposed to not increment the
count and skip to another cell, to avoide the above. However, it sucked.
For some reason I cannot tell, it was making one way exits. I scrapped
that idea and am working on another variant, which I'm liking a lot more.

I should just give it up and grab someone elses code, but it wouldn't be
as fun (besides, then I wouldn't have anything to do). I'm liking this
method better, as it stores much less info. (Only 1/4th the data, though
I have dropped the size of the maze to 8x8x? instead of 10x10x?) Though
it could easily scale up to 16x16x? with a simple variable size change.

But yeah, it was making pockets, one way doors (which would be fun, but
it's not what I had in mind), and, well, it sucked. The 'count' was a
major problem. I can only guess as to why it was one way exiting.

Quzah.