Help with Yield Discount Rate (Math)

[Stalker0]

More like yield (Turn T) = yield (Turn 1) / (1.02^T)
So turn 50 you divided by 2.7 approximately.

The curve looks reasonable until about Turn 324. At that point the discount stops being high enough, and the raw yields aren't even high enough (not even counting any snowball bonus).

To clarify, if I assume a 375 turn game. On Turn 324, the discount yields 1 science = 611.5833 SPT, multiplied by the remaining turns (51) = 31190.75. On Turn 325 its the same total. On 326, its 636 SPT, which would give you a total of
31178.27.

So this means under no circumstances would I take the 636 SPT deal on Turn 326, it is unequivocally worse than the deal of Turn 324.....again not even account for the fact that science earlier has other snowball effects. So the discount needs to be stronger here.

We may need a second function for the last 50 turns of so, the payoff requirements climb so quickly at this point that you really get a steep curve. I took the last 50 turns, and made the assumption of no snowball bonuses. Aka, what did the SPT numbers need to be just to maintain the 31190.75 number with ever shortening time to gather the science. I then calculated what the discount rate would need to be to get at that number. The curve is shown at the bottom (I ignored the data for Turn 374 as its to the moon at that point). So the discount goes from .02 to about .02 to .026 over those 50 turns. This would be the absolute minimum discount at those later turns to have viability.

 

[Stalker0]

@CrazyG, here's the by civ data you wanted. You just need to sum the SPT with the instant science in each row, I did Greece for you as the example. The first tab is the raw data.

 

[CrazyG]

@CrazyG, here's the by civ data you wanted. You just need to sum the SPT with the instant science in each row, I did Greece for you as the example. The first tab is the raw data.

Beautiful!

Okay I started with some analysis. Here's a plot of each civ's culture. It's messy.

Spoiler Graph :

Here is a plot of it's log. It becomes a lot easier to see, it's pretty close to a logarithmic relationships, except at the very beginning and very end.

Spoiler Graph :

Here I calculated a 5 turn rolling average and used it's log. Now it looks pretty good.

Spoiler Graph :

And here's the log of rolling average for science:

Spoiler Graph :

If you ignore the first and last 50 or so, the data follows a logarithmic model fairly closely. So if your goal is to compare yields over time, some sort of a logarithmic model should do the trick, rather than a polynomial function like you were trying before.

Even just a linear model on the log transformation of the yields works pretty well.

 

[Bryan317]

You guys are gods among men. Thank you for doing all this mental labor so I can pretend I'm a ruthless dictator.

 

[Stalker0]

Even just a linear model on the log transformation of the yields works pretty well.

Send me the updated excel so I can take a look!

So we have all put out some various graphs and charts, but I want to come back to our fundamental methodology. What is the best way to approach this? So far we tried the following:

• IRR: Calculate an IRR for several buildings, and use that as discount rate. I'll admit I still don't really understand how this works.
• Normalize based on Yield Production: We graph to the yield data, and the discount rate is the rate of yield increase. If yields increase 5% over 5 turns, then the discount is 5% over 5 turns, etc. This is the main method CrazyG and I have been graphing in various ways.
• Accumulation by Turn (no snowball factor): At bare minimum, 1 YPT * discount(based on turn X) * X must be >= 1 YPT * discount (based on turn X+1) * X+1, where X is the number of remaining turns in the game. Put in english, if I choose to get A yield per turn now, versus B yield per turn in 10 turns, at absolute minimum should give me the same cumulative amount of yield or more at the end of the game, otherwise objectively A is better than B in all cases and there is no comparison. This is not a great basis for a discount formula, as it includes no snowball factor, but its serves as a lower bound and a sanity check. Any discount formula that fails this basic test requires adjustment.

So is there anything else we can try? I was thinking one other idea:

• Accumulation + Checkpoint Concept: So we now that for example science kicks up at various points in the game. The acquisition of councils, then libraries, etc etc. We could try to determine at what accumulated science those checkpoints occur, and then that would be when the discount is highest. This would lead to a flatter curve with some steep drops, representing the various checkpoints.

 

[Gazebo]

So as a quick and easy lower bound, it we consider science "useful" for 375, than


Yes I have that data it will just take a little time to format it

I’ve added instant yield logging for the next version.

 

[Stalker0]

I’ve added instant yield logging for the next version.

Is it possible to log it per city? If so that will be the absolute holy grail, I have several stats I'd love to run if we had that info!

 

[CrazyG]

Yes if was per city the level of analysis would be sublime.

I’ve added instant yield logging for the next version.

IF only I could like a post more than once.

Send me the updated excel so I can take a look!

I actually used R, not excel, but I can export the data to a spreadsheet to share it.

 

[Gazebo]

Is it possible to log it per city? If so that will be the absolute holy grail, I have several stats I'd love to run if we had that info!

Well instant yields are not 'handled' per city, they're all fed through a super-function that's player-level. I can pass the affected city through to the logging so you can use excel functions to filter by city, if that works?

G

 

[CrazyG]

