News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

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

I visited the Brooklands Museum on Saturday (an interesting day out indeed: I should recommend it to anyone interested in London 'buses, aviation, racing cars or bicycles).

Their star exhibit is an example of the famous and now retired BAC-Aerospacial Concorde, pictured below:

Concorde by James Petts, on Flickr

We have a lovely example of Concorde in Pak128.Britain-Ex, made by Giuseppe (Milko), the pakset's chief aircraft engineer:



At present, Concorde is not of much use in the game, as it is a long-range aircraft, and maps can never get large enough for a realistic long haul flight, especially over water (and, in Simutrans-Extended, aircraft cannot fly supersonic unless they are over water: Concorde was not permitted to fly supersonic over land because of the sonic boom created by flying at that speed).

However, one planned feature is portals: special tiles on the edge of the map that represent foreign ports and airports at which long-distance ships can dock and long-distance aircraft can land. Once those are implemented, long-range aircraft such as Concorde (and other long-range aircraft) will be much more useful.

However, this presents a difficult challenge from a balance perspective: in Simutrans-Extended, passengers, mail and goods will always take the single fastest route from their origin to the destination. It is thus coded for good reason: having different passengers taking different routes (e.g. some preferring a cheaper, slower journey, others preferring comfort over speed, etc.) would involve calculating not one optimum route between each origin/destination pair of stops, but many such optimum routes for different passengers, and this would make the game too slow on big maps.

Because Concorde is so much faster than anything else, any destination served by Concorde will inevitably attract all of the passengers to that mode of travel. However, Concorde is small and very expensive to run: the interior cabin is narrower and lower than a railway carriage:

Concorde (interior) by James Petts, on Flickr

I could only just about stand up straight in the middle of the aisle.

In reality, Concorde was significantly less profitable than other airliners, which lead to its eventual retirement in 2003 without being replaced by any other supersonic airliner. It crossed the North Atlantic on one of the busiest air routes in the world, but carried only a small fraction of the passengers carried on that route: all of them paying a very significant price premium to do so (the ticket price was circa £3,000 one way at one point, although I am not sure exactly when this was). In Simutrans-Extended, because of the speed bonus system, all of the passengers would take Concorde and pay the premium.

Concorde is actually just an extreme example of a balance problem with aviation more generally, especially the short-haul aviation that is currently most readily simulated in Simutrans-Extended: it is so fast that, for long journeys (greater than about 3 hours overland), it will attract all the passengers from land based transport, yet aircraft, especially early aircraft, have a small capacity. It would be absurd, for example, if 100% of the London to Edinburgh traffic travelled in DC-3s in 1937.

This does not just apply to passengers, but also mail: in Simutrans-Extended, all mail would be air mail whenever there were an air route for mail faster than the overland or sea route.

This will make it very tricky to balance revenues properly. The in-built speed bonus (adapted from Standard long ago to be based on the actual speed of the journey rather than the top speed of the vehicles) also makes calibration difficult: it assumes that all passengers can and will pay a premium for speed, and that that premium is fixed irrespective of competition between routes.

The only solution that I can think to this that is reasonably simple for players to interact with and that will not result in much reduction in the game speed is to implement different classes of passenger.

What I envisage is this: each passenger generating building will generate passengers assigned to a particular class: 1, 2 or 3 (roughly to correspond with first, second and third class travel as it existed on the railways in years past). A building's .dat file will be able to specify what proportion of each that they should generate, in default of which a standard distribution will be used (e.g. 10% class 1, 35% class 2 and 55% class 3). Possibly, buildings might then demand passengers of different classes in different proportions.

To prevent the need for excessive micromanagement of prices by players (which was very annoying in Cities in Motion 2, for example), each vehicle run by a player should be able to be set to charge a low, medium or high price (described as "low", "medium" and "high" for simplicity, and corresponding to the three classes of passengers). Different vehicles in a multi-vehicle unit, such as a train, should be able to accept passengers of different classes, and charge differential prices. Each vehicle should have a default price charged (i.e., low, medium or high), which the player should be able to customise on the vehicle's details window. Good pakset design should mean that players do not usually need to change the defaults. Some individual vehicles should be able to be made into composite class vehicles, with accommodation (at different levels of comfort) for different classes of passenger. This is particularly important for aircraft, but is also significant for composite railway carriages.

Once the classes of passengers are thus separated, the routing system could simply run once for each of the three classes of passengers: this would triple the time taken for route generation for passengers, but would not multiply it by ten or a hundred in the way that re-calculating the optimum route for each passenger individually would take. Only routes containing vehicles priced for that class of passengers or lower would be taken into account when calculating the route for each such class.

For each leg of the journey, passengers would choose whether to travel in a lower class than they could afford based on the difference in comfort between the lower class and the class that they can afford: at no difference in comfort, passengers would always use the lower class unless it were full. This calculation would, for simplicity, only affect in which accommodation that passengers travel on a particular vehicle/convoy: it would not affect which convoy that passengers choose to board.

A similar principle should apply to mail (without taking into account comfort): mail should be generated in first and second class, the former being prepared to pay more than the latter, and players being able to designate convoys/lines as accepting only first class or both first and second class mail (without distinction between vehicles in a convoy, which would not be meaningful for mail).

This would allow some interesting emergent gameplay: aircraft such as the Concorde could be priced at the "high" level and thus be available only to wealthy travellers who can pay enough to subsidise its high fuel consumption (and the same for early aircraft of all sorts). On a busy route with little competition, a player might raise the minimum class to "medium" to exclude those who can pay only a little from travelling at all, thus earning a higher margin for the services. A slower competitor might be able to prosper by having cheaper fares (without price micromanagement). Passengers would not always take the same route, leading to more realistic distribution of passengers. Expensive forms of transport (such as early aircraft) could be calibrated to be able to be profitable only when taking mainly or all first or second class passengers. The rise of low-cost airlines could well thus be simulated. Multi-class rail travel could be simulated in full (although unfortunately this would require producing graphics and data for many more railway carriages).

This should also make it significantly easier to balance the game with realistic data, as price discrimination of this sort is often fundamental to the revenue model of many transport outfits, and it would have been very difficult accurately to calibrate the revenue against expenses without this.

I should be grateful for people's thoughts on this. I should be particularly grateful for people's thoughts on some unresolved issues. Firstly, what to do about the speed bonus? None of this would apply to goods (which already have built-in price discrimination by charging different amounts for different goods): should they retain their speed bonus? (The real life prices for transporting goods did not appear to fluctuate with the speed of delivery, so I am doubtful that good balance could be obtained by doing this). Should the code for the speed bonus be retained in case anyone wants to use it, or should it be excised entirely to simplify matters?

Secondly, are three classes of passengers and two classes of mail enough, or do we need more? (Does modern long-distance rail travel count as medium or low, for example? Should air mail be considered a class above first class post creating three total classes? There were such a thing as fourth class carriages on trains in the mid-19th century in some unusual situations where the railway had to compete with the slower but more comfortable canal for passenger traffic).
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.

Junna

Would vehicles have separate capacities for various classes with this implementation? The Pak128.Japan set changed mail to first class passengers for example, and it made for very bothersome capacity provision.

jamespetts

Quote from: Junna on April 11, 2017, 03:37:03 AM
Would vehicles have separate capacities for various classes with this implementation? The Pak128.Japan set changed mail to first class passengers for example, and it made for very bothersome capacity provision.

The idea is that there would be separate capacities for different classes for each vehicle by default, but for players to be able to re-designate classes on a per vehicle basis, and also for passengers of a higher class to be able to use accommodation of a lower class either if the accommodation of a higher class is full or if the difference in comfort is not enough to justify the difference in price and the accommodation of the lower class has sufficient room. May I ask exactly what the problems with capacity were in the Japanese pakset?

I also wonder about comfort: if comfort is used to enable price discrimination, does a separate comfort bonus any longer have any merit? It is difficult to see how realistic calibration of revenues can work with a separate comfort bonus.

However, the difficulty with abolishing the comfort based revenue entirely is that it provides no incentive to offer any comfort at all to third class passengers, even on very long journeys indeed: third class passengers would happily endure fourteen hours standing in a re-purposed coal truck. I wonder whether it would be necessary to introduce the concept of unendurable discomfort: a journey leg so uncomfortable for its duration that no passenger, no matter how poor, is prepared to endure it. This would not overburden the routing system as it could simply leave out certain journey legs from consideration when generating routing data. Players would have to be warned when unendurable journeys had been detected. This would also have the effect that passengers might on some occasions split a single journey into multiple legs, for example, getting off a train at a station only to get on another train going to the same location, (Indeed, it might well not be possible to stop them getting back on the same train or other form of transport, thus defeating the purpose of the system entirely).

I should be interested in people's views on this and related issues.
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.

Ves

A quick comment and thought:

(1) don't hardcode the number of classes (i.e. Two or three number of classes) let the player or pakset author decide in simuconf tab how many classes up to, say, ten or so. This would help paksets if they don't need more than one or two classes or if they need four or more.

(2) What if you specify in simuconf.tab the classes, their revenue/km (with all the variations with commuter/visitor etc) and their minimum comfort (and maximum comfort(read below)).
Then a comfort above the class comfort minimum would increase the revenue, and if the comfort is below the set minimum for that class, it would decrease. Pakset authors then have to balance it well, so the player not just are setting high comfort cars to be third class etc to get a big bonus.

The maximum comfort would specify the limit to which any further increase in comfort doesn't matter.

Balanced good, this should ensure that a first class car should only be viable if you put first or second class passengers in it. If you set a low comfort car to be first class, the negative difference between the class desired comfort and the actual comfort should drag the price down far enough to not make it viable. Passengers would however be happy to take that anyway.

(3) suggestion:
Maybe also raising the monthly cost of the car if it is set to a better class to simulate that it needs more cleaning, free newspaper, free coffee etc?

jamespetts

Thank you for your feedback. I was minded to follow suggestion (1) in any event, but thought will need to be given to how precisely this will interact with the pricing levels and the UI for these. (Actually, would you have any interest in helping with the GUI for this project? It would be much appreciated if you could). I should note, however, that these things would probably need to be set, not in simuconf.tab, but in goods.dat. Precisely how to set this up I will need to consider.

As to comfort, I suspect that the best thing to do would be to allow a penalty for excessive discomfort (that is, a comfort rating that is sufficiently far below that necessary for the journey time in question to be comfortable according to the maximum comfortable journey time already given in the depot window), but allow no bonus for comfort beyond that required; luxury should be relevant only as a means of discouraging wealthier passengers from using a lower class of travel than they can afford. I think that, on reflection, the idea of unendurable discomfort is likely to be unworkable.

The increase in the cost of maintenance and purchase of a first class carriage is likely to be minimal if realistic figures are used, as is the intention. The real purpose of first class carriages is not that first class passengers are just paying extra for the cost of providing the extra luxury which they receive, but rather that they are paying more for the journey because they can afford to pay more for the journey, but the only way to persuade them to pay what they can afford, rather than what poorer people can afford, is to give them more luxury in return for their higher price. The transport company will make a much higher margin on the higher class tickets than on the lower class tickets, which would not be the case if the ticket price simply balanced out the cost of providing the additional luxury. Indeed, in many cases, the transport company can only make a profit if it transports enough higher class passengers, the lower class passengers being accommodated because, accommodating them in addition to the higher class passengers does not significantly increase the cost in many cases (especially on railways where the infrastructure overhead is fixed no matter how many are transported; less so for aircraft) and there will be some additional revenue from doing so. The same principle applies to goods: the higher value goods such as manufactured goods pay much higher rates than lower value goods such as coal, not because it costs more to transport them, but because the ultimate consumers of the higher value goods can more readily afford to pay the extra for the cost of the transport than the ultimate consumers of coal. This is the concept of charging what the traffic can bear, and is of considerable importance in the realm of transport economics.
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.

zook2

It's an interesting idea. Also, it's good to see that balancing is on the agenda now. And my opinion is:
... I can't really say, at the moment, despite having played a maximum size map for over a year (real life, 11.35 version), with thousands of vehicles and hundreds of lines, all the way from stagecoaches to maglev trains. And I suppose that other players have similar experiences: my main concern, after financially surviving the first decade or so, was managing the huge number of passengers somewhat efficiently. I never did pay any attention to the effects of comfort levels or speed boni, because these effects are AFAIK difficult to measure with the feedback the game gives.

I like the idea of different buildings generating different passenger classes. A small town would generate very little or no 1st class passengers, so luxury vehicles of all kinds would and should appear very rarely and only between major business centers or hubs, and even then might turn out to be money-losers (the Concorde being a prime example). Like the Concorde, they could add a lot of prestige to the company, though.

As for overly inconvenient routes: I understand that refunds are currently not being used (?). Wouldn't that be an option where some code to handle that issue already exists? Instead of not traveling, they want their money back.

jamespetts

Thank you for your feedback. As to some of the more specific points: the huge number of passengers from 11.35 was because there was a problem with town growth, resulting in excessively large towns and therefore an excess of passengers. Town growth should be more realistic in the current version.

I should note that the concept of prestige is not simulated, and there are not currently any plans for it to be simulated, as it is very difficult to calculate what impact that this would have in real life on objectively measurable things that can be simulated with precision in the game. In a multi-player game, of course, a player running Concorde might well get some kudos from other players for doing so, and thereby attract some real life prestige.

Refunds are used, but only in some limited circumstances (more limted than was formerly the case). They exist only to prevent a very particular exploit consisting of transporting goods/passengers part of the way to their destination(s) without any intention or ability to transport them the whole way there, yet making a profit on the partial transport.
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.

Ves

I would very much like to help on the GUI!

Great that you consider doing it flexible with number of classes!

Il write more in detail later :-)

