Proposal for Custom Daylength Using Ticks and 24 Hour Time

[supermop]

Hi All,

Daylength has never been a huge problem for me personally, but reading the numerous fruitless ideas for it so far inspired me to have my own idea for a framework to allow people to adjust as they see fit, without them having to use odd workarounds like repeating days, years, or decades.

As I understand, a major problem with lengthening a day in the game is that costs, cargo production, and payments are all a function of days (or months...) rather than 'real time' as it is experienced by the user. A user sitting down to play the game for 10 minutes will expect his train to cover a certain about of distance on his screen in that time, and may also expect a mine to produce a certain amount of coal during that time. If he finds years flying by too fast in his game and decides to slow the progress of in-game days by a factor of 6, however, his train will cover the same distance in his 10 minutes, but he will need to wait an hour to receive the amount of coal he was expecting. If he tries to compensate by then boosting cargo production by 6, he finds that now his train is delivering the same amount of cargo per real time minute as before but with a speed 6 times greater as seen by the game, and is paid more accordingly. Additionally, he now finds he paying for his infrastructure and running costs only 1/6 as often. While some users may have no problem with this, it certainly does not cleanly achieve the goal of 'the same real time experience but with longer nominal days/months/years'. Additionally some users may indeed find various rates of payments and costs lacking and wish to tune them differently than in proportion to daylength - as with larger maps a user may choose to imagine that the increased space represents an area four times as large, or the same area in four times as much detail.

My idea, for better or worse, is therefore to divorce the game calendar, which players may associate with changing seasons and eras from the game time or speed - which can be thought of as the rates at which game action occurs. I envision this being implemented and fleshed out in a series of modular steps, hopefully to improve viability and granularity of control by users. Constituent steps are as follows:

1) perform actions which now occur every n days instead every equivalent number of ticks (n*74 presumably, but conceivably adjustable by game or newgrf setting where desired). Likewise, payment rate should be expressed in tiles/ticks rather than tiles/days.

2) implement a 24 hour clock, with a default of 60 or 74 ticks per game clock minute, but adjustable per game setting

3) change calendar days to increment every n game minutes, adjustable by game setting. At default this gives the same game experience as before, but increasing n slows the passage of game seasons, years, and vehicle availability without changing the real-time rates of costs, payments, or production.

4) render timetable in user's choice of ticks, game minutes, or game hours+minutes instead of calendar days. Based on my persona experience with the 24hr patch, this is helpful even when not using any daylength effects. Timetable should not use game clock days to avoid confusion with game calendar days.

5) if desired, convert displayed costs and production rates to calendar time context from ticks/game clock time when rendering in various dialogue windows.

This could accommodate users who want more calendar time with the same apparent rate of game actions in real time, those who want the default calendar time with a different rate of game actions, and any other combination. Settings mentioned in part 1 could be used to vary various costs and production rates independently of one another.

If the tick counter cannot be made to exceed 74, or otherwise has a relatively low ceiling (say, 255 or so), then I suggest to implement part 2 first, and perform those actions mentioned every n minutes instead of n*74 ticks

I envision the basic setting users will adjust to be shown as "Number of minutes per calendar day (default 1)" with the user able to enter a higher or lower value. Other settings which could be more tucked away would include: "number of ticks per game minute (default 74)", "Show payment rates as function of (ticks/minutes/hours?)", "industry production every x minutes (default 30)"...

Of course, a vehicle will now effectively last longer and make more income before getting 'old', thereby further reducing the purchase cost as amortized over the life of the vehicle, but I see this as less of a daylength issue, as a vehicle will already often make back its cost on the first run. I feel it is better for the player to adjust production and payment rates downward if they desire than to force players to replace vehicles more often, as more micromanagement per game year is antithetical in many ways to the spirit of longer daylength.

Thoughts?


Best,

[YNM]

If you want it there's better be a default value (or a fixed value, maybe by polls ?).