News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Incentivising signalling upgrades

Started by jamespetts, January 05, 2009, 12:15:47 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

jamespetts

Although signals can have an introduction and retirement date, and although in some paksets (Pak128, for example), different, newer, railway signals become available later in the game, this seems to be entirely cosmetic: the cost and function of the later signals are identical to those of the earlier signals. There is no incentive for players to upgrade 19th century signals in the 21st century, which sits uneasily with the system (which works well) of players having to upgrade track, road, stations and vehicles as better ones become available and/or older ones become obsolete. 19th century semaphore signals look silly on modern high speed track, yet, if that modern high speed track is upgraded from previous track that had older signals, that is exactly what one might find, and there is no reason for the player to spend money in changing them to modern types.

Currently, signals (which are treated by the game as a category of roadsign) have the following parameters:

(1) the type of way on which they are permitted;

(2) the minimum speed (for minimum speed signs; most are set at 0, which means no minimum speed);

(3) the purchase price;

(4) the introduction and retirement dates; and

(5) a set of eight flags as to whether the signal/sign is: (a) one way; (b) free route; (c) a private road sign; (d) a signal; (e) a pre-signal; (f) only displays a back-image; (g) is a long-block signal; and (h) is an end-of-choose signal.

There is no provision for signals to have any maintenance cost, nor any provision for parameters that affect how signals perform. There are a number of possible options for incentivising the upgrade of signals without overly impacting game performance, creating a great deal of work for whoever codes the patch, or making the game excessively complicated. The first is simply to add a maintenance cost provision for signals. Pakset authors could then specify earlier signals to have a lower purchase price but a higher maintenance cost, whereas later signals have a higher purchase price but a lower maintenance cost, to reflect the fact that early signalling was mechanically simple but labour intensive, whereas modern signalling is enormously complicated but very efficient: there would then be an incentive to upgrade to save in the long term on maintenance costs. If the maintenance cost was made, not per month, but per use (i.e., the amount was deduced from the player's coffers only whenever a vehicle passed the signal, or activated it, to simulate the fact that how often signals are used affects how many signalmen are needed to operate them at any one time, etc.), a realistic set of incentives to upgrade signalling on busy routes but not on quiet routes would be created.

Furthermore or alternatively, a set of constraints could be added to signals, meaning that certain signals could only be used with certain types of track: this would prevent elderly sempahor signals being used with modern, high-speed track. One possible drawback to this approach is that it might be difficult to code for the situation where track is upgraded with non-compliant signals in place; and how is the player to be told that that tile of track cannot be upgraded because it contains an older signal? An alternative would simply be to make the maintenance cost of the signals depend not just on the number of passing trains, but also on the underlying speed limit of the track, such that using elderly signals with high speed track would become prohibitively expensive.

Another possible option would be to alter the performance of the signals depending on parameters set in the signal's data file. For example, a signal could be set to allow trains to go only up to a maximum speed in any block controlled by that signal (to simulate the fact that trains must travel slowly enough to stop by the next signal if there are not, as there are with more modern signalling, multiple signals warning trains of the approach of a danger signal), and/or signals could be given a delay factor: a certain amount of time that elapses between the section ahead clearing and the signal giving a clear indication to a following train to simulate the inefficiencies of operating older types of signalling.

Finally, and on a rather more advanced level that is probably more of a long term aspiration, an entirely new kind of signalling system could be added to the existing fixed block system: a moving block system (see here for details). That system could be used by default for trams (which use signalling by sight at low speed: a very low-tech version of moving block signalling), but only be introduced later for railways, and require expensive signals to operate it (but would make the operation of a busy and/or high speed railway much more efficient).

I should be most interested in people's thoughts on these ideas, or any other ideas to add depth and interest to the progression of technology in railway signalling.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Combuijs

1) introducing maintainance cost for signal, thereby more or less forcing new signals to be placed later in the game

The day this is programmed, I quit playing Simutrans!!!! I like to play with big maps, but I hate to add all the signals every 10 tiles manually for a 300-tile double railway track. I have to do this now once, and that's hell. I won't do it every time a better signal comes up. For this to be used, you definitely need an automatic signal placer: place along the track from here to there this signal every n tile. I would appreciate it if you could build such a tool first.

2) allowance for signals only to be used on certain track types

The current signalling system is in my opinion reasonable simple to understand, but still causes a lot of problems for newbies (and not only for them!). Once in a while you get these eternal questions in the forum: "How do signals work", "what's this signal doing", "why is this signalling layout not doing what I want". To complicate it further is bound to cause a host of questions from desperate players, trying to understand why Simutrans is not behaving as they expect. So I think this suggestion is only acceptable if you put your telephone number on the info-dialog of a signal, telling players in need to phone that number 24 hours a day, 7 days a week in case of questions. I predict you won't get any sleep...  :D

