News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Balance discussion: revenue (air travel, classes, speed bonus, comfort)

Started by jamespetts, April 11, 2017, 01:25:39 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Some exploration of the path explorer and preliminary testing yesterday evening appears to show that it is likely that path exploring for multiple classes of passengers is feasible on large maps within reasonable limits of computational intensity and time to complete.

Edit: I should note that I have now made a start at implementing this feature in the passenger-and-mail-classes branch on Github, although it is still very incomplete at present.
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.

jamespetts

As an update: work is apace on implementing this on the passenger-and-mail classes branch: any intrepid self-compilers are welcome to test this, but the UI is incomplete and saved game compatibility cannot be guaranteed (the saved games are not backwards compatible with the current master branch).

I have implemented (just now) the separation of private car ownership percentages by class. It is very hard to find data for this separated by income quintiles going back before the 1990s, so I have had to do much guessing.

I have used income quintiles for the first three classes, then averaged the income quintiles for the fourth class and set very high figures in all eras for the fifth and highest class on the basis that, as discussed above, at least in the higher classes, these are not intended to represent income quintiles (as far less than 20% of the population can afford to travel in first class on airlines, for example).

Here is the updated privatecar.tab from Pak128.Britain-Ex (notice the new format):


# Private car ownership over different years. The numbers other than years are
# percentages, and should be integers (i.e., no decimal point).
#
# Source of data (1951 onwards): http://webarchive.nationalarchives.gov.uk/20091009084502/http://www.dft.gov.uk/pgr/statistics/datatablespublications/tsgb/2008edition/sectionninevehicles.pdf
# See also http://www.racfoundation.org/assets/rac_foundation/content/downloadables/low_income_motoring-bayliss-280909.pdf
# This website has good modern data, but only two data points: https://www.ucl.ac.uk/transport-institute/pdfs/transport-poverty
#
# Figures before 1951 and after 2012 are educated guesses. Data are for the UK:
# other countries might vary.
#
# This is indexed by passenger class (as of July 2017). 0 is the lowest and 4 the highest. Much of the quintile data are extrapolated as accurate data are hard to find,
# especially for the higher income qunitiles. Note that the classes are not intended to represent actual income qunitiles, especially the highest classes.
#
# Author: James E. Petts (jamespetts)

car_ownership[0]=1750,0,1945,0,1955,2,1960,5,1965,7,1973,10,1980,18,1983,20,1992,30,1995,34,2002,40,2005,43,2012,52
car_ownership[1]=1750,0,1945,0,1955,5,1960,10,1970,18,1976,23,1980,30,1985,41,1989,48,1995,53,2003,60,2012,65
car_ownership[2]=1750,0,1906,0,1935,3,1945,5,1951,21,1955,25,1960,36,1966,45,1995,80,2012,80
car_ownership[3]=1750,1,1800,2,1850,3,1880,4,1890,5,1898,6,1906,10,1920,20,1935,33,1945,40,1950,60,1958,70,1980,85,1995,90,2012,88
car_ownership[4]=1750,95,2000,99,2050,98

# These are the original general figures, not distinguished by income quintile
# 1750,1,1906,3,1935,6,1945,7,1951,14,1955,20,1958,26,1960,29,1963,36,1966,45,1968,49,1971,52,1974,55,1977,57,1980,59,1983,61,1986,62,1989,66,1993,69,1996,70,1999,72,2003,74,2006,76,2015,82


If anyone can find more detailed data, please let me know, as this would be very helpful.
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.

Kuk

Just my opinion:

1) You should not let the user assign passenger classes to vehicles.
2) There should not be a speed bonus. The revenue per passenger*travel_distance should be fixed for a given vehicle. If and how much profit a vehicle generates should only depend on usage.

Reason: It becomes too complex for the player.

I think:
1) The incentive for higher speed should be more passengers and less operating costs of vehicles (the staff gets paid the same no matter how fast the vehicle moves, faster vehicles become available at less extra cost in late-game, extra costs for faster tracks will be limited when there is a lot of traffic and they do not get wrecked by cargo traffic).
2) The incentive against air travel should be less "desirability" because of comfort and time spent to/from/at the airport.
3) There should not be a concept of "comfort" but rather "desirability": You split passengers into a few types depending on what they want and not not want. This can whether comfort/price ratio matches their wishes, but also e.g. how important it is that the vehicle is low-entry. Depending on whether the vehicle is a good or bad match the travel time spent in it is multiplied by a specified factor set in the pak, which effects both route selection and travel time limit. The type of passenger will also determine the speed of walking, the speed of changing vehicles and how long they will stay on a vehicle which does not have a(n accessible) toilet.

