Update:
added function fixstages to TMap class, for prevent unreachable platforms from pattern in stage. Implementation is very simple and you can extend method as you wich. Currently is checked only "platform" tile id.
Method:
From generated POI point is created connection to free edge in stage and remove platform tiles between connected stages if exist.
This example show procedural level building combined from two method:
1) maze generator - for wall
2) predefined pattern - for stages (platform, ladder, obstacles, ...)
Every room is created from 2x2 stage, and stage is defined in sprite as template, where color index = tile id descibed in data structure:
self.template[0] = {name="empty" ,color=1,tile=self.starttile+0,probability=1.0}
self.template[1] = {name="wall" ,color=2,tile=self.starttile+1,probability=1.0}
self.template[2] = {name="platform" ,color=3,tile=self.starttile+2,probability=1.0}
self.template[3] = {name="breakable",color=4,tile=self.starttile+3,probability=0.5}
self.template[4] = {name="obstacle" ,color=5,tile=self.starttile+4,probability=0.5}
self.template[5] = {name="ladder" ,color=6,tile=self.starttile+5,probability=1.0}
self.template[6] = {name="item" ,color=7,tile=self.starttile+6,probability=0.5}
self.template[7] = {name="exit" ,color=8,tile=self.starttile+7,probability=1.0}
self.template[8] = {name="hazard" ,color=9,tile=self.starttile+8,probability=1.0}
|
Maze is generated in stages count and walls are implemebted as wall to stage.
Control
[z] = generate new maze with wall
[x] = generate new order of patterns in stages
arrow=scroll map
this is very cool ! Can i just add some platformer player into this ? I guess there is a few customization needed to make this playable as theres no level end , and some unreachable paths
Hi.
It is an idea, when you need your modification it's ok.
For prevent unreachable stage (wall) is prepared poi. this "point of interest" you can use to connect/link between stages and remove platform on connected sides of stages. It is not implemented, because it is on a developer.
AndyGFX.
there shouldn't be any unreachable paths (i tried 3 times and all were made only of reachable paths).
But I'd like to see this and the Lode Runner clone combined!!
Hi,
yes unreachable path exist now because used pattern sprites are not designed correctly.
My first goal was, make level generation.
Pattern you can change as you need or using POI field to connect stages and remove platform tiles on connection between stages. Direction to next cell in maze is set to 1.
Used idea is discribed here: Procedural Level Generation for a 2D Platformer
A.
Now this is cool. I've been reading the Spelunky book but much of the math/logic behind it all escapes me. Gonna spend some time picking this apart to learn.
From what I understand, Spelunky generates "a solution first," then it builds rooms that contain that solution, which may or may not be closed off in the other directions. Then it simply adds the other "scenes" to it kind of randomly, although it always adds at least one point of interest (like an idol, altar, shop, etc.) except on the first level.
There's also two levels of probabilistic blocks - one set that only generates when it's part of the solution set - so that nothing closes itself off - and a second set that generates where it isn't part of the solution set, which CAN break up a screen into split parts. The "pushblocks" are usually preset in areas where they're relevant, although the game does have a tiny percent chance to make a regular block change into a pushblock (I think it's 2/500).
PS: Because it is a platformer with low jumping, it also makes the end on the bottom first, then the solution set writes the level bottom-to-top and finishes by placing the level entrance. But to be fair, most of the areas have "ladders," (only the ice caves don't?) and the engine just uses them very sparingly - where it appears that you are using them more robustly.
Still, color me highly interested here. :D I was just (eventually) gonna do a 4-across, 3-down, 2-stages-per-type kind of thing, but you're blowing it out of the water!
Engine feedback:
The thing that sticks out to me most here, is that your engine is still placing walls of breakable blocks in the path from the start to the finish. Given that the player typically has a finite amount of bombs, this will brick them really early. The alternative that comes to mind is changing the whip to a pickaxe, but I don't know if that would remove the kind of tension you'll want in the game. I'm digging how it makes bigger levels that make some kind of sense to it, though.
Also, is it deliberate that the bottom of the level is exempt from the maze generation? It feels deliberate.
A question from a beginner: I notice in your _draw() function you first set the camera and then draw the entire map, even though most of it is off-screen. In situations like this, would it be considered better to have some kind of level:draw(x1,y1,x2,y2) function that just draws a particular subsection? Or does it not make much of a difference? (I'm assuming that under the hood pico-8 is smart enough to exit out of spr() calls as soon as it evaluates that they're off screen, but you're still making at least a few hundred unneeded iterations through your level:draw() loop on every frame)
Hi,
of course, is it possible, but this is on a developers. Primary goal was create and try system for procedural level building. Optimalisation is now on users.
Andy.
Hi AndyGFX!
Thanks for share the procedural generation functions!
I used your functions in my game: Random Dungeon
https://www.lexaloffle.com/bbs/?tid=32299
Hi AndyGFX!
Thanks for share the procedural generation functions!
I used your functions in another game: Random Escape
[Please log in to post a comment]
