Feature: Change speed of calendar progress

[2TallTyler]

Motivation / Problem

In the daylength discussion, @andythenorth gives motivations for players to configure how fast technology progresses in OpenTTD:

Play 1960 trains forever!

For many players, the game seems to progress quickly. A new generation of vehicles appears, so we upgrade and tune our networks. Then just as we finish, boom! A new generation of vehicles appears.

On busy or large maps it can be hard to keep up.

Slower progression of vehicles would make a more relaxing games for some players.

Additional usecases might be:

• A GS freezes technology progress and advances it when the player completes transport goals ("research" in many games).
• Early-year games such as the American Wild West can actually reach a late-game network size and bank account without cheating time and money — without this, by the time a large network can be built, the era is long past.
• Industry sets can be designed for frozen progression without regard to supporting realistic technological progression, and can offer industry chains which were phased out long ago. Imagine sending ships to hunt whales, delivering coal to gasworks for town gas production, and harvesting ice from frozen lakes to ship around the world. Currently, the NewGRF author can either choose to force these industries to close, frustrating the player, or keep them around forever, which feels silly.

Description

This implements @nielsmh's approach described in my previous attempt to implement this (#9789).

Date/time handling is separated into two systems:

Calendar time for technology and world appearance

• Vehicle introduction and obsolescence
• Available airports, stations, objects, etc.
• NewGRF variables which can be used to determine visual styles or behavior based on the time of year
• Snow line movement

Economy time

• Industry and house production/consumption, etc.
• Town growth
• Industry production changes, closure, and spawning
• NewGRF variables for things like FIRS production boosts
• AI/GS API additions for things like town growth scripts
• Running and maintenance costs, loan interest, etc.
• Vehicle and group profit statistics
• Finance graphs
• Cargo payment rates graph
• Local authority reputation, station ratings, etc.
• Vehicle service interval and time since last service
• Linkgraph tooltips and update interval setting
• Autosave frequency and other settings
• Network game duration in server list (replacing "Years") - @TrueBrain will help with this before merging.

Calendar time is kept in a common Gregorian calendar, with 365 days in a year, leap years, variable length months, and so on.

Economy time is kept in (approximate) real time. There are logical days with a duration of 1.998 seconds, logical months with a duration of 1 minute, and logical years with a duration of slightly more than 12 minutes.

Internally a calendar with 12 months of 30 days is observed. There are no leap periods.

In the user interface, all elements that run on economy time are presented in real time units:

Seconds (multiples of 2), for things which were originally daily

• Timetables

Minutes, for things which were originally monthly:

• Industry production per minute
• Passengers last minute
• Vehicle service intervals and time since last service
• Subsidies

Economic periods (sometimes described as simply 12 minutes) for things which were originally yearly:

• Running costs
• Company finances
• Vehicle and group profit statistics
• Company performance rating (league table)

Internally most events will still be referenced as daily/monthly/yearly.

Limitations

This changes MILLISECONDS_PER_TICK from 30ms to 27ms to make an in-game day last 1.99 seconds instead of 2.2 seconds, making real-world time feasible. This actually matches TTD and closes #10205. 😉

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[PeterN]

Your checklist doesn't mention town growth, is that covered under house generation?

[James103]

I found some minor items whose grammar could be improved.

[LC-Zorg]

The preview game crashes very quickly (once when I trying to build a station, the second time when the vehicle arrived at the station, the third time when I was not doing anything), so it's hard to judge how it works. Overall it might be good maybe very good but I have a few doubts.

1 - Release dates for new vehicles
Will a vehicle that should appear in 1990 always appear in (ca.)1990, or is it dependent on the calendar setting or the game start date?

2 - Running costs, production, everything else based on real time
Are you planning this as an option or the only choice?