jamespetts

Welcome to the forum, and thank you for your contributions.

I should note that the coding for this feature is already largely complete, save for some bug fixing and GUI matters. The reason that it is necessary to allow players to change classes is that it would be absurd (and frustrating) if players were ever stuck with a vehicle with a high class that could not attract enough passengers to its route of the right class, but could be profitable if only it would allow lower classes of passenger to travel for a lower price.

The speed bonus will be abolished by this new code. Comfort, however, will remain: one of its most important functions will be to give higher class passengers an incentive to pay higher prices to travel in the more expensive classes of accommodation; if they are not more comfortable than (or not enough more comfortable than given the length of the journey) cheaper classes of accommodation, the wealthier passengers will just save their money and travel in the lower classes of accommodation, just as in reality.
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.

Kuk

Quote from: jamespetts on October 08, 2017, 10:32:25 AM
I should note that the coding for this feature is already largely complete, save for some bug fixing and GUI matters.

After I have seen the age of the thread I thought so...

Quote from: jamespetts on October 08, 2017, 10:32:25 AM
The reason that it is necessary to allow players to change classes is that it would be absurd (and frustrating) if players were ever stuck with a vehicle with a high class that could not attract enough passengers to its route of the right class, but could be profitable if only it would allow lower classes of passenger to travel for a lower price.

I am not sure about the feature to of adjusting the price. It might make sense to e.g. raise the price
- if you have lots to direct connections which cannot make a profit because their usage on part of the route is low
- if a long line is overcrowded on a small section where a good alternative exists
- if the network is overcrowded and you need money to extend it
- in multiplayer games depending on lines which have no competition

On the other side if you constantly need to make significant adjustments there is probably something wrong with the pak. I do not think it will be hard to balance tough. A default price that make a vehicle profitable if it is e.g. ~33% full should do it.

But most importantly it is not clear to me how assigning passenger classes to vehicles will help. The granularity sounds very low. I could allow all passengers to use high comfort vehicles, but then I make a loss even if the vehicles are full? Or if I have a network with lots of direct connections I assign the lowest vehicle class to medium class passengers and either leave the lowest class passengers without a route or build a second network?

Quote from: jamespetts on October 08, 2017, 10:32:25 AM
Comfort, however, will remain: one of its most important functions will be to give higher class passengers an incentive to pay higher prices to travel in the more expensive classes of accommodation; if they are not more comfortable than (or not enough more comfortable than given the length of the journey) cheaper classes of accommodation, the wealthier passengers will just save their money and travel in the lower classes of accommodation, just as in reality.

This is why I mentioned "desireability". The main difference would be that wealthier passengers would not only pay more but actually prefer to travel with high comfort+speed. And poor passengers will also use expensive means of travel, but will prefer other routes and hit the "travel time limit" sooner if the vehicles are too expensive.

jamespetts

Quote from: Kuk on October 08, 2017, 01:29:33 PM
I am not sure about the feature to of adjusting the price. It might make sense to e.g. raise the price
- if you have lots to direct connections which cannot make a profit because their usage on part of the route is low
- if a long line is overcrowded on a small section where a good alternative exists
- if the network is overcrowded and you need money to extend it
- in multiplayer games depending on lines which have no competition

On the other side if you constantly need to make significant adjustments there is probably something wrong with the pak. I do not think it will be hard to balance tough. A default price that make a vehicle profitable if it is e.g. ~33% full should do it.

I am not entirely sure that I follow this. What is it that you are not sure about? The system adjusts the class: it is not a direct adjustment of the price (unlike the system in, e.g., Cities in Motion 2).

The idea is not that one constantly adjusts the class: one would only adjust it if something were to change.

I should note that there is probably not a great deal to be gained by putting forward alternative suggestions for basic design elements of something that has already largely been implemented unless it is clear that the thing that has been implemented is a failure: the time that we have to code these features is very limited as there are very few people working on this (two in total for this feature, and there are lots of other things, such as fixing bugs, that I need to do, too), and no progress would ever be made if basic elements of design were constantly to be revisited.

QuoteBut most importantly it is not clear to me how assigning passenger classes to vehicles will help. The granularity sounds very low. I could allow all passengers to use high comfort vehicles, but then I make a loss even if the vehicles are full? Or if I have a network with lots of direct connections I assign the lowest vehicle class to medium class passengers and either leave the lowest class passengers without a route or build a second network?

