I saw a neat algorithm for generating mazes on YouTube called "Origin Shift" and tried it out in PICO-8. Works pretty good!
This first cartridge generates a maze and puts a player inside it. You can move around. Pressing X will generate a new maze. The algorithm guarantees that any cell in the maze is reachable from all the other cells. So you can regenerate the maze around the player without worrying that they'll be trapped.
Maybe this becomes a game; maybe not.
This second cartridge was for debugging. The idea with Origin Shift is that the maze is a directed tree graph with a root, or origin. You start with a very simple "maze" and then iterate a bunch of times, moving the origin around, swapping pointers to ensure the whole thing stays a directed tree graph. But my code wasn't working, so I needed to visualize what was happening better...
The cartridge starts with the simple starting "maze" with the origin marked with a red dot. Pressing X will step through the iterations. Pressing Z will fast forward though the iterations, 30 per second. It takes about 2,500 iterations to really scramble up the maze, so you'll be holding down the Z key for over a minute.
It did help me fix my code, so time well spent.
Finally, here's the YouTube video describing the algorithm:
https://www.youtube.com/watch?v=zbXKcDVV4G0
I could see that as a 2 player game : instead of a 16 x 16 maze, have a 32 x 32.
Each player starts in a corner, and the red dot keeps modifying the maze as the players move in the maze.
You win a point by reaching the red dot or a static target in the maze.
Reaching the target makes it respawn somewhere else, reaching the dot resets the maze and the players. there could also be a follow left wall and a follow right wall enemies that can push the players starting in the two other corners.
For the game view, you'd either get a camera centered over the two players if they are near enough, or a split screen with a diagonal line goins through the center of the screen, so each player has half of the screen and you know the direction of the other player in the maze.
Interesting ideas. Not sure how I would divide the screen diagonally given that the screen is a bunch of tiles. Horizontally or vertically would be easy.
I kinda of thinking a Wizard of Wor sort of game. Enemies trying to track you down, with the maze rescrambling on a timed basis, or maybe, as you noted, by reaching an object.
Maze generation is such an interesting topic. Thanks for sharing the algorithm, another one to add to the stack :)
For the split screen, when the two players are too far apart to share the same fullscreen :
screen is separated in two halves by a line (purple). That line goes through the middle of the screen and its slope is perpendicular to the line going through the two players.
If the line hits the top and bottom of the screen, map display is handled colums by collums.
If it is hitting left and right :
top part of the screen above the line is displayed with map.
bottom wart under the line is also handled with map.
for the middle section, for each screen line, the horizontal segment left of the purple line is handled with a tline, and the right part with another tline.
Worst case where the players are on a diagonal, that's 128 x 2 = 256 tline calls per frame.
If that's too much cpu, we could use spr() to display all the map tiles that fully belong to a players field of view, and cover the remaining black staircase with a thick black line. That line would have variable width and obscure a significant part of the screen surface...
Ah, I get it now! I haven't played around with tilne at all. Thanks for the explanation!
[Please log in to post a comment]
