inconsistent production values of mines

[3plus4i]

The barbarian's mines have inconsistent values for production specified in the lua-files. I'll assume one unit of the respective required food consumed in the following.

In mines you get 2 coal but only one iron or gold ore. This would make sense if the difference would be kept with enhanced mines. But in deep mines you get 4 coal or for 4 gold ore but two iron ore. And in deeper mines you get 5 coal, 4 gold or 5 iron ore.

In addition, the production times ans sequence of deeper mines vary pretty widely:
Coal mines produce 5 ores in 72 seconds and two steps
Iron mines produce 5 ores in 88 seconds and three steps
Gold mines produce 4 ores in 74 seconds and two steps

I don't even have an idea how it is intended to be ...

[3plus4i (tobi-heinz)]

Okay, since it was apparently unclear what I was aiming for, I'll try to explain again.

I'll make three assumptions about how mines work that seem naturally logical:
1. Different minerals take different times to mine (not necessarily but it's easily comprehensible). Gold takes longer than iron which takes longer than coal. Stone/marble/crystals can be somewhere in between.
2. Enhanced mines work faster but require more resources per output unit than the previous stage.
3. The differences of basic mines persist with enhanced versions (pretty basic logic).

Atlanteans and Empire follow these rules almost perfectly. Atlanteans for example can mine coal every 15 seconds, iron every 21 seconds and gold every 35 seconds. That looks really convincing.

Barbarians on the other hand ...
With simple mines they get iron as fast as gold. One could argue that all of them should need the same time for a cycle and since iron gives only one unit per cycle gold can't get any lower. But then again, the mines on other levels don't have equal times either and I don't see a reason why they would absolutely need to.

But it's getting even worse with deep mines. Here they gain gold twice as fast as iron and on equal speed with coal! Btw, it's the same with the food requirement.

With deeper mines the order of the speeds is fine but the differences are pretty small: 14.4 seconds for coal, 17.6 for iron and 18.5 for gold.

On average this means, that Barbarians can mine gold much faster than any other tribe and faster than they mine iron. While I understand that one tribe might be better (and thus faster) miners than another it doesn't seem convincing why they should be able to mine one specific ore faster or slower, let alone why one upgrade would be faster or slower over the other mines of the same stage compared to the mines of another stage.

I didn't include stone here because I don't think that the same rules apply. Empire and Atlanteans are looking for specific, more rare resources here where stone is rather a byproduct so it's understandable why they could be relatively slower because they need to search more carefully, or faster, because they are more desperate/have a higher priority.

[SirVer (sirver)]

I do agree that the change in relatives is weird, but it also seems inconsequential. I do not mind it to be changed, I think it will not have a perceivable impact on gameplay.

[GunChleoc (gunchleoc)]

Do you have any ideas about which values we should have instead? If you propose a list, it will be easy to implement.

[3plus4i (tobi-heinz)]

I can map out a proposition, I hope. But first I have to nudge king_of_nowhere for that, to make sure that I don't mess up the balancing.

[3plus4i (tobi-heinz)]

The easiest solution would be to just change the amount of ores per cycle for babarians deep and deeper iron resp. gold mines:

deep iron mine: 3
deep gold mine: 2
deeper iron mine: 4
deeper gold mine: 3

Not perfect but at least they stick much closer to a system. There are some more questions I'd like to discuss before actually changing anything. I think I'll put these in the forum thread instead of here. If we still end up on staying with just these little changes I can still make a branch. I'll have to learn to handle Bazaar anyway.

[hessenfarmer (stephan-lutz)]

Just linked this to a new branch which fixes this bug at least partly