Enable high reclaim style for all biomes

[BlackYps]

I added boulders surrounded by small stones throughout the map. It works quite nice even on biomes that didn't have the ability to generate high reclaim before.

I still need to make the style and biome option non-exclusive

[BlackYps]

For some reason I now have the problem that all boulders spawn twice. I went back to the first commit where the screenshot is from, but now I have this problem there as well. Sometimes it works as intended, but I couldn't reproduce successful generations yet and I have no idea where the double spawns come from. Looking at the code that should not happen at all.

[BlackYps]

Update: It's all the prop placing that happens twice and it seems to be related to having the generation run with --debug

[BlackYps]

Added boulder fields

[BlackYps]

But this means that any biome has to support any map style which might be a tall order to ask of a biome so I am not sure if this is wise or the direction it should go.

I think the root of the problem is that most of the styles primarily concern terrain generation, but some styles affect resources as well (high reclaim and low mex). Maybe we should think about a decoupling here, as at the moment it is impossible to combine options to have a map with a center lake that has also high reclaim prop generation. Imo the biomes should mainly act as an aesthetic skin to the map. I understand that this is not 100% possible, because different props have different reclaim values, but the current high reclaim style also significantly alters the way props are placed, so the high relaim amount doesn't only stem from choosing a biome that has naturally high reclaim props.

[Sheikah45]

Biomes weren't designed to only be a different skinning thought especially when you bring reclaim into it.

I am not sure this is something you can just wave away.

Also why reduce the amount of reclaim on high reclaim style? It was intended to be very high.

[BlackYps]

Then what were biomes designed to do?

I was working with the input from the matchmaker team. I don't remember the details anymore. We could change the average reclaim amount that the new high reclaim biome produces.

[Sheikah45]

The biomes as they currently are were designed to be an aspect of the style, with the intention that potentially different terrains could have different biomes that benefit them and could be coupled with different texture generation processes and differences between how the layers are used.

You mention mostly terrain generation but there is also texture generation that can be different which is highly coupled to biomes as you know from the pbr.

Decoupling in this case could lead to for example a non pbr biomes being used with the pbr texture generator.

[BlackYps]

But most styles aren't really doing that, are they? Styles like big islands, center lake, little mountains, etc. are the vast majority and these are rather generic styles. I find it unsatisfying that I can't select a style when I choose a certain biome.

Looking at the code again, what I really want to decouple is the terraingenerator and the texturegenerator. The texturegenerator, propgenerator and decalgenerator are inherently linked, but the way we have used the terraingenerator so far it is orthogonal to the biome. I.e. the terrain generation does not try to create shapes that e.g. fit a desert specifically.

But either way I think we should ask some more people about their opinion what styles should or should not do and how the biomes should be related to them. We probably won't convince each other because in the end it's to a large degree a matter of opinion/vision how the map generator should work. Being only two people we run the risk of inadvertantly choosing a solution that runs counter to what most people want.

[Sheikah45]

This isn't really a question of what styles should or shouldn't do, but almost exclusively a maintenance burden problem.

Generally the wide range of options were a failure as they are hard to control and predict from just the values given.

They were all bundled under styles so they can have greater cohesiveness and easier to maintain and predict.

You say the terrain generation is uncoupled right now but that is only the case because no one has implemented a coupling yet and I didn't have time to initially when I split things out.

But the style system was created to encourage that coupling for better quality maps.

[Sheikah45]

The idea was similar to how age of empires does their generation.

Additionally separating the terrain generation from the other generators is just adding additional complexity for little gain as generally it isn't good for players to select those things independently and my goal is to lower the number of options not increase them.

Maybe it would be good if this was used as seeding for map making but not in the map generator

[BlackYps]

Hm, I'll have to look into how the terrain generation works in age of empires.

I have approached this from the user perspective and there it is a bit frustrating that you lose access to the terrain presets when selecting a biome. I assume that many people want to control the biome they generate because people seem to have strong opinions on the different biomes. Losing the map style options and being thrown back to only the value sliders when wanting to control the biome selection is frustrating and runs counter to the plan to encourage people to use the map styles for higher quality maps.

