News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Regions for environment variation

Started by IgorEliezer, December 28, 2017, 02:58:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

IgorEliezer

Current situation:

The landscape values such as mountain height, roughness, rivers, trees, snow line and climate altitude etc are applied in the whole map equally. If you set a low roughness, the whole world will be flat; if you set a high roughness, the whole world will be hilly, no variation.


Proposal:


Instead of remaking the whole landscape thing, what if the current landscape generation were applied with some variation, with less or more intensity, depending on the part of the world?

Roughly:

       
  • Divide the world into regions, which can be random rectangles or polygons.
  • Each region will have a coefficient, a real number ranging from 0.0 to 2.0 or whatever.
  • The resulting region's terrain is a product between the landscape value and the coefficient. Some regions will have more mountains, rivers etc than others.
That's it.

Leartin

I think if you do it with rectangles, you'll always get some kind of visible border. What you would need to do is having gradual change.
So for example, roughness is always a number between 0 and 9. You could find some random spots on the map and give any value from 0 to 9 to them, then fill the rest of the map with values between the existing once. Hence there is always a smooth change from flat to rough.


Buit for the most part, I wonder if this wouldn't be better connected to climates? I would rather have all my deserts flat and all my mountains rough than having more randomness. Perhaps not only roughness, but also double-heightchanges in mountains appearing naturally, but not in lower climates (Essentially, I'd like some kind of non-linear height levels and roughness changes along with it)

Probably best if someone could fix the current landscape settings though.

Ters

The problem is that while deserts are mostly flat, mountainous regions are not just one climate. Simutrans does get it somewhat right that terrain dictates climate, not the other way around. However, terrain is more than just the height of the particular tile. It is unlikely that all players care for realistic climates, however.

For the original wish, I think using bitmaps to control terrain generation might be the easiest. With the three channels of an RGB image, you can code for three factors, such as hilliness, amount of rivers and denseness of forests. With an alpha channel, one can even control a fourth (how urban/rural the region is, perhaps), but it is perhaps more difficult to visualize.

wlindley

Good thoughts here. In the long term, it would be good if sawmills actually spawned in forests, and if resources like grain, iron, and so on could somehow be tied to the underlying  map structures.

Leartin

I said climates because it's easier to visualize, of course terrain generation comes first, and climates are applied second. Uhm. Let's go 2D to explain it better, and have a look at the attached file.
Assume the first line is the result of the map generator, as it is, without roughness. The second line is the same "map", but with roughness applied.
What I imagine is a kind of gradient, such that any lower area has less elevation than higher areas - that would cause the "map" to be generated like the third line (as you can see to the right, what was straight before becomes curved)
Now, the fourth line shows how that new map would look if the old roughness would be applied again. Same deal, really. But instead, take a look at the last line - here, low areas don't get roughness, while higher areas get a lot of it. This also means it's much easier to build in lower areas than in high ones.

Now I don't know if that would be more realistic or generally better, it's just what I wished I could do.

Ters

I'm not sure if Simutrans maps are big enough for such detailed mountains, if one also wants non-mountainous regions.

jamespetts

Quote from: Ters on December 28, 2017, 06:47:36 PM
I'm not sure if Simutrans maps are big enough for such detailed mountains, if one also wants non-mountainous regions.

The current map on the Bridgewater-Brunel server is 7736x3496, which should be plenty of space for detailed mountains.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

Especially since those mountains would actually take up less area, as the mountain foot is curved in - it's the valley which gains in area, which causes the mountains to be more steep even if they reach the same height.

Ters

Quote from: jamespetts on December 28, 2017, 09:28:03 PM
The current map on the Bridgewater-Brunel server is 7736x3496, which should be plenty of space for detailed mountains.

I'm not sure that would be plenty. If all the details of mountains.png should be represented, the mountain would be about 200 tiles wide. 5 such to a range, and you have used up 1000 tiles. That gives just enough room for a range and a plain along the y-axis, a bit more for the x-axis. Another thing is that such a big map must take quite a while to load and save. A 2048x2048 map is starting to test my patience, and that is loading from a local harddrive.

