Passenger Satisfaction

[zook2]

I'm coming back to Simutrans about once a year, and I enjoy it very much. Also, in my opinion your SimEx branch with its alternative method of passenger generation is superior to vanilla Simutrans.

That being said, I think there's a problem that should be addressed. What's the opposite of "intuitive"?

I ran into the problem described here (waiting times so high that nobody travelled on that route any more which meant that improvements to service weren't registered):
http://forum.simutrans.com/index.php?topic=12144.0
which resulted in my network losing more and more passengers and bleeding money. Now, like I said, I've played Simutrans and SimEx several times over the years and I don't consider myself a newbie, but with the long pauses between games (and versions), I forget about the details. It took me hours to figure out what probably caused my problems and I had to carefully read the various forum posts and FAQs about SimEx features and, most importantly, the annotations in the config file to get a clue about how things work.

What might have helped a lot would be a tab that displays "Passenger Satisfaction" (or "Route Reputation") somewhere:

----------------------------------
Line Bumborough Express
Length of Trip: 12.33 km (local/medium/long)
Passenger Satisfaction

Waiting Time: 4% (abysmal)
Travel Time: 78% (good)
Comfort: 65% (avg. level 52 - OK for local trips)
Overall judgement: somebody ought to be fired. 
----------------------------------

That tab could function both as a tool to quickly judge service quality and explain what factors are important to passengers in the first place, thus making the game much more newbie-friendly.

What do you think?

[jamespetts]

This an interesting idea, but it should be noted that the distinction between short, medium and long distance passengers is about to be abolished in the next major release of Experimental, which should make problems with passengers not using routes because of excessive waiting times easier to handle.

I generally tend to prefer not to generate metrics that do not represent some specific data that would actually exist in the real world, such as waiting times or travelling times, as doing so adds economic dynamics that do not exist in real life, making things harder to understand and model accurately. In your example, what would these percentages be percentages of, exactly, and how would we know what percentages are good, mediocre, and poor? The difficulty is that there is no universal and general standard for what level of comfort or journey time makes the service "good" or "abysmal": these things vary over time, with the distance to be travelled, and, with journey times, depends to a large extent on the competition. Players might also expect that these percentages would of themselves have some specific effect in the game, but there is no way of doing that without making it less realistic.

However, as indicated above, a change which I have already coded and will be present in the next major release (which is waiting for further work on town growth before it is ready) should deal with the original issue relating to it being difficult to find passengers willing to travel short to medium distances in the early eras (before steam trains) by abolishing the distance ranges entirely. The issue with high waiting times deterring future passengers, preventing lower waiting times from registering is dealt with by the mechanism of slowly making old waiting times stale.

[zook2]

But even without fixed distance ranges you'd still have to calculate acceptable travel and waiting time, right?
(I assume it's the tolerance time in the current implementation:
min_midrange_tolerance = 5
max_midrange_tolerance = 240
etc.)

If the new, dynamically calculated, acceptable time for distance X is between 20 and 160 minutes, the average being 90 min., then an actual rating of 120 min. would be 133% of average acceptable time, with 177% being the maximum. Call anything above 150% "abysmal" and anything above 125% "bad". Or just display a scale between 20 and 160 and an "X" at the 120 min. mark, then let the player decide whether it's good enough. At least the game would point out that there is a lot of room for improvement in that line.

The difficulty is that there is no universal and general standard for what level of comfort or journey time makes the service "good" or "abysmal"

By defining these tolerance constants you already defined a maximum of what is acceptable. Beyond that, traffic drops to zero. If that behavior is still desired for the nest version, there will still be a baseline from where to calculate these times.

My main point, though, is that these dependencies should be displayed somewhere in-game.

[Jando]

I believe that the Waiting Time feature is probably the least-liked change Experimental introduced to Simutrans. I also find it highly unrealistic because it makes low-frequency services almost impossible. The real world however knows quite a number of low-frequency services.

Zook2 in his post linked to an older thread about the issue where James said something I fully agree with:

Passenger transport in the very early days is difficult, as not many passengers are prepared to travel the very many hours that a stagecoach journey would take: this is how it was in real life. You should only be able to sustain one or two coaches travelling between any given set/pair of larger towns on a single route.

The problem however is that in Experimental a route that can only sustain one or two coaches will in practice sustain none - what little demand there is for slow travel on coaches (and ships) gets nullified by long waiting times due to low frequency.

In the real world demand for a service determines it's frequency - as witnessed by the fact that high frequency services reduce frequency during times of low demand (weekends, late in the evening, school holidays). In Experimental it's the other way round: not demand determines frequency - but frequency determines demand.

[jamespetts]

But even without fixed distance ranges you'd still have to calculate acceptable travel and waiting time, right?
(I assume it's the tolerance time in the current implementation:
min_midrange_tolerance = 5
max_midrange_tolerance = 240
etc.)

If the new, dynamically calculated, acceptable time for distance X is between 20 and 160 minutes, the average being 90 min., then an actual rating of 120 min. would be 133% of average acceptable time, with 177% being the maximum. Call anything above 150% "abysmal" and anything above 125% "bad". Or just display a scale between 20 and 160 and an "X" at the 120 min. mark, then let the player decide whether it's good enough. At least the game would point out that there is a lot of room for improvement in that line.
By defining these tolerance constants you already defined a maximum of what is acceptable. Beyond that, traffic drops to zero. If that behavior is still desired for the nest version, there will still be a baseline from where to calculate these times.

Ahh, but the new code will have a much, much broader range of times - anywhere between 5 minutes and about 36 hours; but it will be skewed towards the lower end of the scale. It will also vary depending on whether the passengers are on a commuting or a visiting trip (these are new concepts introduced with the passenger-generation branch on Github), with the commuting passengers having a narrower range of tolerances than visiting passengers. I am not quite sure how one would get a percentage out of that, much less what any such percentage could usefully represent. There would, especially in early days, be many long distances transport routes (stage coach journeys, sea voyages, etc.) which took so long that only a small proportion of passengers would be prepared to endure; yet, if they are the fastest journeys possible in the era, it cannot be right to call the service "abysmal" or "poor". That would give players the impression that they are doing something wrong, which would be incorrect.

As to Jando's point about waiting times: they are an important part of the simulation, especially for shorter distance routes. In real life, frequency does have a huge effect on demand on shorter distance routes: if your local 'bus with its 10 minute journey to the nearest town goes every 5 minutes, you would be far more likely to catch the 'bus to town than drive than if it only goes every 2 hours. The waiting times for a route really are part of passengers' journey times.

Three code changes should, however, reduce the problems that waiting times currently cause. Firstly, a change introduced in 11.14: passengers and goods will always be discarded (and claim a refund) if they have been waiting at a stop beyond a set limit (which limit is determined by a simuconf.tab setting). In recent versions of the pakset, this limit has been very high. However, until version 11.14, for passengers, this limit was subject to a further limit of thrice the passengers' journey time. In version 11.14, this secondary limit was removed, so that only the ultimate hard limit counts. The second, also introduced in 11.14, is 'bus queue loading: passengers (and also mail and goods) that arrive first at a stop are the first to load. This will only affect routes with overcrowded vehicles, but it will minimise waiting times on those routes. Thirdly, the abovementioned features on the passenger-generation branch, removing the distance ranges. This will have the effect that shorter distance journeys that nonetheless have a higher overall journey time (whether caused by waiting or otherwise) will still attract some passengers.

Waiting times are potentially difficult for longer routes because in real life, there are timetables, so that passengers can plan their journeys to minimise waiting times, at least at the first leg of their journeys which involves a low frequency service. Simutrans-Experimental does not have this capability, and, because of the way in which the fastest routes between places are calculated periodically then stored (which is necessary to make the game run at an acceptable speed), the waiting times that passengers will encounter on a particular journey cannot be calculated on the fly depending on when the next service is scheduled to arrive. There was a time when waiting times were all halved from their actual values to take into account the fact that there are timetables in real life, but this was removed at the request of others because it gave rise to unrealistic outcomes (especially in short distance transport) and was arbitrary. Waiting times cannot be dispensed with, however, as they are necessarily an integral part of any overall journey time. The issue can be reviewed after the next major release, when we should have a clearer idea of the impact of the passenger-generation code and the abolition of distance ranges on the impact of waiting times.