Tech tree based calendar with round steps

[raxo2222]

Currently my calendar is tailored for tech tree, but it needs minor recalibrating now.
Assuming constant turns/tech era lasts proportionally long depending their tech content.
Prehistoric is exception, but then Ancient era research modifier can calm down its enthusiasm on chokepoint.
That is Prehistoric starts very slow and can end with up very fast tech rate.

200 000 BC - 12 000 BC - Prehistoric - 98 techs
12 000 BC - 1200 BC - Ancient - 93 techs
1200 BC - 450 AD - Classical - 60 techs
450 AD - 1400 AD - Medieval - 54 techs
1400 AD - 1750 AD - Renaissance - 59 techs
1750 AD - 1900 AD - Industrial - 67 techs
1900 AD - 1990 AD - Atomic - 102 techs
1990 AD - 2050 AD - Information - 79 techs
2050 AD - 2150 AD - Nanotech - 85 techs
2150 AD - 2300 AD -Transhuman - 76 techs
2300 AD - 3000 AD - Galactic - 65 techs
3000 AD - 4000 AD - Cosmic - 51 techs
4000 AD - 6000 AD - Transcendent - 52 techs

You can research this many techs max in each era.
As for minimum techs needed to advance to next era I need to recalculate stuff in excel.

I used only one step for entire era length in game speed infos, this means ugly increments.
Prehistoric has two steps - at around 50% of its length date is 50 000 BC - after it there are smaller increments.

Here is Normal GS calendar steps as example

<GameTurnInfos>
                <GameTurnInfo>
                    <iMonthIncrement>18367</iMonthIncrement>
                    <iTurnsPerIncrement>98</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>4653</iMonthIncrement>
                    <iTurnsPerIncrement>98</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>749</iMonthIncrement>
                    <iTurnsPerIncrement>173</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>156</iMonthIncrement>
                    <iTurnsPerIncrement>127</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>96</iMonthIncrement>
                    <iTurnsPerIncrement>119</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iDayIncrement>1031</iDayIncrement>
                    <iTurnsPerIncrement>123</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iDayIncrement>409</iDayIncrement>
                    <iTurnsPerIncrement>132</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iDayIncrement>154</iDayIncrement>
                    <iTurnsPerIncrement>211</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iDayIncrement>122</iDayIncrement>
                    <iTurnsPerIncrement>177</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iDayIncrement>184</iDayIncrement>
                    <iTurnsPerIncrement>195</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>10</iMonthIncrement>
                    <iTurnsPerIncrement>180</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>61</iMonthIncrement>
                    <iTurnsPerIncrement>138</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>116</iMonthIncrement>
                    <iTurnsPerIncrement>103</iTurnsPerIncrement>
                </GameTurnInfo>
                <GameTurnInfo>
                    <iMonthIncrement>191</iMonthIncrement>
                    <iTurnsPerIncrement>126</iTurnsPerIncrement>
                </GameTurnInfo>
            </GameTurnInfos>
        </GameSpeedInfo>

You can see how ugly it is.

Is there automated way to add lets say 5 game turn info entries per era to keep round increments?
Still there could be 1 turn odd increment to close any gap.

Round increment is when calendar goes neatly - for example any divisors of 100 years, or any divisors of 360 days.

There can be one sub division of era (so no actual divisions) or even 5 divisions - all of them roughly equally spaced.
Subdivisions should be monotonically smaller all way to 2050 AD, and then they can get monotonically larger after than date.
1 turn increment can be anything similar to nearby subdivisions to clear up any gaps.
So if subdivision is 10 years, and then 5.33 years remain to next calendar era, then last turn can have size of 5.33 years.

I posted it here and not in github/discord for better visibility and longevity for players.

Here is calculated era lengths

Total amount of techs.
Min amount of techs to pass era (averaged for multiple OR prereqs for nanotech and later lifestyle techs).
Cumulative amount of techs (assumed picking OR prereqs with equal probability).
Calculated era length on Blitz game speed (1000 turns).
Calculated turn of reaching next era, and game percentage.
Average game should fall within 10% of these percentages - this range covers some assumptions.

 

[JosEPh_II]

You can see how ugly it is.

I don't see ugly. I see numbers and an over usage of Day Increments.

 

[Thunderbrd]

I will watch this thread with interest. Not sure what to say yet.

 

[Yudishtira]

Forget all about constant turns per era. If a turn is 30 days or more, it must be an exact multiple of 30 days (a Sid Meier month). Thus it should not need to say what day of the month, just the month. Or for three or six-month turns, you can do seasons, if that's easier.

If a turn is 360 days or more (Meier year), it must be an exact multiple of 360. So no need to say a month, just a year.

 

[raxo2222]