can you explain what you mean with the seeding?

[Sheikah45]

I have approached this from the user perspective and there it is a bit frustrating that you lose access to the terrain presets when selecting a biome.

I am going to push back on the idea that greater end user choice is a good thing. That is exactly how the sliders started. People asked if they could control the terrain generation a bit more, or the mex density, or the reclaim. So I added these as options with possible values. The result was that people just complained that the sliders weren't behaving exactly as they expected and the code began to turn into a maintenance nightmare. This was because while giving the end user choice and flexibility you also had to also produce reasonable maps so that they weren't only water or everything covered in mexes. So this just lead to convoluted constraints on the generation process and people being upset because it wasn't working how they expected.

If a majority of people don't like a biome that is more a sign that the biome should be reworked to be less offensive rather than going down this decoupling route.

can you explain what you mean with the seeding?

This would be the case if this was ever embedded into a map editor, where the generator could start some layer and then a map maker would tweak it to their heart's desire.

[BlackYps]

I partially agree in the sense that more choice is not always better. Can you link me to a discussion about the sliders? I'd like to better understand the process of adding them and their problems. And can you elaborate on how that lead to a maintenance nightmare?

The problem with simply reworking a biome is that people have different tastes, so we can't realistically create a situation where everybody has no significant preferences with biomes. But let's shelve the biome specifics for now and let's rather focus on the more general discussion about "what user choice do we want to (not) make available". I think this carries us more forward now, and we will naturally come back to the biomes later anyway.

[Sheikah45]

There isn't really a centralized place of discussion about the sliders since I was really the only developer at that time. It was only the feedback I was getting from the players and requests for more control over map generation. But some big picture parts of the discussion can be found around this point in the discord https://discord.com/channels/197033481883222026/832725552157687859/983714875467501608.

As for seeing the complication the sliders introduced you can just peruse through the code before the styles were introduced in version 1.3.6 starting around here https://github.com/FAForever/Neroxis-Map-Generator/blob/b8b9ae1de273b66ae274faa0a6dc3cb00826c56d/src/java/neroxis/generator/MapGenerator.java#L869.

There are a lot of if statements and nested control flows that made it very hard to reason about what was going to happen given a set of parameters passed from the player. This lead to the case where needing to make any single change to the generation path required extensive testing to cover all the edge cases and even then something would probably go wrong and weird maps would be generated relatively frequently.

The cause of this was because the sliders and choices seemed to imply that these parameters were independent when in reality for good maps they are very tightly coupled. And trying to present them as uncoupled was just a nightmare scenario. So instead I leaned into the coupling with style generation so that the options were reduced but the quality of maps could have a higher floor.

And with biomes they are still tightly coupled even to the quality of maps because of the reclaim situation. Then you get to the visual quality of maps with the texture generation and so it is better to just admit that up front rather than go down a path trying to make them independent because they just aren't.

And for reworking biomes that is why I said if the majority finds them then they get reworked. Otherwise they are fine because as you said you can't please everyone. And the intention of the use of the map generator from the client perspective isn't necessarily to allow people to generate maps exactly as they want but just to generate new maps they haven't seen. And if they roll the dice a few times when generating because they don't like the biome they got when hosting that is perfectly acceptable to me because of the complexities of doing otherwise.

This is also all before getting into the map name encoding and the determinism aspects.

[BlackYps]

Having read all that I came up with a rough idea for the future. It would probably need significant refactoring in some places, but I want to propose it anyway so we can discuss the feasibility. I think we should nuke the water, plateaus, mountains and ramps sliders for good. As you explained, these are tightly coupled and for example the water slider makes it apparent that we can't guarantee that the amount of water surface correlates close enough with the slider setting to be a satisfying control. It seems to be the better approach to have users choose a map style instead. The problem I see with map styles at the moment is that they can not only affect terrain generation, but also mex and reclaim generation, which makes them harder to use in a flexible way, e.g. combining low mex with a center lake terrain. I propose that we create terrain styles instead. These only affect the terrain generation. We could then control mex and prop placement either with sliders or additionial resource styles. Basically we would expose the different prop generators to the users, so they can either still be chosen at random or the user can choose a specific prop generator. Additionally we should make the symmetry available as an selectable option. From my understanding of how the players use it they often generate a terrain that suits them, but the resource distribution is not satisfying. So there seems to be a strong desire to be able to influence mex placement. Granular control of ramp distribution doesn't really seem needed in comparison.

