Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: The description for "minutes per year" could improved #12492

Closed
hmkemppainen opened this issue Apr 13, 2024 · 4 comments · Fixed by #12726
Closed

[Bug]: The description for "minutes per year" could improved #12492

hmkemppainen opened this issue Apr 13, 2024 · 4 comments · Fixed by #12726

Comments

@hmkemppainen
Copy link

Version of OpenTTD

14.0-RC3 Linux

Expected result

Someone reading the description for "minutes per year" under Environment / Time settings should be able to understand how it really affects the economy.

Actual result

"This setting does not affect the economic simulation of the game," says the description.

That's a bit vague and hard to interpret. Is it a technical statement (how does this help someone who's not intimately familiar with the internals)? Is it a statement about the effect of the change for a player looking at year-on-year financials (which would imply that something under the hood must have been affected to compensate for the change in the time scale)?

The fundamental problem here is that change is relative, and when you change one thing, it inevitably has an effect on other things. What that change looks like depends on which perspective you are observing from (real time? calendar time? simulation code? something else?).

For example, let's say I double minutes per day. What happens?

One interpretation is that (quoting the description for Timekeeping) "cargo production and financials are [instead] based on one-minute increments" always holds. If the quoted statements always holds and no scaling of any sort is applied to production values, then doubling minutes per year should also double cargo production per year. Thus, even though the economic simulation is technically unaffected by the change (it still operates on minutes), the player observing year-on-year production and financials should see a massive effect to the game's economy.

Thus, an alternative interpretation for "does not affect the economic simulation" is that production, maintenance, etc. per year is unaffected; thus the player's year-on-year profit should be relatively unaffected. But achieving this woud literally mean halving the economy rate, which surely is an effect on the economic simulation of the game?

Both interpretations above ignore the effect on train speed, which is leads to another inevitable change. Assuming animation speed does not change, doubling minutes per year should mean trains can make double the trips per year. Again this can have a massive effect on the game's economics, but the exact nature of it depends on how the production is affected.

Some kind of effect is inevitable, and I suggest that to make the setting more understandable, it would be best to describe the effect that the player will observe rather than claiming that the economic simulation is unaffected and leaving them to try and figure out what this implies.

For example, if the first interpretation I proposed is the right one, then I might change the text as follows:

-Choose the number of minutes in a calendar year. The default is 12 minutes.
-Set to 0 to stop calendar time from changing. This setting does not affect the
-economic simulation of the game, and is only available when using wallclock
-timekeeping
+Choose the number of minutes in a calendar year. The default is 12 minutes.
+Set to 0 to stop calendar time from changing. This setting is only available
+when using wallclock timekeeping.
+
+Animation speed and economic simulation are not coupled to calendar time.
+Thus increasing the minutes per year also increases the distance a vehicle can
+travel per year, along with the amount of cargo produced and maintenance
+costs incurred per year

Steps to reproduce

  1. Go to (advanced) settings / environment / time / minutes per year
  2. Try to figure out how that setting actually affects the economy
  3. $$$
@2TallTyler
Copy link
Member

Your first interpretation is correct. Thanks for suggesting a more nuanced explanation. That said, in wallclock timekeeping mode there is no way to see any stats based on the year, so I would not mention years as in your suggestion. The first sentence is good, though. I will think on this further (and feel free to make more suggestions!)

@hmkemppainen
Copy link
Author

hmkemppainen commented Apr 14, 2024

That said, in wallclock timekeeping mode there is no way to see any stats based on the year, so I would not mention years as in your suggestion.

Right. I just realized that last night after playing with the setting. I quintupled the year and reduced cargo & passenger production to 20%, expecting a much longer time between financial reports and a game that feels slowed down (except for vehicle speeds and non-production economics). Turns out I get the financial report five times a year now :) And a lot of complaining about industrial trains making no profit during a period (because they sit waiting for a full load that much longer).

So I agree the text I proposed text isn't quite there yet.

Still, since the setting itself (together with the wall clock setting) is changing the meaning of a year, surely the player will want to understand how different aspects of the game do (or don't) relate to said year.

I only now noticed that enabling wallclock changes the "show finances window at the end of the year" to read "show finances window at the end of the period." That is easy to miss, given how far apart the two settings are.

In hindsight, the description for timekeeping does say that wallclock mode has financials in 12 minute periods. So maybe it is all adequately explained already?

Then again, one description speaking of "cargo production and financials" while the other saying "economic simulation" may have led me to assume that financials here only refers to the non-cargo production calculations of the economic simulation (infra and maintenance costs, interest), but still had in my head the assumption that the financial report is calendar based (end of year). Hmm.

Honestly I'm not sure what to do about this, if anything. How about something along these lines?

Since animation speed and economic simulation are not coupled to calendar time, increasing minutes per year also increases the amount of travel, economic activity and number of financial reporting periods per year.

Someone could probably wordcraft it better.

It is redundant since the timekeeping setting's description already implies all of this (though it doesn't mention animation speed). However, it makes the effect of the minutes per year setting more concrete by saying "if you do this, then that," which may be easier to grasp and won't require you to go back to read the description of timekeeping until you understand how it relates.

@hmkemppainen
Copy link
Author

hmkemppainen commented Apr 14, 2024

To avoid overemphasis on what is not coupled to calendar time (but which still affect's player's experience one way or another when we change minutes per year), it might not hurt to add (redundant but helpful) copy of the text from the timekeeping description to emphasize what the setting does directly affect:

Choose the number of minutes in a calendar year. The default is 12 minutes. Set to 0 to stop calendar time from changing.

Increasing the length of the calendar year slows down the introduction of new types of vehicles, housing, and other infrastructure.

Since animation speed and economic simulation are not coupled to calendar time, increasing minutes per year also increases the amount of travel, economic activity and number of financial reporting periods per year.

This setting is only available when using wallclock timekeeping.

@2TallTyler
Copy link
Member

@hmkemppainen I've opened #12726 to address your comments. Let's discuss how to solve it there. 🙂 (I hope others will chime in too)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants