Brainstorming River Worldgen

[Gummyslav]

Hello there

I am no expert when it comes to VS worldgen (or any worldgen for that matter), but I thought I might share my thoughts on how I would approach the issue of generating rivers (I just couldn’t sleep today and I’m quite obsessed with the game at the moment). My hope is that even if most of my ideas are not relevant, they will at least help the devs see their current system from a fresh perspective and push their thinking in the right direction.

I would start with generating underground water bodies and springs. The size of an underground lake would determine the initial speed of a river.

For a more realistic approach, I would wait with carving the landscape until a “head” of the future riverbed (I think of it as a snake) reaches an elevation drop.

• The head would move in one direction on the surface of the ground, creating a “path”.
• The head’s speed could be slightly reduced when moving on dirt, gravel, sand, etc.
• The path would branch after a certain distance (the greater the distance, the faster the head), if there aren’t any nearby obstacles along the possible new path. No more than two branches would be added on the sides of a path, and they would deviate from it at an angle depending on the head’s speed. The faster the head, the smaller the angle. Additionally, the current width of the river should reduce the likelihood of branching - the wider the river, the less likely it is to form new branches, reflecting increased stability of larger flows.
• Each new path would have its own head, which would be slightly slower than its parent. 
• When a path X bumps into a path Y, it merges with it. The head of path X stops moving. The speed of path Y and its children’s heads increases.
• If any of the heads reaches an elevation drop, all the other heads stop. Now, if any of the other heads is in very close proximity to an elevation drop too, and its speed is higher than the speed of the first head to reach the drop, the riverbed should branch.
• The riverbed path is generated based on rounded path vectors that create the shortest way to the drop.
• The depth of the riverbed depends on the blocks forming the floor and the speed of the “victorious” head. The softer the floor and the faster the head, the deeper the riverbed.
• The riverbed’s width should be based on the number of branches of the main path, the floor blocks, and the average elevation difference between the last few sections of the riverbed. (If there are many large elevation drops in the recent sections, the width should increase more slowly—the harder the ground, the stronger this effect. Mountain streams would be narrower, while rivers on muddy plains would be wider.)
• A riverbed should influence nearby land and form banks.
• One new head continues in the same direction after the drop, and its speed is increased if the drop is small (and decreased accordingly).

Lakes form when:

1. the heads of the paths have low speed, struggle to reach a drop, and often merge with each other,
2. riverbeds with opposite vectors meet,
3. there is a big drop (small drops wouldn’t form lakes).

Lakes may or may not be the end of a river. Let’s take a closer look at the three scenarios I listed above.

1. If the conditions for a lake are met and the chances of any head reaching a drop are low, the river ends.
2. When two riverbeds meet, river A could strengthen river B, or they could spawn a new head with a speed and direction based on their vectors. I’m too tired at this point to think about it any further xd
3. Lakes formed by drops spawn a few heads in all directions. Their speed is lowered proportionally to the height of the drop, but increased based on the width of the riverbed before the drop. We should also consider the depth of the lake, depending on the speed of the head that reached the drop and the height of the drop.

Once we have the riverbeds carved into the world structure, we fill them with still water and cover them with one layer of flowing water. The velocity of the top layer could be calculated based on the width of the river, the average velocity of the previous few “sections”, and local elevation drops. The top layer would have a pushing force based on its velocity and would transfer it to the still water below.

I wonder if you are planning to go even deeper into the rabbit hole and introduce a mechanic allowing water from lakes and rivers to overflow the banks during heavy rains (floods!) and then slowly evaporate or sink into the soil and replenish groundwater resources (possibility of droughts and seasonal rivers!). Even if not, you are still awesome and I can’t wait to see what you’re cooking for us in the updates to come.

Edited March 24 by Gummyslav

[Bruno Willis]

4 hours ago, Gummyslav said:

I am no expert when it comes to VS worldgen (or any worldgen for that matter), but I thought I might share my thoughts on how I would approach the issue of generating rivers (I just couldn’t sleep today and I’m quite obsessed with the game at the moment).

Welcome to the forums! I've also had one of these sessions, and I like what you've got here. 

4 hours ago, Gummyslav said:

For a more realistic approach, I would wait with carving the landscape until a “head” of the future riverbed (I think of it as a snake) reaches an elevation drop.

