Random Map Script: Belgian Uplands

[FeXoR]

This map is based on the simplest way to do erosion. It is more experimental but I thought it might be worth an announcement. The random map script itself is not playable, yet, but some seeds might be (e.g. 2110).

EDIT: Short description of the heightmap generation: Set each tile to a random height -> apply decay erosion several times (about 50 + mapSize / 4) -> rescale the heightmaps height because the erosion process flattens it.

Further explanations:

http://www.wildfireg...=40#entry250216

http://www.wildfireg...35

Random map: belgian_uplands2012-9-10.zip

Map of the "playable" seed 2110: belgian_uplands_seed2110.zip

A sceenshot of seed 2110:

EDIT: A new more playable version can be found later in this post (I might sometimes be to lazy to link to the newest version ):

Ticket with the newest files attached: http://trac.wildfiregames.com/ticket/1688

Edited October 17, 2012 by FeXoR

[feneur]

It's amazing what some people can do with "just" some lines of code

[MishFTW]

Another awesome map dude. Just love the landscape. Plus its not too hard on my computer

[Spahbod]

Nice job. The only thing that remains is that to make it playable.

are all Random maps done? or not?

Only a few official random maps remain. But we can always make non-planned maps if the idea comes to our mind.

[ribez]

it's a good start, but maybe lakes should be always deeper at the center

[wraitii]

Could use a lower amount of rock actors and a transition terrain between the lake surroundings and the grass. Could use different grass patches.

Also: the forest are really not fairly placed.

[Mythos_Ruler]

We need that water depth code soon.

[FeXoR]

It's amazing what some people can do with "just" some lines of code

I'm honored

Indeed this map contains less code then most others ^^

Another awesome map dude. Just love the landscape. Plus its not too hard on my computer

Thx, I'll do my best!

Nice job. The only thing that remains is that to make it playable.

Yes, and there are still some unresolved problems... (see below)

it's a good start, but maybe lakes should be always deeper at the center

That would need non-linear scaling or it will become a water map ^^

I'm working on general functions to deal with such things.

May I know why it's so important for you?

Could use a lower amount of rock actors and a transition terrain between the lake surroundings and the grass. Could use different grass patches.

Also: the forest are really not fairly placed.

Rocks/gold: I haven't play-tested yet. I will see to that.

Transition terrain: Yep, it's quite a rough change. Easy to do.

Different grass patches: There are two "grass types": low (a bit lighter) and high (a bit darker). Both contain at least 4 types of terrain. That seams enough to me. If you mean patches of other type on the same height: Not ATM. I try to keep things simple until the general functions are tested well.

Not fair: Yes, that's a problem that may be not so easy to resolve. However, the map description warns you. This aproach is more to look natural then to be balanced. But I like balanced maps and I'm thinking about how to fix that but not at highest priority right now.

We need that water depth code soon.

Could someone please tell me what's so darn important about water depth?

Or do you mean the general change of heightmap and SEA_LEVEL in rmgen???

Well...

Here's a new version with the players placed valid. That in no way means something like "balanced". Indeed there are many problems left:

(1) Very unequal derivation of resources across the map.

Possible solutions: Adding a tilting function may change the hight derivation to be more equal across the map. In this map it would be the wood to be balanced.

(2) Player start positions are not always close to wood.

Possible solution would be to add a check if wood is inside a current distance of each start position. The amount, however, could still differ much.

A simpler method would just be to add some "civilizes" wood with the starting entities (like some cypresses).

Another solution would be to add more wood to the lakes surroundings. That leads to the next problem...

(3) Stone and metal entities are bigger than a tile. If wood and stone is put in the same "random terrain" the wood might wind up unreachable inside the stone/metal entity.

Possible solution: Don't place different resource types in the same random terrain... but that is a bad restriction IMO.

(4) To ensure valid player starting positions much space is left on the map.

Guess I have to do some finer decoration at the end.

Here's the map: belgian_uplands2012-9-12.zip

