Feature: Technology progresses independently of game time #9789
Conversation
| /** Frozen technology progress speed. */ | ||
| static const uint8 FROZEN_TECHNOLOGY_PROGRESS_SPEED = 0; | ||
| /** The slowest non-frozen technology progress speed, 1/255 times normal. */ | ||
| static const uint8 SLOWEST_TECHNOLOGY_PROGRESS_SPEED = 255; |
There was a problem hiding this comment.
personally, I really have issues with leaking "byte-size" to the public. I much more prefer something like: percentages, where you can indicate from 1 .. 100%. These 1/255th are really a NewGRF thing, and it really has to die out :P No normal user is going to understand why he can only make changes in 1/255th :P
Additionally, you restricted this approach to be from 1 .. 100%. But why not go the small extra mile and allow 1 .. 1000% or something, where people can also speed it up if they so like?
A similar thing happened with "fast forward speed". We were used to either 100% or max-speed. I not only made it go from 100% to .. any % up till a big number, but also the other way, where it can run on 25% speed. As .. why not? :)
There was a problem hiding this comment.
Agree on this, at least partially. The trouble with a percentage is that you need to make it of the regular speed, as well as be integer, meaning that 1% (one-hundredth) will be the slowest technology speed possible then.
My idea for an approach (without having read the code yet) would be to implement it as ticks-per-technology-day internally, but have the setting in the UI select via some other representation. Honestly, a fraction is the most sensible for large slowdowns.
There was a problem hiding this comment.
Isn't it already a fraction? Afaict setting 2 means 2x slowdow, setting 10 means 10x. 255 is just some arbitrary limit because setting and counter use byte, can be easily changed to anything else.
There was a problem hiding this comment.
Let me rephrase then: I agree that a fraction isn't great UI, but it's better than a percentage-based UI which limits the possible range usable. The main downside mechanics-wise of a straight 1/x fraction is that you won't be able to set values such as 67% or 40% speed.
There was a problem hiding this comment.
Not necessarily defending this being set as a fraction, but my prediction is that most people will choose 1/1 (normal and default), 0 (frozen), and 1/2, 1/4, perhaps 1/8...at some point it's so slow that the player probably wants "frozen". But rather than choosing an arbitrary number, I allowed 1/255 as the slowest speed the uint8 will hold.
I can't see a usecase for people wanting to speed up technology progression. It's already quite fast. But if we move to a percentage-based selection I suppose it would be easier to add.
There was a problem hiding this comment.
For faster progression, I can see the case. Many goal games are pretty fast, just 1-3 hours and while normal progression is mostly ok for these it's not that inconceivable to want it even faster. For example, in the CityMania Christmas event, I made it introduce a new engine pretty much every year. Though in hindsight that may have been a bit too fast it wasn't bad either.
|
A potential issue with frozen technology progress: Introduction years of vehicles are randomized on game creation, so a poorly chosen game start date could result in getting incomplete "sets" of vehicles, under some circumstances. |
| @@ -1963,7 +1977,8 @@ void LoadUnloadStation(Station *st) | |||
| void CompaniesMonthlyLoop() | |||
| { | |||
| CompaniesGenStatistics(); | |||
| if (_settings_game.economy.inflation) { | |||
| /* No point applying inflation if technology progress is frozen. */ | |||
| if (_settings_game.economy.inflation && _settings_game.economy.technology_progress_speed != FROZEN_TECHNOLOGY_PROGRESS_SPEED) { | |||
There was a problem hiding this comment.
If I read this correctly, but I might misunderstand the situation, you link inflation to the technology date. Why did you make that choice? (honest question, as always).
Inflation ofc has always been a bit of a weird child, and nobody is actually happy with it. But this choice kinda surprised me, as I assumed the idea of this PR was to stay away from those muddy parts of the daylength discussion :) But you might have an excellent reason for it, so I start by first asking the question :)
I now wonder, if I freeze technology, inflation is effectively also disabled. But why wouldn't the prices go up, despite no new technology rolling in?
If we go this road, maybe we should also make it clear in the settings somehow that inflation is disabled when you freeze the technology.
Sorry for being all over the place in this comment, mostly thinking out loud :)
There was a problem hiding this comment.
In my opinion, inflation should definitely not be tied to technology progress at all. The goal of inflation is to gradually increase difficulty along a game, that would be independent of technology available.
There was a problem hiding this comment.
My understanding of inflation is that it's designed to add difficulty both as the player builds a larger and more profitable network, but also to offset faster and larger vehicles. Isn't that why it's fixed to the original game dates of 1925-2050?
|
While I understand how the idea of techno year came to be and this PR looks like a sound solution technically it seems extremely confusing from the user POV. Why are there two dates in the game? How do I see the second one? What is governed by what? When I open the vehicle window and see "designed in 1977" while it's 1950 I think bugs, not shadow calendar. What's even the point of a calendar date when pretty much everything significant is tied to techno year? Who is even the target audience for this change? For what I see people who want daylength want day length, not some-weird-hidden-value-called-day length. And those few who are content with techo day being separate would be fine with day length as well. Also, this isn't a partial daylength implementation either, once introduced it will be quite hard to get rid of the separate date system. IMO, even if a separate techno timeline is to be added it should be using some custom time unit like techno levels or smth, not mimic the calendar dates it has nothing to do with. |
|
What it does is that the displayed game year starts at 1. I can definitely agree that there needs to at least be some UI to display where technology progress is. That UI issue is part of why my own idea was to instead move the economical calendar over to something phrased in terms of real time: Run the game economy on a calendar of 360 day years with all months 30 days, and change the tick speed (in milliseconds) such that one month is almost exactly 60 seconds. Then you can phrase the UI in terms of "production per minute" and so on, with the main obstacle being what to name a not-year ("penti-hour"? "dodeca-minute"?) without causing excessive confusion. |
Adding to the discussion: I too think that most players would expect the technology year to a) start at the selected year and b) to be what is shown in all visible date displays. This doesn't mean that I am against such kind of date split, just that the technology date should be the player-facing date. |
Randomization is disabled for vehicles introduced within two years of the start date. When the technology year is manually changed, it becomes the start date and vehicles are reset. So this is already solved. 😃
I don't fully understand the "specified-as-the-same" implementation in NewGRF — is it actually the same or is there a time range? If the latter, I agree that it should be shortened or eliminated entirely when playing with sufficiently slow technology progression, to respect the wishes of the author.
I tried to cover this in the PR description, but I see daylength as two separate knobs: technology speed and economy speed. This implements the first half and leaves room for the second (for example, Slow Pace) to be added later.
This might be the solution to the confusion of having two dates. I am wary of both the technical and social challenges of going this route. We use dates to measure a lot of things which would have to be rewritten, including such morasses as timetables, but I think a lot of things would be easier for the player to calculate and plan (including timetables) if they were shown in real-game minutes as opposed to in-game dates. From a workflow perspective, any suggestions on whether to tackle this in a separate PR which this PR then depends on, or in a separate commit to this PR? I am open to other UI suggestions, and any suggestions for incremental changes toward "one-minute months". |
|
I'm not convinced of this idea. It's too abstract for me. I don't like that the vehicles would appear on dates completely unrelated to the facts (most sets contain real vehicles with specific, known release dates) - it makes no sense to me. I would definitely prefer only to add a function of slowing down the passage of time, similar to what is in the JGRPP. I believe that if it will be added in the future, the existence of a change in the pace of technology progress will become practically useless and, as a result, the game code will have to be cleaned again (problem, problem, problem). The fact that when adding this peculiar function, a few additional settings are to be added to the game, while others that players need are removed (e.g. by You) is so irritating that I prefer to skip commenting on this aspect... Apart from the above, for a change in the pace of introducing new vehicles to make sense, their data in the parameters regarding the introduction date should also be modified accordingly - if the vehicle is to appear in 2000, instead of in 1960, the data should show 2000, not unchanged 1960. But it is really very doubtful for me that it would be worth following this path. Regarding technology progression, a script (?) Is used on at least one of the servers (CityMania - Extreme 1 mil city), which sets the conditions that the player must meet in order for a suitable vehicle to appear - in my opinion, this is a much more interesting method than arbitrarily mixing dates. It is also a solution that doesn't interfere with the slowing down the pace of the game. The conditions for the appearance of the vehicle could be alternatively determined by the NewGRF. |
|
This PR does not refer to "slow pace" or not to "technological pace". Most likely, it means "Groundhog Day". Open the cheat and turn on "Groundhog Day" - then play with the steam locomotive forever |
|
Is this one done yet? 🤑 |
|
Referring to the primary motivation...
I think that would be the simplest and imho much better solution. Most likely it doesn't interfere with any existing or planned function. And if necessary, it can be removed painlessly, because this is nothing more than the automation of the existing date-change mechanism: press the left-button for the change of date every January 1st. The appropriate setting could also be created in the configuration file, so that it would also be possible to play online and create scenarios with this setting. |
That sentence shows that you're completely misunderstanding what this patch does. The patch introduces a parallel calendar, called the technological calendar. This technological calendar can have its pace changed, i.e. make days shorter or longer than 74 ticks each. Introduction dates of vehicles, as well as industries, town buildings, rail and road types, all depend on the technological calendar. A train that is introduced in 1960 is introduced when the technological calendar shows 1960, and a train introduced in 2000 is introduced when the technological calendar shows 2000. Regardless of whether the speed of the technological calendar is 1/1 or 1/2 or 1/200. The only issue that kind-of validates your presumption is that the user interface doesn't indicate the technological calendar date properly, yet. But this is a draft, it's a work in progress. |
|
I'll put in my 25c. Era-locking ("Play 1960 trains forever!") is easily achievable in NewGRF - with, obviously, more sensitivity to the appropriate cut-off dates and vehicle selection for the particular set. Features like this, which aim to solve very specific gameplay desires, start to create a situation where there are multiple ways (NewGRF, gamescript, and game features) for players to achieve almost the same thing, and the different methods tend to interact poorly - cf town growth. If players do want overall slower progression, I agree that decoupling "technological year" from "economic year" is massively confusing. What is the benefit in preserving the "economic year" as a separate thing, except to try and duck the issues which prevent us including a comprehensive daylength feature? If we can't find solutions to those issues, let's accept that daylength is conceptually flawed and leave the gameplay aspects of vehicle introduction to NewGRF authors (who, of course, already have complete control over when, if, and how quickly vehicles are introduced and expired). |
|
I'm closing this to reduce my active PRs. If I revisit it in the future, it'll be a new PR incorporating a real-time economy suggested by @nielsmh in this comment. |
Motivation / Problem
In the daylength discussion, @andythenorth gives motivations for players to configure how fast technology progresses in OpenTTD:
Additional usecases might be:
Description
This PR decouples technology date from game time. The availability of content such as vehicles, houses, bridges, etc., as well as date-sensitive game settings like coloured newspapers, automatic selection of semaphore vs light signals, etc., is based on a new technology date which advances according to a new
Technology progress speedsetting. The current, and default, speed is 1/1, but this can be slowed up to 1/255 normal speed.Other than content availability, the rest of the game mechanics continue to use the actual game date which progresses normally and independently of the technology date — so this is not "daylength" in any way.
Is this daylength?
No, this is not daylength. Daylength generally changes the speed of the economic engine, for instance the Slow Pace implementation by @kaomoneus. If years go by slower, the technology naturally progresses slower, but this is a side effect and not the point. It is also impossible to freeze technology progress entirely with a daylength approach.
Does this prevent daylength in the future?
I believe this could coexist alongside a daylength implementation like Slow Pace, giving players separate control over technology and economic time, respectively. I don't see a global reduction of tick speed as a viable, understandable, or desirable implementation. Two parallel controls seem like the way to go, to me.
I've looked through the code in Slow Pace, and don't believe there is any code overlap with this PR.
How does the player choose the technology progress speed?
The world generation screen (all three of them, including the heightmap GUI and the mini generator screen in Scenario Editor) gains a
Technology progress speedsetting. This is given in 1/n (like plane speed factor), where 0 isFrozen, the current speed (also default) is 1/1, and increasing the setting makes the speed slower, up to 1/255 of normal speed.The technology year always starts synced with the chosen start year. If normal speed is selected, it silently mirrors the game year and the player has no idea they are different variables. However, if a game is started with any other technology progression speed, the game year starts at 1, counting up the calendar years played instead of the technology year, since they are no longer synced. This is how the same feature works in Transport Fever 2, and I think it's quite elegant.
I am open to suggestions and debate about whether and how the technology year should be displayed in the toolbar somewhere.
If the player wishes to adjust the technology progress speed, or manually change the technology year, both are available in Settings. Changing the technology year resets the availability of vehicles, road/railtypes, airports, bridges, etc., as well as the current inflation rate. Otherwise, it works like the date cheat where objects (vehicles, objects, etc) already in the game world are not affected.
How does this work in multiplayer?
No differently than singleplayer. Like many settings, the technology progress speed cannot be changed in a running game, nor can the technology year be changed manually.
If we go forward with this PR, the technology date will likely replace the actual date in the server list, while the server detail window will be modified to show the same
DateandYearsfields instead ofStart dateandCurrent date. I haven't implemented this yet since network and game coordinator code is quite complex, and I want to see if there's even interest in this PR before tackling that.What about NewGRF global variables?
The global variables for
current_date/year/month/etccontinue to use the actual game date, to avoid breaking anything.New variables are added for
_technology_dateand_technology_yearto allow NewGRF authors to update their creations. If this is merged, I will make PRs to add the variables to NML.In my experience with NewGRF, the only time I've seen the date variables used are for depot graphics which choose a sprite based on the build year, or for automatic vehicle liveries. These would need to be modified to use the new variables, but I don't see this as a deal-breaker since the NewGRFs will still work with technology progress speed 1/1 — they aren't broken, they just don't support the new feature.
Questions & Limitations
DateandYearsfields instead ofStart dateandCurrent date. I haven't implemented this yet since network and game coordinator code is quite complex, and I want to see if there's even interest in this PR before tackling that.oldloader_slfor loading non-OpenTTD saves and determining which vehicles are available. Do I need to, or are the intro dates overwritten later?Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.