Enable high reclaim style for all biomes #384
Conversation
|
For some reason I now have the problem that all boulders spawn twice. |
|
Update: It's all the prop placing that happens twice and it seems to be related to having the generation run with --debug |
|
Added boulder fields |
There was a problem hiding this comment.
This PR ostensibly decouples the biome from the map style but only does it halfway. If it were truly decoupled the biome would be removed from the parameter constraints all together.
This has to happen because the biome is being set independent of the mapstyle in the command line arguments.
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.
| HIGH_RECLAIM(HighReclaimStyleGenerator.class, .25f), | ||
| HIGH_RECLAIM(HighReclaimStyleGenerator.class, 1), |
There was a problem hiding this comment.
as the high reclaim biomes don't have as extreme reclaim numbers as before I intended to increase their chance a bit. I didn't ask the matchmaker team for feedback yet
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). |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 |
|
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? |
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.
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. |
|
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. |
|
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 .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. |
|
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. 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. |
|
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. |
|
Oh yeah I forgot that we have only one seed for everything. We keep the style presets for a whole-in-one generation of presets.
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. I hope that goes into a similar direction to what you meant with the "custom" style generation. |
|
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. |
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. |
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.
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. |
What is the scenario where this happens?
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.
Hm, I understand the problem. I'll have to think about it some more if this is at all solvable. |
|
I would not pull out the biome separately. Also this is likely a change that is client incompatiable at the momen |
|
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. |
|
Because of the reclaim and different texture requirements as stated earlier |
|
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 |
|
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 |
|
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 |
|
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. |
|
If we want more granular biome choice then I would go the route of more granular texture generators rather than direct biome selection. |
|
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 |
|
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. |
|
yeah, I think we are in agreement here. |
|
Superseded by #396 |
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