FOSS gamedev and creative worlds

Minetest is a great game than can create worlds 60,000 x 60,000 blocks square and looks amazing with all of the new mapgen features and mapgen mods out there,

but... who really goes higher than 500 blocks high while playing on a server or mines that deep you hit the bottom of the map ?

I would love to see 'map layers' in minetest where each layer is 1000 blocks bottom to top and you always start at sea level right in the middle with the world generating around you...

this way you could have MANY different layers available and each with their own mapgen and decoration... imagine nether realms, dream realms, heaven and hell, or even different planets with a new sun/moon texture in the background to make it look the part.

Minecraft (hissss boooo) is able to generate different worlds to do all of this and I feel that having just one map for minetest is limiting it's potential to create an amazing game, spark some imagination and have multiple laters available for mod makes to bring the game into it's own.

Whaddya think devs ?

I have seen such a request already some times and the temporary solution was using a Lua mapgen that starts over-generating a v5/6/7 map.
Having a layer feature as an API function and/or as a minetest.conf setting would be great to see.

This would indeed be handy, but I'm not sure about the difficulty to implement it.
Currently, you can already do layers, but only one is lit like aboveground.

This feature is my primary purpose here. Hmmmm also has been intending to do this but he's taking a break at the moment. I already have a simple fix for the shadow problem that would be useful for lua mapgens too.

Kewl paramat, shadow fix will be great... also yeah, layers mean fantastic biomes to be had in the air and deep underground without being joined to the default mapgen :)

I would love to see a sky realm like the Minecraft "Aether" mod.

Kpenguin wrote:I would love to see a sky realm like the Minecraft "Aether" mod.

Hmm, maybe something like walking on the clouds?

Also, another useful feature would be having multiple cloud layers, and any height/color, and moving in any direction.
Then you could have a sky realm that you can walk on clouds, and have a cloud layer right above you :)

That is great idea! Imagine each world on top of each other with 2000 blocks for mining and 1000 blocks for above ground, that is 3000, you can stuck 20 different worlds on each other, including weird things... like sky blocks.
So the worlds will go like that:
1) Heaven (+27000 ... +30000) - that is place that consists of clouds and nyancats (clouds are walkable)
2) Earth (-3000 ... +27000) - as usual
3) Underworld (-6000 ... -3000) - very dangerous place with lava everywhere (and some water for obsidian), more ores here.
4) Deep water ocean (-9000 ... -6000) - well it is huge super deep water ocean with occasional floating islands
5) New world (-12000 ... -9000) - world with very nice biomes and ores. Up part consists of skyblocks (imagine how someones mines the sky block from above and big water column emerges from the sky (and glitches if liquids over ignore are not fixed)). It is distant and distinct with elite players.
6) Some crazy world below

Basically for anything other than map storage you will need the height in the layer instead of the global height. In this way the layers will be mostly independent. Let's just call it "support multiple worlds by reducing map height and storing y coordinate and world id together internally". :)

yyt16384 wrote:Basically for anything other than map storage you will need the height in the layer instead of the global height. In this way the layers will be mostly independent. Let's just call it "support multiple worlds by reducing map height and storing y coordinate and world id together internally". :)

but wouldn't that give problems to the biome definitions?
biomes appearance is limited by height.
if the there are multiple heights with the same value in different layers, you cannot set different biomes for different layers, unless the entire mapgen is rewritten to work this way. the same goes for teleporters and any other co-ordinate based things.

also, if your co-ordinates are -9000 and you see trees, then you know that you are in the other world below ground. but if the height is 20, like on the surface, how will you know where you are?

firefox wrote:

yyt16384 wrote:Basically for anything other than map storage you will need the height in the layer instead of the global height. In this way the layers will be mostly independent. Let's just call it "support multiple worlds by reducing map height and storing y coordinate and world id together internally". :)

