[Mod] EM Dungeon Generator [em_dungeon_gen]

[Ferk]

I have one question: If I place stair nodes inside the VM, how can I define the direction the node will be facing? This was the first reason why I decided to not make the stairs or the doors inside the VM.

You have to use dir_to_facedir: http://dev.minetest.net/minetest.dir_to_facedir
And set the result as param2 of the node. Just like you do already with the doors.

EDIT: Ow.. sorry, the VM

There's a get_param2_data() and set_param2_data() function. Just like you do alread with get_data() and set_data() for the content id of the node.

[paramat]

There's another VM that contains param2 (rotation) data, you can use the same index for both VMs,
see https://github.com/paramat/flexrealm/blob/master/init.lua#L224 line 224 onwards.

[eduardomezencio]

There's a get_param2_data() and set_param2_data() function. Just like you do alread with get_data() and set_data() for the content id of the node.

There's another VM that contains param2 (rotation) data, you can use the same index for both VMs,
see https://github.com/paramat/flexrealm/blob/master/init.lua#L224 line 224 onwards.

Thanks guys! That will solve the problem. I'll just take a while to 'port' the stairs from schematic to code.

Hmm, maybe a simpler implementation of this dungeon generator might be fit enough for use in Pixture?

I see some reasons why it might not work so well. One is that any wall, floor or ceiling that you destroy in this dungeon, you will be in a new room in the dungeon, because there is no empty space. There's always only a block of wall between one room and the other. This is bad for a game with mining, because exploration may be not so fun.. and it's also bad for non-infinite dungeons because it's hard to find a place to simply stop generating. And also my dungeon is too square.. I think a game like Pixture needs something more polished. I would take a look at 2 things: one is checking the dungeons that generate in minetest_game. I think it may be possible to get something more interesting by modifying that code (I never checked the code myself, actually). The other is Ferk's dungeontest (viewtopic.php?f=50&t=13317). The layout of rooms in his dungeon is also 'square', but with more diversity. I think the real problem is that you would need something more organic, and I feel the dungeons of minetest_games fell a little more like that. Thay are small and empty and those are the things that you would need to change.

There is actually one way that I can think of my dungeon generator being nice to have in a game like yours: let's say you have a type of dungeon in your game (by type, I mean the game could have different dungeons, something like minecraft, that has dungeons, jungle temples, pyramids, etc..) that would be always underground and it would have a perfect cubic shape. The walls/floor/ceiling would neede to be either indestructible or VERY hard to destroy, to make it fun. Then it would have only one entrance on the top and it would have more and more treasure as you went down and also something to make it harder.

Anyway it would need a lot of chages, because my generator relies heavily in probability. It's possible that you don't find a single set of stairs in kilometers, and it is also possible that you find stairs, but then they lead to a dead end, with no doors. Everything is really random, but with an infinite dungeon, this is no problem, because you always can go and find another way.

Think about the exact type of dungeon you would like to have in Pixture, and then share your ideas. I may be able to do something to help (me and the other guys of the 'dungeon gang' that is emerging in the community :p )

[Ferk]

The other is Ferk's dungeontest (viewtopic.php?f=50&t=13317). The layout of rooms in his dungeon is also 'square', but with more diversity. I think the real problem is that you would need something more organic, and I feel the dungeons of minetest_games fell a little more like that

Yes. My dungeon doesn't look that gridy after I managed to add pools of schematics that depend on the layout of exits, but depending on what you want it might not be appropriate for Pixture. It would have to be separated from the Dungeontest game and since the content of the rooms I created might depend too much on the other mods I added you might end up having to make a new set of rooms for it. At which point it might be too much work for what you want. Unless you added almost the whole game... but it's not even stable enough yet to be worth it at the moment.

I actually had the initial plan of making my dungeon finite.
My initial thoughts were to just make the first room of each level as a simple closed room with a special node inside. As soon as a player activated this node a maze-generation algorithm would be triggered that would add doors across the level in specific patterns and set up the rooms as required.

I ended up discarding the idea because I got stuck with some issues in the maze generation and using a binary tree for creating the maze is so much more scalable and nice. It's also specially appropriate for a infinite maze, so I started doing that.

I could easily add an option for the dungeon to only generate in a specific area. There will be a ladder up and a ladder down on each level that would be reachable. But the maze would still use a binary tree algorithm, and this means the result would be looking like this:

There would be a huge long array of interconnected rooms in two of the laterals of the maze. We would have to find a different algorithm to fix this. But I don't think there's one that would work good both for infinite and finite mazes.

I might revisit my decision in the future, since I think smaller mazes might make it more interesting. There would be more dead ends and the players would have to wander more and track down their steps. Also I have some ideas about some new directions in which this could evolve in Dungeontest and ways in which I could reward those who reach a certain level of a finite dungeon.

[eduardomezencio]

But I don't think there's one that would work good both for infinite and finite mazes.

This is a very real issue. I wish I had the option to do things in a different manner within minetest. Right now we generate the map using minetest.register_on_generated, where we tell it what to do when a new block is generated. If we run a complex algorithm to generate a finite dungeon that is larger than the block, we will need to run it later again when generating the other blocks (as far as I know there is no way to store the entire dungeon info to be able to only read the stored info when calling on_generated for other block, right?).

If we could generate an representation for the entire dungeon and then leave it stored to use when generating each block, I would probably choose to do this instead of doing my infinite dungeon design.

Other option would be if we could, as the world is loaded for the first time, before putting the player in, generate as many blocks as we wanted and put players in only after they are generated. That would also be very nice, allowing more complex dungeons, while avoiding the slow generation problem while the game is being played.

I wonder if there's already a way to do something similar to this and I'm just being dumb.