And a screen shot of a more balanced seed (9) of a medium map with 4 players:

Keep burning!

Edited September 12, 2012 by FeXoR

[MishFTW]

^ Hah that reply is just awesome.

So from what I understand you're trying to create terrain erosion. I wonder what it would do to the buildings. And exactly what is defined as erosion? Water levels changing? Textures changing? The terrain changing as if it were a a pile of jello or a water bed?

[Pureon]

What I really like about it is there aren't any straight lines like in other RMS maps, and it's also asymmetrical, which I'm a big fan of.

(We really need that texture blending upgrade)

[ribez]

That would need non-linear scaling or it will become a water map ^^

I'm working on general functions to deal with such things.

May I know why it's so important for you?

there isn't any practical reason... only cosmetic

[FeXoR]

^ Hah that reply is just awesome.

So from what I understand you're trying to create terrain erosion. I wonder what it would do to the buildings.

I fear that would mainly raise the number of polygons... if at all possible. I read somewhere (http://www.golem.de/...1209-94503.html) that polygones are not needed any more, though, so it might be possible but I'm not the one to answer this question.

And exactly what is defined as erosion? Water levels changing? Textures changing? The terrain changing as if it were a a pile of jello or a water bed?

I should have explained a bit further x)

E.g. that I start with a random heightmap and rescale it at the end because in the process the heightmap gets extreme flat of cause. More explained here: http://www.wildfireg...=40#entry250216