but wouldn't that give problems to the biome definitions?
biomes appearance is limited by height.
if the there are multiple heights with the same value in different layers, you cannot set different biomes for different layers, unless the entire mapgen is rewritten to work this way. the same goes for teleporters and any other co-ordinate based things.

also, if your co-ordinates are -9000 and you see trees, then you know that you are in the other world below ground. but if the height is 20, like on the surface, how will you know where you are?

If you just give the real coordinate to mods then many mods will break in another layer. Like ones that check for y>0.

To enable mods to access other layers we can pass the layer id when positions are passed to mods, but I don't know what to do when the mod doesn't give the layer id when passing a position.

and layers IDs don't exist yet.
using real coordinates is a better option, also if mods can do >y then they can also do <y to specify which layer they will affect. it's the same for the mapgens biome definitions.

https://github.com/minetest/minetest/pull/3418
Here's the first step, any comments of support (or otherwise) appreciated.

Nice, paramat!
This should be first step of map layering feature. So, whenever we have sky dimension, the bottom will not get dark. :D

+1 Fixerol

Yay! I've been thinking about something like this too, for a while. It does make a lot of sense, given the vertical space available.

Nice to know that the shadow issue is being tackled – there's not much more that needs to be done from the engine, is there? (Originally, I had assumed that sunshadows worked like this: alongside the 3D map cube, there is a 2D map of 16-bit integers holding the highest known node in that vertical column that blocked sunlight. To add several layers, one would need to duplicate this shadow map several times. But from what I gather, that's not how sunlight works in Minetest.)

Now there's just two more things to do, I'd say:

1) The core (i.e. C++) mapgens need to have a range of Y values they should take care of, ignoring the rest. This is probably not much of a problem going up, but otherwise they'd waste effort at best, and at worst the cavegen or similar would clobber the work of previous mapgens.

2) The lua based mapgens need to start accepting that they're not the only ones. That means also having a defined and configurable range of Y values (I hope all the numbers above are just examples, and noone's suggesting to hardcode thicknesses!). This may also mean a further sort of "protocol" between cooperating mapgens, such as configurable borders and transitions. But "keep your eyes on your own area" should be fine at first.

By the way, here's my wishlist, high to low altitude:

• asteroid belt / low orbit space
• walkable clouds
• floating islands, skylands
• "overworld" with standard caves
• underworld, caverealms
• hot solid-magma realm, "nether"
• The Core Is Lava™ (tba)

https://github.com/minetest/minetest/commit/49073ba2c34dfd8e286865ed2d108a4ec1eb3e3c

The feature is usable in the mapgen-object-luavoxelmanip too, so usable in lua mapgens:

* `calc_lighting([p1, p2], [propagate_shadow])`: Calculate lighting within the `VoxelManip`
* To be used only by a `VoxelManip` object from `minetest.get_mapgen_object`
* (`p1`, `p2`) is the area in which lighting is set; defaults to the whole area
if left out or nil
* `propagate_shadow` is an optional boolean deciding whether shadows in a generated
mapchunk above are propagated down into the mapchunk; defaults to `true` if left out

Lua mapgen mods should set 'propagate_shadow' to false like this ..
calc_lighting(nil, nil, false)
.. for a single layer of mapchunks at a chosen y a little way (100-200 nodes?) below a realm or floatlands. The shadow cutoff will be unnoticeable if the chosen y is empty space.

Awesome! This looks like it could fix the lighting issues I was having with the Tutorial world mapgen, I'll test it in a while.

Btw.. what if every time a chunk is generated I included the chunk below in the calc_lighting limits? Would it be too expensive for calc_lighting to have double the volume?

This way the propagation would work in the opposite direction, which might fix other possible lighting problems in case a chunk actually exists above that has to cast a shadow. The lighting from the chunk below would be updated as soon as the chunk above generates.

Well the calc_lighting API triggers core lighting code so should be fairly fast (compared to lua), although lighting calculations are complex. You could time it with code.