News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Raise rail fares

Started by AP, January 02, 2013, 10:18:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AP

Noting that in the news recently, UK rail fares have gone up (again!) and are now the most expensive in Europe (if they weren't before) has got me thinking.

If one has a passenger network that us cursed by overcrowding, would that not be an ideal opportunity to raise ticket prices and thus both increase revenue per seat filled, and decrease overcrowding as fewer people travel.

If this could be done on a per-line basis, rather than universally (per-company) it would enable competition between routes, and perhaps subsidies too...

No idea how easy it would be to impliment though... since I suppose at present passenger generation derives from service provision not affordability.

jamespetts

I have considered the issue of variable pricing in the past. My view at present is that it is best not to implement it. If demand is affected by price, then either players will have to control prices on a per-line basis manually, or there will be perverse results (lines being unprofitable when they could be profitable if only the prices were higher/lower). The latter result is the sort of aberration that we must avoid in order for the game play to be satisfying.

If, however, players have to price each individual line, the game will become, I fear, painfully tedious. The best way to go, I think, is with the assumption that the accountants get the pricing at the optimum level automatically and passengers (and mail and freight) follow. The overcrowding issue is best alleviated by a proper balancing of the passenger generation settings, I think.
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.

AP

That is a very well rationalised point. I'm inclined to agree with you.  :D

asaphxiix

well, players already have to set the frequency/number of convoys of each line.... which is not an easy semi-automatic process... you have to figure out demand, then figure out trip time, then type of convoy used, then set the spacing. If these actions could also lead to a determination of price, that might work, I think...

Quote from: jamespetts on January 02, 2013, 10:26:47 PM
lines being unprofitable when they could be profitable if only the prices were higher/lower

I actually would think this is just the point of the game, at least one of the points - to figure out the best way to make profit. IRL, pricing is one of the most crucial elements of success, isn't it. Seeing profit rise/drop in reaction to price changes could be very cool, especially when combined with more elements (scale economy, speed, competition etc.).

I think the idea has potential :)

ӔO

#4
I think pricing/fairs/service-quality are best used as a method of competing against opponent lines with similar routes.

For the sake of simplicity, fair rates and service quality can be the same thing, as they will have the same results. Decreasing fair rates, improving service quality, or both will result in more attractiveness in using your company. Likewise, increasing fair rates, lowering quality or both will result in less attractiveness.

Say, a "service quality" scale from 0 to 100 with default at 0. For every 1 point raised, pax would more likely prefer using your network, even if it is slower or the longer way. From my understanding, due to the way routing works, to the pax, this 1 point will "look" like the route is 5% shorter in time, although not actually. This, same, 1 point will raise fixed running costs and maintenance by 5% each.

---
maybe 5% shorter time won't work too well if the scale goes from 0 to 100.
a formula for diminishing returns should work better. http://lostsouls.org/grimoire_diminishing_returns
a scale of 45 would result in 75% shorter time seen for someone willing to put 100 points and 500% on their running costs and maintenance.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

o_O

#5
It would be nice to have ways to discourage passengers from already overcapacity lines and encourage the use of undercapacity ones, but simulating price competition wouldn't really work without AI companies, government services and more detailed private car + economic simulations.  I guess we can semi realistically assume that fares are either set by the company for maximizing income or set by the government for maximizing votes.


Maybe passengers should have an overcrowding tolerance factor, such that a few percent will avoid a severely overcrowded station or line and just disappear or take a car instead without refunds or clogging up other networks.  After all a great many trips are discretionary and will not be taken if its too much of a struggle.

jamespetts

If one were to think of using price as a factor affecting modal choice, then not only do we have the micromanagement nightmare that I described above (and, unlike scheduling, where everybody understands what a certain number of minutes means, how on earth are players supposed to be able to set prices in Simucents and know what proportion of people will be able to afford an arbitrary figure in a made up currency?), but we also start interfering with the routing system implemented by Knightly a long time ago to a high standard that probably cannot be attained by any of the programmers currently working on Experimental. His system is designed to use the travelling time as the ultimate criterion for determining the routes that passengers/goods take. This is a computationally intensive process, and requires a very great many checks of "is X greater than Y"? This is very simple when pairs of integers are being checked against each other; but suppose that we were to add price? What then?

At present, the system inherently works by calculating a single best route from any given stop to every other stop, storing those routes in a table, then infusing the network of stops with information about which transfer stop to which passengers need to catch to go from that stop to their destination. When passengers/goods/mail alight/are unloaded at that transfer stop, that stop holds information about which next transfer stop to catch transport towards, etc., until the passengers/mail/goods reach their destination.

If price were to be a factor in modal choice (and if price is simulated at all as a determiner of anything, it would have to include modal choice) the whole routing system would need to be rewritten from the ground up to accommodate the fact that some people are prepared to pay more for a faster journey, whereas others are more sensitive to price than journey time, and therefore allow multiple routes from everywhere to everywhere else. Not only would this be a monumental coding task requiring somebody as skilled as Knightly to do to a standard matching the current system, but I really doubt that sufficient performance could be achieved by having such a system that calculates many different routes and re-determines the "best" route individually for the many thousands of passenger/mail/goods packets produced every game hour. Even a system that uses more than one factor (journey time and comfort, say), which could conceivably be achieved without a fundamental rewrite by creating a journey_time_comfort struct and providing >, = and < methods to use in the routing system which produce a sort of amalgam of journey time and comfort would quite possibly impose such a burden by having to undertake a set of calculations at each comparison operation (rather than simply comparing pairs of straightforward integers) that I doubt that this, too, would be able to be optimum - and added to that is the difficulty that it is by no means obvious how one goes about combining comfort and journey time to produce a sensible answer to the question "which is the best route from A to B?": how much comfort improvement is worth an extra five minutes? Ten minutes? An hour? What weight does the overall length of the journey have? And so forth. This really is the ultimate can of worms, I am afraid.
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.

The Hood

Worth also noting in this discussion that based on expertise garnerned in a previous job even the professionals can't get this right even remotely accurately. Demand forecasting is notoriously inaccurate but forms a major component of the business case for most large infrastructure projects - e.g. Channel Tunnel was hideously over-optimistic whereas many recent rail reopenings in Wales and Scotland have been so pessimistic that year 1 demand was more than the projected demand 20 years later. If you get this one right, fame and fortune awaits! Anything other than a crude multiplier would be (A) very difficult to implement and (B) probably wrong anyway.