Rounding error

Thalassicus

Bytes and Nibblers
Joined
Nov 9, 2005
Messages
11,057
Location
Texas
There's an error in the purchase cost formula for units and buildings. It's most visible on faster and slower game speeds.
310:c5gold: cost for worker on standard
300% cost modifier on marathon
930:c5gold: target worker cost on marathon
700:c5gold: actual worker cost on marathon
The cost is 25% lower than the target value. If the error was in the ~5% range it wouldn't be a big deal, but this far off the target significantly alters game balance. It changes the value between gold and production. It also affects balance between spending gold on units/buildings and other costs which do scale appropriately.
 
Commerce SP: Mercantilism
Purchasing items in Cities requires 25% less Gold.

That's possibility 1 (my first thought).


Possibility 2 would be that more expensive items are cheaper than less expensive ones, which is clearly the case for e.g.
A warrior on standard costs 40 hammer and 200 gold while
A longswordman on standard costs 120 hammers (x3) but only 460 gold (x2.3).
A warrior on marathon costs 120 hammer and therefore also 460 gold. (again x3 vs x2.3) - that's a ratio of 3.833.

A nuclear missile on standard is 1000 hammers or 2270 gold; so for a high price example this is a ratio of 2.27.
310/70 for a worker on standard is a ratio of 4.429.

Concise:
310/70 -----> 4.43
460/120 ----> 3.83
2270/1000 --> 2.27

The less hammers, the worse the ratio becomes. Game speed doesn't matter here.
Some units have an anomally though. That would in particular be the Settler (understandably, as he's kind of a special unit) and one I remember is the Caravel (whichs rush buy costs are higher than it should be).
 
Thinking about this some more, I realized the underlying bug is the purchase cost modifier depends on speed modified cost, instead of base cost. That's what's upsetting the balance. I think a temporary solution is to disable this by setting it to 1:

HURRY_GOLD_PRODUCTION_EXPONENT

Then replace it with a sql formula to set HurryCostModifier for each unit and building to the same final purchase cost modifier as it used to be. I think this approach would use the correct non-speed-dependent cost. :think:
 
Top Bottom