Vladki

This is very interesting discussion. But before I propose something I'd like to perfectly understand the current system. Please correct me if I am wrong.

Now we have base prices for delivery/km and speedbonus set in goods.dat. We have minimum speed for each waytype and era set in simuconf.tab. Also we have minimum required comfort for the journey time also in simuconf.tab. How do these combine?

If I understand right, if the travel time is exactly the max for the given comfort (as seen in depot), you get the base price. If it is shorter, you get more, and vice versa? Catering offering additional bonus, while overcrowding is penalized.

How do the passengers board and pay for a train that has a mix of cars with different comfort?

I'm less sure about speed bonus. Do I get the base price if the avg speed is exactly the minimum set for current year in simuconf.tab? And any improvement increases revenue and vice versa?

How much do I get (or lose) for each comfort level and km/h of avg speed above/below the base level?

My idea of classes would be that each class has a limit of how much it is willing to pay for extra speed and comfort (together) and how much it is willing to suffer from discomfort. Then you could discard some connections during the pathfinding as too expensive or uncomfortable.

This would keep the number of classes in control of player (in simuconf.tab). Only the generation of passengers would have to be solved.

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

Ves - excellent, that is much appreciated. If you are able to code the GUI elements of this, this might considerably increase the speed with which this can be done, and likewise other features, such as inflation.

Quote from: Vladki on April 13, 2017, 07:11:08 AM
This is very interesting discussion. But before I propose something I'd like to perfectly understand the current system. Please correct me if I am wrong.

Now we have base prices for delivery/km and speedbonus set in goods.dat. We have minimum speed for each waytype and era set in simuconf.tab. Also we have minimum required comfort for the journey time also in simuconf.tab. How do these combine?

If I understand right, if the travel time is exactly the max for the given comfort (as seen in depot), you get the base price. If it is shorter, you get more, and vice versa? Catering offering additional bonus, while overcrowding is penalized.

Yes, indeed, that is true so far as comfort is concerned, with the added point that the discomfort penalty is greater than the luxury bonus. One clarification, however: overcrowding is penalised by treating standing passengers as if they had a comfort level of 10: how this works in combination with the seated passengers is the same as a convoy with multiple levels of comfort, as described below. Further, catering has two distinct effects (1) it increases the comfort level for the whole convoy; and (2) it offers an additional monetary amount to simulate the revenue from the catering itself.

