Thanks

The function scaleByMapArea takes its default max area from a map size of 256 which is incorrect, as it should be 512 like the above function scaleByMapSize. Calling that function with that default would lead to incorrect results.
Since all random maps call it by the intermediary of scaleByMapAreaAbsolute, which uses its own maxMapArea, this has no consequences on current maps, and the fix is trivial (change the default value in scaleByMapArea to 512).

In D5247#223311, @Baelish wrote:

Be careful about that. Depending on how it's done it could have an impact for competitive gameplay. Distance of berries for example is quite important as it can occasionally happen that there is a very early cav raid here and the longer it takes for women to come back to CC, the more are killed. And maybe if a resource is close enough to the CC that can remove the need to build a dropsite to collect it.

I understand what you mean, but the code starts on the same radius for each player and it stop iteration if there is enough space. You can see the difference only if some players have got big disadvantages with their space, so it can be a rebalancing to put resources nearer. In addition, I want to underline that code searches all around the base, so if a player has got all the external radius full, is strongly disadvantaged.

In D5247#223305, @sera wrote:

Anyway I'm only in this discussion for code review and have no relevant opinion on starting base layout, so I wont root for or against it.

Yeah I imagined. Even though I quoted you I intended my argument to be directed to everyone. I made my opinion since reading the ticket already.

In D5247#223300, @sera wrote:

What the ticket suggest is to make the radius variable to some extent to increase the probability such a solution exist in the first place. Ofc there is a tradeoff that now possible minor imbalance is introduced, like one players chickens are on average one tile further away than the other players or the like.

