Day/Night Changes In Game

Got an idea for OpenTTD? Post it here!

Moderator: OpenTTD Developers

Post Reply
User avatar
Railwaymodeler
Tycoon
Tycoon
Posts: 2097
Joined: 23 Dec 2004 18:31
Location: Wisconsin, USA

Day/Night Changes In Game

Post by Railwaymodeler » 09 Mar 2019 05:23

When I was a kid one of the more impressive aspect of A-Train (Imported through Maxis in the US) was the cycle between day and night, with lights in buildings and train windows, and dawn and dusk transitions. Having a Macintosh LCII back then, this was quite impressive.

There has been for some time a night GRF set for TTD and now OpenTTD. But the game stays in night time, which is not really much better for long term play.

OpenTTD's day length patch gives me an idea, a button to toggle between "Regular time scale" and "Realistic time scale". To elaborate, the manual to Railroad Tycoon explained that the months it took for trains to travel between towns only a couple hundred miles away (Much as they do in TT onward) is balanced by the exaggerated revenue (Also in TT and newer) and the effect is one animated train doing the work of many unseen identical trains. One three car passenger train taking a year to travel between New York and Chicago, is a visual representation of hundreds of trains, and costs and revenues are scaled to reflect this.

This to me has always been an acceptable way to balance game play with realism. But it does not lend itself well to micromanaging and finely tuning schedules. And there's no good way to emulate seasons or days.

The idea I have had is a button that, when pressed, changes the date at the bottom of the screen to hours and perhaps minutes (Or perhaps 5-10 minute blocks, I.e. 12:00 then 12:05, then 12:10 and so on) and adjusts other time related things as well, such as vehicle timetables, and also adjusts the vehicle operating expenses and revenues. A locomotive that costs $10,000 per year to run would still cost that much in one year, just the amount spent per game "tick" might differ if one "Tick" represented one game day, or 10 minutes out of a day.

The effect would also be that in normal TT game time day and night transitions and changes would be disabled, the game would stay in daytime, or nighttime if the user preferred (A preference setting could handle this) but when running in "Scale" time, day night changes and transitions would be possible.


I do not know enough about GRFs to know if they could automatically handle day night changes, A-Train did so by a simple pallate swap, and I do not know if a solution like that would work, but I do think it would be possible for GRF artists to have action colors (Like the dark blue in original TT graphics) that would react to pallate swaps. Perhaps a line of code in a GRF like 'nightchangeenabledgrf' that if it is present, tells OpenTTD that day night transitions will work, and if some GRF sets do not have that, a message advising the player that some sets are not known to be compatible with night transitions and may look odd. Some abandoned GRF sets, given the right license, could probably be picked up and given minor changes to windows and other parts to make them compatible, though I am not sure if it really would be that simple or not. Pallate swaps may not even be possible for all I know.


A button on the toolbar would serve as the control. This way, if I wanted to closely watch a new train or bus service run in a more realistic timetabled setting I could, but then toggle back to original speeds as a sort of "Fast forward" for a while.

I don't know how feasible any of this really is, but I would love to see this implemented, especially with day/night transitions.
Without Trains America Stops

Image
Image

agentw4b
Traffic Manager
Traffic Manager
Posts: 157
Joined: 14 Apr 2017 15:51
Location: Czech Republic

Re: Day/Night Changes In Game

Post by agentw4b » 09 Mar 2019 08:09

I think some things you write about as a novelty are already included in the OpenTTD JGRPP. But I can not judge how your version differs ...
Owner and admin of servers:Experimental games 01 (92.63.57.152:3979), Experimental games 02 (92.63.57.152:3879), Experimental games 03 (92.63.57.152:3779), Experimental games 04 (92.63.57.152:3679), Experimental games 05 (92.63.57.152:3579).
My heightmaps: Flat Earth Map and United nations logo
My scenarios: Game Fallout 1,2,3 Map scenario
My gamescripts: City Founder GS

User avatar
Andrew350
Route Supervisor
Route Supervisor
Posts: 508
Joined: 19 Dec 2011 07:54
Location: Washington State, USA
Contact:

Re: Day/Night Changes In Game

Post by Andrew350 » 11 Mar 2019 07:04