QuoteHow do the passengers board and pay for a train that has a mix of cars with different comfort?

At present, the comfort level of the vehicles in the convoy is simply averaged. So, if there are 10 seats with a comfort of 100 and 50 seats with a comfort of 75, the comfort level for all passengers is 79.

QuoteI'm less sure about speed bonus. Do I get the base price if the avg speed is exactly the minimum set for current year in simuconf.tab? And any improvement increases revenue and vice versa?

Yes, indeed: the actual figures are shown in the goods list GUI.

QuoteHow much do I get (or lose) for each comfort level and km/h of avg speed above/below the base level?

This depends on the speed bonus rating (a concept inherited from Standard): I cannot remember the formula immediately, but you can see the actual figures in game.

QuoteMy idea of classes would be that each class has a limit of how much it is willing to pay for extra speed and comfort (together) and how much it is willing to suffer from discomfort. Then you could discard some connections during the pathfinding as too expensive or uncomfortable.

This would keep the number of classes in control of player (in simuconf.tab). Only the generation of passengers would have to be solved.

I am not sure that I understand precisely how routing would work in this case. Remember, all routing for each class of thing to be transported has to be a graph: each stop is a node and each connexion between each pair of stops is an edge. Each edge must have a single number representing the weight of that edge. The pathfinding system then uses the Floyd-Warshall algorithm to find the path with the lowest weight from each node to each other node, which is then the path taken by all passengers/goods of the relevant type.

In the system that I envisage, one would just split classes of passengers into different classes of things to transport (just like different types of goods), and only register a connexion between two nodes for that class of passengers at all if convoys with vehicles accommodating passengers at or below that class's price-point travel between those points. When actually boarding a convoy containing multi-class accommodation, passengers would then be able to choose accommodation at a lower price point than their class's price point if the difference in comfort were small enough, but this would not affect the actual routing in any way: they would still board the pre-assigned convoys.

It would be possible to discard connexions for passengers entirely on the basis that going from A > E takes 3 hours, the maximum comfortable journey time of the vehicles on that route is 30 minutes, and therefore the journey is too uncomfortable. However, if the A > E convoy also stops at B, C and D, and the A > B, B > C, C > D and D > E journey times are all 30 minutes each, then the passengers would simply take exactly the same convoy, but get off and get back on again at each stop, so this would be a futile and confusing game mechanic.

I do not fully understand how you envisage prices interacting with routing (at least, in so far as what you envisage is different from what I have described); can you elaborate?
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.

Vladki

My idea is probably quite similar to yours, I just wanted to avoid the explicit assignment of class to vehicles. It may be easy for trains, but how do you assign it to buses? And even with trains - the differences between 2. class commuter trains and 2.class long-distance express trains is very big. And we already have comfort settings so we should use them.

Lets imagine 3 example classes:
1st class passengers are willing to pay unlimited premium for comfort and speed, but will not take slower or less comfortable vehicle than the base value stated above.
3rd class is exactly opposite - willing to take slow and uncomfortable vehicle, but not willing to pay anything extra.
2nd class is willing to pay limited premium, and also to take somewhat slower or less comfortable vehicles
(how the limits are specified can be decided later)

When the pathfinder finds a link it checks if the price/comfort/speed is within the passengers class limits, and if not, the link is discarded. To avoid hopping on/off the same train, a hard limit on transfers could be put, or adding some weight to nodes as well to account for the discomfort of taking off/on - even if not waiting for next train.

Another idea:
I suppose that now the pathfinding algorithm finds the fastest route and does not care about comfort or price. So the weight of each edge is travel time. What if the weight is travel_time*ticket_cost ? I just don't know how to balance that for different classes. Maybe travel_time*x + ticket_cost*y, where x is how much you prefer fast travel, and y is how much you prefer cheap travel. I cannot think up how to add comfort to that now.. I have to go to bed...


jamespetts

One has to be extremely careful with this not to introduce arbitrary parameters that give rise to unrealistic emergent behaviour: careful thought is needed to work out all of the remote consequences of each of these changes. For example, a hard limit on the number of transfers would arbitrarily prevent a whole range of reasonable journeys without actually solving the problem described above (passengers may make a one transfer journey, that single transfer being getting off and onto the same convoy again to circumvent the comfort limit). Likewise, any restriction on speed as opposed to time gives bizarre, arbitrary results: passengers may end up taking a much longer, more convoluted route that takes a greater amount of time overall (but is still within the journey time tolerance) just because the speed of each component is higher.

Also, it is not realistic to suppose that wealthier people will simply refuse to travel when less wealthy people would travel: that is not how transport economics (or economics in general) works. If a person wants to get to a place, the person will take the best route available to her or him. If the best route is a bad one, then that is what the person will take. If the best route available to that particular person is restricted by that person's wealth, then what counts as the best route for that particular person may well be a worse route than the best route for another person. A person will not be more likely to stay at home rather than take an slow or uncomfortable route merely because he or she is wealthy, just as, if the only food available is fish and chips, a wealthy person will not go hungry because there is no caviar whereas a poor person would eat.

