There's not much gameplay here at the moment - just wander around the maze. It's mostly an exploration of some procedural generation. I might yet try to build a proper game around it, but I thought it might be of some interest on its own.
- 16x16 room maze generated with Kruskal's algorithm plus some extra connections to make it more interesting.
- Basic random room generation so that each room has connections to adjacent rooms that match up.
- Automatic wall borders.
- Textures assigned by randomly combining a selection of 3-colour palettes with a number of different wall, floor and border textures.
- Basic texture transitions between rooms.
- Transition textures and borders are assembled into pre-combined and paletted tiles on entering a room, saving a lot of time in rendering each frame.
- Basic shadows under the player and walls to give a bit more depth, with some hacky code to render quickly.
- Each room has a few extra walls scattered around to make it a bit more visually interesting, but there are no constraints and it occasionally clogs up an exit.
- Sometimes there's a flash of garbage textures on entering a room, because the texture assembly works by rendering every tile combination to the screen, then it's memcpy'd back into sprite memory. This could probably be avoided by drawing straight into sprite memory in the first place, but it needs more custom code.
- Some of the colour palettes clash pretty badly, and there's no constraints to try to prevent the walls and floors being the same or clashing colours. Some rooms are utterly garish, and the transitions don't look great.
- There's only about 20% CPU free even with the optimizations. Any further decoration probably can't cover much of the screen.
- The code is pretty incomprehensible right now. I've not yet made a major effort to clean it up and try to improve the identifiers and comments. If you're curious about any part let me know and I can try to explain it.
It currently uses 4020 tokens, but I think that could probably be reduced a fair bit by stripping out redundant code.
Very cool, I'm currently exploring different algorithms for generating mazes. I really like what you made here, a lot of cleverness too with the texturing and transitioning.
I think you could probably do away with basic shadows though, as the code used to make them might be not worth it(just a hunch though)
I also have a hunch that if you go about cleaning up code, you might find more optimizations and get the CPU usage down.
How many rooms does it make?
Really cool so far!
The shadows are tricky. I find they make a huge difference to the readability of the room (i.e. how distinguishable the walls and floor are), but they are verrrry slow. There are two methods for rendering them - the super-slow pixel-by-pixel version that works at any x/y coordinates, and the faster-but-not-quick version that only works grid-aligned and must not be used across the edges of the screen. The latter is absolutely necessary to keep the frame-rate okay.
I'm not sure the texture transitioning is really paying for itself right now. The borders look lovely, but the texture transitions only look so-so. That said, once they have been set up for a room they are basically free (so far as CPU goes), whereas the borders need an extra rendering pass.
It's currently generating a 16x16 room maze, where each room is one screenful, so 256 rooms total. As far as I can tell there's still plenty of Lua RAM, so that could easily be increased - the maze itself is stored in a Lua table, but the map data is all generated deterministically when you enter each room. I don't want to go so big that the player becomes hopelessly lost, so I'll probably not go much larger.
I think I'm going to leave the tech about there and focus on building a game on top of it for now. After that I'm interested in seeing how large and detailed a free-scrolling world I can make, but I don't want to get too ambitious for the time being.
Really cool stuff!
I wonder if you can cache the shadows at the beginning and then render them as sprites without having to calculate them in real time? I haven't looked at the code but that thought crossed my mind so thought I'd share.
I hear you on not getting too ambitious, so far you have something really good and I'm looking forward to seeing it develop further :)
Log in to post a comment