Erosion, as I mean it here, is a change to the heightmap calculated by a function that simulates a real erosion process. The one I use here could be called "decay erosion" because it just depends on the height difference between all pairs of fields connected to each other and a portion of the difference is added to the height of the lower field and removed from the higher field - like material falling downhill. More mathematic: newHeight = oldHeight + erosionStrength * laplaceOperator(oldHeightMap, actualCoordinates)². The square in this case only means that not only appending fields in X and Y direction are compared to each field but the diagonal shifted fields are as well (German Wikipedia: http://de.wikipedia....ildverarbeitung ...can't find this in the English version). I use a map of x/y shifts to determine the fields compared to a given field: [[1, 0], [1, 1], [0, 1], [-1, 1], [-1, 0], [-1, -1], [0, -1], [1, -1]]. This enables me to do directed erosion, too, like sun would do (or wind when further checking if the change is down or uphill).

But all those are to simple for lets say water gathering in streams and forming rivers. The Laplace operator is in general just div( grad( scalarField ) ) and the grad( scalarField ) gets you the direction and speed water would flow at each point of the scalar field (the height map) - generating a vector field (the water floating field). There you have to apply non-linear scaling before processing the div(). For that I wrote a javascript lib for discrete n-dimensional vector analysis inside a finite n-hypercube (with the "beginning" and "end" of each dimension wrapped together to ensure the same size of scalar and vector fields): http://www.wildfireg...=40#entry250606 . The problem is... it is MUCH to slow - I wish someone could help me with that though I fear it will always be slow with the needed self-recursive functions. So I'll implement 2D and 3D versions.

I think in general that would be the main types of erosion to define: General decay, directed decay by the sun (so only at one side), additive/removing only directed erosion to simulate wind and the non linear streaming water erosion.

I don't have taken into account the texture at all. That would make things more realistic by having different materials that resist more or less to different types of erosion.

So in short: Erosion for me are changes to the heightmap and the terrain applied in a similar way like natural erosion would do.

Of cause you could generalize "heightmap" to "surface" and "terrain" to "material" so it could be applied to entities as well.

Those functions will be easy to use (ATM I use getBla() functions and set the heightmap to it later):

- applyDecayErosion(strength)

...with strength between 0 and 1 determining how extreme each apply changes the heightmap

- applySunErosion(strength, northVector)

...with north vector defining the direction the sun is coming from and it's length the average angle towards plain ground (the longer the lower over the horizon)

- applyWindErrosion(strength, direction, type)

...with direction similar to the northVector (in this case where the wind is blowing towards) and type can be "additive", "subtractive" and "both"

- applyWaterErosion(strength, nonLinearExponent)

...with the non linear exponent determining a scale factor strength is scaled with got by the normalized vector-fields vectors length with the exponent given by nonLinearExponent

- rescaleHeightmap(minHeight, maxHeight)

...to "stretch" the heightmap after multiple erosions are applied. It's stretched in the height, ofc, not in the plain.

An additional argument determining how often the erosion should be applied would help. Don't confuse this with strength! Strength can't be set to high values because the heightmap will wind up in self interference (with the frequency determined by the "compare field map" used) while the number of applies can be infinite (if you want to wait that long ^^) and blurs structures each time so the average size of structures will grow (and blur ofc.). To avoid the extreme blur after many erosion processes it might be a good idea to add a rescale function in X/Y direction as well.

Additionally it might be a good idea to make erosion possible to only parts of the map...

What I really like about it is there aren't any straight lines like in other RMS maps, and it's also asymmetrical, which I'm a big fan of.

Me too! I like balanced as well but I hope that's not to contradicting.

(We really need that texture blending upgrade)

To smother blend two textures at the edges? At least I noticed that textures look quite unnatural in some cases showing the edges of the tiles.

Edited September 13, 2012 by FeXoR

[Pureon]

To smother blend two textures at the edges? At least I noticed that textures look quite unnatural in some cases showing the edges of the tiles.

Yes exactly. In this case, the tiles are very obvious around the lakes, but there's nothing you can do about that yet

[FeXoR]

Yes exactly. In this case, the tiles are very obvious around the lakes, but there's nothing you can do about that yet

Indeed ^^. Though I will follow wraitii's advice to add a terrain between the lakes surroundings (plants and bog mainly) and the light grass to make it more smooth.

[Mythos_Ruler]

Could someone please tell me what's so darn important about water depth?

Someone was working on new water rendering code that realistically renders water depth correctly. There haven't been any recent updates though.

[wraitii]

That was me, Mythos. Updates aren't really needed, the code is pretty much there. There's a patch in Trac, it just need to be tested against the latest SVN, as it's quite old now... The only last thing to touch up were the waves but they're already "quite" good.

[fabio]

About water effects: is there some map using the recently added waterfalls and "lakes" (other than the test map).

[FeXoR]

Someone was working on new water rendering code that realistically renders water depth correctly. There haven't been any recent updates though.

That was me, Mythos. Updates aren't really needed, the code is pretty much there. There's a patch in Trac, it just need to be tested against the latest SVN, as it's quite old now... The only last thing to touch up were the waves but they're already "quite" good.

Ah, yes, I remember.

About water effects: is there some map using the recently added waterfalls and "lakes" (other than the test map).

In random maps the coordinate for the hight cannot be set so I don't think they can be used easily. The waterfall in addition needs the terrain to be shaped as the fall to look well, so it's even harder to use.

Here's a new version, changes:

- Added a darker more fitting terrain between the light grass and the water surroundings like Wraitii suggested.

- Added bushes to the water surroundings so players without high ground near (forests) will still have access to wood though less.

- Added berry bushes and cypresses as start resources next to the players (not sure if I should have used grapes/apple trees/other (wood) trees instead/additionally).

Players now all have access to wood but not equally high. It should by far be enough to reach town state. After that players with less access to wood will have more stone/metal so it will be about balanced I think.

A bit off topic:

- Some buildings (like e.g. civil centres) in part "fly" above the earth when placed on uneven ground. I thought/think they should have they foundation reach wide below their placement height coordinate.

- I noticed that not all civilizations have infantry units that cost food and metal (only). I feel that should be the case (foot fir the living and metal for the arms).

The RMS: belgian_uplands2012-9-16.zip

...and a screen-shot:

Edited September 16, 2012 by FeXoR

[FeXoR]

Here's another version.

Changes:

- Players will not be placed in the corners (only inside a circle fitting into the rectangular map)

- Players will now be close to "bog" (low ground) and "woods" (high ground) so they will more likely have access to all resource types (due to the very random nature of this map an equal amount can still not be ensured).

- Again added more bushes to the "bog".

- Reduced the number of deer entities.

- Very Large and Giant maps does not seam to raise an out of memory error any more (not sure why, guess the extreme reduction of possible start positions is the reason).

The map takes longer to generate now because of the "ensure players are close to low and high ground" check.

In some cases the added start location restrictions result in less "equal" start location derivations over the map. I still think it's an improvement. Here's a screen shot that shows that:

Since no high ground is top left no player is placed there. So one player is more in the mid of the map so more likely to be attacked. That does not happen often with 3-5 players. With more then 5 players it's natural (when maximizing distance between players) and intended.

And the map: belgian_uplands2012-9-18.zip

If no further bugs/objections show up I will add a ticket soon to add this map after I cleaned up the code.

Afterwards I will refocus on a general erosion lib for rmgen and mess around with the existing maps

Edited September 18, 2012 by FeXoR

[Pureon]

Brilliant work FeXoR. I like what you've done with it.

[Mythos_Ruler]

Now all we need is buildings flattening terrain when being constructed.

[feneur]

Now all we need is buildings flattening terrain when being constructed.

We might be getting that soon: http://trac.wildfiregames.com/ticket/21 (But maybe that was what you were alluding to? )

[historic_bruno]

The map takes longer to generate now because of the "ensure players are close to low and high ground" check.

Why not start with the player positions defined, and use that as a constraint when generating the terrain? Otherwise you end up with situations where there may be no room to place a player, especially on smaller maps or when there's many players, and as you say the random(?) search for valid positions is time-consuming.

[FeXoR]

Why not start with the player positions defined, and use that as a constraint when generating the terrain? Otherwise you end up with situations where there may be no room to place a player, especially on smaller maps or when there's many players, and as you say the random(?) search for valid positions is time-consuming.

I could do this and place the terrain after the players and restrict placement of other entities in the areas around the players but:this is mainly a test of concept map for heightmaps generated by erosion to look more natural. To derivate players like I do now feels more natural to me as well. Additionally there's no way to tell if the predefined start locations will be placed where water shows up on the random terrain (Or after everything is build and a player is detected in water the heightmap would have to be rebuild... even more time consuming OR the heightmap would have to be changed "artificially" afterwards to ensure the players are placed valid which somehow defeats the purpose of this map). Most other maps (or all) are done like you suggest but I think variety in the random maps is a good thing, not only in design but also in the general approach. In some rare cases it can indeed happen that there are not even 8 valid start locations but only on a tiny map. I'm pretty sure that no one would like to play with 8 players on a tiny map and many other RMS will wind up in chaos as well with this settings

EDIT: The players start locations are chosen "randomly" because lets say there are 100 valid tiles found to place the start positions and there are 8 players present leading to a number of 100^8 = 10^16 = 10000000000000000 possible player derivations. Looping over them will result in an out of memory error. So I randomly pick 10000 possible derivations and finaly take the one with the maximum player distance (more precise the derivation with the maximum distance between the 2 players closest to each other).

Now all we need is buildings flattening terrain when being constructed.

That would help, yes. Keep in mind though that flattening the terrain in one area will make it more step on the edges of that area so it might be good not to flatten it totally but only make it more flat. The changes to the terrain will be seen after the building is destroyed as well and might look a bit strange but it's quite realistic that terrain build by mankind looks a bit "unnatural". another question is: Will it be applied to buildings placed in random maps at all? I guess it will have to be implemented for RMGEN separately...

Edited September 20, 2012 by FeXoR

[Zaggy1024]

That would help, yes. Keep in mind though that flattening the terrain in one area will make it more step on the edges of that area so it might be good not to flatten it totally but only make it more flat.

I don't think anything but completely flat will work, because some buildings (like the Greek civil center) have floors (or tiles in the case of the Greek civil center) that wouldn't look good if the ground underneath isn't completely flat.