-
Civilization 7 has been announced. For more info please check the forum here .
Ozzy's Forest Chop Grid
- Thread starter OzzyKP
- Start date
.pixiejmcc
Prince
eek
i think it's all change now with the new patch. a new grid may be required
i think it's all change now with the new patch. a new grid may be required
pixiejmcc
Prince
BTW. I htink I just worked something out that has been confusing me for a while. I wondered how I was getting 40 hammers on a quick start, and now i know it was cos (e.g.) i was building a wonder with an industrious civ. So theoretically (though i never noticed) it is possible to get 60 hammers when u have appropriate resource hooked up.
DaviddesJ
Deity
The new standard grid should be 30,30,25,20,15,10,5. Compared to v1.52 which was 30,30,30,25,20,15,10,5. Scale by appropriate percentages for quick, epic, marathon. (And by 2/3 before Mathematics, and by 2/3 if outside cultural borders.)
It looks like there's some funny rounding going on. One would expect a forest 3 tiles away, within the cultural borders, on epic speed, pre-Mathematics to be worth 25 hammers. (25*2/3*1.5) However it looks like, in game, they're rounding the result of 25*2/3 down to 16 and then when they multiply by 1.5 the result is only 24. Bug, or by design?
DaviddesJ
Deity
malekithe said:
Or maybe it's 25*1.5 = 37.5, rounded down to 37, and then 2/3 of 37 is 24.7, rounded down to 24. It's not surprising that they are using integer arithmetic with fractions rounded down, as this happens many other places in the game too. I've heard that Firaxis avoids floating-point arithmetic because different systems might round differently, resulting in out-of-sync errors in multiplayer games. Of course, there are other ways to deal with rounding, but, it's not a big deal (in this case anyway).
I'm sure they didn't "design" it to be either 24 or 25. It just came out that way.
True, it's a product of how they do fractional math. Taking a look at the SDK, at each step of the formula they do something like:
Technically, I was correct with the order of operations. The order of operations followed in the code is (rounding at each step):
Get Base Forest production
Add extra production for current city project
Reduce Production by 5 for each tile past the second away from a city
Modify by Player's Production modifier (67% before mathematics)
Modify by Game Speed modifier
I was aware the game rounded all of it's arithmetic to the lowest integer, but I wasn't aware they did it for every interrim operation. It seems a tad unnecessary in this particular case, as there's little reason they couldn't just divide by some multiple of 100 at the end of the block of code. That would produce a more "accurate" result.
Code:
iProduction *= getFeatureProductionModifier()+100
iProduction /= 100Technically, I was correct with the order of operations. The order of operations followed in the code is (rounding at each step):
Get Base Forest production
Add extra production for current city project
Reduce Production by 5 for each tile past the second away from a city
Modify by Player's Production modifier (67% before mathematics)
Modify by Game Speed modifier
I was aware the game rounded all of it's arithmetic to the lowest integer, but I wasn't aware they did it for every interrim operation. It seems a tad unnecessary in this particular case, as there's little reason they couldn't just divide by some multiple of 100 at the end of the block of code. That would produce a more "accurate" result.
DaviddesJ
Deity
malekithe said:
I think it's a little more complicated than that---if you "save up" too many multiples of 100 to divide by, you can get overflow, which would be worse than rounding errors. But I agree that you could do the calculation "exactly", without floating-point arithmetic. If it were me, I would probably do that. But it does add some complexity and thus some chance of new bugs.
Actually, I did a little more investigation, and I had the order of operations wrong. The full formula is as follows (again, flooring after each step).
Get base forest production (30).
Subtract 5 for every tile away from the nearest city > 2 (4 tiles away would = 20)
Multiply by the city's production modifier (1.25 if it has a forge)
Multiply by the player's forest production modifier (1.5 after mathematics)
Multiply by game speed modifier (1.5 for epic)
--- now the tricky ones that I didn't get before ---
Multiply by the BASE_FEATURE_PRODCUTION_PERCENT (0.67) - this is what they added to give forests a perceived base value of 20 hammers
If you're chopping a forest outside your borders, multiply by the DIFFERENT_TEAM_FEATURE_PRODUCTION_PERCENT (0.67)
What all of that results in is quite a lot of potential for rounding "errors". For instance, the most glaring example to me was, in an epic game (with mathematics), after chopping a forest right next to a city, I received only 44 hammers intead of the 45 I used to get. So, I ran through the math and came up with this:
30*1.5 = 45 (mathematics)
45*1.5 = 67.5 (epic)
67*.67 = 44.89 = 44 hammers. (BASE)
Say you had a city bonus of 100% (stone for the pyramids), now you'd get the full expected 90 hammers.
30*2.0 = 60 (stone)
60*1.5 = 90 (mathematics)
90*1.5 = 135 (epic)
135*.67 = 90.45 = 90 hammers. (BASE)
That 100% bonus really turned out to be a 105% bonus.
Interestingly, there's also a variable in the formula that's not currently being used that can mitigate the reduced hammer value based upon city population. For instance, cities with 5 population could potentially receive full chop value before mathematics.
Get base forest production (30).
Subtract 5 for every tile away from the nearest city > 2 (4 tiles away would = 20)
Multiply by the city's production modifier (1.25 if it has a forge)
Multiply by the player's forest production modifier (1.5 after mathematics)
Multiply by game speed modifier (1.5 for epic)
--- now the tricky ones that I didn't get before ---
Multiply by the BASE_FEATURE_PRODCUTION_PERCENT (0.67) - this is what they added to give forests a perceived base value of 20 hammers
If you're chopping a forest outside your borders, multiply by the DIFFERENT_TEAM_FEATURE_PRODUCTION_PERCENT (0.67)
What all of that results in is quite a lot of potential for rounding "errors". For instance, the most glaring example to me was, in an epic game (with mathematics), after chopping a forest right next to a city, I received only 44 hammers intead of the 45 I used to get. So, I ran through the math and came up with this:
30*1.5 = 45 (mathematics)
45*1.5 = 67.5 (epic)
67*.67 = 44.89 = 44 hammers. (BASE)
Say you had a city bonus of 100% (stone for the pyramids), now you'd get the full expected 90 hammers.
30*2.0 = 60 (stone)
60*1.5 = 90 (mathematics)
90*1.5 = 135 (epic)
135*.67 = 90.45 = 90 hammers. (BASE)
That 100% bonus really turned out to be a 105% bonus.
Interestingly, there's also a variable in the formula that's not currently being used that can mitigate the reduced hammer value based upon city population. For instance, cities with 5 population could potentially receive full chop value before mathematics.
@malekithe: Good job. I really wonder, after reading all this, if it would be better to modify accordingly the values for base chop (from 30 to 20) and BASE_FEATURE_PRODUCTION_PERCENT (from 0.67 to 1). Don't you think that the result would be the same, but with one rounding less?
I am pretty sure that this 1 lost hammer (45 to 44) wasn't intented, but rather a bug. For example, in normal speed there is no lost hammer in this case.
I am pretty sure that this 1 lost hammer (45 to 44) wasn't intented, but rather a bug. For example, in normal speed there is no lost hammer in this case.
Atreas, the problem with changing the base value of a chop from 30 to 20 is that it breaks the first operation of subtracting 5 per tile distance > 2. To tell the truth, I can't come up with a good fix for this that doesn't involve an SDK-based mod. The best I could do without touching the code would be to modify the game speed modifiers and restore the BASE modifier to 1.00. I'd propose something like Quick = .45 Normal = .67 Epic = 1.00 Marathon = 2.00. That would produce nearly identical results on Normal, Quick and Marathon, but Epic would be fairly close to "exact".
A better fix, to me, would be to go in and change the order of operations to be a bit more logical. I would combine the Math Bonus with the base bonus such that they "cancel out" most of the time. I would make it the first modifier I applied. I'd then apply the game speed modifier combined with the outside-cultural-radius modifier (which cancel out on epic). Lastly, I'd apply the city's production bonus.
A better fix, to me, would be to go in and change the order of operations to be a bit more logical. I would combine the Math Bonus with the base bonus such that they "cancel out" most of the time. I would make it the first modifier I applied. I'd then apply the game speed modifier combined with the outside-cultural-radius modifier (which cancel out on epic). Lastly, I'd apply the city's production bonus.
@malekithe: Right. You can't fix it unless you delve into the code. For my part, I will probably play a few games with the given settings and then make the change I stated and also change the distance factor from 5 to 4. That creates almost identical values with the intented, unless you chop too far from the city (which I almost never do, especially after the new patch).
I just hate it when I see (for one more time) that they didn't manage to find a formula that balances for all game speeds. After all, epic isn't the most unpopular game speed (I could say exactly the opposite is true).
I just hate it when I see (for one more time) that they didn't manage to find a formula that balances for all game speeds. After all, epic isn't the most unpopular game speed (I could say exactly the opposite is true).
DaviddesJ
Deity
atreas said:
This seems like complete nonsense. You surely can't believe that one hammer more or less has any significant effect on game balance.
You are certainly more clever than me, of course, so you can find things "complete nonsense" or not. I have similar habbits, I admit, but generally I try to be more polite.DaviddesJ said:
Can you find a good reason why even 1 hammer should be taken or given according to game speed? Can you find me a good reason why fast workers are better in normal speed than in Marathon? If it isn't intented, then it's bad balancing. PERIOD.
DaviddesJ
Deity
atreas said:
It keeps the code simpler and requires fewer changes, thus reducing the probability that the patch might be released with a really serious bug that would affect many people, as opposed to a trivial "bug" that hardly matters.
But, if it were me, I would have written the code differently. That's not the point. The question is not whether you or I would do it one way or another---when we design and publish our own games, we can do them however we like. The question here is whether it matters, one way or another, to the players.
There are lots of things in the game that aren't "intended" but still have no effect on balance. They are just immaterial.
@DaviddesJ: I don't disagree with you about the importance, but about the expression you used. I would even like more DaveMCW note about having a chopping penalty in faster speeds - but I just don't like to make a +/-1 rounding when it could be avoided.
As you might note, I am not talking about the code but about the values of parameters - as a programmer, I know very well what it means to change a formula and what it means to change a bit the parameters. So, let's just say that the "complete nonsense" phrase didn't ever existed
.
As you might note, I am not talking about the code but about the values of parameters - as a programmer, I know very well what it means to change a formula and what it means to change a bit the parameters. So, let's just say that the "complete nonsense" phrase didn't ever existed
.
DaviddesJ
Deity
atreas said:So, let's just say that the "complete nonsense" phrase didn't ever existed
The rounding is not a balance problem. If we can start with your claim of a balance problem and make that posting retroactively not exist, then everything that followed it will disappear, too.
Similar threads
