I started working on a maze generating thingy after seeing KermM's BASIC algorithm (using some DCS7 routines). I have coded this in Grammer and I am still working on optimising it more. If you want to edit the size of the path (2 pixels wide, 3 pixels wide, et cetera), open the source and change the value for →S. 2 makes a 1-pixel wide path, 6 makes a 5 pixel wide path, for example. On my actual calc, I have a game started, but I haven't been able to transfer my programs.

Here is the code:

Code:


That creates a maze that is guaranteed to have a path from the upper left corner to the lower right of the screen.


MazEgg.8xp

One I have an actual game created (and the code cleaned up), I will upload it all to the archives!

That's great, Xeda! I'm glad I was able to give you some ideas to get this done. I presume you found the Wikipedia article on depth-first search-based maze generation algorithms more understandable than the last time you tried to read it? Are you planning to expand this to let users use your program to solve the maze as well?

Yes, I am fairly sure I understand it now I finished the program on my actual calc that allows one to navigate the maze, too. It inflates the pixels to 4x4 so the player only a portion of the maze. I will probably copy it into Wabbit later and then upload it (with a screen shot).

I've used that algorithm in Java for a Minecraft maze generator. Let me know if I can lend any assistance.

Hey, this is cool! It's really fun to watch it walk around like that an make the maze.

Copy it by hand? Surely there are some tools available to you that would make that easier

Yes, I actually realised that in a cross post elsewhere XD I am so used to programming directly on a calculator.

The program is now uploaded to the archives Here is a screenshot:

Recursive division algorithm is best algorithm.

Are you talking about the one where you divide regions of the screen and make subdivisions iteratively until you have a maze?

You should make your dude a little smaller than the width of the path so he sticks out more.

Yes. You have a box. Split it in two, punch a hole through the divide. Split the two subboxes in two, punch a hole through their divides, etc. Until the subboxes are size 1.

Should I then put a cap on the size of the path? I would make it a minimum of 3 pixels wide and that should help. The adjustment would be changing the type of rectangle drawn (white border, black inside instead of a black filled rectangle).

@Pseudoprogrammer: I should try to implement that, now that I am not as afraid of recursive algorithms XD I am always too antsy when it comes to how much RAM is being used. I think I could get away with using one of the 768-byte buffers without fear of overflowing it.

I don't think a cap is necessary; I guess what I'd do is make it so it's 2 less wide-and-tall than the walls, until the walls are as small as it can be, then just make it as small as it can be. Like, if the walls are 5x5, make the dude 3x3. If the walls are 3x3, make it 1x1. If the walls are 1x1, make it 1x1.

Does that make sense? Alternately, greyscale the dude.

Yes, that makes sense. If I do grayscale, I probably won't need to worry about the size of the player sprite. I am a little worried about how it will look when the screen is scrolling (I am not sure if there will be a lag). I will try to see how it looks, if it looks decent, I will keep it gray

That's what inspired this project in the first place, I believe.

Yes, indeed it is! I am hoping to get it to work because it looks really cool (it could make a decent screensaver if it is fast enough).

Also, I tried Merth's greyscale suggestion and unfortunately it is too laggy when scrolling for me to like. If I make it less laggy, I cut down n the grayscale frame rates, sot he gray looks rather poor. I kind of wish I had made it possible to update a portion of the screen with Grammer .__.