It's funny, not too long ago while revisiting NightGFX I came up with some ideas myself about how a Day/Night cycle could be done "the right way" in OpenTTD, but never got around to posting it. My thoughts on how it would work are a little different (mostly no daylength stuff, since that seems like a good way to get shot down quickly ;)), but the end result of a day/night cycle would be mostly the same. Most of my concept revolves around how to make this work with NewGRFs, which will be a central issue with something like this. But I think, at least conceptually, my 'plan' offers a good solution. Bear in mind that I lack the skills to really understand the technical implications of what I'm proposing, but I've tried to consider the real issues and offer something at least somewhat realistic to implement (my first point below is no doubt the biggest hurdle, if even possible, and unfortunately it's also the key to the whole thing :? )

Anyway, here's what I came up with:

My Proposal for Doing "Night Mode" the Right Way™

From a conceptual standpoint, NightGFX is not a good implementation of doing "night mode" for several reasons. Even though it's possible to make NewGRFs that work with NightGFX, the way in which it's done is cumbersome and laborious, for authors and players alike. It requires complete manual conversion for all sprites, and only works for a specific combination of this one baseset and whatever NewGRFs may decide to support it, and requires saving and exiting the game to manually make the switch.

A better solution would be integrating a day/night cycle directly into OpenTTD. Easier said than done, this needs a few key pieces to be done right. Most importantly:

OpenTTD itself needs to supply the "night-time" effect.

Somehow the game must be able to apply a sort of 'darkness filter' over everything in the game world. This is the only way to ensure 'compatibility' with the wide variety of graphics already available, especially older ones which won't get updated (more on that below). There is simply no way to make OpenTTD include a night-mode without somehow making it work for everything out-of-the-box. Relying on (and effectively forcing) NewGRF authors to update their sets to support a feature like this simply won't work; the effect needs to be handled automatically.

That being said, there is more to a night mode than just making everything dark...

What to do about lights?

If OpenTTD handles the darkness, then the only thing set authors have to handle are the (optional) lighting effects. My thought on implementing this was something like adding a new flag to the alternative_sprites block (talking NML here, obviously) so that the lighting effects could be simply coded as a separate layer to be applied when the game calls for it (some time during the day/night transition). This also makes it easy (at least in theory) to maintain parallel support for 32bpp/EZ since those are also applied as flags in the same way, so just pick and choose which to activate to supply the graphics for each situation. (obviously I'm completely ignorant on how this would work on the backend, but, you get the idea!)

This would mean relatively little additional work necessary for NewGRF/Base Set authors to add some cool effects for night time if they wanted to, and easier for authors = more acceptance, right? ;) Of course there's room for different ideas here; this was just the one that made sense to me :)

OK great, but what if I play with the original TTD graphics?

Well that's the great thing about doing the darkness stuff within OpenTTD itself; all graphics and basesets are 'supported', it just needs some additional love to add the lights. In the case of the original TTD graphics, these light sprites would need to be added to the openttd.grf shipped with the game (or possibly a new one?) to maintain support. Yes, this takes some work initially, but it's a one time investment, and people like me can even help with that :)

How does this work for the end user?

With the technical details worked out as proposed above, the end user should have a much better experience where the day/night cycle just 'works', even when NewGRFs don't explicitly support it. Obviously older/non-conforming sets won't have any lighting effects, but at least they will still fit in with everything else by being darkened, which is probably the most acceptable result possible. At least it is vastly preferable to any altenatives I could think up :)

As far as how it would work, I imagine something relatively simple wherein the actual day/night cycle would be an option activated (by default?) via a new setting. Maybe a three-way setting between 'Day Only', 'Night Only', and 'Day/Night Cycle'. The day/night cycle time would likely end up being something arbitrary that feels right, but perhaps an additional setting to adjust the length of the day/night cycle might be preferable (but this of course starts really opening up the conversation to the aforementioned daylength debate, so....;))

So in review...

