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
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.