Rework Terrain Generation

[Inspirateur]

Current terrain generation has a few problems:

• it's not easily extensible (with custom Biome logic or new additions such as boulders)
• it's not user parametrized (user can't decide the proportion of landmass, mountains, etc.)
• it could be way faster on GPU (very important if we use 3D noise for caves)
• it doesn't provide the slope value for soil selection
• there's no way to quickly get a big picture of what it's generating when working on it

Sidenote: Caves actually might be do-able with 2D noise only ? I'm thinking this could be done with 1 layer of 2D noise deciding where the cave "floor" is, and another deciding where the "roof" is. This could alleviate the need to move terrain gen to the GPU. Also parametrisation is easy to add :p

Extensible terrain generation

Current terrain generation code is messy and we can't add biome related logic to it easily. I need an API that easily lets me define Biomes with points in the parameter space (temp, hum, pH, Nitrates, etc.) and then lets me define custom terrain noise per biome (optional) which will be blended with normal terrain generation by multiplying with the biome value. Soil selection must also be abstracted away.

New system draft

1. A first pass like we already have defines global terrain noise and parameters
2. Biomes values are inferred given these parameters
3. Custom biome noise can be defined for some biomes (ex: Desert dunes, canyon, etc.) and will be blended to the global noise based on the biome values. If no custom noise is provided we just proceed with the global terrain noise.
4. Biomes also define layers of Blocks that will be applied relative to the terrain height (it can be as simple as saying that the top 3 blocks are grass)

Layer definition

The layers of blocks (which can be defined globally and per biome) could be of the form Layer(value, Block), with value being relative to the height specified by the terrain noise:

• if value is negative it will fill N blocks under the terrain height
• if value is positive it will fill N blocks above the terrain height

At the end of the process we get a final height noise and a sequence of Layer(value, Block) which will be applied in the order they're specified.

Future improvement

Having a clean and modular terrain generation is the first step before addressing the other issues. Once we get that, we can more easily rework terrain generation again to make it asset based (with custom biome noise written in files like desert.noise), which will enable a lot of things such as generating both GPU and CPU code and getting the slope value analytically for example.

[Lemonzyy]

I don't know if you've considered these issues, but I think they're very important in terms of Riverbed's goals.

• Generating chunks on the GPU is great, but you want multiplayer. This means that if you're doing something like Minecraft where you can buy a server hosting solution, you'll need a server with a GPU which cost far more money. The same goes for people who host their own servers. Can they use an integrated GPU?
• If the server doesn't have a GPU, perhaps the clients can generate the map on their own? But then comes the problem of cheating and players who know the seed.

All this may or may not concern you, but I just wanted to share some of the issues I've been thinking about for my game.

[Inspirateur]

Thanks for your input :) These are interesting questions ! I do need to evaluate whether GPU generation is worth it or not, and maybe provide a fallback method of generation if no GPU is present 🤔

Other solutions could include asking clients to generate the terrain indeed, and we could imagine cheating mitigation strategies such as validating random chunks ...

Anyway I'll see that when I go over this issue :)

[nerdachse]

I just want to chime in and say: cheat prevention also depends on what kind of multiplayer you want to have.

Is it just friends / small scale, is it competitive?

If a few friends play together and one friend cheats: so what? Let the friends handle that.

If you give everyone a seed and let the clients generate the terrain and one client cheats they could potentially see far away valuable ores (just an example), but the server can still decide not to send them the info that an ancient dragon sleeps near those ores. Or the server can decide that it won't send any updates for that far away chunk... Movement and actions should still be server side validated, to disallow instant teleportation etc. pp.

Just my 0,05

[Inspirateur]

I just want to chime in and say: cheat prevention also depends on what kind of multiplayer you want to have.

Yes, my stance on that is that being able to do multiplayer with friends is certainly valuable and is always the first step in development, but eventually I want to be able to have larger scale public server and that does require anti cheat measures, which we will figure out when we're there, meaning not now :p

[Inspirateur]

Added this internal crate https://github.com/Inspirateur/riverbed/tree/main/crates/riverbed_closest (what used to be "nd-intervals") for biome/plants selection. Hopefully this will allow us to blend custom noises per biomes together. It's just 1 small piece of the problem though.