In order to do a true, well-implemented day/night cycle, it is necessary that OpenTTD itself handles much of the work to make the transition to night and back, especially when considering the NewGRF situation. It opens up the possibilities of making a smooth day/night transition instead of instant, easier handling of compatibility for older graphics, and perhaps most importantly, reduced effort needed for authors and players alike to make it happen. Also, adding night mode might be a good candidate for making the jump to OpenTTD 2.0, so we can keep the OpenTTD versions matching the release year (I'm only slightly joking here :P)

Obviously reduced effort for end users means more work for anyone developing this, but to do it right is the only way in my opinion. If it can't be done right, just leave 'night mode' to NightGFX and let it be as the experiment that it is now, which is fine :) Also I'm sure I've overlooked and oversimplified some things while putting this together; just throwing some ideas out there. Feel free to comment, add to it, shoot it down in flames, or propose some alternatives. :)

User avatar
Railwaymodeler
Tycoon
Tycoon
Posts: 2097
Joined: 23 Dec 2004 18:31
Location: Wisconsin, USA

Re: Day/Night Changes In Game

Post by Railwaymodeler » 14 Mar 2019 23:09

Andrew350,

My idea about the day length was mostly for people like me who like to build something, then watch it, then build some more, watch some more, and so on.

I was playing SimCity 4 last night, and the day/night cycle just felt "right" even though it took days and months to make a complete cycle. It works there, and I think it could work in OpenTTD the same way.

I know nothing about NML, but using NML flags, is that like a certain color that does something in game? Like if headlights used a specific pixel color, they would change color at night?
Without Trains America Stops

Image
Image

User avatar
Gwyd
Chief Executive
Chief Executive
Posts: 700
Joined: 17 Apr 2017 16:52
Location: Western Ile-de-France Region

Re: Day/Night Changes In Game

Post by Gwyd » 15 Mar 2019 17:55

Railwaymodeler wrote:Like if headlights used a specific pixel color, they would change color at night?
This could happen, but this would make the palette even more of a minefield of unusable colours than it already is, with company colour, water cycle and fire cycle colours already. Having a designated sprite would work better, I think, especially with backwards compatibility.

User avatar
Andrew350
Route Supervisor
Route Supervisor
Posts: 508
Joined: 19 Dec 2011 07:54
Location: Washington State, USA
Contact:

Re: Day/Night Changes In Game

Post by Andrew350 » 16 Mar 2019 02:04

Railwaymodeler wrote:I know nothing about NML, but using NML flags, is that like a certain color that does something in game? Like if headlights used a specific pixel color, they would change color at night?
No, I was thinking of using separate sprites which are activated by a special flag in the NewGRF code. So basically the 'headlights' would be their own sprite drawn separately, which would then be applied on top of the vehicle sprite during the day/night transition when the game called for it. But the effect would be the same :)

As Gwyd says, making certain colors 'special' so they work differently at night would be a headache, especially for any graphics which aren't expecting it (i.e. everything in existence :P), so I don't even think that's really an option.

But that reminds me, one thing I forgot to touch on above is the palette action colors (such as the crossing cycle, fire cycle, and flashing yellow) would either have to be somehow excluded from the darkening effect, or otherwise these colors would also need to be (re)applied in the same way as the rest of the lights as a separate layer (which isn't a big deal I guess, but could slightly 'break' some old graphics).

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Day/Night Changes In Game

Post by Eddi » 16 Mar 2019 22:15

the thing is, if you want to do light properly, you need shaders and stuff, because a light would affect the adjacent pixels
You might not exactly be interested in Ferion, but if you are, have fun :)

User avatar
Andrew350
Route Supervisor
Route Supervisor
Posts: 508
Joined: 19 Dec 2011 07:54
Location: Washington State, USA
Contact:

Re: Day/Night Changes In Game

Post by Andrew350 » 16 Mar 2019 23:06

Well, yeah, but that's probably like a whole game re-write to do that properly. With some clever shading one can at least achieve some level of local light glow with pixel art/rendered graphics, you just can't make things like headlights that shine down the tracks or anything.

Although who knows what amount of work it would take to do the darkening effect like I've proposed; maybe "real lights" aren't a huge step past that by comparison :P

User avatar
FulliAutomatix
Engineer
Engineer
Posts: 104
Joined: 24 Aug 2014 12:20
Location: Kaon Prison, Cybertron

Re: Day/Night Changes In Game