It is good if the base placer is more flexible.
That said, in my opinion, it should not be expected of every random map to support the most extreme settings. So if an hypothetical random map that typically has 75% its total area impassable is generated in 4v4 tiny and fails to place some features... It's fine in my opinion.
What should be done imo is that in the game settings screen, if the configuration is deemed too extreme, then a warning should appear (I'm not referring to the console but something integrated to the game settings UI) but the user should be allowed to launch the game anyway. Then if the base placer fails to place some features, it should not show an error, at best a warning (possibly more generic, appearing once, saying not everything has been placed).

In D2830#220221, @real_tabasco_sauce wrote:

In D2830#220220, @Feldfeld wrote:

In D2830#220216, @real_tabasco_sauce wrote:

So why is it that you can't place the players and then apply the noise to the non-player area? Then I think placements might be more balanced and u could use the placement options.

Since the player area will be set to the low elevation without considering the noise output at that location, there will be areas at the frontier between player area and the non player area where the noise value will be very high, making a huge delta of elevation, and that would most likely make it look unnatural as it will also draw a clear circle. That said it's true that I didn't try it and maybe there could be ways to mitigate and not make it look as bad as it sounds. But that map was not much designed for multiplayer, because even if that issue is fixed there is still the problem of small chokepoints not playing well with 0 A.D. (though that didn't stop players from playing Ambush, I guess)
Also when player placements are predictable that is one less thing you can get out of exploration though that doesn't compare with having a nicely balanced map.

That last bit is partially solved with the placement options. Especially since you can choose random selection, or select randomGroup, which is a bit more balanced than the current randomGroup-esq placement. In 1v1s, the placement options yield pretty interesting results.
Then you would have to have some kind of smoothing function to avoid the sharp ring around each player.
Also, even with the current generation, I think the iber walls work out ok, so they should still spawn.

Sorry for the late answer.
By randomGroup, are you referring to the playerPlacementRandom function? If not sorry if I'm not up to date with latest changes.
If it is playerPlacementRandom, I have some concerns about the resulting balance with that option. In a 1v1, it can place both players pretty much adjacent, and it can place a player in a corner. Even if the result is balanced, adjacent starting positions may still not be desired.
See a gen of Belgian Uplands to illustrate what I mean:

In D2830#220221, @real_tabasco_sauce wrote:

In D2830#220220, @Feldfeld wrote:

In D2830#220216, @real_tabasco_sauce wrote:

So why is it that you can't place the players and then apply the noise to the non-player area? Then I think placements might be more balanced and u could use the placement options.

Since the player area will be set to the low elevation without considering the noise output at that location, there will be areas at the frontier between player area and the non player area where the noise value will be very high, making a huge delta of elevation, and that would most likely make it look unnatural as it will also draw a clear circle. That said it's true that I didn't try it and maybe there could be ways to mitigate and not make it look as bad as it sounds. But that map was not much designed for multiplayer, because even if that issue is fixed there is still the problem of small chokepoints not playing well with 0 A.D. (though that didn't stop players from playing Ambush, I guess)
Also when player placements are predictable that is one less thing you can get out of exploration though that doesn't compare with having a nicely balanced map.

That last bit is partially solved with the placement options. Especially since you can choose random selection, or select randomGroup, which is a bit more balanced than the current randomGroup-esq placement. In 1v1s, the placement options yield pretty interesting results.
Then you would have to have some kind of smoothing function to avoid the sharp ring around each player.
Also, even with the current generation, I think the iber walls work out ok, so they should still spawn.

In D2830#220216, @real_tabasco_sauce wrote:

So why is it that you can't place the players and then apply the noise to the non-player area? Then I think placements might be more balanced and u could use the placement options.

In D2830#220145, @real_tabasco_sauce wrote:

So I just did a few generations of the map and it looks great. I really like the randomness where you don't necessarily know what resources or even space you will have access to. So @phosit this map is quite unique compared to the existing maps.
One issue I have is that the mountains themselves take up so much playable space. I think it would be good to keep these obstacles in place while increasing the playable map area, so basically making the mountains steeper.
I would like to see slightly more frequent clumps of wood. I like that they are very dense, but in my eyes, wood shouldn't be too difficult to expand to. There were a couple 1v1 generations where 1 expansion would get 1 player control over almost all the accessible wood, and in team games it was even rarer to find forests not associated with a player.

In D2830#220143, @phosit wrote:

In D2830#220110, @Feldfeld wrote:

Could there be an interest in merging this map?

Propably we should answer this question first before you invest more time. I don't think real_tabasco_sauce perceives this map as pretty only by changing some decoratives or textures.

May i ask you what the uniqueness (gameplay wise) of this map should be? Compared to Ambush or Frontier for example.

It looks a bit computer generated. Maybe you could add more decoratives or use multiple "floor" (not mountain) textures.

It does look computer generated, though to my eyes the biggest factor in that is that the Simplex noise (or at least how I used it) is too regular.
I recall when I made the map I tried to experiment with many textures and decoratives, and this was the result. But I definitely take any suggestion on that side.

Could there be an interest in merging this map?

That's to reflect the fact that sometimes elephants could run amok and kill friend or foes alike, I believe.
For me it would also make sense if catapults also had splash damage + friendly fire, but oh well. Not so easy to balance.

I kinda preferred when it had higher hack armor than pierce armor as it was realistic
Other than that, if this can go into the game before the release, then I rather have it in even if it is still imbalanced, as it is definitely better than the big imbalance that was looming.
Then this can get tuned again in community mod.

I agree it looked weird before.
Indeed effects on gameplay/balance should be negligible. I won't test but I believe this will delay a little bit the start of gathering on slaughtered animals but those are advantageous compared to huntables anyway.
This maybe nerfs corraling a little bit but it was not balanced to start with so whatever.

I checked the tech tree ingame and it appears there is a "friendly fire" feature to their splash damage. Did you observe its effects? It might be important for balance.

Then go for it for sure, 20 splash still looks like a lot, elephants were strong already in A26 despite there was no splash damage.

From what I've seen in the forum and this patch, it does look like the elephant is super OP and a nerf is needed. I don't have the time to experiment with values now, so go with this if no other feedback.

So it seems there would be now two distinct groups of resources. The primary group directly adjacent to the CC, starting animals, small forest, berries and two mines. And a secondary group somewhat far away but still part of the greater player base. Neutral resources would be outside of the greater area I suppose.

Indeed that's the goal (this emulates fairly well former mainland gameplay except this time resources are balanced)

In D4232#201256, @marder wrote:

Just some random meta comments:

There are enough forum threads of people wanting balanced maps that we should definitively do something for a27.

my biggest question is to what extent should things be balanced?

We already have the 'basic' balance of the normal starting animals + straggler trees. Funny enough, many of the new scenario maps don't even have this anymore.
This patch aims to also balance the hunt in the surrounding area (and maybe in the future also the surrounding forests)
We have some symmetrical maps proposals which make 'everything' balanced, while still having random looks: D4053 or https://wildfiregames.com/forum/topic/85756-fair-multiplayer-random-map/
And we also have the multiplayer who just want a flat perfect balance plane: https://wildfiregames.com/forum/topic/83077-map-balanced-plainland/

So I'm not sure what the right balance is between randomness and balance / or what people want.
Should we go after all of the approaches? I.e. have some symmetrical maps, have a flat plane for people who don't like pretty things and try to include something like intermediate area balancing/ this patch?
Or should we choose one and stick to it?

In D4232#200536, @lyv wrote:

I am not sure if this is actually going to be that usable unless the map scripts are explicitly designed to be balanced. And having the overall balance of it tweaked via Gamesettings seems somewhat ineffective. Having the option doesn't really matter if the underlying generation isn't updated too.

I generally dislike having too much options as well since it essentially creates two branches of code. And while balance is important, so is imbalance.

I propose making actual balanced maps, starting with D4053, and your balanced mainland, under a new keyword, "Balanced".

Then again, balance and resource balance are also not the same thing. And the patch Is specific to food, as you see, this quickly spirals to the point where trying to plug this into existing maps as a knob in gamesettings isn't enough and you end up rewriting the map anyway.

Feel free to argue for the concept, nothing is set in stone. Read "requested changes" as "requested for comments".

In D4232#192239, @marder wrote:

Makes sense, but I think that's not what you would expect when reading the description : Every team will receive the same amount of resources overall sounds to me like they actually get the exact same amount. So maybe that would need to be rephrased.

In D4232#192236, @marder wrote:

after a quick test: It does work as advertised with player balance and no balance, but the team placement seems a bit less reliable?
What is the expected result in a 1v3 for example?

Of course if there is a new patch to add mainland balanced, it would have to be much smaller and include only that map.
The reason biomes were duplicated was so I could remove the Jungle biome, IIRC it was quite laggy, but of course that would not be something I do if Mainland Balanced gets included in the game.

The ideas I had to make biomes look better was to first of all let them describe more resources, like @wowgetoffyourcellphone did. Some resource/decoration type could be left blank if the biome doesn't feature them and from there, the biome tries to describe as much stuff as possible. And behind this, the map maker would implement as much as they need/want.
This would make map scripts more complex in general (so I guess against what @smiley said if I understood correctly), but well I feel like many random maps currently in the game lack refinement.

Thanks :) Yes I agree that the snow distribution is subotimal, the problem is the the new snow textures don't blend well with other textures, therefore it is hard to reach a natural looking result either way. But I can try the ways you proposed.
It should be noted however, that the current distribution is at least semi realistic. When the first snow falls, the forest floor is usually not covered, as the snow fall on the trees and melts there with the next sunshine.
In spring it is the other way round: snow stars to melt on open ground as the sun shines on it, but the snow that has fallen over the course of the winter inside the forest is covered in shade and survives longer.

That's a nice rework of the map, I like the concept of the new biomes.

In D4232#181200, @marder wrote:

To throw it into the discussion here, because it seems related,
This map could solve balancing resources:
https://code.wildfiregames.com/D4053

Resource distribution has been moved to player.js, where base resources are done.

Updated, now the function works as I intended.

Yes indeed this is what I had in mind.

Here I used the function scaleByMapArea in mainland and I will explain my changes and my non-changes.

• The terrain textures currently scale by map size, however not only their quantity, but also their size scale with map size, so by the same argument used with forests earlier in this patch discussion, even if it is possible to reach a good and natural result using scaling with map area, it is not immediately obvious how to reach it, so I didn't modify this
• The placement of hunt and berry patches only scale with the number of players. As a consequence it looks unnatural, if I generate a 1v1 in giant size the map will be almost empty of hunt and berry patch, and the probability that one of these resources spawn next to a player is very low. Like I justified in this patch, resource placement would be an improvement using scaling with map area, however since it will be even better with my other player resource balancing patch I decided not to change it yet.
• The placement of decorative actors scales with map size, and looking at the values it looks like the intent was to preserve the density with map sizes. However it will always be imperfect using linear interpolation as explained in the patch summary. See how straightforward the conversion to using map area was, and how I didn't need to tune a 'max 'argument.

It should be checked if this is really required. Example maps might convince.

From a technical standpoint, I guess you are trying to replicate AoE2 style distribution where the base resources of berries, 2 boars, etc. In that case, rather than making a swiss army knife of a function for N cases, it might be better to incorporate this into player placement.

In my opinion this just forces a particular type of game

It forces nothing as soon as the meta is different than (rush OR p3 boom with timing attack), which it arguably already is in a25

If you have more berries, then a rush of any type is more likely. If you have more hunt then a rush of any type is more likely.

It is more likely... but it is far from guaranteed. So, if you play in this balanced map and you see you have 1 or 2 patches of berry other than the starting one, what are you going to do? Judge that a rush is more likely, decide to skip scouting, and make more men early and risk being at a disadvantage if the opponent decides to go full boom? Looks like scouting is still useful. Even without additional resources, scouting how much commitment an opponent has booming can still be useful, I have a good replay which shows that.

Additionally, another way to make rushing less predictable in game, would be to have hunt being useful to things different than rush, say booming, or corralling.

In D4232#179859, @chrstgtr wrote:

In D4232#179849, @Feldfeld wrote:

In D4232#179836, @Freagarach wrote:

It would make it easier for potential reviewers to take a look at your patch if you would provide context. :)
(And set the repository to 0 A.D. when uploading.)

If it is what you mean, the context is that the multiplayer community is interested in the balance of the game, and map balancing is an important part of it. Since mainland is the most standard map played online, it is the first map getting changed in this patch.
The biggest cause of imbalance in multiplayer games is the availability of additionnal food near the player base. Because this food is faster to gather than say fields, and because it can facilitate strategies such as cavalry rushing, you can see there is an interest of having each player get a similar amount of food around his base.

For what it is worth, "imbalanced" res actually makes games much more fun for me. If everyone has the same food, especially if I know what type of food, then I can make a pretty good prediction as to whether or not I will be rushed. For example, look at games on African Plains. Everyone knows there is a ton of hunt. Everyone knows a lot of hunt means that a rush is likely. As a result, everyone makes a ton of men/cav early. Is that balanced? Sure. Do I know whether a rush is coming? Pretty close. Is that more fun than an unpredictable game? I don't think so. And I think the fact that African Plains is now a rarely played map reflects the fact that this isn't something that multiplayer community actually wants. This has been a compliant that has been repeated with respect to the balanced maps mod.

Personally, I would prefer if teams--not players-- had more balanced resources. That way the unpredictable, fun nature of the game is preserved while enhancing balance. Team balancing would also fix the 1v1 problem of imb resources because that would still be two different teams.

In D4232#179836, @Freagarach wrote:

It would make it easier for potential reviewers to take a look at your patch if you would provide context. :)
(And set the repository to 0 A.D. when uploading.)