What we could maybe do, but I am not sure if that is too complicated, is to allow a partial regeneration of the map. So you would keep the terrain of the map, but would regenerate the props or the mexes. I would have to look up the details, but I would guess that some steps depend on earlier steps, I imagine the prop generator needs the mex locations to not spawn props on mass spots. So regenerating the mexes would force a regeneration of the props, but I think that is ok and we can communicate this with adequate design of the user interface.

[Sheikah45]

Partial regeneration is not feasible because that would require those steps to have independent seeds and that would be a breaking change to the map name encoding as well as making the map names too long.

As far as making it only terrain style I am not as sure about that either because the map style was designed to be fairly cohesive and things like prop distribution are affected by the terrain due to how pathable the map is and the amount of water limiting where you can place certain props for example. I would think that it would be more reasonable to just expand out the set of map styles that currently exist. And they shouldn't be removed because they are effectively premade wrappers for ways to produce good maps.

Maybe I could be convinced of allowing a form of "custom" style that allows a user to compose the underlying generators as they wish but that requires a lot more communication between the client and the generator about what is possible.

But I am definitely against using sliders for anything more as they are just poor communication.

[BlackYps]

Oh yeah I forgot that we have only one seed for everything. After more examination of the current code I have the following proposal:

We keep the style presets for a whole-in-one generation of presets. But we change how the tuning options work, if people don't want to use these presets. I propose the following options:

• Seed
• Symmetry
• Choosing the Terraingenerator
• Choosing the Biome
• Choosing the Resourcegenerator plus slider for mex density
• Choosing the Propgenerator plus slider for reclaim density.

My reasoning is that instead of having just these dreaded sliders that only offer an illusion of control people can basically create their own custom style. Which terrain generators are being used is far more important than the density values that are the input for the terrain generator. For resources we don't have that many generators, but I like the direction they go. They basically control the spawning options. The underwatermex version is a good example. We could add one that produces very uniform distribution and one that produces very clumped distribution of mexes to accomodate the wish to control mex distribution that I read in the discord discussion somewhere. My reasoning to also provide a density slider is that this basically allows a reroll of the mex distribution. We can keep the same seed, so the terrain will be the same, but a different mex density input will make the resouce generator produce a different layout. This way we don't run into problems with deterministic generation from one seed. The reasoning for the prop generation is basically the same.

I hope that goes into a similar direction to what you meant with the "custom" style generation.

[Sheikah45]

There is no guarantee that the same seed produces the same terrain if any other option changes and that is not really a guarantee I am interested in supporting due to the limitations it imposes.

Given that, the sliders are not a good idea just because it is still hard to give meaning to those values and just makes determinism harder when you allow people to override the values or introduces complex map name parsing logic.

It would just be better to give people discrete choices of prop and or resource generators rather than a seemingly continuous slider.

[BlackYps]

There is no guarantee that the same seed produces the same terrain if any other option changes and that is not really a guarantee I am interested in supporting due to the limitations it imposes.

It's not an explicit guarantee, but if the terraingenerator doesn't use the mex or reclaim density values, then it doesn't change the terrain generation. And to my knowledge that is the case at the moment.

I don't understand how overriding the values makes determinism harder or introduces parsing problems more than choosing a generator.

What we could do is to start with the generator choosing, because this is the main improvement. When we have that we can test it and maybe it's good enough already that I don't even see a need anymore for an additional mex density slider.

[Sheikah45]

It's not an explicit guarantee, but if the terraingenerator doesn't use the mex or reclaim density values, then it doesn't change the terrain generation. And to my knowledge that is the case at the moment.