Bob Marley: No woman, no cry

Programmer: No user, no bugs



jamespetts

I take the point about no. 2 - that might make things a little difficult. As to no. 1, I am just thinking of how the interface for an automatic signal replacement tool would work. Perhaps there would be an "upgrade" and an "upgrade all" button on the signal properties window, to upgrade the signal to the signal of that type with the retirement date furthest in the future, with the cost of each next to the buttons? I am wondering how easy or hard that that would be to code...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Combuijs

QuoteI am just thinking of how the interface for an automatic signal replacement tool would work

Info Dialog with additional "replace" and "replace all" buttons (maybe "replace on track", followed by start and end tile of track, but that might be very difficult to program), and a button for every possible signal that can be used as an replacement, together acting as radio-button.

I see two, perhaps three problems:
1) How to prevent replacing normal signals by for instance choose signals?
2) The dialog-systems of Simutrans are not very ease to understand as far as I know. I read once that there are 3 different systems, all with their own pecularities.
3) I don't know if it's difficult to draw buttons with every possible signal. As an alternative a list of names to choose from can be given.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Fabio

Quote from: Combuijs on January 05, 2009, 01:19:13 PM
you definitely need an automatic signal placer: place along the track from here to there this signal every n tile. I would appreciate it if you could build such a tool first.

this would be definitely GREAT!
i suggest something like a BLOCK_START and a BLOCK_END signals. starting from BLOCK_START, the procedure places automatically a signal every n tiles (n being set by the player in BLOCK_START properties) till BLOCK_END. If a juction is found in between, the BLOCK_END signal is not placed.

BLOCK_START -> BLOCK_END gives the direction of the signals. the automated signals cannot be removed. all the other signals can be freely placed. if you remove either BLOCK_START or BLOCK_END signals, the other is removed too, with all the automatic ones in between. you can change n and the automatic signals are deleted and placed back at the n distance. this, in a way, would fake alse the moving block system quite well.

prissi

PRogramming a signal place every x tiles is very simple. It would be like a very little modified electrify tool, which the only change to avoid signals directly on switches or crossings.

Other than that most pak including the default pak64 has only a single signal. That is enough imho and further signals only confuse new players. Even now we have maybe too many signals ...

jamespetts

#6
There is another way of dealing with upgrades that does not involve automated signal placing: I will address that in a separate thread (Edit: thread here). However, I do not think that having more than one generation of signal is realistically going to be excessively confusing. Of course it is open to pakset authors (both now and in the suggested way of doing things) to make things ultra-simple and have only one type of signal for all times, but it is also open to pakset authors to have signals evolving over time. It is an ordinary and basic incident of railway operation, and is likely to be confusing and/or disappointing for players to find out that there is only one sort of signal, or that, whilst there are multiple sorts of signal, and that later signals emerge later in the timeline, there is no difference between them and earlier signals.

Pak128 has at least three generations of signals, and it is very confusing that they are all functionally identical. Different players have different preferences: some prefer simplicity, others greater depth. Different playing styles can readily be accommodated by the basic code having scope for the maximum level of depth, and pakset authors and/or players having the chance to choose the extent to which they make use of that depth.

I think that too much is often made of things being confusing for new players. The reality is that many of the features that Simutrans already has are confusing for new players. In some cases, the lack of depth and/or realism is confusing for new players. Any simulation game that has sufficient depth to be interesting and engaging for more than a short time will have some aspects that are confusing to new players. The best way of dealing with such confusion is by making the depth intuitive, realistic, well-designed and well-documented, and perhaps also by making it optional. New players are not the only sort of players to consider: people are more likely to progress from being new players to experienced players if the simulation provides a greater level of depth.  Opportunities to add such depth, engaging with during a game which can be extremely satisfying, should not be shunned simply because of the background possibility that always exists when adding depth that some newer players might for a short time be confused by it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

#7
In reality, it's rather normal for train signals being used for many decades, far beyond the introduction time of their successors. The reason for their replacement is often the need for changed track layouts, requiring different signal functions or locations, or preparation for higher speed.

A simple method would be to automatically upgrade signals (to the current ones) whenever the signals are touched (changed), and also when the connected track is upgraded. A more complicated effort (programming-wise) would include the upgrade whenever the track layout is changed in a way that affects the signal (like in real life).

I don't think that (more) micro-management would add to the depth of Simutrans.

Edit: in Pak128, the signals of the different eras follow a certain scheme, so the function should always be apparent (often indicated by a board). However, People may not look at these small details, but be distracted and confused by the different looks. For Pak64, I would prefer if after a certain point in time, semaphores wouldn't be built at all any more.