3 - Percentage setting of the calendar speed
Whenever I set costs in any add-on, I think why there's just no percentage setting, it would make it so much easier to customize different add-ons. Here, however, I'm not really sure if it's better than the form used by JGR or kaomoneus. Not a very important note, just thinking out loud ;)

4 - Broader game pace setting instead of just calendar pace
What do you think about making it a group of settings rather than a single setting? I mean, the pace of production, including the amount of passengers, could be regulated in a similar way. Thanks to this, you could create a game where not only time changes slower (or faster), but also where everything except the pace of vehicles is slower, as in the JGR version. Such a game, when you don't have to use thousands of vehicles on every connect and can focus on the development of a wider world, can be equally interesting. Something like that:

Settings > Generating world > Game pace:

• calendar progress speed
• industries / economy speed - it determines how fast, how much enterprises and cities produce and thus how fast you earn

Yes, this idea probably excludes the third point. :)

[nielsmh]

1 - Release dates for new vehicles Will a vehicle that should appear in 1990 always appear in (ca.)1990, or is it dependent on the calendar setting or the game start date?

Why would it depend on the game start date? When the calendar shows 1990 things that appear in 1990 will appear.

2 - Running costs, production, everything else based on real time Are you planning this as an option or the only choice?

It is real-time, and real-time only. Real-time based on the wall clock in your real room, nothing production or earning or scoring related is based on the game calendar.
Production happens on the same game tick increments as it has always done, vehicles move the same distance per game tick as they have always done, running costs might be slightly different because they are calculated per 30*74 ticks (one "economy month) instead of per 28, 29, 30 or 31 days of 74 ticks.

3 - Percentage setting of the calendar speed Whenever I set costs in any add-on, I think why there's just no percentage setting, it would make it so much easier to customize different add-ons. Here, however, I'm not really sure if it's better than the form used by JGR or kaomoneus. Not a very important note, just thinking out loud ;)

You need to re-state this question. The game setting is already configured in percent.
Personally I think it would be better to define the technology calendar day length in game ticks (default = 74) than a percentage setting.

4 - Broader game pace setting instead of just calendar pace What do you think about making it a group of settings rather than a single setting? I mean, the pace of production, including the amount of passengers, could be regulated in a similar way.

In my understanding/opinion, this is out of scope.

[LC-Zorg]

1
Because economic time is different from calendar time. This fact alone raises some doubts.

2
I understand that everything works the same (with a slight acceleration). It's about the way it's presented and the point of reference used. I believe that presenting the level of production, the number of passengers, and especially costs and revenues in relation to real time (minutes) as the ONLY form is not a good way to implement this function.

3
It's not really important. Any other form, including ticks, can be added if it will be needed.

4
Yes, it's not something that needs to be done now (or ever). Just an idea that might be related to this change.

[James103]

Regarding the timetable change, would it be possible to allow timetabling to the nearest second (including odd numbers of seconds), instead of just rounding to an even number of seconds?

An economy day contains 74 ticks and lasts 1.998 seconds (very close to 2 seconds) after this change; therefore, there are 37 ticks in a second, which should make this feasible based on how the numbers line up.

[2TallTyler]

It's possible, although it would require changing timetables from using dates to using ticks. I don't think many people use timetables for anything beyond separating vehicles with shared orders and I plan to upstream the JGRPP autoseparation feature soon™️ (my next big project after this), so I'm not convinced it's worth the effort. Rounding to even seconds is only a visual change, after all -- the timetable resolution is unchanged.

[PeterN]

Is it possible to have economy time related to calendar time, so the length of the economy month is variable instead of moving to fixed 30-economy days?

At 1x, there'd be 1:1 relationship with economy and calendar, and the game is effectively the same as without this.
At 2x, you'd get 2 economy Januaries in calendar January, 2 economy Februaries in calendar February, etc.

Changing day length mid-game would make it go out of sync though, but that may not be a huge problem -- it would just be as the PR already is.

[2TallTyler]

Superseded by #10605, in which real-world time display is optional.