Leartin

That PNG only serves to visualize the concept, it's not at a scale like one tile per pixel or anything. The basic map generation would stay the same, and so would the amount of mountains - except instead of being homogenous goo like the second line, you'd have more distinction between mountains and valleys (in the first and second line, you couldn't even say either exists).

IgorEliezer

#10
Quote from: Leartin on December 28, 2017, 04:06:04 PMBuit for the most part, I wonder if this wouldn't be better connected to climates?
Sure it would. I didn't intended to propose a full fledged environmental system because I was afraid that would be too much... and to avoid RPG/Minecraft references. So my move here was "start simple" by proposing just a tweak in the current system.

If we consider a more elaborated idea: the world would be divided into zones -- the shape or method, what suits best. Each zone will have a climate zone, which will be a compound of three characteristics: climate, surface and objects:

       
  • Climate: the graphic style (snowy, sandy, pasture, water etc). Can be tied to temperature, moisture and altitude.
  • Surface: roughness, average altitude, mountain height etc. Pretty much what he have now.
  • Objects: what populates the ground (trees, river springs, rocks, decorative elements, factories, buildings etc).
With that in mind and that the current pak files already have a climates=* parameter, we could have climate datfiles like this:


# Note: the "-" means a range and "," is a list.

name = desert
chance = 1-2        # per 512x512 world map

# Climate
set = sand, dirt        # graphic styles, winter version etc.
# alternatively, the graphic style and other objects can be bound to temperature, moisture and altitude
temperature = 40-50       # (what about negative numbers?)
moisture = 1-8       # in %: 0 = absolute dry, 100 = absolute wet.

# Surface
altitude = 1-3       # above the sea level
height = 0-2       # peak height above altitude
roughness = 0-1
mountain_chance = 0-1      # per 8x8 tiles (not buildings; landforms such as mesa, mountain range, lakes, canyon, craters [who knows?] etc)
lake_chance = 0-1      # per 8x8 tiles

# Objects
riversprings_chance = 0-1      # per 8x8 tiles
vegetation_chance = 0-1      # per 8x8 tiles
decoration_chance = 0-1      # per 8x8 tiles, for ground objects
attraction_chance = 2-4      # per 512x512 tiles
factories_chance = 1-2      # per 512x512 tiles
cities_chance = 1-3      # per 512x512 tiles


I'm using "zone" instead of "region" in reference to "climate zones". What I'm proposing is to replace the current altitude-based method with region-based method and add more flexibility via datfile.





Addendum:

What about seasons? My idea would be add or subtract the base values in Climate (i.e. temperature and moisture) depending on the month. If the resulting temperature and moisture are above or lower than a certain value, the game will replace the graphic styles, normal with snowy and vice-versa.

jamespetts

Quote from: Ters on December 29, 2017, 07:20:28 AM
I'm not sure that would be plenty. If all the details of mountains.png should be represented, the mountain would be about 200 tiles wide. 5 such to a range, and you have used up 1000 tiles. That gives just enough room for a range and a plain along the y-axis, a bit more for the x-axis.

One must keep in mind the resolution of each tile - in Pak128.Britain-Ex, each tile represents 125m squared, so 200 tiles would be 25km wide. One might not be able to have exactly the detail shown in the last line graph, but one could probably get something quite close at a realistic scale.

QuoteAnother thing is that such a big map must take quite a while to load and save. A 2048x2048 map is starting to test my patience, and that is loading from a local harddrive.

I have just timed the loading from my local SSD on my Linux mini-desktop of a game saved a few days ago from the Bridgewater-Brunel server: from clicking on the load button to the game being fully loaded, only 14 seconds elapsed. I have spent some considerable time of late optimising the loading/saving routines to improve the play experience on network games.

Incidentally, I note that much of what is proposed here is quite complex in nature and may well take a lot of work to implement - but one fairly simple idea that I think has been proposed before is to have a latitude offset for climates.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

Quote from: IgorEliezer on December 29, 2017, 10:06:01 AM

       
  • Climate: the graphic style (snowy, sandy, pasture, water etc). Can be tied to altitude and moisture.
  • Surface: roughness, average altitude, mountain height etc. Pretty much what he have now.
  • Objects: what populates the ground (trees, river springs, rocks, decorative elements, factories, buildings etc).
I can see what you try to achieve, but I'm not sure if that is the best way to go from where we are right now.
We currently have 8 climates (if we include water), and most objects refer to those. Since any change shouldn't affect every object, it seems best to me to keep those climates as the main destinction and have various zones/regions within those climates, which all use the same buildings and other objects, but may have a different ground texture, ground variation (roughness) and different density of self-spawning objects. To use your example:


name=desert_sandy          #name of the region
climate=desert             #climate in which that region exists; or from a different perspective: range of objects that can spawn in this region
probability=50             #the desert climate is divided into regions - what each region is happens at random, based on the probability, much like how citybuildings spawn.
texture[x][y][z]=image.0.0 #the ground textures in use for that climate, where x is an index starting with 0 and y is the season and z is the type of slope the texture is used on. If [z] does not exist, you only need one texture which is applied to the different slopes by the game (as it is now)
altitude[x]=0-5            #range of height levels above sea which influence probability
altitudefactor[x]=2        #multiplicator for the base probability for regions at that altitude. Use 0 to disable region for given altitudes. Same concept for moisture and temperature if introduced.
roughness=0                #multiplicator for roughness. Base roughness still set in landscape dialog.
[...]_chance=1             #various spawning chances for different objects (trees, ground_obj,...)


Regions for deserts might by desert_sandy, desert_rocky (with a different ground texture, bit more roughness) and desert_oasis, (more vegitation, rivers, lakes etc.) - all of which will use the same objects inside them.


This is only what those regions would BE. Now, climates themselves are traditionally set by altitude, and if this is kept, regions should do as well. If climates were to be set based on different criteria (temperature, moisture) of course regions would follow. How exactly I'm not sure - but I think it makes a lot more sense talking about how any kind of regions/zones/new climates work, since  they could be implemented without proper spawning at first and still be useful for map designers.


Quote from: jamespetts on December 29, 2017, 11:43:26 AM
Incidentally, I note that much of what is proposed here is quite complex in nature and may well take a lot of work to implement

Probably. But a rework of the map generator is in order (make proper use of double height, climates based on something other than altitude, lakes as a slider with preview rather than a button), as well as some changes in the relief-maps (allow a method to safe climates, river and city position without actually saving the map, indicate forests,...) - so there is a lot of work to be done either way, and it makes sense to propose additional stuff before someone starts that task.

jamespetts

Quote from: Leartin on December 29, 2017, 11:48:39 AM
Probably. But a rework of the map generator is in order (make proper use of double height, climates based on something other than altitude, lakes as a slider with preview rather than a button), as well as some changes in the relief-maps (allow a method to safe climates, river and city position without actually saving the map, indicate forests,...) - so there is a lot of work to be done either way, and it makes sense to propose additional stuff before someone starts that task.

If there are people with the time and willingness to work on reconstituting the map generation thoroughly, this is a splendid thing. In which case, I will make some suggestions as to that here in the hope that they will be helpful.

One thing that I had thought of doing for Extended some time ago, but deferred indefinitely owing to having higher priorities, was to have user-defined regions. I had not thought of tying these in with map generation, but there would be much to be said for doing so if map generation is to be overhauled. Each of these regions would have:

(1) an in-game name to be displayed in the minimap and in the infobox displayed when clicking on any tile in that region;
(2) a different set of town name syllables;
(3) a different set of street/stop names;
(4) a different set of industries (which may overlap, depending on .dat file settings, with industries in other regions);
(5) a different set of city buildings (which, again, may overlap, depending on their .dat file settings, with buildings in other regions); and
(6) a different density of towns.

The region data could be defined in a settings file, giving a maximum number of defined regions; the player might then choose how many of those regions (and possibly which ones) appear when the map is generated.

This could then produce some quite interesting gameplay, as players may well have to ship products some distance from one region to another if, for example, all the coal mines are in two of five regions on a map.

Quite how, geographically, those regions should be defined is more complex. One might use latitude and longitude offsets as a relatively simple mechanism, although this would make regions large rectangular objects which cannot be entirely contained in other regions. That may or may not be a problem.

The additional ideas suggested by Leartin/Igor of having the region also dictate the map roughness, probability of trees and certain sorts of ground objects as well as the base textures are also splendid ideas.

If map generation is to be overhauled, there are two other things that would be worthwhile considering. Firstly, the current map generator very, very rarely generates any double/full height slopes as opposed to single/half height slopes. It would be a good thing if, in mountainous regions at least, double/full height slopes could be generated with more frequency.

Secondly, it would be a splendid thing if the map generator could create proper river estuaries and tidal rivers; the map generator might treat rivers as they exist currently (i.e. special way tiles) as non-tidal rivers, and generate tidal rivers (which may be more than 1 tile wide), leading into estuaries (which would be even wider) by lowering the land to at least a single/half tile below the surrounding and making the base tiles of the water climate rather than a river way tile. Having very wide rivers and estuaries would add enormous variety to the gameplay.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Well, in itself, I wouldn't really mind spending 200 tiles on a single mountain (with multiple peaks). That way, crossing it would involve several hairpin turns and tunnels. If only the economy did not make doing so unprofitable and just tunneling straight through it affordable.

Different climates should realistically have different seasons. Deserts don't normally get snow, even if it gets very cold. (There are snow/ice covered deserts, especially in Antarctica, but it is only because what little snow there is never melts and/or ice comes flowing in from non-desert areas.) Tropical climates have dry and wet seasons, or none at all (a single season is not a season).

prissi

Somewhere deep in this forum is a suggestion to simulate rainfall for more realistic map generation. But unfortunately it never got until a patch. I personally would like a better map creation feature. I am not verz happy with the current one, since the beginning of the two height feature, since two height levels are only created on maps with unrealistic roughness settings.

IgorEliezer

Quote from: prissi on January 04, 2018, 01:54:37 PM
Somewhere deep in this forum is a suggestion to simulate rainfall for more realistic map generation.
By chance, is this topic? https://forum.simutrans.com/index.php?topic=984.0


Leartin

One thing that might help a bit: What if, instead of focusing on map generation, we would focus on map importation? That would somewhat provide an interface for 'custom' map generators that don't actually need to be provided by the game itself (except for a very basic one).
Of course, it would still mean that someone would have to program a map generator, but doing so wouldn't replace any existing map generators, and they wouldn't need to oblige Simutrans design logic - if someone writes a decent map generator in Java, it could still be used, despite Simutrans being written in C. And someone might even write a little paint tool that does not only auto-create maps but also allows the player to alter them before starting the game. Pretty sure there are people more willing to write their own little tool than to change anything about Simutrans without knowing what all the code even does (though then again - I'm no programmer, so perhaps not)

jamespetts

I suspect that needing to use an external tool would be much less user friendly.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

That might depend on how user friendly we could make a good map generator within the confines of the Simutrans UI system. Sure, we could rewrite the UI system in Simutrans, but having to do so might mean nothing is done at all.

jamespetts

Quote from: Ters on January 05, 2018, 07:06:05 AM
That might depend on how user friendly we could make a good map generator within the confines of the Simutrans UI system. Sure, we could rewrite the UI system in Simutrans, but having to do so might mean nothing is done at all.

Why do you think that a better map generator would need a completely new UI, rather than just a few new settings in the existing UI?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

I envision something like a map-file, which could be as simple as a zip-folder with pngs and xml files in it for positions of some things. Like a bunch of old games, Simutrans could come with a bunch of hand-crafted maps as well as a 'rudimentarey' map generator (as it is now).

In the start-world-dialog, you'd have a drop-down-menu to choose a map generator, as well as a start-button next to it. That would open up the settings of each map generator, either inside Simutrans as a window, or outside as it's own program. Generate the map, and it will be saved in your maps-folder. The map generator only needs to send one string to Simutrans once it's done - the name the map was saved as.
Under the generator button, you'd be able to choose an existing map. If you just generated one, it would be already selected. Beneath that, you'd have settings about gameplay rather than the map (eg. timeline start year, beginner-mode etc.)


And I, personally, don't know if it makes much of a difference to programmers whether they need to use the simutrans UI or could use whatever they want. But with such a system, you might want to start the map creator only (especially those that allow for manual influence), which is probably not too easy to do if it's a simutrans subroutine?

Ters

Quote from: jamespetts on January 05, 2018, 11:39:10 AM
Why do you think that a better map generator would need a completely new UI, rather than just a few new settings in the existing UI?

I didn't think either way, but I had no reason to find it unthinkable that someone would ask for more than just a few new settings.

IgorEliezer

#23
Quote from: Leartin on January 04, 2018, 05:29:07 PMWhat if, instead of focusing on map generation, we would focus on map importation?
Somewhat speculative: I think that would turn out like a quick fix. Why? The game will need to be a bundled up with a set of maps (like a pakset) and/or will need a site to share maps (like Simutrans Maps). Later on, we'll come up with the conclusion that Simutrans still needs a native terrain generation as definitive solution. :)

Anyway, I like the idea of a world editor of some sort. One of the reasons that Minecraft became popular was because you could create custom terrains with world editors (e.g. MCEdit, demo) and share them with other people.


-----


I was playing around with some ideas for the terrain generation methods. I would like to start with some premises:

       
  • Climate zones are a set of definitions for topography (terrain shape), ground tiles (grass/snow/topsoil), vegetation, ground objects and perhaps some values for factory and touristic attractions layout.
  • Cimate zones can be created like a pakset, following #1.
  • Lift the limit of 8 climate zones. The game will use the climate zones available in the pakset and distribute them on the map.
  • The zones will be distributed on the map as cells following a X-Y gradient (today it's a Z-coord gradient). I propose a temperature/moisture grid which I'll explain further below.
  • Once the zones are distributed, the terrain generator will apply the relevant values set in the climate zone datfiles in each zone: roughness, average altitude, ground tiles, trees, terrain features, suitable buildings etc.

Terrain generator procedure

This is just a bullet list for a terrain generator, bear me:

1. Game startup.

2. The player uses the landscape settings to tweak some values (how many climate zones, sea level, etc)

3. "Create new world"

4. The terrain generator searches all climate zones available in the pakset, sorts/lists them according to temperature and humidity levels :

name, temperature, humidity
"desert", 40, 5
"tropical", 35, 40
"mediterranean", 25, 30
"subtropical", 20, 25
"tundra", 10, 20
"polar",  0, 10

Note: I'm ignoring oceans/water climate for sake of simplicity.


5. The terrain generator randomly picks two "extremes" for temperature and another two "extremes" for humidity. The temperature extremes are for a temperature axis, and the humidity extremes are for a humidity axis.



The angle between of the axes can be anything. If the world is bigger than 512x512, more "extremes" and axes are concatenated/expanded.


6. Distribute the climates according to the axes. The hottest climate close to the hottest extreme, the wettest climate to the wettest, and so on.





7. Divide the world into cells by using the climates as barycentres. The cell size can be set via datfile.





Yes, I don't like to have "polar" next to "desert" either. But I believe you got the idea.


8. Apply the climate values in the terrain within each cell: topography, ground tiles, vegetation and terrain features (mountains, valleys, rivers, etc). Also spread factories, attractions and cities according to the densities and probabilities set in the climate zone datfiles.




9. A new world is ready.

That's it.

Leartin

Quote from: IgorEliezer on January 07, 2018, 01:19:06 AM
Somewhat speculative: I think that would turn out like a quick fix. Why? The game will need to be a bundled up with a set of maps (like a pakset) and/or will need a site to share maps (like Simutrans Maps). Later on, we'll come up with the conclusion that Simutrans still needs a native terrain generation as definitive solution. :)

See, there are two very different things to consider here. One is "what can be in the game" and one is "how is it generated". For example, we have double heights in the game, but the map generator rarely makes use of them - and that works. What wouldn't work is a map generator that generates a nineth climate, because that does not exist in the game yet. Naturally, we'd have to think about what we want to have in the game first, and how to generate it second. Something that could exist, but no player will see it for it won't appear naturally, isn't quite that great either - hence the suggestion of map import, as that's how you currently get a map with proper use of double heights as well.

Since you compared it to Minecraft: Minecraft comes with 3 map generators (normal, large, flat), none of which creates maps as nice as a handcrafted ones. You can install mods to get additional map generators - Biomes O'Plenty comes to mind. Even if you have all those additional stuff from Biomes O'Plenty in the game, they won't spawn with the normal map generators. This is akin to having a pakset that relies on additional climates which won't ever spawn with the old map generator, which only knows of the original eight.

So yeah, it is a quick fix - a quick fix that allows testing of various new landscapes/features in the game while no generator exists for them yet, that goes on to enable the use of different types of generators at a later stage, as there will never be a 'definitive' generator anyway. But it's not like the game needs to be bundled up with maps (albeit it could) since a native generator would still exist... just not a great one, until someone makes a better one.

Would it hurt if players could choose between a map generator that works like the current one (climates based on height) and your idea (climate based on temperature/humidity)? Probably not - but it would already require the ability to choose between map generators.

prissi

I like the idea of the different map generator quite much, although I would not generate polar (only via high level).

Also some pak set use climate to distinct regions, but that has nothing to do with humidity or temperature. Still such a generator would just require a few different settings
Heat poles <1> and then a list to cycle to all of them
Cold poles <1> + list box
Temperature drop <2> (One climate cooler per x height steps)
Rain poles <1> + list box
Dry poles <1> + list box

The preview window would show two previews: The terrain view and the climate view. (Unfourtunately it does not solve the double height problem, but at least climate transitions can sho off then).

This seems a very reasonable amount of work for tile based climates.

jamespetts

I imagine that the double height/terrain shape generation issue can be solved by an entirely different (but not incompatible) alteration to the current Perlin noise generator. I wonder whether there are algorithms other than the Perlin algorithm that might be better?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Isaac Eiland-Hall

QuoteYes, I don't like to have "polar" next to "desert" either. But I believe you got the idea.

To be fair, the largest desert in the world is Antarctica - deserts are based on precipitation, not temperature, so it makes sense for them to be next to polar. :)

QuoteI would not generate polar (only via high level).

One of my favorite maps from several years ago was one where I generated the entire map as snow-covered year-round and pretended it was in the arctic (even though not all of the Arctic is snow-covered year round, of course). I manually placed factories for things like oil/coal/sand and transported them "south" to represent getting them ready for export to warmer climes. :)

Ters

Quote from: Isaac.Eiland-Hall on January 07, 2018, 04:49:27 PM
To be fair, the largest desert in the world is Antarctica - deserts are based on precipitation, not temperature, so it makes sense for them to be next to polar. :)

That would be the McMurdo Dry Valleys, I guess. Furthermore, deserts are located roughly 60 degrees apart, near 90S, 30S, 30N and possibly 90N. The last one is uncertain. I don't know if an ocean can be a desert, or if it actually does precipitate there. Mountains and stuff cause some deviations.

Leartin

Quote from: prissi on January 07, 2018, 12:47:25 PM
Also some pak set use climate to distinct regions, but that has nothing to do with humidity or temperature. Still such a generator would just require a few different settings

Paksets could use their own translations for "humidity" and "temperature", allowing for any two variables that fit. Eg. "Longitude" and "Latitude" to make sure in a German pakset, Bavarians and East Frisians aren't exactly next to each other.