I don't see ugly. I see numbers and an over usage of Day Increments.

By ugly I meant irregular - day increments are overused, because they gave me highest precision.

Forget all about constant turns per era. If a turn is 30 days or more, it must be an exact multiple of 30 days (a Sid Meier month). Thus it should not need to say what day of the month, just the month. Or for three or six-month turns, you can do seasons, if that's easier.

If a turn is 360 days or more (Meier year), it must be an exact multiple of 360. So no need to say a month, just a year.

Well this is why I need proper tool - excel or similar isn't suitable for that.
And this is why I used steps like that - there is only one increment per era (prehistoric has two different increments)

@billw2015 is there way to make such tool to make such calculations easier?
That is some better way to add multiple increments of different durations?

For example instead of single increment of 80 days it could be split in 90 and 60 days with such length, that average would give 80 days.
Also total length would be unchanged, or reduced by 1, so that one turn could be scarified to make sure, that there is no remainder years/months/days when starting new calendar era.
This tool could also generate whole <GameTurnInfo> entry, so you can copy that to XML file

 

[Yudishtira]

In my SVN 8722 (2015 version) game, in the "Medieval" calendar segment I was in (on Eternity which was 14300ish turns), there were 3 turns every 2 years. This was being done as for example Winter 500, Autumn 500, Spring 501, Winter 502 etc. Thus the turns were not of equal length (270, 270, 180 days). I assumed the game's calendar was handling this itself. Was that not the case?

 

[raxo2222]

What you see in calendar is result of gameturninfo entries.
For example it could be this:

<GameTurnInfo>
                   <iMonthIncrement>9</iMonthIncrement>
                    <iTurnsPerIncrement>200</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
                   <iMonthIncrement>6</iMonthIncrement>
                    <iTurnsPerIncrement>400</iTurnsPerIncrement>
</GameTurnInfo>

Earlier calendars had smooth flow, because GameTurnInfos weren't tied so hard to tech tree.
What you see in current game speed infos is result of trying to not stray too far from calculated amount of turns per era.

If I had tool to split and calculate GameTurnInfo that represent one era in multiple entries, then I could to that for all game speeds.
For example thing representing one era could look like this:

<GameTurnInfo>
                   <iMonthIncrement>9</iMonthIncrement>
                    <iTurnsPerIncrement>200</iTurnsPerIncrement>
                </GameTurnInfo>
<GameTurnInfo>
                   <iMonthIncrement>6</iMonthIncrement>
                    <iTurnsPerIncrement>399</iTurnsPerIncrement>
                </GameTurnInfo>
<GameTurnInfo>
                   <iDayIncrement>90</iDayIncrement>
                    <iTurnsPerIncrement>1</iTurnsPerIncrement> <--- Rounding calendar to correct starting date for next era (1st January XXXX year) -->
                </GameTurnInfo>

