Okay, I thought I'd just about run out of choices; then I got a new idea. This, bigsig-003, is based on the fact that the only thing you really need to see about a signal is what colors it is showing and which way it is facing. Therefore, nothing should be shown except the lights themselves.
Let me point out first of all that I'm an American, accustomed to right-hand running (although we do have some left-hand roads here); and in OpenTTD, I have my signals set on the running, right side of the track. Due to a single careless choice I made very early on in the drawing of this sketch, it has come out LEFT-HAND RUNNING, with signals on the left side of the track from the engineer's viewpoint.
I'll describe the elements of the sketch and then discuss rationale and implications. Please realize this is only a rough sketch; especially, the abundance of signals is not only useless, it's impossible to achieve ingame.
Near the center is a row of five lights not associated with any track. This is the basic set: white, yellow, blue, green, red (W/Y/B/G/R). Each has a 4x4 bounding box and consists of a 2x2 in one shade bordered by another shade of the same color, with the corners clipped off. Transparency is all or nothing and the lights are composed from the ttd-noaction-nocomp.gpl palette.
I have not drawn anything at all except the lights themselves; I put them on existing signal poles, for speed and laziness. Something Bad happened between the screenshot and the finished sketch; the background is strangely dithered.
In the SW corner are 4 sections of NGA track. These are all normal block signals, crammed in as tightly as I could get them ingame.
The western, northbound section has a line of signals on 'proceed', as does the eastern, southbound section (again, left-hand running). The 'inside', facing-wrong-way signals mostly show 'stop' but I've mixed it up a little to better show the effects of overlap. The two E-W sections are both signaled 'proceed' for westbound traffic and 'stop' otherwise.
To the SE is a gallery of all signal types in both aspects, shown on a section of X track. Moving along this section to the NE I show normal, entry, exit, combo, path, and 1-path. All the signals facing a NE-bound train are at 'stop'; all facing a SW-bounder, 'proceed'.
The hill is covered only with 1-path signals showing 'stop'. Yes, this is operationally ludicrous.
Potentially, signals may be set very close to one another. The idea here is that by eliminating nonessentials, it's possible to make each light bigger without making a much larger signal overall. A tile is 32 px from E to W and on that stretch there can be 2 signals, so I allow 16 px per signal. Three lights at 4px each total 12px, leaving 4 px to distinguish where one signal ends and another begins.
Read from the signal post "out".
1 2 3
W G G : normal block; proceed
W R R : normal block; stop
Y Y G : entry; proceed
Y Y R : entry; stop
W W G : exit; proceed
W W R : exit; stop
W Y G : combo; proceed
W Y R : combo; stop
B Y G : normal path; proceed
B Y R : normal path; stop
B R G : one-way path; proceed
B R R : one-way path; stop
I'm not quite settled on this scheme. Prototypes have tried many different schemes over the years, even ignoring semaphores. Also, OTTD signals are not quite replicas of any prototype, where a common indication is 'proceed with caution'. I certainly don't know of any road that orders engineers to swap end-for-end when they see the back side of a signal. While I believe in realism, bigsig is intended to make game play more straightforward. I'll be interested in suggestions.
It's difficult to choose from a limited palette to contrast with everything else on the board. The Y and R may be a bit too close together in shade, as will as the B and G. I'll experiment.
You do not need to see the signal post to read this (although it may make it easier to figure out on which which track the signal is). The light nearest the engineer (as he would see it) is always R or G. (I leave it as an exercise to figure out how he sees the others, "behind" it from his viewpoint.) The light at the post is always W, Y, or B. Only path signals contain B lights at all. All signals that contain two of W and Y are presignals of some kind.
The entire signal is visible to the player no matter where it is (given that obstructions can be made transparent). For me, at any rate, being able to see which signals are indicating 'proceed' is invaluable in troubleshooting. As it is, even with IMO-better-than-default signals, I can't even tell the type when it's edge-on.
The direction the signal faces is clear, even if the post cannot be seen. Again, the old hands may never think of this but when I'm laying signals in the middle of a busy yard, with steam all over the place and trains smashing into horse carriages, I can hardly tell if I've laid two block signals or one, let alone where the one might have gone.
Realism is great but it stops being fun when you have to crane your neck and squint. When you have to whip out a magnifying glass, I say it's time to create more lucid graphics.
In my last post, I argued that slopes made novel signal creation very difficult. You see here the same arrangement on the four slopes that you see on the flat. I think it's not great; the signals look a little funny. But they do not actually nose right into the hillside.
Being cheap, for this sketch I just stole existing poles from the screenshot and, therefore, put the new signals over the old signalheads. Of course, I will draw new poles when "for real". I think signals will look better on the flat if the poles are a bit shorter; but they may look worse on slopes. Some thoughts here may help me.
I need a collaborator on this. As I mentioned last post, I know next to nothing about OTTD and it will be as much as I can do to draw the graphics correctly. If you like what you see and want to see more, step up.