[Solved] Pattern-based procedual generation

Hi Constructurerers!

Since quite a few hours now I'm trying to think about an algorythm, how to generate a dungeon with premade patterns the *best* way (there is no "best way", yes - but I want it to be as scaleable/ressource-friendly as possible ).

The main problem might be, that I'm not exactly sure, what the correct name for such generator is, in english - things like "pattern based generation" or "dungeon generation with samples" doesnt showed me any usefull google.

What I want to achieve:

Sorry for the big picture; here's its direct link: http://proxy.wtf/_storage/construct2/screenshots/sketch_pattern_based_dungeongeneration.jpg

When scene/level is starting, the generation-backend generates X (or less/more) rooms of an endless dungeon. The game starts when player wants to and ends when the player dies. A 8-way controllable player will be guided through a pixel-ish dungeon, filled with tons of monsters, secrets, chests, items and everything else, whats needed for a roguelike-hack'n'slash-RPG.

The biggest deal (for me) on this project, beside the art/gfx (because I suck in creating it like noone ever before ), is the room-generation part.

In what I need help:

I need some advice in creating the generator. Thinking about an array, which stores informations about multiple, premade room-templates like: floor, walls, static elements; a random one is picked and "created" for the player. To make some pseudo-pseudo-code:

Generation is triggered; // Trigger = player.X < 40% of current room; or a trigger-zone which is beeing entered

Generator picks X; // X = a random number which represents a room-index

Informations from array are parsed to the tilemap;

Tilemap is beeing extended & parsed tiles are getting added;

Generation finished;

Because the player should be able to run backwards, I think, it would be the best to use a single tilemap which is getting bigger over time, instead of using multiple ones (if theres a more performance-friendly way, let me hear it!). Enemies, chests, dynamic objects, secrets and everything else should be added, too, when creating a room. Since Ild like to keep it on minimalistic hack'n'slay (not too heavy), many sprites are going to be generated each room (thinking about a minimum of ~10-15 objects and a maximum of ~20-25 sprites (or less, if the performance-impact would be too big in general... the targetted platform are mobile-devices)).

So, if anyone got improvements on my sketch, before I start to script it, please tell me here. I'm thankfull for every idea or tip to make my life easier!

Have a great weekend

Proxy

Hey Proxy, is this dungeon intended to be seamless? The only thing I would worry about if I was you would be creating another room while there is a lot going on in the current screen because that is how you get jank.

Debug is your friend. Keep a close eye on how things are going as you implement it and it should give you a good idea of what is efficient and what isn't.

Hey Proxy, is this dungeon intended to be seamless? The only thing I would worry about if I was you would be creating another room while there is a lot going on in the current screen because that is how you get jank.

Debug is your friend. Keep a close eye on how things are going as you implement it and it should give you a good idea of what is efficient and what isn't.

Hi GenkiGenga,

yes, its intended to be seamless.

Im thinking about generating 3-4 rooms on start, and every time you reach the next one, an another is beeing genereted, if there isnt much action onscreen (thinking about making the generation dynamically; if not many objects are onscreen, the "generate-trigger" will be called; if there isnt such moment there is a hard-cap, when entering the last room created.... something like this might be possible somehow, if I debug it correctly, how you said .

This is my current status on it (much more simpler than I thought at first, lol...):

http://proxy.wtf/_storage/construct2/capxs/PBDG.capx

This is a very quick and even more dirty version... rooms are stored in *.txt files; they are loaded into an array on start.... just figured out, that my experience in working with tilemaps isnt the best - after I got the generator done, Ill take a look into it. The "TilemapGenerator" layout + event sheet is provided by R0J0hound: (will be removed, just used it for a fast tilemap JSON).

Cheers

Proxy

It looks good to me. If you did find that it stutters a bit when you add in all your other gameplay elements on top you could think about creating the room a bit more slowly to lessen the load at the point of creation but it probably won't be necessary.

It looks good to me. If you did find that it stutters a bit when you add in all your other gameplay elements on top you could think about creating the room a bit more slowly to lessen the load at the point of creation but it probably won't be necessary.

Ill see it, when its time to script that part of the game

If I remind myself, Im going to report here, how performance is going (and may keep this *.capx here updated ).

"Final" version (for now) for generating rooms:

http://www.proxy.wtf/_storage/construct2/capxs/PBDG_v2.capx

In the end, it was very simple... had too many too complex thoughts about what Im going to need & do... as always... thanks C2 for your simpleness! ;D

Best regards

Proxy

That's great man,

Looking forward to seeing some gameplay

Thanks for sharing your idea & capx here.

That's great man,

Looking forward to seeing some gameplay

Thanks

This is how far I have come today/and yesterday..? ).

Working with tilemaps is much easier than I thought...!

After spending hours trying to realize the idea of creating an additional array (1D), just for storing already calculated (by random) X,Y coords for each newly generated tilemap, at some point where I realized that this method is slower (I strongly think, thats just me, beeing unable to work with arrays that way

Cheers

Proxy