The way I read this section is that the game would essentially draw out an elevation map and then overlay a number of likely rivers, then choose the best of those rivers following realistic parameters (fastest flow, most direct route downhill etc.), and generate terrain, those rivers included. Is that right? 

4 hours ago, Gummyslav said:

• The path would branch after a certain distance (the greater the distance, the faster the head), if there aren’t any nearby obstacles along the possible new path. No more than two branches would be added on the sides of a path, and they would deviate from it at an angle depending on the head’s speed. The faster the head, the smaller the angle. Additionally, the current width of the river should reduce the likelihood of branching - the wider the river, the less likely it is to form new branches, reflecting increased stability of larger flows.
• Each new path would have its own head, which would be slightly slower than its parent. 
• When a path X bumps into a path Y, it merges with it. The head of path X stops moving. The speed of path Y and its children’s heads increases.
• If any of the heads reaches an elevation drop, all the other heads stop. Now, if any of the other heads is in very close proximity to an elevation drop too, and its speed is higher than the speed of the first head to reach the drop, the riverbed should branch.

Reading this, I initially thought that rivers don't typically split again once they've met (the exception being braided rivers which are wonderful and not common). Reading it again though, are you suggesting that the game uses the branching mechanic to propose alternative paths, and then chooses the best of the three possible options and generates that one? I like that idea.

5 hours ago, Gummyslav said:

I wonder if you are planning to go even deeper into the rabbit hole and introduce a mechanic allowing water from lakes and rivers to overflow the banks during heavy rains (floods!) and then slowly evaporate or sink into the soil and replenish groundwater resources (possibility of droughts and seasonal rivers!)

I really like the idea of floods, but I've also been listening when people explain that a full meter of water rise would A: not be realistic and B: cause a lot of problems with terrain gen.

But, your post gave me an idea about special river-flat blocks which might let us do flooding in a cool way: They'd essentially be dirt slabs, which would generate when a river ran through flat dirt land. They'd generate on either side of the river, out until they met an elevation change. They'd be able to have plants placed on them (I know, that'd be an issue but bear with me), which would grow extra bushy around the base (allowing the devs to use their normal plant models and then extend a half-block of tangled foliage filling the space below). The river-flats would be able to be tilled, and would have good fertility, but if dug up would just produce "silty earth" which would work like fertilizer rather than a placeable block.

When rain fell for an extended amount of time though, all rivers with river flats would rise one block higher, and the river flats half blocks would flood, destroying any plants and crops (except rice?) which were planted on them. Any missing bits of river flat would re-generate if there were river flat blocks adjacent (simulating silt washing over the flats). It'd stay flooded for four days after the rain stopped, and then return to normal, except the river-flat blocks would be refreshed to full nutrient value, be un-tilled, and stripped of any grass which might have grown on them. 

[Gummyslav]

On 3/25/2026 at 12:19 AM, Bruno Willis said:

Welcome to the forums! I've also had one of these sessions, and I like what you've got here. 

Thank you for the warm welcome. I didn’t expect such a quick and positive reaction  

On 3/25/2026 at 12:19 AM, Bruno Willis said:

The way I read this section is that the game would essentially draw out an elevation map and then overlay a number of likely rivers, then choose the best of those rivers following realistic parameters (fastest flow, most direct route downhill etc.), and generate terrain, those rivers included. Is that right? 

My initial idea was that rivers would be generated in a second phase, after the terrain is already in place. This would allow the properties of the terrain to influence the rivers (for example, if a river flows over sand, it might have a lower potential to propagate due to drainage). But that might be overthinking it.

On 3/25/2026 at 12:19 AM, Bruno Willis said:

Reading this, I initially thought that rivers don't typically split again once they've met (the exception being braided rivers which are wonderful and not common). Reading it again though, are you suggesting that the game uses the branching mechanic to propose alternative paths, and then chooses the best of the three possible options and generates that one? I like that idea.

I must admit, it’s a bit hard for me to fully grasp my own idea, but I think you understood it well. For the sake of explaining it, I made a simple simulation. While it deviates slightly from my initial vision, I personally think the results look convincing.