Here's the excel with rolling averages included:

 

[CrazyG]

Well instant yields are not 'handled' per city, they're all fed through a super-function that's player-level. I can pass the affected city through to the logging so you can use excel functions to filter by city, if that works?

G

Passing the city name to logging should be more than enough.

 

[Gazebo]

027, America, Washington, Instant Yield Type: Won Battle, Yield Type: Culture, Value: 8

 

[CrazyG]

027, America, Washington, Instant Yield Type: Won Battle, Yield Type: Culture, Value: 8

That's perfect!

 

[Stalker0]

Well instant yields are not 'handled' per city, they're all fed through a super-function that's player-level. I can pass the affected city through to the logging so you can use excel functions to filter by city, if that works?

G

Yeah as long as the log has some indicator of what city a perticular set of instant yields are connecting to, I can parse the rest!

 

[Stalker0]

027, America, Washington, Instant Yield Type: Won Battle, Yield Type: Culture, Value: 8

G, just noting that when InkAxis worked on this for a mod, there was an issue where the log was recording values before the turn was "complete". For example, if I did some unit buying and got some bank yields, they weren't recorded. Your method may be superior and not have that problem, but just something to watch for.

 

[Stalker0]

Here's the excel with rolling averages included:

Thanks!

So looking at the data you posted myself, yeah what you see is almost 3 phases of the data. For about the first 100 turns, its a very smooth curve, than until about 320 its a different curve but still workable, and at 320+ it become very spiky due to the prevalence of instant yields at that point (perhaps also going in and out of processes).

 

[InkAxis]

G, just noting that when InkAxis worked on this for a mod, there was an issue where the log was recording values before the turn was "complete". For example, if I did some unit buying and got some bank yields, they weren't recorded. Your method may be superior and not have that problem, but just something to watch for.

Well it probably just triggers whenever an instant yield activates, so it won't have that issue.
I fixed it in my code with a kinda jank workaround, it seems Gamevent.PlayerDoneTurn doesn't work?
@Gazebo just wondering how you would enable it, is the code on the github yet?

 

[Stalker0]

So I tried apply the log transformation that CrazyG talked about, and got a variety of curves which I'll show below. Ultimately two order polynomials fit best in all cases, most of the curves tend to overestimate in the very beginning and then taper off, so it still seems worthwhile to consider different equations at different turn points to get more accurate data.....especially when deal with logs where every error is 10x multiplied.

I also did some compilations of the main civs together, both median and average. I removed Austria from the data because she didn't finish the game and was eliminated, and I don't think that's a good baseline for data, we want to look at numbers for civs that make it. I also removed Siam and Sweden as their science numbers tanked at the end, which suggests while they survived they effectively fell out of competition. That leaves the remaining civs who at least were reasonably competitive throughout the game.

Spoiler :

 

[InkAxis]

So I tried apply the log transformation that CrazyG talked about, and got a variety of curves which I'll show below. Ultimately two order polynomials fit best in all cases, most of the curves tend to overestimate in the very beginning and then taper off, so it still seems worthwhile to consider different equations at different turn points to get more accurate data.....especially when deal with logs where every error is 10x multiplied.

I also did some compilations of the main civs together, both median and average. I removed Austria from the data because she didn't finish the game and was eliminated, and I don't think that's a good baseline for data, we want to look at numbers for civs that make it. I also removed Siam and Sweden as their science numbers tanked at the end, which suggests while they survived they effectively fell out of competition. That leaves the remaining civs who at least were reasonably competitive throughout the game.

Well that last graph seems pretty accurate, except maybe at the very beginning. What would the equation in that case be if I want to convert a yield?

 

[Stalker0]

Well that last graph seems pretty accurate, except maybe at the very beginning. What would the equation in that case be if I want to convert a yield?

So if your wanting to say: 1 science (Turn 1) = X Science (Turn Y).

It would be: Power(10, -1*POWER(10,-5)*A2*A2+0.0118*A2+0.5552) / 6.3

Now note, in the early turns the formula undercuts this and has values lower than 6.3 since we know 6.3 is the minimum science a civ makes, its best to just say "this value or 6.3, whichever is higher).

Trying that formula out, I get.

1 Science (Turn 1) = 2.1 (Turn 50) = 6.9 (Turn 100) = 20 (Turn 150) = 52 (Turn 200) = 120 (Turn 250) = 249 (Turn 300) = 458 (Turn 350)


Another note, this formula fails the smell test around Turn 323. At that point, the discount is still not high enough. Effectively what this is saying is that civ yields at this point do not grow fast enough to compensate for the ever shrinking rate of return before the end game....which throws the discount off. In other words.....the 458 science on Turn 350 is 100% objectively worse than any of the numbers previous, there is no subjective feel required.... if someone offered you 249 onTurn 300 or 458 science on Turn 350 you should always take the first deal.

A "perfect discount" should mean that all of the numbers I present you are tempting, so we still need a compensator towards the end turns to really reflect a proper discount. At Turn 350, at absolute minimum (no snowball factor at all), it should be 501 science.