Yal's Basic Dungeon Crawler Engine

1) All scripts in the Dungeon Generation folder and the Assist Scripts folder, plus the obj_dungeongenerator object. That should be enough, if you change dungen_render_tile to spawn whatever objects your game uses (instead of the placeholder tiles it uses now).

2) You don't need any special behavior in the player, it's completely separate from the dungeon generation system. (You can always check playerstate_normal and the obj_viewcontrol if you want to see how the camera is controlled)

3) Currently the pattern sprites (the sprites that are used for the floor/wall patterns) are assigned in dungen_rooms_assign_biomes, you can edit this script to e.g. pick different sprites depending on what floor you're on. The tilesets uses for walls, floors etc are set in obj_demosetup, you can set these variables based on current floor / area to control the parameters.

4) You should use a surface the size of the screen, and move it around based on the camera position, right???

5) Yes, dungen_rooms_assign_biomes currently always uses the same chance for every floor but you could edit it to pick different tilesets / pattern sprites depending on which floor you're on.

I could confirm it, it looks like buffer_get_surface had some arguments removed since the version I was using to export the source code 2 years ago. I've uploaded a new version that's adapted for this.

The only thing that's changed is that on the script surface_to_sampler at line 12, the two last arguments passed to buffer_get_surface was removed. The corrected version of that script should look like this:

Had a look in the code, and I think the easiest way to do this would be as follows:

• After dungen_special_loop finishes, right now it changes state to dungen_rooms_assign_biomes.
• Instead, you'd want it to change state to a new state, for finding things like corridors and corner rooms.
• The idea is that you loop through the entire global.grid_roomtype, checking for "rt_NORMAL" rooms. If you find one, check the four surrounding cells as well, and set its type to a corridor / corner based on which neighbors exist. (You'd create one new room type for each new type you'd add, each with a new sprite). There's 4 types of corners, 2 corridors and 4 T-junctions in total. Since you can flip sprites' orientation but not rotate them, you need 1 corner sprite, separate horizontal and vertical corridor sprites, and separate horizontal and vertical T-junction sprites (5 new sprites in total).
• dungen_render_room currently randomly flips the room ("exdir" variable), this of course won't work for corners. You'd need to check the room type (global.grid_roomtype, check at the cell coordinates in argument2/3) and have different behavior for types that can't be rotated. On the plus side, you could reuse corner sprites this way: use the same roomsprite for all corners, and just always mirror them the same way in this step.
• (The reason we insert this new state after the special loop is because the special loop can create new rooms, so we could base the room shape on inaccurate info if we do this earlier).
• (When this new state finishes its loop, you'd continue at dungen_rooms_assign_biomes)

The only explanation I can think of is "something goes wrong when trying to draw to the surface", I know alpha + surfaces is a bit of a wonky mix. I did a bunch of searches through the codebase to see if there's any unresolved alpha settings that might carry over, but I couldn't find anything suspicious. So... derp, back to square one.

Some things to investigate...

• The size of the view might be zero at the moment the surface is created, perhaps? Try printing out the surface's size with a debug message after creating it.
• If you use draw_clear_alpha to fill the surface with both color (preferably something like c_fuchsia so it's possible to tell the black background from a black surface) and 100% alpha at once, does it show up properly?
• If the object that draws the surface draws something else at the same time (e.g. a gradient circle with draw_circle_ext, large enough to be visible even if the thing is offscreen a bit), does that work or is it also invisible? Depth sorting, accidentally turning off visible etc all could explain it being gone.
• This goes without saying, but do you re-create the surface if it gets destroyed? It doesn't happen all the time on a desktop target, but it's definitely going to get destroyed eventually.
• I noticed the view/HUD control object has a depth outside the 16,000 range, perhaps that could lead to oddities in the depth sorting? (I had similar issues when doing the DDG2 port job, changing depths had absolutely no effect when objects were outside the valid range). Changing the object's depth to be in front of everything else (e.g. -4000) could help shedding light on this; if it draws at the new depth the depth sorting is the reason why the surface is invisible.

I'm pretty sure the game hangs because dun_room_pos_free only returns true if there's a tile of the wtd_FLOOR type on the position (which also uses the legacy tile function), and there's a number of loops to place enemies/treasure that will loop indefinitely checking random positions until they find a free spot. (Completely blank spots are treated as collisions to stop points outside of the dungeon to count as empty) If no spot is free since the collision-checking function is broken, it will loop forever, and since you now don't spawn the legacy floor tiles anymore, it will never find a free spot.

To fully fix this, you'd need to replace all the legacy tile functions in the engine with something adapted for your multi-layer solution:

The first 3 matches delete wall tiles and overwrites them with floor tiles at positions that should have a door, the next 3 matches are the tile rendering you've already replaced, the four subsequent ones are in the collision-checking function that's currently causing the crash, and the final match is just an effect object that you don't need to worry about at the moment.

My idea for the fix to dun_room_pos_free is to replace the wall/floor checks with checks to see if the tilemap at the wall / floor layers has a nonzero tile, since walls are checked before floors it should work without changing the order/priorities.

Oh, side note... just remembered instance_create() has been removed in GMS2 and it's now instance_create_layer() or something like that... you'll need to modify the code snippet to generate the correct functon name (and add a layer name) if you're going to use it in GMS2, but hopefully that's easy enough. (I don't use GMS2 a lot myself, I mostly import projects originally made in GMS1 and then export them without doing any actual editing)

Sure. First of all, what exactly is a "stick room"? Is it related to tree data structures in some way?

The rooms are actually defined using four sprites (one pixel corresponds to one tile in the room, each color means a different type of tile) - Sprites-->Room Maps will give you those, and their names should explain the purpose of each map. Just add more subimages to a sprite and they should automatically get added to the random selection.

You'll also need dungen_render_room() and dungen_render_tile() to actually create a room from the blueprints, though. (And also all the scripts in the folder Scripts-->Assist Scripts--->Floofpaws' Sampler Extension). I think they're pretty much standalone enough that they can be used on their own without the rest of the dungeon generation structure around them with just some small changes to dungen_render_room():

• Remove the part that spawns enemies and treasures.
• Remove the lookup of the "doorflags" variable and pass that as an argument instead.

In either case, the important bit is how dungen_render_room() uses a sampler to read the sprite data. The colors that are used to represent different types of tiles are defined in the list of macros, under __VaultMapData__, and these constants is what dungen_render_tile() is checking for.

If there's anything more that's unclear, feel free to ask :3