jamespetts

Whoami,

I am not suggesting more micromanagement :-) See here for a suggested way of dealing with upgrades of all sorts in a way that makes for less micromanagement than is present now, whilst simultaneously allowing more depth.

I do realise that in many cases signals stay the same for decades, and often beyond their intended lifespan: that is deliberately taken into account in the original suggestion by incentivising the replacement of signals only where the track speed is upgraded, or where the signal is in a heavily used area, just as in reality. Automatically upgrading signals as you suggest would take control away from the player, and thus reduce the scope for interesting decisions about whether and when to upgrade certain parts of the signalling system.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

I wouldn't care so much whether a few signals are upgraded or not, without my personal order in every single case. But it's nice to have a more versatile appearance of the whole track network, although that makes it harder to understand for newbies (including those new to the pak set). However, I don't want to be forced to upgrade due to maintenance cost, so here I concur with Combuijs.

jamespetts

Whoami,

whether one is forced to upgrade would depend on the pakset authors' decisions as to how to author the assets and whether to provide more than one type of signal. However, Combuijs's reason for not wanting to be forced to upgrade elderly 19th century semaphore signals on a 21st century 400kph high speed railway line was that he abhorred the prospect of replacing each one individually (which is understandable). Is that your reason, too? If so, is it not addressed by this suggestion? If not, I am a little confused; why would you be happy to have to replace elderly track because it will not allow trains to go very fast, but not be happy to replace elderly signals for either the same reason, or because they cost too much to maintain? Or is your objection only to the part of the suggestion where signals cost more to maintain the higher the speed limit of the track?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Lmallet

Does anyone remember how TTD replaced signals?  Did they self-replace when a new signal was available?

VS

IIRC there was only one version, or they all changed automatically at some date. I remember well my great amazement that Simu had different signals for electrified track :D

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Roads

While I have no problem with automation of things that are tedious, I much prefer an option to turn automation off.

I have no problem with incentivising upgrades if there is no penalty for not upgrading.  Forcing an upgrade to anything in the game may be adding depth but what does depth mean?  Does it automatically mean more fun?  No.  It merely means there are more things to do.  Those things may or may not be fun, they may actually be tedious work.

To me, anytime anything is added to the game, there needs to be a reward for doing it and no penalty for not doing it unless it is something absolutely essential like having a road for vehicles to travel on.  I think there are a few of us who like old fashioned looking systems, trains, stations, etc.  Might I suggest all these upgrade suggestions work toward some sort of choice in transportation systems where the player can build either a sleek new transportation system or choose to maintain an old fashioned system that is perhaps more esthetically pleasing to some of us but somewhat less profitable?

jamespetts

Roads,

interesting points. Is the penalty to which you are referring (and that you dislike) the suggestion that the maintenance cost of signals be increased with the speed limit of the underlying track? That seems to be the least popular of all the ideas. Would you be happy if the incentive to upgrade was that signals carried with them a maximum speed (so that trains in their block section could not exceed that speed), so that upgrading them allowed for faster trains, but that players were not penalised for having older ones (other than not being able to use the latest, fastest trains)?

What do you think to the suggestion that the maintenance cost of signals be based on the number of trains that use them, rather than a fixed monthly cost, in much the same way as the maintenance cost of vehicles is based on how far that they go (so that stationary vehicles cost nothing to maintain, whereas ones that constantly keep moving cost a great deal to maintain)?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roads

Yes JamesPetts I do like the idea of costs for signals being only associated with faster trains.  This would not only allow us slow pokies to go our merry way but possibly be something of a money sink for the faster crowd.  That's you BTW. :)

As I have said before I do not think games should necessarily be based on reality but it does jerk me out of the game if something is jarring.  I believe a fixed monthly cost for signals is more believable than having it based on the number of trains that use signals.  Again though, I have to point out that I see no reward for this, only a penalty for using trains instead of vehicles.


jamespetts

Roads,

I am not sure that I quite understand your last sentence - the reward is occasioned by buying better signals later in the game that have a lower maintenance cost, which would then be cheaper in heavy traffic than earlier signals. Having signals cost more to maintain depending on the number of passing trains is realistic, since the actual use of the equipment is higher if there are more trains, and more signalmen would need to be employed to keep track of them all.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

The fact, that signals update automatically, when the track is electrified is not considered as enough eye candy? As time progresses more and more tracks are updated and thus more and more signals are modernized. (In reality this also was done together.)

jamespetts

#18
Prissi,

the suggestion is not merely aesthetic - the idea is to add realism and interest to network design, as stated in the original post. Why should newer signals (in those paksets, such as Pak128, that define newer and older types of signal) function in exactly the same way as older signals? That is confusing and disappointing for players.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roads

