Moderator: OpenTTD Developers
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.
My heightmaps: Flat Earth Map and United nations logo
My scenarios: Game Fallout 1,2,3 Map scenario
My gamescripts: City Founder GS
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.
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?
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.Railwaymodeler wrote: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 sameRailwaymodeler 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?
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 ), 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).
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
(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
Probably. It's mostly a fun thought experiment on how NewGRFs and existing graphics might be able to work with such a featureFulliAutomatix 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
This idea of using special tricks with the palette always seems to be the first idea for night mode, usually with two variants: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.
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 ) 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
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...FulliAutomatix wrote:For now I think editing screenshots in GIMP to emulate night time is equally as cool
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...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
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 Might be tmwftlb though.
This is side tracking here. However.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
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.
Users browsing this forum: No registered users and 8 guests