Handle square maps

Is it different though? It would make just as much sense to scale forest sizes with areas.

Fixed a bug which could trigger errors on placing players initial resources, and could slow down loading time. Now the map generation should be very reliable.
Added winter biome, and 3 environmental presets that go with it: Sunny, Snowy and Night. For now they are chosen at random. I am not fully sure that I know what I'm doing with environmental settings.
Here is how the map looks like now:

New terrains. Might make a winter biome, and possibly also something more elaborated later on.

• Flood fill now avoids the map border
• Now nomad generations always have enough space
• Better wood generation
• Updated a few gaia entities in reaction to the terrain and map overhaul, however I didn't change terrain, but I am open to suggestions for that.

Update: use flood fill to get an area instead of only connectivity check.

Considering this patch as a standalone (ignoring major gameplay changes that could happen), and from a multiplayer gameplay POV:

• From the few games I played up to now in a24, I would say that in 1v1 mainland, both strategies (making a new Civic Center in town phase, against going straight to city phase without building a new CC) are good depending on the situation. Note that for the 2nd strategy, still building a new CC in the city phase will probably be needed.
• However in teamgames played in mainland expanding with a new CC is generally not worth it.
• That said many maps other than mainland reward expansion.

where one player can be basically entirely surrounded by mountains except for a minor passage near the border, things like that

It is in my plans to add a constraint so that the flood fill passage can't be near the border because indeed that can hurt gameplay.
I will also try to guarantee bigger passages but I don't know to which extent I can go without making the loading time too long.

Rebased

In D3538#155144, @wraitii wrote:

I'm OK with committing this if you're confident in the values. They seem sensible to me.
For reference, bireme is 800 health, trireme 1400, quinquereme 2000, meaning it now takes one additional fire ship death to destroy them.

Not really. We had two +10% cavalry speed technologies, now only one +10%. Before we had a +20% health increase for all cavalry, now it affects only champion cavalry and a new one with +10% health.

Fair points. The speed technologies were quite expensive though.

In general the ranged cavalry was very nerfed compared to the a23. Now you need stables for mass training, range and attack is reduced, spear cavalry has its bonus increased and sword cavalry is more effective against ranged units, including cavalry of course.

To compensate there are 2 new technologies for cavalry (speed and health) whereas infantry doesn't get any of this. Also now forge technologies that affect cavalry also affects infantry so it makes it a bit easier for cav player since sometimes they will want to fight with infantry too.
The train time of cavalry has been relatively reduced compared to infantry (+2 seconds for infantry when they were at 10, +1 second for cavalry when they were at 15 iirc) so it makes them easier to mass. Also persian for example has 2 technologies that reduces train time by 10% for archer cav
Range is reduced but spread as well so they are more accurate.
The formation change makes it easier to hit and run.

