Passengers and infrequent services

[Banksie_82]

Just coming back to a point Ves briefly touched on, and moving slightly off topic (is it worth splitting?). In reality, for infrequent services, passengers don't just turn up to a station and wait for the next ride... they check the timetable.

I understand that this is a complex issue for Simutrans, but could there be an easy work around?

My thoughts aren't fully developed, so consider this 'thinking out loud'.

How about passengers, when looking for a destination and considering their journey time, ignore the waiting time of the stop with the longest time (or apply a nominal 5mins)?

Basically, they plan their journey so they're not waiting for the infrequent regional train or international ship. In terms of game play, they would still be waiting at the stop, but it wouldn't be considered in their routing.

Maybe this rule only applies if it's the first stop on the itinerary? Or, if it's the second, then you could apply the waiting time for the first stop to the second, trying to account for timetables and frequencies not lining up and the passenger needing to leave a bit of a buffer?

If it's the third or later, then a minimum of the actual waiting time for that stop or the sum of all the waiting times before it?

The only problem I can see is if a station becomes too crowded, then it becomes even more desirable for a passenger to travel through it, as it's more likely to discount the waiting time at the stop. I don't know yet how you would prevent this.

What do others think?

[jamespetts]

Thank you for your thoughts. This is indeed a different topic, so I have split it from the "How to catch commuters" thread.

The issue of timetables and waiting times has occupied my thoughts on more than one occasion. The trouble is that this issue is fundamentally very difficult to deal with because of the way in which the routing works (and the routing has to work like this to stop the game from being unplayably unresponsive on larger maps).

The routing of passengers, mail and goods works by calculating the total route from each stop to each other stop, together with the total journey time, all at once, using the Floyd-Warshall algorithm. First, a set of links between stops are constructed (with data as to their journey time, including travelling and waiting time). Then, the Floyd-Warshall algorithm is used to calculate the shortest overall journey time between all points using those links. Having a different waiting time depending on how long that the waiting times at other stops are is not possible within this system. Moreover, this system was written some years ago by a coder, now retired from Simutrans, who is much more talented than I, and I have only been able to make relatively minor modifications to this code.

As well as technical difficulties, there are also conceptual difficulties with this. What is proposed would mean that the local 'bus line with a 2 hour interval is no worse than a local 'bus line with a 10 minute interval for passengers who only ever take the local 'bus and do not change to another form of transport with a shorter waiting time. It also means that a given transport link (e.g., a once every 4 hour train) would fluctuate enormously as to whether the infrequency is an issue depending on whether (adventitiously) any given set of passengers happen to be taking somewhere in their route another transport service with an even longer waiting time. This would cause anomalies and perverse behaviour.

The only possible solution that I have thought of (having considered this issue in great detail many times) is to replace the cached system of routing with fully dynamic passenger routing, where each packet of passengers calculates the route on the fly when generated, taking into account actual estimated waiting times, and can decide when to travel based on what departure time within a limited window in the future will make the travel time the shortest. Unfortunately, this would require much more powerful computers than are common now (adding more processor cores would suffice, so long as memory bandwidth would scale with the cores - I estimate, very approximately, that 16-64 cores would be needed for this on a huge map). It would also require a very large programming effort (circa 1 year of coding, including bug fixes).

[Banksie_82]

Wow James,

You have obviously put a fair amount of thought into this already, and that alone is good enough for me to understand that the solution is beyond immediate reach.

The problem still persists, that while in reality some transport routes may only run once or twice a day, or even less for long ship journeys, in Simutrans this is just not feasible due to the waiting time.

The increase in journey time tolerance, as discussed in the "How to Catch Commuters" thread, has its own merits, but it also has it's limits when applied to the above.

Have any other players found a way to make very infrequent services work in a game?

[Jando]

Interesting discussion, thanks for bringing it back!

I had raised the problem before, although problem is perhaps too strong a word. Overall I think that the system designed by James works very well, just with two exceptions:

• 
  Small villages/destinations. Players can run into a situation where to get passengers at all requires more frequent service - but the number of passengers you get won't be enough to make this frequent service profitable.
  
• 
  Frequency rules. Instead of using the infrequent but fast train passengers will pick the slow but frequently scheduled bus line that stops at 20 villages on the route. 
  

Ad 1: I'd say let the player eat the loss from a line serving small destinations. Real life passenger transport does that as well.
Ad 2: No idea whether feasible and what the workload would be: consider ignoring the longest waiting time on multi-stop itineraries. in reality passengers do the same, they just show up on time for the fast train or the ship to another island or continent.

[jamespetts]

Problem no. 1 is the one that is very difficult, if not impossible, to address within current constraints. No. 2 should be addressed partly by existing code: although the passengers arrive at the starting station effectively at random, if, when the slow train arrives, the passengers calculate that the fast train will get them to their destination more quickly, they will wait and take that instead. They will not, however, time their arrival to take the fast train.

As to Jando's suggestion to resolve no. 2, this is identical to Banksie_82's suggestion in the original post, and is not feasible for the reasons already given.

[zook2]

I guess one of the problems is that we need the same system to work with twice-a-week-if-you're-lucky stagecoaches in 1750 as well as passengers waiting to board the Concorde, where getting to Heathrow and checking in might take longer than the actual flight to NYC. Hopping on the bus to the dentist in 2017 as well as waiting for the slow boat to China in 1850. Any idea to make the system more realistic needs to take all these into account. Unless it does, it might improve one of these cases but cause problems with others.

[jamespetts]

Indeed. The only sensible way of taking into account all cases like this is to simulate the underlying mechanic as accurately as possible, which is likely to require, for larger maps, computational power beyond that currently widely available.