If I remember correctly (and it was a few years ago), I used this algorithm to generate mazes for a multiplayer randomly generated maze navigation game. The second-year embedded systems computer engineering course at the University of Canterbury has a two-person project where we had to write some sort of two-player multiplayer game. The only input was a directional button and I think one other button, and the only output was a monochrome 5x5 screen of LEDs. Each person had one device, and they had to communicate using this horrible little infrared link that didn’t work properly under the flickering fluorescent lights of the computer science building’s computer labs. The devices had something like 32k of ROM and 2k of RAM? It may have been less.
Most people did something like pong or some other fairly simple little game. I’ve seen at least one tetris in the years since, but using only 3-pixel ‘tetronimos’ due to the small screen. My friend and I made a fantastic little maze game where there was a fairly large maze you could move around in, much larger than the screen, and you had to find the blinking square. You could alternate turning on one of your pixels every other frame to get a half-brightness pixel, I think 1/3 and 2/3 brightness were also distinguishable but anything more detailed was difficult to tell apart. You could also blink at longer intervals if you wanted actual blinking, of course.
I had the challenge of trying to get a maze generation algorithm that would work in the tiny confines of the device’s memory. I think I ended up going with this algorithm because you can do it entirely in-place. Most if not all of the other algorithms I found required a fair amount of working memory separate from the maze, and that just wasn’t going to work. I implemented the algorithm and then lowered the size of the maze until it fit on the device. I had to pack the maze into bytes bit-by-bit, so that it looked something like this in memory:
As I recall, generating a random number was a pain as well, I think we might have ended up seeding an LCG from the random bits we got from the fluorescent lights. Unfortunately, I appear to have completely lost the code. :(
EDIT: I found the device. 5x7 pixel screen and an ATmega32u2 in fact, which means 32k of flash and 1k of RAM, but otherwise my description is correct.
If I remember correctly (and it was a few years ago), I used this algorithm to generate mazes for a multiplayer randomly generated maze navigation game. The second-year embedded systems computer engineering course at the University of Canterbury has a two-person project where we had to write some sort of two-player multiplayer game. The only input was a directional button and I think one other button, and the only output was a monochrome 5x5 screen of LEDs. Each person had one device, and they had to communicate using this horrible little infrared link that didn’t work properly under the flickering fluorescent lights of the computer science building’s computer labs. The devices had something like 32k of ROM and 2k of RAM? It may have been less.
Most people did something like pong or some other fairly simple little game. I’ve seen at least one tetris in the years since, but using only 3-pixel ‘tetronimos’ due to the small screen. My friend and I made a fantastic little maze game where there was a fairly large maze you could move around in, much larger than the screen, and you had to find the blinking square. You could alternate turning on one of your pixels every other frame to get a half-brightness pixel, I think 1/3 and 2/3 brightness were also distinguishable but anything more detailed was difficult to tell apart. You could also blink at longer intervals if you wanted actual blinking, of course.
I had the challenge of trying to get a maze generation algorithm that would work in the tiny confines of the device’s memory. I think I ended up going with this algorithm because you can do it entirely in-place. Most if not all of the other algorithms I found required a fair amount of working memory separate from the maze, and that just wasn’t going to work. I implemented the algorithm and then lowered the size of the maze until it fit on the device. I had to pack the maze into bytes bit-by-bit, so that it looked something like this in memory:
As I recall, generating a random number was a pain as well, I think we might have ended up seeding an LCG from the random bits we got from the fluorescent lights. Unfortunately, I appear to have completely lost the code. :(
EDIT: I found the device. 5x7 pixel screen and an ATmega32u2 in fact, which means 32k of flash and 1k of RAM, but otherwise my description is correct.