instead of this (assuming you don't want increment of 7 months):

<GameTurnInfo>
                   <iMonthIncrement>7</iMonthIncrement>
                    <iTurnsPerIncrement>600</iTurnsPerIncrement>
                </GameTurnInfo>

Assuming era lasts 600 turns, but I don't think any era had such round number on any game speed.

There would be up to 13 1 turn oddballs here (containing some amount of days) - each one adding enough days to calendar, so next era starts where it should start.

 

[billw2015]

@billw2015 is there way to make such tool to make such calculations easier?

Of course there is a way, however my time is limited and the backlog of things I want to do is only growing not shrinking! Need more coders/scripters...
Currently my priorities are based on firstly making the game as it currently is playable to the end, which means fast end turn (it is good enough for now), crashes are rare, AI is a challenge, then after this I will turn to helping with new features/content:

1. Crashes - at least until I don't get any when doing overnight auto runs.
2. Memory usage - this will help with late game oom crashes, but also unblock the adding of more content
3. AI - refactor and improve, if the AI can't provide a challenge, then it isn't much fun, and simply giving AI faster research rate/money etc. isn't satisfying.
4. Xml tools - improve how easy it is to make data modification, this will help future development.

 

[JosEPh_II]

AI - refactor and improve, if the AI can't provide a challenge, then it isn't much fun, and simply giving AI faster research rate/money etc. isn't satisfying.

Preach Brother Preach! +1

 

[Thunderbrd]

Forget all about constant turns per era. If a turn is 30 days or more, it must be an exact multiple of 30 days (a Sid Meier month). Thus it should not need to say what day of the month, just the month. Or for three or six-month turns, you can do seasons, if that's easier.

If a turn is 360 days or more (Meier year), it must be an exact multiple of 360. So no need to say a month, just a year.

I've always agreed with this philosophy.

 

[raxo2222]

I've always agreed with this philosophy.

I think advancing by 2/3 or 3/4 of month or year is fine too.

I know, that my calendar is very irregular, but at least follows tech tree very closely.
I just don't have tools to easily make more subdivisions (and multiple of them per era).
Prehistoric era has two subdivisions though.

 

[Thunderbrd]

I think advancing by 2/3 or 3/4 of month or year is fine too.

I know, that my calendar is very irregular, but at least follows tech tree very closely.
I just don't have tools to easily make more subdivisions (and multiple of them per era).
Prehistoric era has two subdivisions though.

I think you figured out how to find a good place to create a division but then it takes a little aesthetic over accuracy to nail down exactly how to round that out to the nearest month and nearest year if you aren't breaking into months yet, and there is a huge acceptable degree of tolerance to that because no 2 games are ever going to progress exactly the same anyhow.

 

[AIAndy]

Maybe you should change the calendar calculation entirely. Instead of these messy precalculated turn increments, add an intended year to each tech and then average the year of the x latest techs. That is your tech date. Every turn (or maybe every x turns) you compare current date to tech date. If current date is considerably ahead, you speed down (reduce the date increment per turn). If it is considerably behind, you speed up (increase the date increment per turn).
Record the turn with date and new increment each time you change it to reconstruct turn date later.
The only disadvantage is that this is player dependent. Well, I guess you could use the x latest techs over all players for the tech date to solve that.

 

[raxo2222]

I think you figured out how to find a good place to create a division but then it takes a little aesthetic over accuracy to nail down exactly how to round that out to the nearest month and nearest year if you aren't breaking into months yet, and there is a huge acceptable degree of tolerance to that because no 2 games are ever going to progress exactly the same anyhow.

Yeah, if increment for era on given GS would be 23.5 days, then you could split it up in two - 15 days and 30 days, each would be differently sized part, and then add 1 turn on top of that to closeup gap on calculated place.

Also its more than likely, that on different game speeds subdivisions would happen on different dates.
For example one era is 1990 AD - 2050 AD, and on one game speed you would have time step change in 2000 AD, and on other - in 2020 AD.

Also I assume, that 50% games will be under target, when it comes to tech leaders, and 50% would be over target.
There is margin of 10% of turn count target, so if tech leader fall within it, then that game is balanced when it comes to calendar.

 

[Yudishtira]

Also I assume, that 50% games will be under target, when it comes to tech leaders, and 50% would be over target.

You mean if the calendar was perfect? Because currently, I'm sure you realize, every game is ahead of calendar, once it catches up for the Prehistoric tar-pit slowdown.

With how far ahead the tech leader generally is, I'm not sure it's even desirable for the calendar to keep pace with them. The other civs are usually in a bunch (except the player on higher difficulties who may be further back), so maybe aim for the calendar to keep pace with them, and let the leading civ be some sort of alien-assisted anomaly...

 

[TaylorItaly]

Sorry to ask ,but for what purpose is that calendar thing?

 

[raxo2222]

You mean if the calendar was perfect? Because currently, I'm sure you realize, every game is ahead of calendar, once it catches up for the Prehistoric tar-pit slowdown.

With how far ahead the tech leader generally is, I'm not sure it's even desirable for the calendar to keep pace with them. The other civs are usually in a bunch (except the player on higher difficulties who may be further back), so maybe aim for the calendar to keep pace with them, and let the leading civ be some sort of alien-assisted anomaly...

Well era info research modifiers always can be increased - they affect everyone.

Also it was original intention to have half of civs reaching calendar on time (for example half of civs in Ancient era by 12 000 BC), but Thunderbird preferred if tech leader reached target date - so most advanced civ reaching ancient era in 12 000 BC.

 

[raxo2222]

Sorry to ask ,but for what purpose is that calendar thing?

Just fancy thing, and turn increments are tailored to effective era length.
So if someone researched around tech per 2 turns on Normal speed, then he naturally reaches next eras close to date target.
So in average game tech leader who reached Ancient era around 12 000 BC will reach Classical around 1200 BC, Medieval around 450 AD and so on.

 

[billw2015]

I'm interested why you didn't use a (global) science output modifier instead of time modifier? I'm not saying I think it would be better, just wondering.

 

[raxo2222]

I'm interested why you didn't use a (global) science output modifier instead of time modifier? I'm not saying I think it would be better, just wondering.

Global research modifier is good for setting base cost, so you don't have to change Prehistoric era modifier from 100. Also era research modifiers aren't fully balanced.
I prefer constant tech rate, so for example every 100 turns on Blitz tech leader should have gained 90 - 100 techs (we have 942 techs, you need 899 techs to research future tech).

Each era has different amount of techs - Prehistoric and Atomic have most techs.