The low granularity is deliberate in order to overcome limitations with passenger pathfinding. Paths between points are found in the abstract for all passengers or goods of a given type travelling between those two points on the network. For a very large map, finding a new path for each passenger would be too taxing on the CPU/memory bandwidth. Thus, having a set of classes (five is the number implemented for passengers in the passengers-and-mail-classes branch of Pak128.Britain-Ex on Github) will mean that only five sets of passenger routes between points will need to be generated.

As to how it will help, take the example of early aircraft. In the system that currently exists on the master branch (and the downloadable binaries), al passengers take the fastest route and pay according to speed. Thus, if one were to run an air service using DC-3s between, say, London and Manchester, all the passengers going from London to Manchester would take the aircraft instead of the train. With the classes system, the aircraft might well take only the highest class of passengers (and might only make a profit when taking higher classes of passengers), leaving all the lower classes of passengers still to use the train, just as in real life.

QuoteThis is why I mentioned "desireability". The main difference would be that wealthier passengers would not only pay more but actually prefer to travel with high comfort+speed. And poor passengers will also use expensive means of travel, but will prefer other routes and hit the "travel time limit" sooner if the vehicles are too expensive.

Taking into account comfort in routing decisions is not workable for two reasons: firstly, because it would require too much computational effort when computing the routes, and secondly because it would produce essentially arbitrary and unpredictable results: because routes are calculated for all passengers rather than individually (or, in the passenger-and-mail-classes branch, all passengers of each of five classes), there would always be a point where a minute change in comfort would make all passengers (or all of one class) travel on one route rather than another, which is never how it works in reality.

"Desirability" is also rather too nebulous a concept to be able to be calibrated for vehicles spanning nearly 300 years using historical data: comfort is already implemented (and scores of hours have been spent calibrating it).

This system was designed with very great care to be able to work well within the limitations of the routing system that exists in Simutrans-Extended.
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.

Kuk

Quote from: jamespetts on October 08, 2017, 02:29:57 PM
I am not entirely sure that I follow this. What is it that you are not sure about? The system adjusts the class: it is not a direct adjustment of the price (unlike the system in, e.g., Cities in Motion 2).

I am not sure about whether it is a good idea to allow adjusting the price. I do not see anything wrong with it in particular, but I do not know whether it improves gameplay either.

Quote from: jamespetts on October 08, 2017, 02:29:57 PM
The low granularity is deliberate in order to overcome limitations with passenger pathfinding. Paths between points are found in the abstract for all passengers or goods of a given type travelling between those two points on the network. For a very large map, finding a new path for each passenger would be too taxing on the CPU/memory bandwidth. Thus, having a set of classes (five is the number implemented for passengers in the passengers-and-mail-classes branch of Pak128.Britain-Ex on Github) will mean that only five sets of passenger routes between points will need to be generated.

[...]

Taking into account comfort in routing decisions is not workable for two reasons: firstly, because it would require too much computational effort when computing the routes, and secondly because it would produce essentially arbitrary and unpredictable results: because routes are calculated for all passengers rather than individually (or, in the passenger-and-mail-classes branch, all passengers of each of five classes), there would always be a point where a minute change in comfort would make all passengers (or all of one class) travel on one route rather than another, which is never how it works in reality.

I am not suggesting to change it from a small set of passenger classes towards giving each passenger individual metrics.

Quote from: jamespetts on October 08, 2017, 02:29:57 PM
As to how it will help, take the example of early aircraft. In the system that currently exists on the master branch (and the downloadable binaries), al passengers take the fastest route and pay according to speed. Thus, if one were to run an air service using DC-3s between, say, London and Manchester, all the passengers going from London to Manchester would take the aircraft instead of the train. With the classes system, the aircraft might well take only the highest class of passengers (and might only make a profit when taking higher classes of passengers), leaving all the lower classes of passengers still to use the train, just as in real life.

Yes, but why would the player ever want to reassign the classes? Allowing lower classes of passengers will not make a profit and restricting the train to higher classes of passengers will only make it empty.

Quote from: jamespetts on October 08, 2017, 02:29:57 PM
"Desirability" is also rather too nebulous a concept to be able to be calibrated for vehicles spanning nearly 300 years using historical data: comfort is already implemented (and scores of hours have been spent calibrating it).

The idea was not to be historically accurate, but to have something that can be multiplied with the travel time.

jamespetts

The player might want to reassign classes depending on the route on which the vehicle is used: if, for example, it faces competition from other players, players may well need to select a lower class to be optimal; likewise, using the vehicle on a quiet route may well involve a lower optimal class than on a busy route, all things being equal.

The whole premise of Simutrans-Extended is to calibrate the values so far as possible based on historical data, so a system that involves doing that less is not likely to assist with achieving that aim.
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.