Ps: When I started writing this generator, I choose a room size that would note divide 80 perfectly just to say like: "hey blocks, you don't scare me". Well.. actually not. It was just because I didn't knew if the size of the blocks would always be the same. Still don't know, truth be told.

[Ferk]

If we could generate an representation for the entire dungeon and then leave it stored to use when generating each block, I would probably choose to do this instead of doing my infinite dungeon design.

Actually, you can set_node in an ungenerated chunk and it will get stored.

The problem is that if you are using a mapgen other than singlenode (which you should if you want the world to be something more than just a small dungeon floating in the middle of empty space). As soon as the ungenerated chunk gets generated, all the air in that area might be overwritten by the default mapgen.

Other option would be if we could, as the world is loaded for the first time, before putting the player in, generate as many blocks as we wanted and put players in only after they are generated.

You could do that by having the player start up in the surface and trigger the generation when he activates the dungeon entrance.
However, depending on the size of the level you might have to force_load too many areas, and it would cause a significant slowdown, I would guess.

I wonder if there's already a way to do something similar to this and I'm just being dumb.

What I was recomended to do, when I asked in the mod questions thread was to use a special spawner block with an ABM that will trigger the generation of the room only after some time has passed of it being there (1 second) and then dissappear (it actually gets replaced by the schematic).

Ps: When I started writing this generator, I choose a room size that would note divide 80 perfectly just to say like: "hey blocks, you don't scare me". Well.. actually not. It was just because I didn't knew if the size of the blocks would always be the same. Still don't know, truth be told.

Blocks are always 16x16x16 nodes. But the mapchunks (which is what on_generate gives) are customizable by minetest.conf (chunksize parameter) which by default is 5, which means that in the end you get by default 80x80x80 nodes in each mapchunk (16*5 = 80)

[Ferk]

What I was recomended to do, when I asked in the mod questions thread was [...]

Actually.. now that I read the answer from Hybrid Dog a second time.. he said that only "ignore" nodes get replaced on mapgen. If this is true then it might already work if you just set every node that you want to be empty to have "air" as content.

I think the problem might be then things like the ores, that might use a different system to get added. But maybe you could get around this by creating a special v7 biome for your dungeon, and make this biome not have ores.

EDIT: Ach.. nope, doesn't look like you would be able to do that, at least by looking at the code there doesn't seem to be a way for biomes to do anything about the ores. Maybe you'll have to simply avoid using stone blocks or things that the ores can replace.

[eduardomezencio]

First of all, I was using the terms 'block' and 'chunk' swapped, but it seems like you already noticed that

Actually, you can set_node in an ungenerated chunk and it will get stored.

The problem is that if you are using a mapgen other than singlenode (which you should if you want the world to be something more than just a small dungeon floating in the middle of empty space). As soon as the ungenerated chunk gets generated, all the air in that area might be overwritten by the default mapgen.

But wouldn't generation using a lot of set_node be slow compared to using VM? In the thread you linked, Hybrid Dog said "l think voxel manipulation works in unloaded chunks". Do you know how that is done?

Edit: I got this from rubenwardy lua modding api reference:

VoxelManip

An interface to the MapVoxelManipulator for Lua.

It can be created via VoxelManip() or minetest.get_voxel_manip(). The map will be pre-loaded if two positions are passed to either.

But I have never seen an example of passing two positions to see how it works. I'll give it a try when I have time.

[Ferk]

But wouldn't generation using a lot of set_node be slow compared to using VM? In the thread you linked, Hybrid Dog said "l think voxel manipulation works in unloaded chunks". Do you know how that is done?

Yes, sorry. I didn't mean set_node exclusively (though in my case I used set_node since I just place the spawner).

I didn't really try it myself but think you can get a VM for any area with this: http://dev.minetest.net/minetest.get_voxel_manip though I guess it's more expensive than using the one the mapgen already holds for the chunk.

There's a lot of documentation on the wiki: http://dev.minetest.net/VoxelManip
Thought often it's missing examples for many of the functions. Is there some way we can contribute to the wiki? I've tried creating an account but the captcha is broken.

[kaadmy]

I actually think it might work by re-using my village generation code for dungeons...
They might have a very defined pattern, but whatever. I'll try it.

[twoelk]

...
snip
...
Is there some way we can contribute to the wiki? I've tried creating an account but the captcha is broken.

look here: Dev wiki captcha broken

and apply here: Wiki account requests

[Ferk]

and apply here: Wiki account requests

That only gave me an account for http://wiki.minetest.net not for http://dev.minetest.net

I tried asking for dev.minetest.net but got no clear response. My comment in that thread got deleted but there's no clarification added to the thread top comment so I'm not sure what exactly is going on. But it's likely that the dev.minetest.net wiki is only intended to be edited by the official development team

[twoelk]

when done request posts always get deleted in that thread. Maybe ask Calinou on IRC.

[Sokomine]

A spawner node may not be the best approach. When the player reaches such a spot, he'll see the world as before the spawner did its work, and then with a plop the world around the player changes. It's a bit irritating, in particular if the changes affect a large area.

As long as a mapgen can reproduce the same terrain (and/or structures) for each given chunk whenever called, all is fine, and register_on_generated with lua voxelmanip ought to work very well.

[eduardomezencio]

Just to let you guys know, the latest changes that I made to this mod (not pushed to github yet) make use of a newly added feature to the lua modding api that allows you to change the chunk size in a mod. This means that it will not work (properly) with 0.4.13 anymore. Since the base of the mapgen is already done, I'll probably stop working on this as a standalone mod to start creating the game that will use this generator. I'll probably update this code soon, but after that, don't expect to see a lot around here. I'll post the game as soon as it becomes mildly interesting