Circular and square maps should have the same area

[elexis]

The mapsize gamesetup setting (that only works with random maps) should yield the same map area independent from the map shape (square or circular).

A square map will have the size x² while a circular map will become pi * (x/2)².

Thus the area of a square map is4/pi times larger (+27%) than a circular map. (This may account for some "new a21 lag").

The change should likely be done in the rmlib, not every random map script.

As long as square maps are supported, this factor should be taken into account. If we entirely drop support for square random maps, the setting isCircular should be removed and implied to be true.

[Vladislav Belov]

What's the reason of the ticket? Not the side means by size?

[elexis]

People are used to playing the "normal" mapsize on circular maps with 8*150 pop, as that seem to be the greatest numbers before adding 'performance lag'. Smaller maps and population are less fun, greater mapsizes and population are too 'laggy'.

When playing a "normal" sized square map, it will end up with 27% more map area than a circular map of the same "mapsize", thus adding more trees, causing simulation and graphical lag while the player expects that circular and square maps end up with the same map area and lag.

The map area shouldn't depend on the map shape, which may not be known in advance (random random map), nor should we require the players to know about the 4/pi difference.

[Vladislav Belov]

Replying to elexis:

When playing a "normal" sized square map, it will end up with 27% more map area than a circular map of the same "mapsize", thus adding more trees, causing simulation and graphical lag while the player expects that circular and square maps end up with the same map area and lag.

I think it should be in the ticket description.

[elexis]

It was relevant when we had many popular square maps in alpha 21 and 22, but they're round now. (The remaining square ones have water, so chosing "Normal" happens to yield a comparable result as on "Normal" circular maps without water.)

[FeXoR]

IMO this is a non-issue and should be closed.

[elexis]

IMO this is a non-issue and should be closed.

I don't want to try to refer to what I guess what you might think making you come to this statement. The statement is not an argument that relates to the argument I had given in comment:2 or below:

When playing a "normal" sized square map, it will end up with 27% more map area than a circular map of the same "mapsize", thus adding more trees, causing simulation and graphical lag while the player expects that circular and square maps end up with the same map area and lag.

The map area shouldn't depend on the map shape, which may not be known in advance (random random map), nor should we require the players to know about the 4/pi difference.

I can elaborate it a bit further.

First some more facts.

We compute how much area difference there is between the N'th and N+1st mapsize on a square map using map_sizes.json and 1 - areaSmaller / areaLarger = 1 - (mapsizeSmaller / mapsizeLarger)^2

1 - (128/192)² = 56%
1 - (192/256)² = 44%
1 - (256/320)² = 36%
1 - (320/384)² = 31%
1 - (384/448)² = 26%
1 - (448/512)² = 23%

To fit more than 2 players, the host needs to set a map of 256 tiles (medium), preferably 320 (normal) or 384 tiles (large).

So we see that the host can reduce the map area in this range (256-512) by about the same area difference of the square and circular map when chosing the same mapsize (27%).

1. The performance argument: Players and developers that start matches or run replays where between 50-300 pop and 4-8 players, possibly petra bots are enabled can witness an extreme performance difference depending on the total count of entities on the map (including all units of all players and all gaia entities such as trees).

Itms new pathfinder in alpha 19 for example allowed one to run the simulation on a Normal mapsize (320 tiles) with 8 players * 150 population, whereas alpha 18 only allowed 100 population * 8 players for the same mapsize. So we at least observe that even a small number of moving entity count can make a critical performance difference to any user (developer and end-user).

Chosing a too large mapsize or too much entities drains the game performance on even the best CPUs and GPUs to the point where the ability to interact with the userinterface is not given anymore:

Broad performance estimates for a circular map:

128 tiles, 300 pop = Very Good
320 tiles, 150 pop = Acceptable, 30 FPS on my GPU
320 tiles, 200 pop = Inacceptable, 1500ms+ turns on every system, 4 FPS on my GPU
512 tiles, 50 pop  = Inacceptable

The simulation and renderer code may have unoptimized algorithms, but that doesn't mean that developers may pick the freedom to not consider performance differences of the maps they generate.

2. The gameplay argument: Each mapsize produces an entirely different gameplay.

128 tiles
* area so small that CCs are almost in attack range

256 tiles 1v1
* space for maybe 1 civic center for every player

256 tiles 4v4
* one of the 8 players can build a CC
* distances between players so small that everyone can defend/attack everyone else very quickly
* allied territories almost always connected (territory loss not relevant in comparison to military situation)
* map vision of allies is total, unforseen surprise attacks are impossible

320 tiles 4v4
* enough space for most players to build a CC
* allied territories are disconnected unless expanding manually
* there is fog-of-war between allies, enabling surprise attacks
* distances between players are sufficiently large that a player having to go from A to B needs so much time that it can decide between victory and defeat in some cases

384+ tiles 4v4
* distances between allies are so much larger that players can't change the directions easily
* map area is so large that defense structures become almost irrelevant in comparison to mobile forces

We observe that regardless of the most recent simulation implementation and templates, it makes an extreme difference which mapsize the host choses and how the program code translates this setting into a map.

If the host choses a 320 tiles 4v4, he expects the scenario described above in the "320 tiles" point, regardless whether he choses a square or circular map.

If the map provides the player a different game experience than what the host has intended to start, that is the opposite of satisfying the users and can lead to the ending of the match and chosing different settings again, making the player lose all the time to setup the game and play it up to the point where they realize it's not what they wanted.

It's virtually impossible to figure out that square maps are affected by this mis-expectation if one hadn't read the code. Wildfire Games should enable the to shape settings in a deterministic way, enabling the player to get the experience that he wanted.

3. The setting consistency argument: If we offer players a gamesetting, the meaning of the setting should preferably not depend on the other settings.

"Normal" means "Normal" on circular maps, but "Large" means "Normal" on a square map, for every intent and purpose except sandbox development.

---

Conclusively, we see good reasons for making the "mapsize" setting relate to the map area instead of something arbitrary determined by the selected map shape.

The engine supports all tile sizes that are a multiple of 16 unless I'm mistaken. Regardless of the restrictions it sounds like a very cheap price for the developers to pay to find a number more closely resembling what the user expects. Only an implementation attempt can find more accurate information of the results that a possible implementation can achieve, unless you have more information.