Version 2.0 - Look to the Future

[keoz]

I am so happy OpenTTD does not aim for realism!!

Obviously OpenTTD cannot be aiming exclusively for realism, because it's still a game and need to be playable.

But OpenTTD also includes some degree of realism. It uses trains, buses, trucks, ships, inspired from real world. So, for me, the question is not (and should not be) if OpenTTD must or not aim for realism, but more, at what degree of realism should it/can it pretend. The answer to the realism question is not binary.

[joshua peli]

I really love Open TTD. And, seriously, I think it's the best of his genre!
But I would really love a couple of cool new stuff. This is a list based on my thoughts while playing (and I'm happy there is already someone that has already purposed some of them):
> the possibility to COUPLE and UNCOUPLE cars. This would be possible separating the "engines" names and orders from "cars" ones.
For example: I have Train 1 going from A to B passing through E. And I have another train (Train 2) passing from C to D through E.
I have 5 copper ore cars (we can call them 01,02,03,04,05) that have to be moved from A to D. I build these cars in the depot A. Train 1 is ordered to couple 01,02,03,04,05 in depot A, arrive in depot E and uncouple them and then continue his journey to B. Train 2 is ordered to couple these cars (and wait them if they're not already available) and bring them to D.
Another cool example would be the possibility to use an electric train from A to B (a very important line) and then couple a diesel engine to this train to finish the journey on a branch diesel line to C.
> the possibility to regulate ticket prices and contracts with industries (there is a default one, but you can change them )
> new type of orders.
For example: stop Train 1 at platform 1 at station 1 and wait Train 15 if Train 15 has already left station 0.
This would be great if you want i.e. a fast passenger train to overtake a goods train.
> the possibility to use others' rails (like in Railroad Tycoon): when you "send" a train, the competitor can change some particular orders (like waiting for another train).
> yellow light at signals. When you put signals (for example a signal each 10 tiles), another signal is post each 5 tiles: if this signal shows yellow light, train starts to decrease its speed until stopping or the next signal becoming green. This feature will give a lot of realism
> last but not least: changing the time system. I think it would be cool to have a sort of "SimCity 5" clock: you have hours and minutes (we can say, for example, that a minute lasts 3 seconds), and a day is considered a month. So you have 12 days/year.
This feature would be awesome to regulate timetables

I hope you would consider these (in my opinion) beautiful features and that you will add them in future releases. Of course, these features will require a lot of time and trials, but if you apply these, OPEN TTD would be the best transportation game EVER!

[kamnet]

the possibility to COUPLE and UNCOUPLE cars.

This may be possible. At one point somebody had written a patch that accomplished this, but changes in OpenTTD's source code broke it and the author ceased working on it. No patch was ever published publicly for it.

Another cool example would be the possibility to use an electric train and then couple a diesel engine to this train to finish the journey

This is already possible with the Universal Engine NewGRF.

the possibility to regulate ticket prices and contracts with industries (there is a default one, but you can change them )

This would probably fall under "Too much work for not enough benefit" to try to build that directly into OpenTTD. But this is already accomplished via NewGRFs. Industry sets can do just that.

new type of orders. For example: stop Train 1 at platform 1 at station 1 and wait Train 15 if Train 15 has already left station 0.
This would be great if you want i.e. a fast passenger train to overtake a goods train.

If this is what you wanted to accomplish then this only works if you have those two trains on an isolated network. If you throw in more trains you get more issues. This is better accomplished by using timetables and segregating passenger routes from goods routes whenever possible.

the possibility to use others' rails

The Infrastructure Sharing patch addresses most of this, but it still has some issues with bugs and how costs are shared and distributed.

yellow light at signals. When you put signals (for example a signal each 10 tiles), another signal is post each 5 tiles: if this signal shows yellow light, train starts to decrease its speed until stopping or the next signal becoming green. This feature will give a lot of realism

And the mention of "realism" in this aspect will likely kill any interest in getting it developed at all. While developing such a feature would definitely enhance the "ooh" and "aah" factor, the first thing you have to ask with any change is "how does this improve the game play?" Since it doesn't actually matter if trains slow down or come to a screeching halt, then you have to ask why is this necessary. The only reason this becomes necessary is if you reprogram OpenTTD to have consequences if trains do not properly slow down to a halt. While that will increase the challenge for some, more than likely for most players it will completely frustrate them since all they want to do is move stuff from A to B and make profit. Unless this system is implemented as an advanced configuration option that is disabled by default, this will probably never fly.

last but not least: changing the time system.

There are several iterations of the Daylength patch, but all of them have one glitch or another and can cause desyncs in multiplayer games. I say that more than likely this patch will eventually make it into OpenTTD, but probably not for a long time as its not very high on anybody's list to implement.

[Eddi]

the first thing you have to ask with any change is "how does this improve the game play?"

the benefit is pretty obvious. a faster train stuck behind a slower train doesn't fall into a stop-and-go trap, but instead adjusts speed roughly to the speed of the leading train, which causes overall smoother operation on busy lines.

it may also provide another approach to "priority lines"

[Alberth]

the first thing you have to ask with any change is "how does this improve the game play?"

the benefit is pretty obvious. a faster train stuck behind a slower train doesn't fall into a stop-and-go trap, but instead adjusts speed roughly to the speed of the leading train, which causes overall smoother operation on busy lines.

The entire yellow signaling thing looks like a red herring. As far as I can see, there is no actual need to change the signals at all, the only goal you need to accomplish is that the second train arrives at the signal not before the moment that the first train has left the block.

There is however a whole array of smart path finder tricks, and path signals to negotiate

[Kevo00]

I actually think yellow signal riding would be a great addition to the game - it would moderate a lot of the stop-start train behaviour at the moment.

[MarkyT]

I actually think yellow signal riding would be a great addition to the game - it would moderate a lot of the stop-start train behaviour at the moment.

Good thinking, but to cater for the variable signal spacing that people use, I don't think you actually need yellow signals or a fixed minimum signal spacing like real railways, just a way for following trains to space themselves out so they always have enough room to stop gradually like at stations regardless of signal spacing, and a means to set reserved paths through junction conflicts earlier for faster/higher priority trains, so the secondary trains slow down and give way automatically. Incidently this would remove the advantage of providing very closely spaced signals across entire networks, where with today's game lengthy trains can be following each other at full speed only two squares apart!