OK, JamesPetts I see I did not fully grasp all of the concept you are proposing.  I can see a requirement for strategic thinking in your idea.  Correct me if I'm wrong but the idea is to determine whether to upgrade and improve maintenance costs and if those maintenance costs would be less than keeping the old equipment?  And this being based only on the number of trains using the equipment in excess of x number?

If this is the case, it is a bit complex - I kinda like it.  It is good to have the option to take a chance on trying something.  The only downside I see is if the reward is money and you have plenty of money at that stage in the game...on the other hand, I can't think of any other possible reward.  Maybe a plaque to hang in your office that says Most up-to-date signaling network?

Lmallet

Quote from: jamespetts on January 05, 2009, 09:24:26 PM
Why should newer signals (...) function in exactly the same way as older signals? That is confusing and disappointing for players.

Sorry, I don't understand this part.  Signals in Simutrans only have two aspects: stop (under certain conditions) and go (under certain conditions).  Are you thinking of something like track speed signals?  

On another note, path based signaling means you can get away without signals in many cases (ie. at stations).  How would that work?

On charging more for a signal for high speed lines: I was reading about the French TGV.  They don't uses trackside signals at all, but cab signals exclusively.   After all, it is hard to notice a colored dot at 300 km/h :)

prissi

On another side note: Signals function the same since their dawn. All the images of the old signals are translated 1 to 1 to newer signals. The only exceptions are the new type of multiple block signals (i.e. the pre-signals) or rather look ahead singals.

And as said: Newer track have very few signals (usually just as backup in emergencies). On those tracks continious signalling or the very complex ETS (European Train Control, which is rahter 5 national system in one) or just mobile with GPS (shudder) is used, the latter in conjunction with normal signals.

jamespetts

Roads,

yes, indeed, the idea is to reward strategic thinking, and also for players playing the game just to maximise their success in the game make decisions that are as close as possible to the decisions that would be taken by a player trying to make the network seem as realistic as possible, so that realistic networks emerge, as if by magic, simply from players trying to do their best. In reality, there are lots of places (in the UK - I do not know so much about railway networks in other countries) where very old semaphore signals are still used; but they are places where the number of trains passing is low, and the speeds are moderately low, and where it would therefore be uneconomic to replace them all with modern signalling because the benefits would be marginal.

The idea is that the player has to make similar decisions, such as, "now that these new signals are available, are there any places on my network that could benefit from them? Can I afford them everywhere, or only in some places? Should I put them in on one or two major routes now, and see how it goes? What if an even better set of signals become available in another ten years' time? Does the traffic on this route warrant upgrading all the signalling? What if the traffic increases in a few years? What if it decreases?". Those are all interesting decisions for a player to make, the whole point of a game in the first place being to put the player in the position of making interesting decisions.

Incidentally, I had not thought of it in terms of "number of trains in excess of X", but that might be a good way of doing it: to have a base maintenance cost, and then add to that if the traffic exceeds a particular amount (say one or two trains per game month). On the other hand, if no trains are using the signals at all, then the signalmen do not need to be employed at all, so there is some justification for having it simply based on the number of actual trains - and it would be easier to code, too.

As to the reward - if the signal's performance was affected by how new or old that it is (if there was, as is suggested, a delay in resetting the signal for older types, or a speed limit for trains controlled by that signal), then the performance of the network and its capacity would be affected by the signalling. There are some people who play just to get the best transportation network that they can, without thinking about money (often playing in freeplay mode), and this would be a reward for them. In terms of maintenance costs, the rewards would indeed be purely financial. As to having more money than one knows what to do with in the later game - I consider that to be a game balancing problem that needs to be solved, and some of my other patches are working towards solving it. Saving money should be a reward in the later game as much as it is in the earlier game.

Lmallett,

some of the ideas in the first post were to add function to signals, for example, to give signals an associated speed limit (not speed signals, but a maximum speed that trains can travel while under the control of that signal: in reality, higher speed running requires more sophisticated signalling for trains to work safely). Later signals would then have a higher speed limit. Another idea was to give signals a small delay between the time that the section ahead becomes clear and the signal clears to allow any waiting train to pass. If that was made less and less for later signals, there would be a good reason to upgrade.

Good point about the stations - the easiest way of coding it would be simply to assume that stations always have the latest signalling and not give them any delay or speed limit at all. A more sophisticated approach (but one almost certainly far harder to code) would be to make stations take their signalling performance from the next signal in the block, or to have signalling performance built into the station type.

As to the TGV  and the other high-speed rail networks to which Prissi referred - see above on the long-term future wish-list of moving block signalling, which would accurately simulate that, too...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.