If the random number generator is called in a different order you will get a different terrain. So it doesn't necessarily need to use those values for them to affect the terrain. And the fact that it is not an explicit guarantee is why I don't want to make it an implied one.

I don't understand how overriding the values makes determinism harder or introduces parsing problems more than choosing a generator.

The problem becomes what happens if the user doesn't override the value. Do you leave that out of the map name or do you put in some placeholder value. If you leave it out of the map name then you have a variable length encoding that depends on context so you need to spend more bits encoding that. If you include it in the map name then the have to make sure your generation processes when it is explicitly included in the options vs not are the same and still produce the same maps.

[BlackYps]

If the random number generator is called in a different order you will get a different terrain.

What is the scenario where this happens?

And the fact that it is not an explicit guarantee is why I don't want to make it an implied one.

We don't have to imply it. I think people will figure it out by themselves. But if we don't give a guarantee (and don't imply it) then it's fine if it breaks at some point in the future, so we don't have to worry about it.

The problem becomes what happens if the user doesn't override the value. Do you leave that out of the map name or do you put in some placeholder value. If you leave it out of the map name then you have a variable length encoding that depends on context so you need to spend more bits encoding that. If you include it in the map name then the have to make sure your generation processes when it is explicitly included in the options vs not are the same and still produce the same maps.

Hm, I understand the problem. I'll have to think about it some more if this is at all solvable. Apart from this detail if we include a slider for some options (let's assume for now we get rid of all the sliders), do you see merit to go into this direction of letting the users select the generators of the generation steps individually?

[Sheikah45]

I would not pull out the biome separately. Also this is likely a change that is client incompatiable at the momen

[BlackYps]

Of course it is not client compatible at the moment. I am trying to define some sort of roadmap and then client changes have to be part of that if necessary. Why would you not pull out the biome separately? It's basically the way to control the texture generator.

[Sheikah45]

Because of the reclaim and different texture requirements as stated earlier

[BlackYps]

but when you can select the reclaim generator then this is not an issue anymore. The correct texture generator could automatically be chosen depending on the biome

[Sheikah45]

It is not just about the reclaim slider but also the appearance and placement of the reclaim with the prop generator. And it forces all styles to support all biomes which is not something I want to force on styles

[BlackYps]

Do you mean terrain generators? This is independent of the styles. You would either select a style OR fiddle with the generators and choose a biome

[Sheikah45]

There is an interdependence between the texture generators and the biomes that would be too cyclical.

Because it seems like you are implying a biome would know what texture generator is uses but a biome could technically be used for multiple texture generators. So I still think the texture generator should limit the biome not the other way around.

[Sheikah45]

If we want more granular biome choice then I would go the route of more granular texture generators rather than direct biome selection.

[BlackYps]

This seems to be a misunderstanding. When we specify a biome the mapgen chooses an appropriate texture generator (at random, but at the moment there is only one valid texture generator per biome). I don't see what the issue is with specifying the biome. It is already possible with the mapgen as it is now. There is no need for a cyclical dependency.

More granular texture generators is not feasible IMO. I coded the only other texture generator other than the default and it was way, way too much effort to do this for every single biome and honestly I don't see the benefit. It is possible to create very different looking biomes that all use the same texture generator. I also don't expect any random contributors to show up and to code a new texture generator. The possibilities for artistic control are very low and indirect. It is much easier to make a new biome and even that have only done very few people.

I don't understand why you are so adamant on not providing a biome option when the mapgen already supports this and shows that it is feasible

[Sheikah45]

The point is that there will be no support for supplying a biome and a map style. I guess if we remove all the sliders then we can also remove the parameter constraints from the sub generator types.

But it still wouldn't be possible to just pick a biome for a map style, instead it would be wrapped in a custom style. But the usage should make that clear. As it also needs to be thought through what happens if people only specify a biome.

[BlackYps]

yeah, I think we are in agreement here. I'll try to come up with a rough sketch how the new ui would look like. During this I hopefully also find an answer to the question what happens if people only specify a biome. It might take some weeks though as I am becoming busy with other stuff.

[Sheikah45]

Superseded by #396