I made two GIFs simulating river pathfinding on flat terrain. To simplify things, I assumed that the initial “potential” of a river is 5, and it decreases by 1 after each cycle. If no path to an elevation drop is found after 5 cycles, the river ends. When a path is found, the cycle count resets. If more than one path is found, the river branches, and each branch has its potential reduced by 1.

     

     

 

 

On 3/25/2026 at 12:19 AM, Bruno Willis said:

I really like the idea of floods, but I've also been listening when people explain that a full meter of water rise would A: not be realistic and B: cause a lot of problems with terrain gen.

While I’m one of those slightly masochistic players who turn cave-ins and soil instability on, I assume floods would be a bit too much I love your idea of river-flat blocks. They promise a lot of fun and new possibilities while not being too punishing or unrealistic.

I’m really glad this sparked such a discussion  

 

[DUCATISLO]

Commented cuz u have a gothic profile too!

 

[jerjerje]

This generally seems like a sensible approach to generate rivers. But I don't think it would work well for a game like Vintage Story. (Assuming I understood your idea correctly. Please correct me if I misunderstood something)

This is mainly, because Vintage Story doesn't generate the entire map at once, it only generates singular chunks at a time.

More precisely: Your idea always starts generating the river from some "head". This may be fine, if the player first generates the chunk in which the head is located. But what if the player first loads a chunk in the middle or at the end of the river? How would the game know that there should be a river here?

A naive solution to this would be to always generate chunks with rivers outside the normal render distance. However, this could very easily be a performance nightmare. The further rivers can flow, the further away the game would need to generate all rivers. I don't think this would be feasible performance wise (unless you only allow rivers to be very short).

Figuring out how to generate large scale features like rivers is always a problem on these infinite open worlds. I'm definitely interested in seeing how the devs will solve this problem in Vintage Story.

[Thorfinn]

33 minutes ago, jerjerje said:

This is mainly, because Vintage Story doesn't generate the entire map at once, it only generates singular chunks at a time.

So much this. I've spent a lot of time fiddling with changing from chunk-based to landform-based generation, so that you generate all the "divides", but that rapidly gets insane. If you zoom way out on the map, you can see how huge some of these landforms are, yet they are still way too small to plot a river all the way to the sea. Moreover, you will almost always end up with some massive multi-tributary river draining into some tiny pond because that's the lowest point. In order to avoid this, you have to generate continent-sized regions all at once.

Which is going to need a pretty massive change to landforms. Islands are pretty easy without much change. You only have to generate until you return to sea level. For continents, I think what you would be stuck with is flattening the world substantially and having landforms using elevation offsets. For example, instead of a plateau landform, you have a cliff landform with a plains landform sitting on top of it. Or maybe you use something more like a geomorph, where the next piece is selected based on the existing ones, kind of like dominos.

In any event, flowing water is a serious hog. Granted, once generated, you could optimize it, but you still have to generate it, and at scale.

[Bruno Willis]

3 hours ago, Gummyslav said:

I made two GIFs simulating river pathfinding on flat terrain. To simplify things, I assumed that the initial “potential” of a river is 5, and it decreases by 1 after each cycle. If no path to an elevation drop is found after 5 cycles, the river ends. When a path is found, the cycle count resets. If more than one path is found, the river branches, and each branch has its potential reduced by 1.

These gifs are amazing, really helped explain the idea. I would say, I'm pretty sure rivers almost never split once they start flowing, it's more likely you get streams converging as they flow down hill (which your model also does). 

1 hour ago, Thorfinn said:

Moreover, you will almost always end up with some massive multi-tributary river draining into some tiny pond because that's the lowest point.

I think this might be solved if rivers had a data identity for the river as a whole, which would record how big and fast it was, which would help determine how it ends up falling across terrain, which I think you were getting at, Gummyslav:

On 3/25/2026 at 6:31 AM, Gummyslav said:

The velocity of the top layer could be calculated based on the width of the river, the average velocity of the previous few “sections”, and local elevation drops.

That way a large river will hit small divots and check how big and fast it is, and then just barrel through, maybe reducing its speed by a few ticks in the process.

1 hour ago, Thorfinn said:

So much this. I've spent a lot of time fiddling with changing from chunk-based to landform-based generation, so that you generate all the "divides", but that rapidly gets insane. If you zoom way out on the map, you can see how huge some of these landforms are, yet they are still way too small to plot a river all the way to the sea. Moreover, you will almost always end up with some massive multi-tributary river draining into some tiny pond because that's the lowest point. In order to avoid this, you have to generate continent-sized regions all at once.

Which is going to need a pretty massive change to landforms. Islands are pretty easy without much change. You only have to generate until you return to sea level. For continents, I think what you would be stuck with is flattening the world substantially and having landforms using elevation offsets. For example, instead of a plateau landform, you have a cliff landform with a plains landform sitting on top of it. Or maybe you use something more like a geomorph, where the next piece is selected based on the existing ones, kind of like dominos.

Damn, you're right. Does the game generate a "height map" or something before it generates terrain? I think that's what the farseer mod uses to get its distant mountains? If it were generating a vague outline of the terrain height, could it not have a second vague outline which just records the paths of rivers relative to the terrain height, so that when the game goes to generate terrain off the height map, it also takes into account the "river map"?

Saying that, I do think the devs will have to do this sort of re-vamp of world gen. anyway to give landscapes more large scale coherence, and rivers will be easier as a result. The way you described islands being alright to do, but larger landforms needing plateaus, makes me think about essentially stacking islands overlapping each other, like scales, to get elevation change while still using those smaller shaped landforms? I'm not sure if that's what you're talking about with geomorph, or if that actually solves anything. 

Currently I really like seeing the terrain generation where there are obvious geological slabs sticking out of the ocean on these dramatic leans, with slight steps where the land looks like it's eroded to a hard ridge and then left a bit of it jutting out. What makes those look so good it how often they are at angles, which really sells their tectonic origins. You wouldn't want to lose that by generating based on elevation offsets. 

[Tabbot95]

On 3/24/2026 at 7:19 PM, Bruno Willis said:

But, your post gave me an idea about special river-flat blocks which might let us do flooding in a cool way: They'd essentially be dirt slabs, which would generate when a river ran through flat dirt land. They'd generate on either side of the river, out until they met an elevation change. They'd be able to have plants placed on them (I know, that'd be an issue but bear with me), which would grow extra bushy around the base (allowing the devs to use their normal plant models and then extend a half-block of tangled foliage filling the space below). The river-flats would be able to be tilled, and would have good fertility, but if dug up would just produce "silty earth" which would work like fertilizer rather than a placeable block.

When rain fell for an extended amount of time though, all rivers with river flats would rise one block higher, and the river flats half blocks would flood, destroying any plants and crops (except rice?) which were planted on them. Any missing bits of river flat would re-generate if there were river flat blocks adjacent (simulating silt washing over the flats). It'd stay flooded for four days after the rain stopped, and then return to normal, except the river-flat blocks would be refreshed to full nutrient value, be un-tilled, and stripped of any grass which might have grown on them. 

I think it would be somewhat simpler (if still annoying for the developers and modders) to make the "leap" to "all blocks are half height, but most are multiblocks" thus allowing the "rules" to work without annoying air gaps opening up. 

 

21 hours ago, Bruno Willis said:

Currently I really like seeing the terrain generation where there are obvious geological slabs sticking out of the ocean on these dramatic leans, with slight steps where the land looks like it's eroded to a hard ridge and then left a bit of it jutting out. What makes those look so good it how often they are at angles, which really sells their tectonic origins. You wouldn't want to lose that by generating based on elevation offsets. 

I think the solution is something a lot more like dwarf fortress, which might be process intensive, but could create far more coherent (in terms of worlds)...

trouble is that DF-style worldgen is quite intensive and not very friendly for JIT worldgen

[Thorfinn]

1 hour ago, Tabbot95 said:

trouble is that DF-style worldgen is quite intensive and not very friendly for JIT worldgen

That and DF is both tiny in terms of gameplay size and is inevitable FPS death, neither of which work well in open-world MP.

One could generate a DF-type map and treat the gameplay map as just a drill down, but that's just re-inventing landforms and Perlin noise, which the game already has. You could do it similar to Carcasonne, where there are a limited number of "edge" transitions, and you just select from amongst those "geomorphs" that fit the existing world, but at a substantial loss in terms of worldgen variety.

But fundamentally, yes, incorporating rivers that make sense is going to be difficult to impossible without a first pass to generate divides and watersheds.

[Gummyslav]

On 3/26/2026 at 8:38 PM, Bruno Willis said:

Damn, you're right. Does the game generate a "height map" or something before it generates terrain? I think that's what the farseer mod uses to get its distant mountains? If it were generating a vague outline of the terrain height, could it not have a second vague outline which just records the paths of rivers relative to the terrain height, so that when the game goes to generate terrain off the height map, it also takes into account the "river map"?

And what if we flipped the whole world generation order and started with a river map instead? It seems like we can define a realistically looking flow path even without much context. Then that river map could be used to improve the realism of later layers, like terrain height, water bodies, or vegetation.

[Bruno Willis]

3 hours ago, Gummyslav said:

And what if we flipped the whole world generation order and started with a river map instead? It seems like we can define a realistically looking flow path even without much context. Then that river map could be used to improve the realism of later layers, like terrain height, water bodies, or vegetation.

I like this ide in some respects, but I feel like you have to know where the mountains are and the coasts are to generate rivers.

Perhaps they could use a low complexity river map, which stores information about where the mountains are, and where the coastlines are, and how the rivers flow between those two points. Then you get valleys generating around rivers, and depending on the stone type in that area, you either get abrupt sandstone cliffs or broad glacial bowls. 

Rivers really are so important to the way a landscape forms, so it would make sense to them right at the core of world gen, but I really don't know how the world gen. system works. I feel like I'm just throwing guesses into the wind here.

[Gummyslav]

8 hours ago, Bruno Willis said:

Rivers really are so important to the way a landscape forms, so it would make sense to them right at the core of world gen, but I really don't know how the world gen. system works. I feel like I'm just throwing guesses into the wind here.

 

Same here. We are well past the point in the discussion where I can fully comprehend everything and give the kind of feedback I’d like to provide.

That being said, I think that with some smart algorithms it should be possible to at least sketch the paths of a few major rivers. These could be spaced far apart, and since the worldgen settings already contain information about continent size, the rivers wouldn’t go out of bounds. They could also help outline where the highest mountain ranges and seas or oceans should be.

With some randomness in the code, we could get rivers that turn unexpectedly, like the Yangtze, or flow across entire continents, like the Amazon.

Once the major rivers are set, we could then sketch the paths of tributaries. Their length and proximity to the mouth of a major river could hint at their width and help define a general outline for the elevation map (with some exceptions, like fjords, of course).

My main point is that trying to simulate a realistic flow of rivers on an already existing terrain is a very complex and resource-intensive process, as others have pointed out. Doing it the other way around, however, at least from my limited perspective, seems to have several advantages. I’d also like to thank everyone for sharing their knowledge and for the friendly, thoughtful responses. I had no idea how complex this subject is.

[Thorfinn]

Interesting thought, @Gummyslav.

It just means rivers/streams form the boundaries of at least some of the landforms, then do your Perlin noise between them, rather than just use an arbitrary boundary between them. Probably have to create some landforms that are smaller scale, but that should not be terribly difficult.

That makes enough sense that I would not be surprised if that is the way they are implementing rivers.  

Edited March 29 by Thorfinn

[Tabbot95]

On 3/27/2026 at 3:18 PM, Thorfinn said:

That and DF is both tiny in terms of gameplay size and is inevitable FPS death, neither of which work well in open-world MP.

 

I mean my thought is "generate world all at once" meaning a lot of the big calculations are done beforehand; it would be something of a "big worldfile size" but Idk I'd prefer it for sailing across large bodies of water if the seas were generated already;

the FPS death has more to do with the nature of "every object and it's history is tracked, every living being has living memories, and there is world-lore, etc"; (ex: a dwarf sinks into depression remembering the pain of their favorite pair of embroidered socks (which depicted an event 50 years before) rotting off their feet) this creates a whole bunch of exponential feedback loops... tree growth is another thing but idk there's ways around the tree-problem.

Edited April 5 by Tabbot95

[Bruno Willis]

On 4/6/2026 at 7:04 AM, Tabbot95 said:

I mean my thought is "generate world all at once" meaning a lot of the big calculations are done beforehand; it would be something of a "big worldfile size" but Idk I'd prefer it for sailing across large bodies of water if the seas were generated already;

Perhaps they could generate a "landmass" at once, rather than the whole world, and then hide the borders under oceans (I play on a world with lot of water, but I don't think that is the intended standard). If that didn't work they could consider each "Landmass" to be a different geological region and where each landmass met, if it were above water, you'd get mountains. That way, you wouldn't usually see the next landmass generating because it'd be hidden behind a mountain range.

The benefit of that would be that you'd guarantee big mountain ranges on continents big enough to constitute more than one "landmass", and you could generate rivers flowing out of that meeting point, the mountain range.

[Tabbot95]

15 hours ago, Bruno Willis said:

Perhaps they could generate a "landmass" at once, rather than the whole world, and then hide the borders under oceans (I play on a world with lot of water, but I don't think that is the intended standard). If that didn't work they could consider each "Landmass" to be a different geological region and where each landmass met, if it were above water, you'd get mountains. That way, you wouldn't usually see the next landmass generating because it'd be hidden behind a mountain range.

The benefit of that would be that you'd guarantee big mountain ranges on continents big enough to constitute more than one "landmass", and you could generate rivers flowing out of that meeting point, the mountain range.

perhaps;

would need controls on the server/admin side.

 

honestly never been too much of a fan of JIT worldgen or MC's "InfiniGen".. thought it created too many issues that have never been resolved (though some of these it shares with DF as far as things like "villages that clip into terrain" are concerned)

[Thorfinn]

On 4/5/2026 at 2:04 PM, Tabbot95 said:

'd prefer it for sailing across large bodies of water if the seas were generated already;

Seas aren't seas per se, they are just regular old landforms that are below sea level. Probably so long as the default is minimal seas (99.7% land, or whatever it is) terrain will be JIT. I once thought occlusion culling of mapgen would be a good idea, but it doesn't make that much difference. Most crusts will require 2 chunks, and there's only 1 more at sea level, and maybe 3 more in the highlands. So generally you save somewhere between 1/4 and 1/2, not counting the algorithm to decide if you need to generate another 1 or 2.

I have not looked into FarSeer, though my sneaking suspicion is it does regular old JIT terrain gen. Otherwise it would be kind of a pain to make sure it looked the same once it came in range.

You can pregen your world, BTW. Something like 

/wgen pregen [radius]

 

[blauertee]

On a philosophical note:

It's kinda wonderful how far we've come with with continues functions to generate noise maps to generate terrain. It's amazing it looks like somewhat of a real landscape at all. It works so well, that now people are surprised there are things it just can't do. I think rivers fundamentally break with that concept. To get realistic rivers you have to iteratively simulate geology of a whole interconnected world instead generate the next chunk.

And as @jerjerje said any realistic river is always highly dependent on the neighboring terrain. It will make vastly distanced landmarks "dependent" on one another and break procedural generation.

I think when you zoom out on a vintage story map you can clearly see that it's just a noise map. I agree with the general trend of the discussion that Vintage story should make use of it's huge advantage of having a finite world where you can do some calculations globally when generating the world. There should be a large scale geology layer on the same level as the current climate/temperature map rather than doing all of it per chunk. To get more varied beautiful worlds.

Edited April 19 by blauertee

[Bruno Willis]

23 hours ago, blauertee said:

I think when you zoom out on a vintage story map you can clearly see that it's just a noise map. I agree with the general trend of the discussion that Vintage story should make use of it's huge advantage of having a finite world where you can do some calculations globally when generating the world. There should be a large scale geology layer on the same level as the current climate/temperature map rather than doing all of it per chunk. To get more varied beautiful worlds.

Yeah, I think vintage story could do amazing things if it did planned world generation. Imagine if the game sketched out certain key things, mountain ranges, large rivers, oceans, and then placed significant terrain into the world based on those landmarks: mountain passes, mountain forts, overgrown quarries forming in the mountains, the second story location forming near one of the rivers, and on other rivers maybe large ruined cities, or just old bridges with ruined roads leading to other locations and landmarks. 

The game could start of placing these large bits on a vague map, and once the biggest land features were set, the parameters for the next most significant features would become clear, and the game might work its way down from there. We'd end up with an interconnected world (even if it would lose some of that random generation charm). This does feel like a radically different way to generate a world, and I'm not sure it would support the re-playability of a noise map as well, but who knows?