News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Possible mechanic for allowing limited comfort competition - long term

Started by jamespetts, January 01, 2018, 01:34:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

I had previously thought that it would not be feasible to have any means of allowing competition between players on the ground of passenger comfort without full dynamic routing (which would require very high core counts (by 2018 standards) to become widespread). However, I have recently hit upon a possible way of allowing for at least some limited competition between different passenger routes on the ground of comfort that may well be within what modern computers can sensibly cope with without producing anomalies or gameplay imbalances.

I should note that this would involve some considerable amount of work, similar in magnitude to the passenger and mail classes feature, albeit without the GUI or pakset work, and I estimate that it would take 4-6 months to complete (including bug fixing). Being a lower priority than price balancing (and probably lower also than town growth/generation reworking), it might be a considerable time before work can begin on this feature.

I thought that it would be worthwhile to post the outlines of the design here lest I forget what I had imagined, and also so that anyone might comment to spot any inherent flaws in the system that I have not yet found.

If this system does work as intended, the benefit might be considerable: comfort was in reality (as I am increasingly discovering in my research to implement the passenger and mail classes feature into the pakset) an important driver of competition between modes of transport, and it was the ability for comfort to draw passengers from one service to another that gave the main incentive for transport companies to improve the comfort of their services. This explains why third class passengers on railways went from a minimal "Parliamentary" carriage with no windows or lights and hard wooden seats in the 1840s to comfortable corridor compartments with soft cushions, lighting and heating by the 1910s.

The basic design of the mechanism is this: passengers would, at generation, be assigned to one of two categories for comfort purposes: speed priority or balanced. Speed priority passengers would, as all passengers currently do, prefer the fastest route no matter what the comfort. Balanced passengers would use a blended routing algorithm (on which more below) to combine comfort and speed in their preferences. The speed preference classification would be separate to the current class/wealth system. Thus, a passenger might be of high wealth with speed priority, high wealth balanced, very low wealth speed priority, etc.. It should be possible to add this additional datum without increasing the memory footprint of passengers by astute use of existing fields (e.g. for comfort preference for class purposes), although I have not looked into this fully.

As with the current passenger and mail classes system, the routing algorithm would run once for each comfort preference for each class, so, with 5 classes, the routing algorithm would run 10 times for passengers. Each comfort preference/class would have its own optimum route from each origin to each destination: a high wealth speed priority passenger would have a different route stored to a high wealth balanced passenger, both of which would be different to a medium wealth speed priority passenger, etc.. The routes between any given pair of points might in fact be the same (e.g. if the fastest route is also the most comfortable, or rather, the route with the lowest combined comfort/speed cost, as discussed below), but would be stored independently.

Having only two defined strategies for routing should keep the computational effort required within reasonable bounds (although I am not sure whether doubling the amount of work necessary for passenger routing might cause difficulties in the time that it takes routing data to refresh; some investigation in allowing more route computation per step might be necessary, but this might adversely impact performance on computers with lower core counts or core speeds). These two different strategies should hopefully also be sufficient to eliminate anomalies that would arise from just using the balanced strategy (which anomalies are one of the reasons that I rejected this sort of thing in the past). Thus, there will always be at least some passengers willing to use the fastest route, just as there would be in reality. The proportion of passengers randomised to prefer comfort or speed should be configurable in simuconf.tab.

The blended route cost algorithm is the next important part of this model: this determines a single optimum route for passengers who are randomised to the balanced strategy from each stop to each other stop. The current system uses the Floyd-Warshall algorithm and calculates each route on the basis of the lowest cost of that route, the cost being expressed in total time (that is, travelling time plus waiting time plus stop transfer time plus walking time for each leg of the journey). The system was written by a talented coder who has now retired from Simutrans development, so any alteration to this algorithm needs to be peripheral rather than to the fundamentals of how it works.

The idea is to calculate, in addition to the time cost, a comfort cost for each leg of the journey, and then add this to the time cost to produce a blended value. The route with the lowest total cost will thus be chosen by the blended algorithm, using the same fundamental mechanism as is now used: the only part that would need modifying is the function that returns the cost, which is separate from the main routing algorithm itself.

How to calculate this comfort cost is not entirely straightforward. One possibility is to use positive and negative values depending on whether the comfort for any given journey leg is more or less than the minimum for a comfortable journey given the journey time involved, with 0 being used if it is identical. In the simplest version of this, the two figures would simply be added together; thus, if the journey time for a given leg of the journey were 60 minutes, and the maximum comfortable journey time of the journey leg were 30 minutes, the total cost of that journey leg would be 90 (being 60 minutes, plus 30 minutes over the comfort threshold). Similarly, if a given leg of the journey were 60 minutes and the maximum comfortable journey time of the leg were 180 minutes, the total cost would be -60.

However, using negative numbers is likely to be problematic (the current times are all denominated in unsigned integers, and I am not sure that the Floyd-Warshall algorithm can even handle negative numbers), and this would in any event give too high a weighting to comfort, so a more subtle algorithm is likely to have to be devised, one in which the effect from comfort is proportionately less (perhaps divided by a number set in simuconf.tab, and divided by a different number for higher than 0 than lower than 0 comfort cost to allow making avoiding discomfort more important in passengers' routing choices than attaining luxury), and one in which the overall effect is capped so as not to make the cost of any given leg more than a certain number of times the time only cost, or less than a certain fraction of the time only cost (again, both values might be specified in simuconf.tab).

The important thing about this design is that a single figure for a blended time/comfort cost is calculated at the early stage of computing all the possible individual journey legs, before the much larger task of calculating from all those journey legs all the possible routes is performed, as computing the blend of comfort/journey time at that stage is likely to be too computationally intensive for reasonable performance on very large maps.

The data structures will require some consideration: already, there is a dynamic array of hashtables for each of the classes; it may be necessary to make this a multi-dimensional array, with the first dimension being a static array with a fixed size of two.

It might also be possible to assign comfort values to stops in the same way as vehicles, and have passengers using the balanced strategy equally take into account these comfort values in the same way as with vehicles (using, instead of the journey time, the transfer time plus waiting time to calculate the maximum comfortable time at the stop).

One might also have a minimum comfort threshold: comfort for a stop or journey leg so low relative to the stop or travelling time that no passengers will ever use it (imagine a service requiring one to stand in an open railway wagon with no food, water or sanitation for a journey lasting 48 hours, for example, or requiring one to wait 36 hours at a 'bus stop for a connexion).

These mechanics may well help to give comfort a more realistic degree of prominence in the game, and give players greater (but realistic) incentives to build more comfortable vehicles (and possibly also stops). I should be interested in any thoughtful feedback before I add this to the list of outstanding features in case I have missed anything important.
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.