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

Change: Always apply inflation from 1920 to 2090, no matter the game start year. #7589

Merged
merged 1 commit into from Dec 25, 2020

Conversation

michicc
Copy link
Member

@michicc michicc commented May 12, 2019

Motivation / Problem

With inflation dependent on the game start year, the cost of a new vehicle in the year X can be £100, £10000, or £1000000. This makes balancing costs for NewGRF sets mostly impossible.

Authors deal with mostly in two ways: Either completely ignore inflation and only balance for inflation off. Or balance against inflation starting at a specific year.

Description

As NewGRF sets are not balanced for a variable inflation start anyway, this PR fixes the inflation period to a known value so there is a consistent target to balance against.

Limitations

As income is also affected by inflation, the starting difficulty increases with the starting year. With well balanced sets, this should be managable.

@PeterN
Copy link
Member

PeterN commented May 13, 2019

I think this changes the default game too drastically to be always-on. A standard 1950 start now begins with 30 years of inflation already applied.

@michicc
Copy link
Member Author

michicc commented May 13, 2019

If it's not always on, then there is absolutely no point except providing a third incompatible variant for NewGRF authors to gripe about.

src/economy.cpp Outdated Show resolved Hide resolved
@Eddi-z
Copy link
Contributor

Eddi-z commented May 13, 2019

While i generally think this is a step in the right direction, i think it falls short on so many levels.

Inflation is meant as a factor that drives the difficulty forward as the game goes on, so that the player is forced to adapt to new technologies and optimize the network to stay profitable.

But forcing this divergence of income vs costs onto a newly started game makes it unnecessarily difficult.

A better approach IMHO would be to always apply the same inflation to costs, but make the difficulty setting about the income divergence. the divergence then would start being applied after game start only, while the price inflation would be consistently applied at the base game year, perhaps even further back, if we introduce fractional currency?

Also, i think applying the divergence should stop at the moment no new vehicles get introduced (the point where the reliability curve gets frozen), not at the "original" end year. maybe even a more dynamic inflation divergence based on the vehicle progression

@James103
Copy link
Contributor

Would it be possible to separate the inflation rate setting into as much as 7 different settings? If so, here are my proposed settings:

  1. Loan interest rate: 0% to 255%.
  2. Inflation rate for company expenses: 0% to 255%.
  3. Inflation rate for cargo income 0% to 255%.
  4. Initial inflation factor for company expenses: 1/16 to 1024 in steps of 1/16.
  5. Initial inflation factor for cargo income: 1/16 to 1024 in steps of 1/16.
  6. Maximum inflation factor for company expenses: 1 to 1024 in steps of 1/16.
  7. Maximum inflation factor for cargo income: 1 to 1024 in steps of 1/16.

This would separate loan interest from inflation and provide customization about the income divergence and initial inflation, on top of the existing inflation rate customizability. This would allow you to make the game easier or harder at the start with finer cost adjustments then what even the Basecosts NewGRF can provide, as well as allow you to simulate deflation (such as during recessions), high inflation (like in the USA during the 1970's), or even mild hyperinflation by changing the inflation rates and therefore financial difficulty curve.

Note that splitting the settings like this would make the inflation toggle obsolete, as instead the inflation rate could be set to 0 to disable inflation (or loan interest to 0 to disable that, if you will).

When converting old savegames, the settings should be set as follows.

  1. Loan interest rate: Same as before (same as the old loan interest setting)
  2. Inflation rate (company expenses): Same as before.
  3. Inflation rate (cargo income): Same as before, then subtract 1 percentage point.
    Note that if inflation is off, then both values will be zeroed on conversion.
  4. Initial inflation factor (both sides): Always equal to 1.
  5. Maximum inflation factor: Calculated as (inflation rate in percent / 100 + 1)^170, rounded to the nearest 16th and capped at 1024.

Note that you could still increase the maximum value for the initial/maximum inflation factor another 32 times, up to 32767. This "inflation cap" value is defined in

static const uint64 MAX_INFLATION = (1ull << (63 - 32)) - 1;
and is is checked for in these lines.

OpenTTD/src/economy.cpp

Lines 759 to 760 in 2e686ad

if (_economy.inflation_prices > MAX_INFLATION) _economy.inflation_prices = MAX_INFLATION;
if (_economy.inflation_payment > MAX_INFLATION) _economy.inflation_payment = MAX_INFLATION;

@TrueBrain TrueBrain added candidate: needs considering This Pull Request needs more opinions size: small This Pull Request is small, and should be relative easy to process labels Dec 14, 2020
@TrueBrain TrueBrain added the preview This PR is receiving preview builds label Dec 22, 2020
@DorpsGek DorpsGek temporarily deployed to preview-pr-7589 December 22, 2020 18:35 Inactive
@michicc
Copy link
Member Author

michicc commented Dec 23, 2020

Even though the last comment was made some time ago: The whole point of this PR is to provide a consistent baseline to balance against.

As such, more settings: Just No.

src/economy.cpp Outdated Show resolved Hide resolved
@DorpsGek DorpsGek temporarily deployed to preview-pr-7589 December 24, 2020 23:49 Inactive
@andythenorth
Copy link
Contributor

andythenorth commented Dec 25, 2020

Modest proposal: remove inflation.

Inflation:

  • makes assumptions about span of gameplay (start / end year) that don't hold in OpenTTD with variable start / end years
  • makes the game borderline unplayable when inflation has reached a high level
  • causes bug reports to newgrf authors about unplayable costs (I've been on both ends of this, filing useless bug reports on newgrfs due to inflation, and receiving them myself)

If we want increasing vehicle run costs over time, newgrf authors can take care of that themselves.

To avoid derailing this PR further general inflation discussion is moved to #8429 (thanks)

@James103
Copy link
Contributor

If inflation as a whole is removed completely, then would it be possible to extend the precision of each of the BaseCosts values so as to allow greater precision in changing the base costs (via BaseCosts NewGRF or a similar setup)? For example:

  • Current domain (from BaseCosts NewGRF parameters): Powers of 2 from 2^-8 to 2^16
  • Proposed domain: All numbers from 2^-8 to 2^16 (or 2^15 or 2^23) that are multiples of 2^8

@TrueBrain
Copy link
Member

Please create a discussion to discuss if Inflation should be removed or not. Let's not try to derail PRs too much with completely opposite views of the PR :D Many people might miss it, and might want to pitch in too!

Tnx :)

@andythenorth
Copy link
Contributor

To avoid derailing this PR further general inflation discussion is moved to #8429 (thanks)

Copy link
Member

@TrueBrain TrueBrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't really have much to go on here if this is a good or bad idea. So here goes nothing :D My reasoning:

  • Given the settings discussion I consider it likely inflation will be off by default soon. Which kinda deprecated the functionality already.
  • There is a good discussion if we should have inflation at all or not.
  • If we merge it, people will complain soon enough if this was a bad idea. The best way to receive input is to just merge it.

So yes, let's go for it. Let us merge this, and see what happens :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
candidate: needs considering This Pull Request needs more opinions preview This PR is receiving preview builds size: small This Pull Request is small, and should be relative easy to process
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants