Increase Max Gatherers for 'Small' Ruins #8945

[Baelish]

For the context, please read https://gitea.wildfiregames.com/0ad/0ad/issues/8599.

I want to explain why I choose 5 gatherers for small ruins.

Many entities inherit from template_gaia_ruins.xml, with different amount of stone and metal. I will do a summary of them:

STONE

stone_statues_kushite_bird, stone_statues_kushite_lion, stone_statues_kushite_ram 200

standing_stone, stone_statues_egyptian, stone_statues_kushite, stone_statues_roman, stone_structure_small 300
stone_column_roman 400
column_doric, roman_rostrum, stone_statues_persian_lamassu, stone_structure_farmstead, stone_structure_house, stone_structure_tower 500

METAL

metal_statue_discobolus, metal_statue_poseidon 400

metal_statue_apollo, metal_statue_isis, metal_statue_wolf 800

 

As reference a small cut of rock has 1000 of stone and 12 gatherers, so I thought that would be a good deal to set 5 gatherers for something that has around 400

Edited yesterday at 09:18 by Baelish

[Atrik]

Best would be to add a poll to the thread @Baelish

[Obelix]

Thank you for opening this thread and adding the poll afterwards, @Baelish!

I voted for a maximum of 2 gatherers because I think they're more special than a small cut of rock (1000 Stone) or a normal cut of rock (5000 Stone). More specialized sources of stone or metal like ruins should be harder to exploit and not have a proportional <MaxGatherers> value.

[Thalatta]

Why not use a function for how many gatherers to have for any possible stone number? If I’m not wrong, the present behaviour seems to be:

5000 stone: 24 gatherers.

1000 stone: 12 gatherers.

500 stone: 1 gatherer.

Which indeed seems too low for 500 stone. I managed to find something nice. As a very simplified model, since the amount of stone is proportional to its volume, and the number of gatherers G are proportional to (a fraction of, if sunk in the ground) its circumference, then naively one would have G=AS^(1/3), where A is some constant, but that’ll never work. Let's then include a "worthiness" factor 1-e^(-BS), meaning that the less stone there is, the less efficient would be to deal with its logistics proportionately (gatherers will soon need to be relocated anyway, for example, besides minimum upfront costs and infrastructure, etc), thus less gatherers than expected would be assigned to it (exponentially, going inversely, that is, the complement of exponential decay). The final formula is then G=AS^(1/3)(1-e^(-BS)), which for the initial conditions G(5000)=24 and G(1000)=12 returns A=1.4036 and B=0.001931. This means that G(500)=7, which might seem high but it’s because the initial conditions (24 and 12) are somewhat weird to begin with. One can check that for some extreme cases the function still behaves nicely: G(100)=1 and G(50000)=52. I’d propose to use a function like this but change one initial condition to G(1000)=10, as such one gets A=1.4064 and B=0.001242, resulting in G(500)=5.

In conclusion: a very simple (non-linear) formula predicts 7 gatherers for 500 stone, but if for 1000 stone the number is tweaked from 12 to 10, one manages a more poll-friendly 5 gatherers, and can use that formula for any stone value to get the corresponding number of gatherers.