Also, as to prices: if there is only one way of getting to a particular place, a person is very unlikely to refuse to travel at all because the price is one which that person would be prepared to pay for a faster means of transport to that same destination, but not for getting there on the only method available, which at present is slow (but still within that passenger's journey time tolerance); likewise with comfort. One of the problems with the current speed/comfort bonus system is that it fails to recognise this. The reality is that, as one increases the price, fewer and fewer people would be able to pay the price. In reality, each individual person would have a different price point for each journey, and all people would appear at a multitude of points along a continuum in a normal distribution. In Simutrans-Extended, we cannot simulate that level of detail within reasonable limits of computing power, so the plan is to divide ability to pay into three discrete classes. At a low price-point, everyone can travel on each journey leg. At a medium price point, all but the lowest class can travel, and, at a high price point, only the highest class can travel. The idea would be that the player has three simple options: low, medium and high, and the imagined clerks of the transport company would automatically set the fares to the correct levels to attract custom from these classes of passengers.

Accommodating multiple classes on the same journey leg would require an incentive to those who can pay more to do so, hence comfort segregation. It should be possible to allow comfort segregation within single vehicles (such as aircraft) by making some amendments to the code giving vehicles multiple passenger capacities at different levels of comfort.

The real conundrum is how to deal with the comfort of the lowest class of passengers, as discussed above. Adding comfort to the routing has been considered for many years, but has two principal difficulties: (1) using anything other than a single integer (currently journey time in 10ths of minutes) for the weight of each edge significantly increases the computational load on what is already one of the most CPU-critical areas of the code: for every single step through the graph, the route finding engine would have to perform a series of computations to determine the edge weight rather than just retrieving a single number; and (2) accurately balancing anything other than a simple time based system is likely to be impossibly difficult. In reality, each individual passenger has her/his own preferences and tolerances for journey time, comfort and price. In Simutrans-Extended, individual passenger routing is not computationally viable, and passengers must be routed as a class (or, at least, one of several classes). It is very hard to see how a sensible conclusion could be no passengers at all using a faster but less comfortable route (and that is a more perverse outcome than no passengers at all using a slower but more comfortable route as is possible 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.

Vladki

One more question. How do the private cars fit into the routing? I remember you had dealt with calculating routes between towns by private cars as well. Does the passenger take private car only if it is faster than public transport and vice versa? How many inhabitants have private cars?

What about simpler definition of classes - how much they are willing to pay extra for speed and comfort, and how many of them have private cars.
1st class is willing to pay anything to get somewhere faster (and more comfortably)
2nd class can pay e.g. 50% more than the base price
3rd class can pay only 25% more than the base price
(maybe even 4th class that can pay only up to the base price and nothing more).
3rd and 4th class passengers do not have a private car at all (or maybe a very small percentage of 3rd class could have one).
All (or many) 1st class passengers have a private car and will use it if it takes them somewhere faster.
Approx 50% (maybe time dependent) 2nd class passengers have a private car and use it, if it is faster than what they can afford.

To avoid the issue with pax getting on/off the same train, there won't be any lower limit for comfort and speed. If a particular leg is too expensive, it will be omitted for given class. This will properly route 1st class passengers to Concorde and 2nd class to normal planes; 1st+2nd class using TGV, while 3rd class will use commuter train to save money. 2nd or 3rd class passenger may end up in situation that it is faster to take his own car, because he cannot afford to travel in a hyper-super-fast-maglev train, and commuter train is too slow.

At last, after the fastest affordable route is found, a weghted average of comfort for the whole journey would be calculated. If the comfort is lower than the base comfort, passengers that have private cars would choose to use the car instead of public transport. Could be again scaled by class - each class could have differently comfortable private cars. (VW Beetle, vs. Rolls-Royce).

If vehicles of varying comfort are available on one leg of journey, the highest affordable will be chosen for routing. However if that one is overcrowded, passenger will take lower class vehicle if available (and save money).

jamespetts

As to private cars, the way that this works at present is as follows: for each packet of passengers generated, there is a weighted random chance that that packet of passengers will have access to a private car. The weighting is based on the current percentage of people who have access to a private car, set in privatecar.tab, and based on real life statistics from the UK government (this can be changed for different paksets).

Passengers with no access to a private car disregard the possibility of travelling by private car when routing. Those with access to a private car compare the private car journey time with the public transport journey time. There is a certain percentage of passengers, set in simuconf.tab, who will always take their private car where possible (i.e. where they have access to it and where the private car journey time is within the passengers' journey time tolerance). For all other passengers, they will take the quickest route.

Private car routing is a separate system from the main routing: this is much more heavily approximated. It works by using the routing algorithm used by vehicles to find a route by road, if available, between every town hall and every other town hall on the map, as well as to every industry and attraction outside a town. The speed of the journey is calculated (based on the maximum speed of the roads between the origin and destination and the maximum speed of the range of private cars currently available averaged (weighted by the cars' distributionweight parameter), the a fraction of the lower of the two being used for each tile). This is then divided by the straight line distance to give a private car journey time per tile figure. When calculating a journey time to a building in another town or to an industry or attraction outside a town, the journey time is extrapolated from the journey time per tile figure just mentioned and the straight line distance between origin and destination. These private car routes between town-halls are periodically updated in the background.

Thus, there is a little more flexibility when passengers compare private car routes with the best public transport route, as it is possible efficiently to use branching logic in the comparison (e.g. if these passengers always prefer to take the private car and the journey time is within their tolerance and they have access to a private car, take the private car, else check to see which is faster, etc.), but this does not increase the flexibility of determining which of the various possible public transport routes are the best. It would thus be possible in principle to have a comfort comparison here between private cars and public transport, but this would present two problems. Firstly, it would require the public transport routing system gathering data about comfort as it plans its routes, and this would add significantly to the overhead. It is unlikely to add as much as actually taking into account comfort in the routing, but it will add a significant amount nonetheless. Secondly, it would be somewhat anomalous for comfort to be taken into account in routing decisions between private cars and public transport but not between different modes of public transport. For example, if the fastest route on public transport between A and B took 1 hour and had a comfort rating of 50, the second fastest route between A and B on public transport took 1 hour and 5 minutes and had a comfort rating of 100 and the private car journey took 1 hour and 10 minutes and had a comfort of 75, it would be very odd indeed for passengers to choose the private car journey over all public transport on grounds of comfort whereas they could not choose the second fastest means of public transport on grounds of comfort when that means of transport is both faster and more comfortable than the private car. Thus, whilst taking comfort into account in choosing between private cars and public transport is probably possible with a lot of work and some probably noticeable loss of performance, it is best avoided unless there is no other way of remedying some insuperable anomaly that is considerably more serious in game-play terms than that just mentioned.

As to the simpler definition of classes - I am not entirely sure how you intended this to differ from what I had originally suggested; can you elaborate? If this would involve players setting the actual prices in individual SimuCents rather than just setting the price as "low", "medium" or "high", then this would be, from the players' perspective, considerably less simple, would it not?

I had considered the interaction between private cars and classes of passengers. It might be worthwhile to have a system in which the probability of any given packet of passengers having access to a private car is linked to those passengers' class. However, there is a problem with this: the current data for the proportion of people with access to a private car is real data from a government website. Those data do not distinguish between socio-economic status and/or wealth levels: they are just general statistics (going back many years). If it were possible to find good, comprehensive data on access to cars (as distinct from car ownership, as the two are not the same) going back to at least the 1930s, then this may be far more workable.

Indeed, one could then assign each individual type of private car in the game to the different classes, and the different classes of passengers might find themselves with different speeds of private car journeys at some points in time when there was a real difference in the speed that people could realistically travel between cheap and expensive cars. It would also involve the actual private cars being spawned from different buildings differing depending on the class of passengers, which would mean adding a number of luxury car graphics to the game (I am staying with my parents over Easter, which means that I am not able to work on the code, but am able to work on the pakset, and I am dedicating this visit to adding more private car graphics; I have been concentrating so far on mass market cars, however).
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.

Vladki

I had a long thought but discarded it. It is hard for me to put all that in writing (and in english).

Just one question - how do transfers and waiting times affect routing. Floyd-Warshall alg is only about link weights (i.e. travel time), not about node weigths?


jamespetts

The transfer times and waiting times are considered as part of the edge weights for any links between stops. So, for example, if, in a connexion between stops A and B, the travelling time is 1 hour and stop A's waiting time is 15 minutes, the edge weight for that transfer is 1 hour and 15 minutes.
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.

Ves

GUI-wise, I think I have to learn some more basics before I can do some more advanced stuff than I have already done, but Im willing to try and learn.

If you read my reply in the other discussion thread (this reply: http://forum.simutrans.com/index.php?topic=16980.msg161917#msg161917), that window could in fact be used to set some of these levels too. The window would then be more of a "vehicle manager window" or similar.
One could add more tabs, ie a "maintenance" tab and, say, a "class" tab and put all the class settings for a particular vehicle or groups of vehicles, like described in the other thread (even more tabs could be added, dependent on the needs). The "groups" of vehicles from the "maintenance" tab, I think should not follow over to this tab, as you will then mix maintenance groups and class groups.
So something like:
* Display total seats
* Set amount of seats Class 1:
* Set amount of seats Class 2:
* etc...
Also, related price information and price calculations for the particular vehicles could be showed there.

I guess the general price settings could also be showed in this section, clearly separated from the vehicles part. If that needs to much space though, I guess you would need a new window for that.

jamespetts

These are interesting ideas - more detailed consideration of precisely how to implement them will be needed in due course. Certainly, the current goods window will need some reworking for this to work properly, although that might be more basic.
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

I have found some very useful historical statistics on car ownership by reference to household income on the RAC Foundation website. That breaks down car ownership in the UK sine circa 1960 into income quintiles. These official UUK government statistics also use quintiles to give car ownership rates by household income in 1995 and 2015, but they do not go back furhter historically.

It may well be possible from those to extrapolate and interpolate with the general car ownership data the car ownership data for different income levels. However, there are some difficulties in that approach.

Firstly, the data are somewhat sparse, and quite a lot of extrapolation/interpolation would be needed, especially in the period before 1960.

Secondly, quintiles are a problem. Having five different classes of passenger would substantially increase the load on the path explorer, considerably increasing the time taken to refresh the paths (the multi-threading implemented last November should at least stop the game from being less responsive whilst this is being done). It would also considearbly increase complexity for the player. Also, quintiles are not a very useful way of breaking down income levels for the purposes of Simutrans: by definition, there are an equal number of people in each quintile, so the differeince in income between the middle quintiles would be far less than the difference in income between the outer quintiles and their neighbours. What we need is the opposite: an even distribution of actual income levels, with the result that there are far more people in the lower income groups than the higher income groups. One might take quintiles 1 and 2 as representing low income, 3 and 4 as middle income and 4 and 5 as high income to preserve a three class system, but that still has an equal number of people in the first two classes, and half that number in the highest level.
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.

killwater

A quick question: is path explorer planed to be multithreaded with separate thread for each class of passengers?

jamespetts

I had originally considered, when implementing multi-threading, whether to do this (i.e. parallel as well as concurrent multi-threading for the path explorer so that each class of goods/mail/passengers would run in its own thread) , but this would involve a huge amount more work (multi-threading code is extraordinarily difficult to get right), and it would only have made the path explorer refresh complete more quickly: it would not have improved responsiveness in any way (indeed, it might have made responsiveness worse, as there would be more path explorer threads competing with other background threads at the same time just to make the path explorer refresh complete more quickly), so I did not think it worthwhile to implement this.
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.

Vladki

Hi James, I'm getting back to this idea. I'll try to rephrase your proposal to see if I understood it correctly:

Passengers and vehicles will be split into 3 (or more) classes. Vehicles will have their default class set by pak designer, but it could be changed during the game. Each class would have different price for travel. Speed- and comfort-bonus will not be needed any more.
Pax of 1st class will use simply the fastest available connection, and use vehicles of any class (as it is now), lower classes will not consider travelling in higher class at all. (So there will be 3 passes in the pathfinding algorithm.)

I'm not really sure what will happen if someone takes a low comfort vehicle and reassigns it to 1st class? Will it allow the player to reap more profit, or just nobody will use that vehicle at all? What will be the comfort rating used for? Will lower class pax consider using higher class vehicles, if their class is full or if the connection is possible only using higher class vehicles?

My proposal was quite similar to yours, just instead of using explicitly set classes on vehicles, it will compare the base price for travelling each hop with price including the speed- and comfort- bonus. Each class could afford to pay different bonus %. (According to previous discussion I'm dropping the suggestion for lower comfort limit for high classes, only keeping the upper financial limit.) So the pathfinding will also have only 3 passes, although the decision which routes are not valid for some classes would be more complex - instead of fixed (and adjustable) class it will require calculating the speed and comfort bonus for that route and compare it with the base price.

Splitting the route in smaller pieces should not happen, as the low comfort limit is dropped. Splitting the route will have opposite effect - as shorter route would have higher comfort bonus, and thus could cross the limit of higher class. However I understand that specifying explicit classes will be much more clear from player point of view, than guessing if the vehicle is too expensive for some class or not.

Car ownership in quintiles is IMHO not a problem. There is always much less 1st class seats in train or plane, so I see no problem in using only the richest 1/5 for 1st class, while using 2/5 for 2nd, and 3rd class. So if we have those numbers available, it would be good to have different % of car owners in each class.

I just have a problem how to pre-assign classes to vehicles that are not usually classified - especially buses. Comfort on buses seems to match their use (city, inter-city, inter-state). Only trains have explicit selection of classes. Or is the long distance bus the contemporary 3rd class, while trains are only 2nd and 1st?

jamespetts

Quote from: Vladki on April 22, 2017, 02:35:12 PM
Hi James, I'm getting back to this idea. I'll try to rephrase your proposal to see if I understood it correctly:

Passengers and vehicles will be split into 3 (or more) classes. Vehicles will have their default class set by pak designer, but it could be changed during the game. Each class would have different price for travel. Speed- and comfort-bonus will not be needed any more.
Pax of 1st class will use simply the fastest available connection, and use vehicles of any class (as it is now), lower classes will not consider travelling in higher class at all. (So there will be 3 passes in the pathfinding algorithm.)

Yes, that is correct.

QuoteI'm not really sure what will happen if someone takes a low comfort vehicle and reassigns it to 1st class? Will it allow the player to reap more profit, or just nobody will use that vehicle at all? What will be the comfort rating used for? Will lower class pax consider using higher class vehicles, if their class is full or if the connection is possible only using higher class vehicles?

The idea is that what counts is the relative comfort of vehicles or parts of vehicles in the same convoy to allow for charging a higher price for passengers who can afford to pay more to travel on the same convoys. If one were to assign all accommodation in a convoy to first class, then only first class passengers would travel, and the player would lose out on the possibility of carrying second and third class passengers (even though the marginal additional cost of doing so once the network has been constructed to carry first class passengers is likely in many cases to be very small).

If a player has multiple classes of accommodation in a convoy all of the same or a similar comfort level, then the people who can afford to travel first class will not buy first class tickets and will instead travel in a lower class, earning less revenue, unless the lower class accommodation is full, in which case the higher class of ticket in any event yields a benefit.

One difficulty for which I have not yet been able to devise an adequate solution is what to do about the comfort of third class passengers when the comfort rating for a connexion is well below the tolerable comfort level. One could simply apply a discomfort price penalty as at present, but that would not fit well with the rest of the proposed system. In reality, this would probably affect whether people took this route at all, but there is no sensible way of taking comfort into account in actual pathfinding as written above, so this is eliminated as a possibility. It is likely to be a matter of finding the better of two imperfect solutions: either apply a discomfort penalty if the comfort level is too low, or simply ignore low comfort in such cases.

This is likely to be difficult to calibrate, as early travel (e.g. by stage coach or early third class railway carriage) was very uncomfortable indeed - far more uncomfortable than, say, a modern short distance commuter train, yet people did in fact make journeys on these modes of very many hours indeed (sometimes sitting on the roof of the stage coach in bad weather), so it would not make sense to prevent any routing over a connexion with very low comfort.

QuoteMy proposal was quite similar to yours, just instead of using explicitly set classes on vehicles, it will compare the base price for travelling each hop with price including the speed- and comfort- bonus. Each class could afford to pay different bonus %. (According to previous discussion I'm dropping the suggestion for lower comfort limit for high classes, only keeping the upper financial limit.) So the pathfinding will also have only 3 passes, although the decision which routes are not valid for some classes would be more complex - instead of fixed (and adjustable) class it will require calculating the speed and comfort bonus for that route and compare it with the base price.

Splitting the route in smaller pieces should not happen, as the low comfort limit is dropped. Splitting the route will have opposite effect - as shorter route would have higher comfort bonus, and thus could cross the limit of higher class. However I understand that specifying explicit classes will be much more clear from player point of view, than guessing if the vehicle is too expensive for some class or not.

May I ask what you think that the benefit of this system would be over what I have outlined? Can you describe a situation that is likely to arise in the game in which this system would work significantly better than what I have suggested?

I can see two sorts of difficulties with a system that relies on the concept of a fixed speed and comfort bonus in this way. Firstly, it would not allow the player any choice as to the pricing. This would give rise to potentially perverse outcomes of a route not being profitable because of low usage, which results from the high price of the route, where it could be profitable if the price were lower, allowing more people to use it, yet the player has no option to reduce the price.

Secondly, it would not take into account competition. In the system that I propose, a player running a competitive route would have a stronger incentive to obtain a higher degree of market share than a player running a monopoly route, and would thus have an incentive to set the prices lower for a competitive route than for a monopoly route. Thus, in the situation of a monopoly route, a player could make a higher margin of profit whilst carrying the same number of passengers than on a competitive route, which is what one would expect to see in reality.

QuoteCar ownership in quintiles is IMHO not a problem. There is always much less 1st class seats in train or plane, so I see no problem in using only the richest 1/5 for 1st class, while using 2/5 for 2nd, and 3rd class. So if we have those numbers available, it would be good to have different % of car owners in each class.

A problem with these quintiles is this: the top qunitile is still a fifth of the population. One fifth of the population could certainly not afford a first class ticket on a trans-Atlantic flight, much less the price of a Concorde ticket when they were still available. Here is some information on the relative price of these tickets to give an idea:

Quote from: Applied Transport Economics, 3rd ed. (Stuart Cole)
The London-New York air return fares on British Airways (2005) varied from £200/£500 (non-refundable) for economy class, £1,847 (non-refundable)/£4,058 to £3,694 (non-refundable) £6,642 in first class. Virgin Atlantic Airways Upper Class is around £4,000 for "first class service". Concorde prices, were they still available, would be about £8,200. The additional costs per first class passenger have to be substantially less than the fare differentials if such a complex product/pricing policy is to be financially justified

If we use quintiles for car ownership of first class passengers, then we are using the car ownership data for a much wider section of the population than could actually afford first class travel, which would be in the top few centiles, and thus the data diverge. First class passengers really need to be, at most, 10% (and probably closer to 5%) of all passengers, not 20% as the top quintile would imply.

Quote
I just have a problem how to pre-assign classes to vehicles that are not usually classified - especially buses. Comfort on buses seems to match their use (city, inter-city, inter-state). Only trains have explicit selection of classes. Or is the long distance bus the contemporary 3rd class, while trains are only 2nd and 1st?

This is a highly complex topic. Firstly, there is the question, raised before, to which we do not, I think, yet have a definitive answer, as to whether three classes are sufficient (and the corollary of whether more than three classes is workable). One might conceivably have five classes of passengers, with prices that can be set at "very low", "low", "medium", "high" and "very high". Those would clearly not map one to one to the traditional three class structure of rail travel (or the different three class structure of air travel). In fact, however, mid-Victorian railways occasionally had a 4th class when they had to compete with canal traffic; and higher than first class fares were payable in some cases for Pullman/dining car trains. Even now, there are actually far more than three price points for rail travel (taking into account peak, off peak, advance booked, and various other types of discounted fares) even though there are now only two classes of accommodation (and note the above on the number of different air fares charged by the same airline for the same route).

We cannot in Simutrans-Extended usefully simulate senior citizens' railcards or discounts for advance booking, but we can have a dynamic market in the assignment of prices to routes.

So, for example, in a three class system a player with a modern long-distance railway service might assign standard class to the "medium" price and first class to the "high" price, and leave passengers in the low price bracket out entirely. A competitor might then start a coach business, with the prices on that route at the "low" setting, which would then, even if slower than the train, attract all of the lower paying passengers, and would also be able to run more economically than the railway because it would have less in the way of overheads, so it could work economically with its lower margin. In the same three class system, however, a player might set an urban light rail network to have all of its routes on the "low" price point, expecting high loading levels to produce sufficient profit in circumstances where adding extra multi-class vehicles (which would be pakset encoded, realistically, to have a lower capacity and possibly worse loading time) would not be workable.

Alternatively, in a five class system, a player with a Victorian era rail network might set third class to "low", second class to "medium", first class to "high", and then have special non-stop Pullman trains between the major business centres that have a good number of "very high" passengers set to "very high" (perhaps with some 3rd class Pullman cars set to "medium" if loading be not sufficient for the "very high" passengers), and run special workmen's trains (as railway companies at the time did) to factories and other industries priced at "very low". Likewise, a Victorian tram might be priced at "very low" in a five class system, whereas a Victorian era horse 'bus might be "medium" or "low" to reflect the higher cost of those services (early horse 'buses were considered the preserve of the middle classes because of their relatively high per passenger operating cost). Likewise, a stagecoach's internal accommodation might well be set at the "high" price level, whereas sitting on the roof might be set to "low", although on a competitive route, players might reduce this to medium/low respectively.
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.

Vladki

Quote
May I ask what you think that the benefit of this system would be over what I have outlined? Can you describe a situation that is likely to arise in the game in which this system would work significantly better than what I have suggested?
I don't know, I was just brainstorming in the hope that some of my wild and disconnected ideas might be interesting. One thing that I like about the current system is that the comfort is fine-grained (0-255), and also that speed bonus is somewhat realistic. Many railways charge extra for using fast trains - often the charge is hidden as compulsory reservation. So I was just trying to use the current system of speed & comfort bonuses to implement some classes of passengers, so that not everyone will travel in concorde ;) Also as the speed necessary for bonus is getting higher over the ages - faster vehicles are getting more affordable, and at some point will cross the class border. Speed and comfort could balance themselves - fast but less comfortable vehicle would be of the same class as slow but more comfortable one - if the sum of speed and comfort bonuses is the same.

OTOH, I like the fixed price levels and the possibility to adjust prices by player proposed by you, as it is also getting closer to reality. The competition between buses, trains and planes is all about changing prices, and offers an interesting gameplay option in multiplayer games.

It would be interesting to allow the player adjust all prices - not only passenger/mail fares, but also price for cargo delivery. Then also the factories could have some smart decision making (or bargaining ability) whether it is worth to pay extra for faster delivery or not? Not only for perishable goods (food, newspapers), but also for bulk cargo that has to be delivered in big amounts (coal for power plant). For perishables a time tolerance would be good with some sort of comfort in cooling/freezing cars to extend the time tolerance.

Uhm, maybe I have one more gray area, which I do not know how would work out even now? If I have a line with commuter train (stops everywhere), and express train (less stops). Pax wants to go all the way from one end to the other. Of course the pathfinding will find the express train, pax gets to the station, but the commuter train arrives first. Will he take it or wait for express? Can it look at the virtual departure board and decide if it is worth waiting for the express in hope that it will overtake the commuter train?

If top quintile is too much for 1st class, we could assume that if it is top 10% or 5%, then that they always have a private car (or horse carriage) available, and reduce the percentage for the rest of people accordingly.

To the point of comfort levels and history - if your proposal is done - pricing by classes, we could just ignore low comfort conditions - people would travel anyway (if travel time is within their limits) and choose higher comfort if available or affordable.

If discomfort penalty is kept (as in my proposal) it could be done in a similar way to speed bonus - as the required speed rises during the ages, also the comfort requirements could grow. E.g. an old omnibus with lower comfort, would be equal to modern (more comfortable) double decker - both will be OK for the same time of travelling.

jamespetts

Quote from: Vladki on April 22, 2017, 09:07:29 PM
I don't know, I was just brainstorming in the hope that some of my wild and disconnected ideas might be interesting. One thing that I like about the current system is that the comfort is fine-grained (0-255), and also that speed bonus is somewhat realistic. Many railways charge extra for using fast trains - often the charge is hidden as compulsory reservation.

Except that this is not quite how the speed bonus works. In reality, railway companies will charge extra to use faster trains: in other words, where there are two speeds of train available for the same route, the faster one will generally be more expensive (and likewise for other modes). However, in Simutrans-Extended, faster will always mean a higher fare, and slower a lower fare, whether there is any competition or not. This is not how it works in reality. If one service between A and B is faster than another between X and Y because, for example, the latter uses a slow, winding route, but there is no competition (or, at least, no competition that is faster) in either case, then the slow route will not be priced at a lower per kilometre rate just because it is slower. (Indeed, conceivably, the price might be higher, partly because the route might be more difficult to maintain, but partlyalso because the slower route would mean that fewer people would travel, and the fixed infrastructure costs would therefore have to be shared between fewer passengers).

Likewise comfort: in a state of no competition, in reality, passengers will not pay more to travel because the comfort is higher. They may choose to pay more to get more comfort when the choices for a given journey are between a lower price and lower comfort and a higher price and higher comfort, but where the choice is a take it or leave it choice between one fixed journey at one fixed comfort and price point or not going to that destination at all, it is unlikely that passengers would choose not to travel at all unless the comfort was so poor as to be considered unbearable.

For the latter reason, there may be something to be said for applying a discomfort penalty where the discomfort is sufficiently high compared to the length of the journey, not directly to simulate the fact that passengers pay less, but rather to simulate (indirectly) the fact that fewer passengers would be prepared to travel at all in those circumstances. This is a very crude way of simulating this, but without full multi-factorial routing (which is likely to be impractical as discussed above), there does not seem to be a feasible alternative.

QuoteSo I was just trying to use the current system of speed & comfort bonuses to implement some classes of passengers, so that not everyone will travel in concorde ;) Also as the speed necessary for bonus is getting higher over the ages - faster vehicles are getting more affordable, and at some point will cross the class border. Speed and comfort could balance themselves - fast but less comfortable vehicle would be of the same class as slow but more comfortable one - if the sum of speed and comfort bonuses is the same.

I am not sure that I fully understand the reasoning here. Firstly, inflation is intended to be a feature, and is a high priority, pre-pakset balance feature. This should take care of rising costs over time. Secondly, the proportion of passengers who fall into each class might well change over time (and this might well be allowed for in pakset settings). Thirdly, faster vehicles do not always get more affordable (think of the 1970s oil crisis, for example), but, when they do, players will simply be able to obtain a higher overall profit by getting a higher market share (and stimulating demand) by making faster transport available to lower classes of passenger (which would not have been profitable with higher cost vehicles).

QuoteOTOH, I like the fixed price levels and the possibility to adjust prices by player proposed by you, as it is also getting closer to reality. The competition between buses, trains and planes is all about changing prices, and offers an interesting gameplay option in multiplayer games.

It would be interesting to allow the player adjust all prices - not only passenger/mail fares, but also price for cargo delivery. Then also the factories could have some smart decision making (or bargaining ability) whether it is worth to pay extra for faster delivery or not? Not only for perishable goods (food, newspapers), but also for bulk cargo that has to be delivered in big amounts (coal for power plant). For perishables a time tolerance would be good with some sort of comfort in cooling/freezing cars to extend the time tolerance.

The difficulty with this is that there is no concept of different classes of the same type of cargo. There do exist different classes of cargo: coal is charged a much lower per kilometre rate than, say, hats, not because it is cheaper to transport coal, but because the people buying hats can afford to pay (relatively) far more in transport cost per hat than the people buying coal can afford to pay transport costs per tonne of coal. One could not adopt the same solution with cargo as with passengers: there could not be first, second and third class coal. That did not exist in reality and makes no sense.

QuoteUhm, maybe I have one more gray area, which I do not know how would work out even now? If I have a line with commuter train (stops everywhere), and express train (less stops). Pax wants to go all the way from one end to the other. Of course the pathfinding will find the express train, pax gets to the station, but the commuter train arrives first. Will he take it or wait for express? Can it look at the virtual departure board and decide if it is worth waiting for the express in hope that it will overtake the commuter train?

The short answer is yes: this is a relatively recently introduced improvement. Passengers deciding which convoy to board is not actually part of the path-finding system itself. The passengers (and, indeed, mail and cargo) will check to see whether the currently arrived convoy will arrive at the next transfer (or even ultimate destination) faster than the predicted travel time using the fastest convoy, and will board it if it is likely to arrive sooner.

QuoteIf top quintile is too much for 1st class, we could assume that if it is top 10% or 5%, then that they always have a private car (or horse carriage) available, and reduce the percentage for the rest of people accordingly.

The difficulty with this is that it would be hard to know by how much to reduce the rest of the percentages at each of the given points in history between which we extrapolate. This is not necessarily an insurmountable difficulty, but it is hard to see at present how it could be surmounted without at least more data than I have been able to find so far. If you can find some more fine-grained car ownership by household income data than qunintiles, it might be possible to do it as you suggest.

QuoteTo the point of comfort levels and history - if your proposal is done - pricing by classes, we could just ignore low comfort conditions - people would travel anyway (if travel time is within their limits) and choose higher comfort if available or affordable.

If discomfort penalty is kept (as in my proposal) it could be done in a similar way to speed bonus - as the required speed rises during the ages, also the comfort requirements could grow. E.g. an old omnibus with lower comfort, would be equal to modern (more comfortable) double decker - both will be OK for the same time of travelling.


I think that what I have written above has already addressed this.

Thank you very much for your feedback on this, in any event: it is very useful to have a detailed, intelligent discussion about these issues. The level of academic detail into which we go in thinking of game features for Simutrans-Extended is something that is (in a good way) far beyond what would be expected in many other game communities.
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

One or two additional thoughts on this issue, if I may.

Firstly, given that the speed bonus is to go, I wonder whether we might introduce a journey time tolerance per class of goods. This was considered before as an alternative to maximum distance between factories but rejected on the ground that there would be too many unconnectable industries. If the maximum distance and the journey time tolerance are calibrated correctly, the number of unconnectable industries would be much reduced, but it would be very hard to eliminate them entirely. I am undecided on whether this would be acceptable and should appreciate feedback on this matter.

Secondly, I am still quite unsure as to what to do about travelling post offices for mail. Currently, they give a revenue bonus, but it is not clear how that would work with the new system. Some consideration would be needed for this. Ideally, these might work as a means of picking up bags of mail from a moving train, but this would take a lot of very difficult work to implement, so cannot be done soon.

Thirdly, some consideration will have to be given to the operation of catering revenue, which is currently fairly crude. The existing comfort boost for catering can be retained, but the additional element of catering revenue warrants consideration One possibility is this: each level of catering might correspond to a level of wealth of passengers. Passengers of a lower level of wealth can still use a higher level catering facility, but will only spend as much money as they would spend at a lower level catering facility (it would be assumed that all of the catering facilities would have the option to sell small quantities of basic items, so that one could buy a single cup of tea in a Pullman car, for example). Also, even for passengers of higher wealth, they would only spend a sum commensurate with a higher level of catering if they were on a journey long enough to justify it. Thus, each of the levels of catering (and it might be that allowing more flexibility with the numbers of these would be required) would simply have a fixed price for a meal/snack, which could be based on historical data for different levels of meal. Passengers on short journeys would not generate any catering revenue. Passengers on longer journeys would generate one of the fixed number of fixed sums of catering revenue each, capped both by wealth level and journey length. For example, a level 5 passenger (supposing 5 classes be introduced) would pay a level 5 catering fee only if the convoy had a level 5 catering facility and the journey were of a length (e.g. 3 or more hours) set in the pakset to call for level 5 catering. If the passenger travelled for a shorter period (e.g. 2 hours) that warranted only level 4 catering, then only level 4 catering revenue would be generated from that passenger no matter her or his wealth and the level of catering on board the convoy. Likewise, a level 1 passenger would only ever pay up to level 1 for catering no matter the length of the journey and the level of catering facility provided.

Fourthly, there may be something to be said for tracking the delivery time and success rate of sending/receiving mail for each building in a similar way to the way in which passenger success rates are tracked. These data could, as with the passenger success rates, come in time to be used in the city growth algorithm, and could perhaps be weighted so that the delivery times of the first class mail has greater importance than of second class mail.
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.

Vladki

I welcome the idea of time tolerance for goods. In that case the limit on max distance of industries could be removed. Also I would like to see some sort of comfort for the cooled goods (cooling/freezer capabilities) that will allow the goods to travel longer.

Also suggestions on catering revenue are nice. Is there a percentage of travelers who will use catering at all?

On a similar note, traveling post office may be relevant only for priority mail (recommande).

One more thought that I would like to share. I'm still trying to figure out better pathfinder that would allow for taking cheaper but slightly longer route and similar cases. I thought that the path cost could be not pure time (with higher class routes completely omitted), but time*price, or even time*price/comfort.
But I don't know how to adjust it for different classes. How to put more weight to time or price...

Sent from my ONEPLUS A3003 using Tapatalk


Ves

I agree, a time tolerance on goods and a comfort system like Vladki describes (and have been suggested before) sounds like interesting ideas. I don't think it matters if some factories are on the edge of possibility to travel to within the timeframe, as that would only make an incentive to the player to buy more modern rolling stock.

Also, your suggestion for the catering car sounds nice! I wonder though, how would you specify the values? Will a meal in the 1850 cost the same as it does in 2017?

The traveling post office, what are your plan on post offices in the first hand? It would be so cool if mail had to be sent first to the post office before it is sent to its receiver. Then I would love the traveling post offices to fill the same role, but just... traveling :)
But in case that is a bit too much, then I fail to make a better suggestion than the existing: that the traveling post office just generates more money.

jamespetts

Thank you both for your feedback. In relation to the journey time tolerance for goods, this would definitely have to be in addition to, rather than as well as, the maximum distance, or else a cattle farm might connect to a dairy on the other side of the map in 1765 and render both industries useless (and this is likely to happen many times over: recall the prominence of the intercontinental milk trade the last time that we had a game on the Bridgewater-Brunel server). I am somewhat concerned that there will be unconnectable industries even with the distance limit, albeit fewer in number, and I am not yet sure whether a journey time tolerance ought to be introduced here.

In relation to whether only a percentage of travellers would use catering, this would not be too hard to code, and may be sensible; it might be that passengers are more likely to use catering for longer journeys.

I do not fully understand the suggestion of a TPO being relevant only for priority mail - in what way do you imagine it being so relevant? The idea of mail having to go to a post office to be sorted is difficult to implement in a meaningful way: sorting presumably means sorting mail for different places into bags bound for those places; yet, in the case of a TPO, how do we know what mail to load onto it in the first place? There is no use loading mail bound for Exeter on the London to Glasgow mail train. In reality, mail is sorted multiple times, which is why the TPO makes sense, but this is very hard to simulate without a wholly unreasonable degree of complexity.

The original idea for the TPO was to give some use for TPO vehicles that made some sense in the context. The idea was that the player's function was of a rail (etc.) company, not a post office, and so the TPO would make revenue as the Post Office would be charged extra for use to sort the mail on board. It is difficult to calibrate this cost, however, although I am currently reading a book on the history of the Royal Mail that might help in this regard (but it is a very long book, and I am still currently in the 1720s).

As to the path-finding system, I am afraid that I think it extremely unlikely that it will be possible to produce any formula that does not (1) produce more anomalies than it solves; and (2) significantly increase the computational load. Anything that involves using an exact figure for price, as I have written before, will lead to either insuperable problems in which players would get great benefit by slightly lowering prices but are unable to do so or to an intolerable level of micromanagement if players are able to adjust prices finely.

As to specifying the values for catering over time, this is where the proposed system of  inflation is necessary. My plan at present is to use the following idea of prices for each level, based on modern day figures, adjusted for inflation in other eras.

Level 1 would be the equivalent of a packet of crisps and a small bottle of mineral water per passenger - say £3.00 charged to the passenger.

Level 2 would be the equivalent of a cold sandwich and a fruit juice per passenger - say £5.00 charged to the passenger.

Level 3 would be the equivalent of a cup of tea or coffee, a toasted sandwich and a cake per passenger - say £10.00 charged to the passenger.

Level 4 would be the equivalent of a basic two course cooked meal per passenger - say £17.50 charged to the passenger.

Level 5 would be the equivalent of a luxury three course cooked meal per passenger - say £45 charged to the passenger.

For the higher levels, a greater margin of profit (I imagine) over the cost of the actual food supplied (not including staff cost, which would be part of the fixed cost of the catering vehicle) would be made than the lower levels, perhaps ranging from 40% to 60%. This would give:

Level 1: 40% of £3.00 would leave a profit of £1.20
Level 2: 45% of £5.00 would leave a profit of £2.35
Level 3: 50% of £10.00 would leave a profit of £5.00
Level 4: 55% of £17.50 would leave a profit of £9.63
Level 5: 60% of £45 would leave a profit of £27.00

Do these figures make any sense? If anyone has any data to allow these to be made more accurate, that would be most 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.

Vladki

Quote
I do not fully understand the suggestion of a TPO being relevant only for priority mail - in what way do you imagine it being so relevant? The idea of mail having to go to a post office to be sorted is difficult to implement in a meaningful way: sorting presumably means sorting mail for different places into bags bound for those places; yet, in the case of a TPO, how do we know what mail to load onto it in the first place? There is no use loading mail bound for Exeter on the London to Glasgow mail train. In reality, mail is sorted multiple times, which is why the TPO makes sense, but this is very hard to simulate without a wholly unreasonable degree of complexity.

The original idea for the TPO was to give some use for TPO vehicles that made some sense in the context. The idea was that the player's function was of a rail (etc.) company, not a post office, and so the TPO would make revenue as the Post Office would be charged extra for use to sort the mail on board. It is difficult to calibrate this cost, however, although I am currently reading a book on the history of the Royal Mail that might help in this regard (but it is a very long book, and I am still currently in the 1720s).

A few ideas.

Mail in simutrans is often not only "The Royal Mail" or whatever goverment's official postal service, but also many other 3-letter agencies like PPL, DHL, UPS, FedUpEx. Moreover in some paksets, railway luggage cars, bike storage and similar services are coded as mail. (I don't know how in other countries, but in czechoslovakla you could send big parcels by train - with pickup on the station. This service had nothing to do with Czech Post.)

One or two years ago I visited a museum of Czech TPO, and subsequently read a nice story about how it worked (in Czech only, sorry). Of course they got the mail somewhat pre-sorted before loading it on the train (they even had special TPO buses). But quite a lot of sorting went on during the journey, as the train picked up and dropped off the bags. There was extra processing needed for "Registered mail" (Lettre recommandée) - it had to be checked if nothing is missing and signed off by the postman on the train. I have used wrong term "priority mail" but I meant "registered mail" which would produce extra revenue. There are other classes of mail (valuables, fragile stuff), that need to get extra treatment for extra price.

If you deliver mail in game, you effectively embrace the role of the postal service with all its costs and revenues. You do not rent the waggons to postal service. You pay the postman's wages, and get paid for delivering the mail. So a TPO should have higher fixed costs than a plain mail waggon that is loaded at one place, and unloaded at onother. Unfortunately we cannot simulate that, so I thought that using TPO to get extra revenue from "high class" mail might be way to go. Or in similar way to catering - low class mail will generate only small extra with TPO, while high class mail will generate more extra.

Another way to distinguish TPO from unmanned mail waggons like GUV, could be the loading time. Czech TPO had 4 minutes time limit to load and unload mail during the intermediate stops - they were attached to night express trains. Of course in that case you do not have to specify catering or anything like that. Just make the TPO load quickly, so it won't delay passenger trains too much, while generic post office waggons will take much longer to load/unload - a time comparable to piece goods waggons.


jamespetts

The loading time suggestion will not work, as, in reality, TPOs were a few vehicles in a train of ordinary mail carriages, and the loading time in Simutrans-Extended is based on the loading time of the longest loading vehicle in a convoy.

The idea of a TPO earning revenue from higher class mail might conceivably work, but I cannot see how this could be balanced or calibrated using historical data.
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.

Vladki

Quote from: jamespetts on April 30, 2017, 12:12:05 PM
The loading time suggestion will not work, as, in reality, TPOs were a few vehicles in a train of ordinary mail carriages, and the loading time in Simutrans-Extended is based on the loading time of the longest loading vehicle in a convoy.

That may be the difference in the usage of TPO in UK and CS. Czechoslovak TPO was usually only one car attached to an express (usually night) passenger train. The cars even did not have doors connecting them to neighbouring cars, so the staff could not sort mail in other cars. If more cars were attached, then each of them would have to be staffed. However TPOs were abandoned by czech post in 1999. Now only unmanned mail cars are used only to transfer larger quantities of pre-sorted mail, in mail-only trains, that go non-stop between Prague and few large cities. So they are now more similar to cargo trains than passenger trains.

jamespetts

That is similar to the UK - but the point is that if TPOs had lower loading times, it would make no difference, as the actual loading times would be based on the loading times of the ordinary mail cars in the rest of the train.
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.

Vladki

Quote from: jamespetts on April 30, 2017, 02:36:24 PM
That is similar to the UK - but the point is that if TPOs had lower loading times, it would make no difference, as the actual loading times would be based on the loading times of the ordinary mail cars in the rest of the train.
Yes I understand. What I wanted to say is that if the TPO had comparable loading time to passenger coaches, while plain mail car would have loading time like piece goods waggons, you would be forced to use TPO if you wanted to add mail to passenger train. If the train would be composed only of mail coaches, it would not matter that the loading time is longer, and TPO would not give you any advantage.

jamespetts

Ahh, I see: that is not how TPOs were used in the UK; they were normally part of mail trains, not passenger trains, although some mail was often carried on passenger trains as recently as the early 1990s.
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.