Good for me, the fire values before the patch had very little effect.

I think Freagarach's values are a bit more natural, it makes fire damage more continuous.

I used svn's context menu on windows.
I asked someone else and they also could apply the patch just fine so no problem.

Can do that.

Rebased

This is blatantly untrue. They had 150 crush / 1.5 s in A21, A22, A23 and still do in A24.

I guess borg looked at roman ram and forgot about the bonus. That number also felt familiar to me.
I'm also fine with not changing because of the new siege technologies and also because after all there were a lot of complaints about rams in a23

I had this error on applying the patch:

I think there is an issue with the patch (file path)

I see. Then just in case I will do some experiments with the new values I think.

Indeed as of right now siege technologies are almost never researched. Looking at the modifications the new values seem good, nothing will be broken.

Indeed as of right now iber champion cavalry's fire damage has very little effect. I like the proposals in this patch, either borg or Freagarach values
That said are Freagarach's values really equivalent? For example if an iber champion cavalry constantly attacks a building, is the 'Duration' constantly extended or something different happens?

I agree with this line of thought (there's also the fact that if a bunch of sword champions are garrisoned in a fortress for exemple, and that a ram attack if, then they can unload, melt it in 1-2 seconds and go back in)
That said their cost was a bit reduced. Just in case I'll try to talk to Valihrant today about this patch.

I like this patch because it goes well with the defense upgrades rework that is already in, and it will not (or at least, less) lock players into an army composition they invested in (like they can switch from cav to infantry and vice versa if they have to)
That said the first technology might be a bit expensive but I think it's an improvement.

Good for me.
The reason I want to see this in a24 is that it will act as a buff to corraling, encouraging players to consider this option.

My proposition.
I think I remember Valihrant agreeing with that too when we played a game.

Oh and yes, I think it would be a good call to raise cattle time like you said

Indeed they are, I rather like it, but since this patch goes a little bit against my policy which is to be careful of patches that could change balance in a not 100% known way just before balancing freeze, I would invite other players to state if they feel it's dangerous

Could you elaborate? I'm confused now, 25% of what? And 20 to 40 s looks better than 30 to 60 s, doesn't it?

When writing this post I didn't see that you already modified the patch, but I meant a 25% reduction from animals original training time.
Now the new values are a buff of corrals, which I'm good with. However I don't know the stance of other players about it.

I initiated the idea of reducing range because my feeling was that archers were possibly too strong, and that it would also make the game a bit nicer (and also fixed buildings range).
My fears for this patch is that it will have unknown effects for balance, it could change quite a bit the balance between ranged units, and we don't have the time or the means to do proper tests for a24

It could work, although i'd prefer 25%, but I think an additionnal problem with this approach is that train time values are supposed to look good in the beginning if you see what I mean

If the question is between having a cost or not for this tech, I'm fine with anything I guess. I'd also have been fine with keeping training in fortress.

This patch nerfs corralling to the ground (and it was already difficult and arguably subpar against farming). There needs to be some compensation, like reducing base animal training stats by quite a bit (like the values after researching the technology that is getting removed)

I'll copy my arguments from the balancing PM here:
"2 things changed that lead toward the same effects: the effect of economy technologies have been increased a lot for the early phases of the game (from +15% to +25% for anything that is not food, +15% to +20% for food I believe). Secondly, the train time of citizen soldiers and women also increased.

Adjusted player placement so that they spawn further apart (on low player numbers) which reduces the imbalance in player positions.
I didn't yet replace the unreachable trees on mountains by their actor variation, because some of them are placed with a TerrainPainter which requires a template.

Adjusted values in previously deprecated functions

Well probably not actually otherwise the deprecated functions placeholder wouldn't be needed. Plus I just reread the ticket so indeed there is no equivalence. I'll adjust the values if necessary

If I recall from my whacky memories, createObjectGroupsDeprecated is equivalent to a createObjectGroups call with a retryFactor of 0, is that correct?

Bug fix required for D2830 to work.

Hi, after I realized that the look of this version of the map might not be as bad as I thought back then, I decided to rebase it to open it once again for feedback.
When evaluating the look of the map I recommend to sometimes generate it with the fog of war, as seeing it from a players perspective can be different from having all revealed.

In a21 where champions were more used, spartan and macedonian champions were quite popular with the previous values of the technologies, which encourages me to think the techs shouldn't be buffed too much.

I also wondered why they were the same when I started the game. The values look good to me. Still ping @borg-

Understandably so. If the train time is removed then the tech should at least cost equal amount of resources than the macedonian silver shields (like now)

I'm fine with it too but the fact that macedonian champions are almost equal to spartan ones, but train 10% faster bothers me a bit but arguably this is compensated by tech cost.

Discard the preceding post, it was not up to date. The changes look good to me

I completely missed that he changed the stats (had probably another version in mind), then it is fine. Now spartan champion might be a little bit too strong but this is probably fine.

In D2846#122473, @Stan wrote:

@Feldfeld care to accept again if it's good?

The changes are good for war horses
For silvershields, the tech will still remain better than the spartan agoge. (macedonian spear champion remain a little bit stronger and train faster than the spartan equivalent after the techs). This is not necessarily a problem by itself but I just want that this is recognized before accepting the patch.

Feel free to suggest different values.

I would suggest not to change champion elephant stat so as to keep current balance for them (which has been achieved by the patch I linked)

I don't understand (in particular the values @borg- suggested), this nullifies half of the work done in D2575(@ValihrAnt). Having hack attack is justified by elephants being good against humans, the walk speed could be justified by armor values (but I can understand why we would want it to be the same as other elephants, that works too).

In D2854#122354, @Nescio wrote:

Does it affect the regeneration rate of all buildings ?

No, not all structures, only centres, colonies, and crannogs are affected by these technologies:
"affects": ["CivilCentre"],

Does it affect the regeneration rate of all buildings ?