Alright, folks. I finally have something I can actually work with! This is the thread for Window Maze, my latest project. I came up with this last night while doing homework.
Basic idea: You, as usual, must navigate through a maze to get to the end.
The twist: You can't see much. You are a pixel inside a thirteen-pixel-square white box. You can see the maze through this. But everywhere else is covered in a black mask. The only way you can succeed is to gaze through this tiny "window" and go from there. There will be five mazes of varying difficulty, and each will have its own best time. I'll post a screenshot as soon as I get the beta working.

I presume that you envision this as being a top-down, 2D scrolling game? Sounds like fun to me, and of course ask us for help. I like both that it aims to exercise the player's memory, and that the limited window will make it nice and fast in pure or hybrid basic.

It's in Axe. Sorry, Kerm, but I need the multiple-buffer and grayscale support. And the speed.

You don't need any of those things; a competent BASIC coder could do everything except grayscale at a good speed. Still, I respect your decision to make it Axe for the grayscale.

You could, of course, do the grayscale with xLib.

This sounds like a really neat game, though. I look forward to it, regardless of language!

How can you render multiple buffers at the same time?

I also like using Axe because I know more of the code tricks and because fewer people are able to shame my coding.

You can use Pic variables as buffers, swap them out, or/and/xor them together, etc.

Wouldn't that be rather awkward?

I don't understand the question. It's no more or less awkward than any other method of using buffers in any language...

It's finished. After two solid days of work, I have WM 1.0 ready for posting.
Expect it this afternoon. Feel free to post suggestions for upgrades and possible bugfixes. Good luck.

It's Axe and grayscale? Does it randomly generate maps? If so, what algorithm does it use?

No random mazes yet. I just included three. But if that's a feature you want added, tell me!
I was thinking about that myself. . .

I definitely would like that feature. I think you have three options:

(1) Just include manually-generated mazes
(2) Just include a generator to automatically make mazes
(3) Have a "campaign" mode using a set of manually-generated mazes, plus a random generator for when the user beats the campaign mode

Yeah, that's a great idea. Thanks. Only one problem: How to execute the plan.
The problem with a maze generator is that, in order to ensure that the maze is always playable and that it is still difficult enough to be challenging, there would need to be an incredibly complex algorithm. I'm not sure how I would go about making that.

Actually, the algorithm is far from complex. A simple Google search will solve it for you:

http://lmgtfy.com/?q=maze+generator+algorithm
http://en.wikipedia.org/wiki/Maze_generation_algorithm

Great. Now I have to figure out how to go about implementing it. This is going to be hard, so feel free to help.

Well, none of those are trivial, but neither do I feel that any of them are prohibitively difficult. Almost all of them are recursive algorithms of some form or another, so if you're unfamiliar with recursive algorithms, I recommend you learn. The recursive division one looks particularly attractive to me.

I guess I'll have to learn. Thanks for the help.

My pleasure; please continue to post questions here. If you want a sample program that's not horribly complicated but uses recursion, take a look at this program of mine:

Dynamic Recursive Fractal Generator v1.2

Lovely, Kerm.
Two questions:
1: Sort of hard to understand
2: Why did you have the subroutine call itself?

As an expert programmer once said to me: