Map generation time by river generation

[Ranran on indefinite leave]

The map generation sometimes takes a huge amount of time, and sometimes I think the game has frozen.
I think one of the causes that greatly increases this generation time is the generation of rivers.

The river enriches the gameplay by increasing the option of transportation by boat, and I love the extended system of building cities along the river because it makes the game more realistic.
However, I think the default value may be too large. That is, there are two settings, number of rivers and max. river length.
Try repeating the map generation while changing these numbers on a large map. The difference is obvious.
It is in the setting of the climate that beginners may miss. In addition, the default value is what many people would consider to be ideal.
What do you guys think about?

[jamespetts]

This is an interesting question. The current default was selected because a majority of rivers in the game, as in reality, are very short rivers that just join other rivers, so setting a low number will result in really very few rivers. In reality, there are many small rivers and streams and a few large rivers.

If anyone can do some calculations and work out an appropriate number of rivers, that would be useful. One thing that might be considered is automatically scaling the default number of rivers with the size of map to be generated in the same way as is now done for the number of towns.

[neroden]

Honestly, I always crank the number of rivers WAY up (to 1024+) and live with the long map generation time.  I think it's an important part of the game...  I agree that the default number of rivers should be scaled with map size, like the number of towns and the number of industries (so should the number of attractions).  My default choice is huge.

Maybe there's a way to make the river generation process faster.  It currently generates one river (with the river builder tool) and modifies the map, then generates another river and modifies the map, etc. 

For initial map generation, there may be some way to do this a lot faster.  It would be worth profiling it to see where the most time is spent.

If it's in riverbuilder.calc_route, I don't have great ideas, since that's not very parallelizable.

But if it's in riverbuilder.build, we could do something else: we could precalc the routes for all the rivers, put them in a shadow array (parallel to karte_t, but just with one byte per map tile) explaining where the rivers of each size are going to go, and then arrange a "mass build" to rewrite the topography all at once.  A big coding project but quite viable. riverbuilder.build_shadow would adjust the shadow array and then there would be a routine to apply the changes from the shadow array to the topography all at once.

If it's in riverbuilder.init_builder, that's another problem and there may be some way to address that.

And there's another possibility.  Currently way_builder_t isn't really using object-oriented programming.  Perhaps a subclass of way_builder_t (river_builder_for_map_generation_t) could be created which *just* builds rivers, deleting all the code for building other stuff, and *this* could be called by the initial river generation code.  It could also delete a whole bunch of unnecessary checks for stuff which doesn't exist in a new map (piers, etc. etc.) I might try this first, it seems easiest.

Anyway, I think it's worth seeing if the river generation code can be sped up.

[jamespetts]

Honestly, I always crank the number of rivers WAY up (to 1024+) and live with the long map generation time.  I think it's an important part of the game...  I agree that the default number of rivers should be scaled with map size, like the number of towns and the number of industries (so should the number of attractions).  My default choice is huge.

Maybe there's a way to make the river generation process faster.  It currently generates one river (with the river builder tool) and modifies the map, then generates another river and modifies the map, etc. 

For initial map generation, there may be some way to do this a lot faster.  It would be worth profiling it to see where the most time is spent.

If it's in riverbuilder.calc_route, I don't have great ideas, since that's not very parallelizable.

But if it's in riverbuilder.build, we could do something else: we could precalc the routes for all the rivers, put them in a shadow array (parallel to karte_t, but just with one byte per map tile) explaining where the rivers of each size are going to go, and then arrange a "mass build" to rewrite the topography all at once.  A big coding project but quite viable. riverbuilder.build_shadow would adjust the shadow array and then there would be a routine to apply the changes from the shadow array to the topography all at once.

If it's in riverbuilder.init_builder, that's another problem and there may be some way to address that.

And there's another possibility.  Currently way_builder_t isn't really using object-oriented programming.  Perhaps a subclass of way_builder_t (river_builder_for_map_generation_t) could be created which *just* builds rivers, deleting all the code for building other stuff, and *this* could be called by the initial river generation code.  It could also delete a whole bunch of unnecessary checks for stuff which doesn't exist in a new map (piers, etc. etc.) I might try this first, it seems easiest.

Anyway, I think it's worth seeing if the river generation code can be sped up.

Interesting! If we can find a way to optimise river generation, this would definitely be good progress.