Post by FulliAutomatix » 24 Mar 2019 15:47

I absolutely love this idea that you've made Andrew350, but I think it would be a bit too difficult for OpenTTD to manage unfortunately.

(Me not also knowing too much about the backend though) I think someone should try making something like this, and then we could see how feasible it is. I think that such a patch could work really well with the clock patch (that one that displays days into hours/minutes) and it could work with what time that patch is emulating.

If it did require extra graphics to be "layered" over existing ones (like sprite stacking) I think that if people wanted to make their GRFs compatible with such day/night cycle patch, then they should have the option, especially if it would be easy for future GRFs to implement.

What I thought though was that (in theory) because GRFs generally have a style that they're drawn in, it might be possible to put certain "rules" on the palette specific to GRFs, saying what entries in the palette represent lights and such. Not sure how that could be implemented, maybe as defined by the GRF in the initial grf block, it is just an idea.

For now I think editing screenshots in GIMP to emulate night time is equally as cool :D

User avatar
Andrew350
Route Supervisor
Route Supervisor
Posts: 508
Joined: 19 Dec 2011 07:54
Location: Washington State, USA
Contact:

Re: Day/Night Changes In Game

Post by Andrew350 » 24 Mar 2019 20:10

FulliAutomatix wrote:I absolutely love this idea that you've made Andrew350, but I think it would be a bit too difficult for OpenTTD to manage unfortunately
Probably. It's mostly a fun thought experiment on how NewGRFs and existing graphics might be able to work with such a feature :)
FulliAutomatix wrote:What I thought though was that (in theory) because GRFs generally have a style that they're drawn in, it might be possible to put certain "rules" on the palette specific to GRFs, saying what entries in the palette represent lights and such. Not sure how that could be implemented, maybe as defined by the GRF in the initial grf block, it is just an idea.
This idea of using special tricks with the palette always seems to be the first idea for night mode, usually with two variants:

Option #1: Turn some existing colors into lights.

This has some major drawbacks, the first being compatibility. Existing graphics are not drawn with any special rules in mind for these colors, which would result in them (most likely) being broken by such a change. These graphics, which include the original TTD base set, most likely won't/can't be updated. This idea also further reduces the already limited color choices an artist has for drawing new sprites. These issues could be mitigated if something needed to be specifically activated first (similar to 2cc green) in order for these special rules to take effect, however choosing which colors should be treated as 'lights' would then be a problem, since lights aren't just white or yellow, they can (and should be allowed to be) any color.

Option #2: Use those unused pink colors for lights!

Anyone who has seen the OpenTTD palette(s) knows about the 8 or so pink entries which can't be used for anything. Naturally a popular idea is to activate them as new special colors for lights. Besides the possible technical problems that might arise from this (who knows, maybe they really do something after all?) you again quickly run into the issue of limitations. IMHO 8 (or so) colors isn't enough to represent lighting properly, so even though this option (probably) doesn't break anything like option #1, it is potentially even more constraining for authors who might want to do night graphics.

...And then we get to possibly an even bigger problem with the palette switch idea: how to handle 32bpp graphics? Since they don't use an indexed palette, simply switching some colors around to some darker ones isn't really feasible, is it? (and if it is, that kinda starts to sound an awful lot like my proposal above :P) Then what to do about "lights" in this situation?

And all of this is without taking into account how things like company colors / other recoulor maps / action colors / etc. would work, which I'm sure present their own problems.

tldr: I'm sure doing some palette magic is "easier", but I still see a lot of challenges and limitations which make the idea less favorable overall. Just my 2 cents :)
FulliAutomatix wrote:For now I think editing screenshots in GIMP to emulate night time is equally as cool :D
Since NewGRFs can support the day/night "switch" between NightGFX and OpenGFX/TTD/whatever-base-set-here, it's also possible to make those screenshots real. Unfortunately none support it (yet), but they could be made to. It is a lot of work, but you only have to do it once... :wink:

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9336
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Day/Night Changes In Game

Post by planetmaker » 24 Mar 2019 23:26

Andrew350 wrote: tldr: I'm sure doing some palette magic is "easier", but I still see a lot of challenges and limitations which make the idea less favorable overall. Just my 2 cents :)
I'm meanwhile not so convinced about this anymore... Most hardware today runs on 32bpp by default and switching to other bit depths even sometimes deteriorates performance - and won't work at all in windowed mode on current OS. As such 32bpp animated is the default blitter nowadays... some 32bpp magic might be thinkable. There also was somewhere an OpenGL driver for OpenTTD...

Having such feature optional, compatibility with existing graphics would be nice, for sure. But as you say, is hardly feasible in a truely satisfactory way.

A proof-of-concept could be nice :D Might be tmwftlb though.

User avatar
Pyoro
Tycoon
Tycoon
Posts: 2477
Joined: 17 Oct 2008 12:17
Location: Virgo Supercluster

Re: Day/Night Changes In Game

Post by Pyoro » 25 Mar 2019 13:09

Wouldn't it clip horribly (or do other unwanted things), if you added actually "shining lights"? Road vehicles seem to barely be "aware" of the length of each other, with how the frequently drive into each other, for example. That can only look even more messier with night lights. And I'd expect similar issues with bridges and tunnel graphics and, well. I'm sure somebody could come up with a list :?

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9336
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Day/Night Changes In Game

Post by planetmaker » 25 Mar 2019 13:23

Pyoro wrote:Wouldn't it clip horribly (or do other unwanted things), if you added actually "shining lights"? Road vehicles seem to barely be "aware" of the length of each other, with how the frequently drive into each other, for example. That can only look even more messier with night lights. And I'd expect similar issues with bridges and tunnel graphics and, well. I'm sure somebody could come up with a list :?
This is side tracking here. However.
Road vehicles know equally well how long they are like any other vehicle. Only vehicles which do not care about collisions are ships.

It's tricky though for any NewGRF author to stick exactly to the bounding boxes. Or even if they do, vehicles can queue front to back without actually colliding. If you then draw beyond the bounding box for the announced length... well, then it seems that vehicles crash without consequence. But that is in principle an error with the particular vehicles.

With road vehicles there's one ceavat: when there's heavy congestion, some vehicles will after some time move despite being stuck so that congestion can finally resolve. This is necessary as there are no signals to control vehicle movement.

On-topic: of course it will be somewhat messy. But not more messy than anywhere else when you try to deduce from pixel colour whether it should be treated as light or not.

User avatar
Gwyd
Chief Executive
Chief Executive
Posts: 700
Joined: 17 Apr 2017 16:52
Location: Western Ile-de-France Region

Re: Day/Night Changes In Game

Post by Gwyd » 25 Mar 2019 15:32

Perhaps treat night "mode" like 32bpp or extrazoom. Night mode gets an alternative sprites block and is only activated if coded. Then day/night cycle can be switched on/off with a warning if a vehicle doesn't have night sprites. (The vehicle would need a 24 hour flag or something). Like some of other people here, I'm not sure of all the implications of this sort of implementation or how to go about it.

User avatar
jfs
Director
Director
Posts: 610
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: Day/Night Changes In Game

Post by jfs » 25 Mar 2019 19:13

For consistency, a night mode should be a filter applied to the graphics, with lights as an overlay sprite applied on top of the effect. Headlights (and street lights) could perhaps be coded as some masks for extracting, filtering, and re-overlaying, part of the ground sprites. You wouldn't get headlights lighting up vehicles ahead etc. but it could perhaps still provide some interesting effects. It would be a massive pain to code :)

User avatar
prissi
Chief Executive
Chief Executive
Posts: 645
Joined: 15 Nov 2004 19:46
Location: Berlin, Germany
Contact:

Re: Day/Night Changes In Game

Post by prissi » 06 Apr 2019 14:42

I made once a day-night patch about 14(!) years ago, using the Simutrans like darkening way of colors. For the 256 palette, one could exclude bright yellow and red for trains, red and green for signals and just darken the rest. This is how it looked like: viewtopic.php?f=33&t=15487&start=21
I like to look at great maps and see how things flow. A little like a finished model railway, but it is evolving and actually never finished. http://www.simutrans.com

Post Reply

Return to “OpenTTD Suggestions”

Who is online

Users browsing this forum: No registered users and 2 guests