Do we have Ticket Prices yet?

[Frodolf]

Hello,

Every other year I do a search for my most favourite features I'd like to see in OpenTTD, and I'm glad that more and more of these are actually finding their way into reality. Big Thank you to all the devs out there! Today, I was trying to find out, again, if there's a patch that enables us to set pax ticket prices for specific routes. This has been talked about for ages but it hasn't been done by anyone yet, has it? Just asking in case I missed it.

Cheers

[kutagh]

Ticket Prices aren't easy to implement in a way that it makes sense and adds to the gameplay:

You can implement it in such a way that the player has unlimited control over ticket prices. But pax is just treated as cargo (with a specific destination in CargoDist) and has no needs for price efficiency, instead giving a flat rate for a specific distance traveled in the number of days (which CargoDist tries to optimize by using the fastest connections first). To make ticket prices actually influence how they go there, means creating a couple new algorithms for CargoDist:

• Make destinations less desirable if there is an excessive ticket price, so more pax go to other destinations (from a specific starting point, not in general).
• Create an algorithm that balances time against cost to determine the specific route taken to that destination.
• Reduce the amount of pax generated if a target destination has only excessive ticket prices
• Create an algorithm to decide whether a ticket price is excessive.

You can implement it in such a way that the player has only limited control over ticket prices, basically being able to choose [very cheap|cheap|normal|expensive|very expensive] and have it influence the amount of pax traveling the line... But how to balance it so it makes sense? You basically have the same situation as above, except that you already know whether it is excessive or not. So it still is a lot of work.

You can implement it in such a way that the game controls the ticket prices. What basically happens is that you get a fixed price for a specific traject that reflects the current model already: Distance versus time. So it would just be a gimmick and only be equal to the current situation if you play without breakdowns. When you factor in breakdowns, fixed prices are better for you and don't encourage good maintenance anymore. So it basically makes the game easier for you or is just a substitute of the current game mechanics.

Considering the fact that CargoDist got accepted into trunk recently, I doubt that you will get ticket prices unless you're willing to use an outdated version, where this might be easier to implement but most people will consider it wasted effort since they can't really update it properly to trunk.

You could however have an estimated or average ticket prices (based on the current game mechanics) showing on a specific connection without influencing anything, but I doubt that this is what you were looking for...

[Frodolf]

I don't know how CargoDest works in detail, so my suggestions might seem a bit naive.

Assumption 1) There's X amount of people who want to travel from point A to point B.
Assumption 2) Your services have an approval rating which is determined by their performance (e.g. reliability, and maybe other factors later on)
Assumption 3) Only a certain percentage of citizens are willing to pay more for better service (speed).
Assumption 4) There's a specific ticket price (STP) for that distance, just as it is calculated in the current game.

Now, as a player what I want to control is the amount of people that are taking busses, trains or planes (or my service instead of my competitor's). Let's assume town A and town B are connected via trains and via airplanes - most passengers will choose the plane, because it's more direct and probably much faster - so my airports will overflow with pax but my trains might be empty. I need to make air travel much more expensive in order to get more people to use other forms of transport.

So everytime a new citizen is born, he's got to make a decision which route to take, which is not only based on speed.

(Travel time * Ticket price) / Performance in % == Y
Y is a threshold value. If it's bigger than a certain number (Z) then people will choose that form of transport.
Z is (somehow, open for suggestions) taken from the standard ticket price which is currently used to determine what Pax pay for a certain distance over a certain time.

Some citizens have a bigger wallets than others, so you'll have different thresholds.

Side note: To (automatically) keep up with the changing economy, you don't make the player to set a certain fixed ticket price but a percentage-based deviation from the standard ticket price. Something like (1+p)STP, e.g. (1+0,2)*50 in case you want 20% more than the STP ($50) would be on this route.

I've done a more elaborated version of this calculation a few years back which worked fine in a little PHP test game I made - but obviously, OTTD works different so it might not be applicable at all. But you get the idea, I reckon...

> Make destinations less desirable if there is an
> excessive ticket price, so more pax go to other
> destinations (from a specific starting point, not
> in general).

Or they take the car (meaning, they're not (visibly) travelling at all). Some old CargoDest-Mods worked that way, IIRC. It's a bit unfair, of course, when you don't have a big network in the beginning.

Still need to find a solution what this could look like in the game's UI. Maybe set the "price" (the deviation from the STP) in the timetable window of each route, or maybe, in each station's window have a list with all possible destinations (so, in a proper network ALL other stations ;)) and set the price for every destination here...

[kutagh]

So you already realize that it is not just creating the algorithms, it is also tweaking the actual parameters and testing them in various scenarios... Plus actually factoring in the UI modifications. And then you need to look at how CargoDist assigns specific cargo a specific destination to basically adapt it to use your traject calculations, yadda yadda yadda...
May I also point out expected waiting time, which you haven't factored in yet? Because if a thousand pax are waiting on a train with 250 pax capacity that has a direct connection to their destination, while there is a regular 400 pax capacity train that takes a bit longer, wouldn't part of the pax choose to take the longer route in exchange for less time taken overall? (CargoDist solves this with saturation thresholds).
And you need to not only make the decision on the route taken, but ensure that it is still a viable option. Routes can change, be eliminated, yadda yadda yadda. I'd say check at every hop in the journey whether the journey is still valid.


So basically you need someone who is interested into coding this, which is not a trivial task as I think I pointed out. But since you have some programming experience, you might want to give it a go yourself. And as for how CargoDist works, you can basically assume that it generates a graph with connections between nodes encoding the capacity, distance and probably the speed too. You would have to expand those connections to encode the cost too and adapt the graph search functions and the heuristics to utilize that cost.
Can I also recommend you to not use the station window to set the ticket price, instead using the timetable window, because you can have multiple trains with different capabilities running on the same traject that you might wish to differentiate in pricing? For examlp a normal train versus a low capacity high speed train.

And I haven't heard you on how to approach delays. Currently if you have a significant delay, you get less money for the same cargo delivered. However, with fixed ticket prices, you need some way to encourage players to avoid regular delays because they're not being 'punished' for subpar service anymore.

[YNM]

Seems like you have to talk to fonso, OpenTTD devs, and other people who have coded things like cargodest, YACD - they've passed through soo many cases on these kind of thing.

Btw, from the name "ticket prices", it sounds like too much micromanagement. Maybe you could improve the current CargoDist, which is in the trunk.

[Eddi]

my own personal approach to "ticket prices" is a vehicle set where "more expensive" long distance wagons have slower cargo decay rates (i.e. when it arrives at the destination, it treats it that less time has passed), but instead lower capacity (so you can't transport as many people in tight spaces)

the only "micromanagement" involved is which type of wagon you buy.

[Xaroth]

I Disagree that ticket prices can only apply to PAX; when you send a box of <insert content here> to somebody, you also pay a price.. that price depends not only on where you send it, but also with who you send it.. UPS and DHL both use different rates..

It could add a nice new way of competing with other companies.. not just in rating, but also in prices

[kutagh]

@Xaroth: While it is true that it can apply to everything, there is an issue for competition: Those with deep pockets can afford it to run it with massive losses, while a newcomer would require at least a cost covering income. This makes me a bit hesistant about ticket prices, because do we really need another way to discourage newcomers (That is assuming both can get enough capacity to carry all cargo)? If you ignore that concern, then yeah it is a nice way to compete with others.
@Eddi: And then you need to get current vehicle sets rebalanced, because people will still want to play with those. Good luck with that...

Can I also mention the fact that it might be a hassle adjusting existing ticket prices without a new generic purpose window that shows all 'connections' on which trains are traveling (so if a train goes from A-B-C or from A-C, they both show up under the A-C header but former also under A-B and B-C, for logic sakes ordering it alphabetically) to get a list of all timetables running on that traject. Add filtering on vehicle type and if all cargo types are added, filtering on cargo too. This would give you easy access to all timetables. It would be a nice way to get started on this project.

[Xaroth]

@Xaroth: While it is true that it can apply to everything, there is an issue for competition: Those with deep pockets can afford it to run it with massive losses, while a newcomer would require at least a cost covering income. This makes me a bit hesistant about ticket prices, because do we really need another way to discourage newcomers (That is assuming both can get enough capacity to carry all cargo)? If you ignore that concern, then yeah it is a nice way to compete with others.
@Eddi: And then you need to get current vehicle sets rebalanced, because people will still want to play with those. Good luck with that...

Can I also mention the fact that it might be a hassle adjusting existing ticket prices without a new generic purpose window that shows all 'connections' on which trains are traveling (so if a train goes from A-B-C or from A-C, they both show up under the A-C header but former also under A-B and B-C, for logic sakes ordering it alphabetically) to get a list of all timetables running on that traject. Add filtering on vehicle type and if all cargo types are added, filtering on cargo too. This would give you easy access to all timetables. It would be a nice way to get started on this project.

Which adds a nice level of depth, don't you think?

Are you, as a big company, willing to run massive losses to screw your competition, or will you play nice?

I mean.. look at all the crap between samsung and apple ..

[kutagh]

[..]

Which adds a nice level of depth, don't you think?

Are you, as a big company, willing to run massive losses to screw your competition, or will you play nice?

I mean.. look at all the crap between samsung and apple ..

Yeah, it does add a nice depth when it is about estabilished companies, but is that the kind of atmosphere you wish to cultivate in most servers with estabilished companies that cover the whole map and new players joining? That is what I'm trying to point out, it does not necessarily make the game more fun for everyone. However, if the server can limit how bad this can get, for example in terms of [no limit, at least break even, fixed price that reflects current implementation] then I'm all for it , but it does add even more complexity to the patch.
There is a reason that I take the time to provide constructive feedback: I would like to see some form of it happening, in such a way that it generally adds to the gameplay, as well as engaging the community to get them to provide more feedback too, like you did But feedback is not necessarily pointing out the positives but also the potential issues, to make people think about how to solve it, or take an accepted risk. You could ignore my worries about competition with no limits on ticket prices, at the risk that it won't get accepted into trunk and thus is only compatible as long as it is maintained by someone. But I assume that we would like to see it coming in trunk eventually, hence the form of my feedback in general: Think about how it integrates with the game and how it adds while minimizing the detracting aspect. The less it detracts from the intended game, the more chance it has for being pulled into trunk.

[planetmaker]

Were I the server owner, I'd disable that feature, if present and possible. I can't be constantly check whether all people play fair. And I want them to be a fun place for all, including those who did not start to play on the map once it was still fresh.

[Mulder]

Well, setting ticket prices should also not only be about competition, but also about demand management, the one aspect I've always felt missing from the game. The only forms of demand management available are station placement and a few tools in the city authority window.

It should be perfectly possible for me to increase my prices to actually deter too many passengers from using routes with lack of capacity and decrease prices to encourage passengers from using routes with spare capacity. (Same goes for cargo - it's sometimes just easier to imagine it in terms of passengers - at least for me).

For it to be effective, it would need to be at least manageable by route or vehicle and not just a blanket price (if you've ever player Cities In Motion, their pricing structure wouldn't actually work).

This form of demand management would be difficult to "calculate" though, especially in cities or industries with monopolies (really thinking about how cool it would make competition!!) - there would be a small number of passengers (cargo) who would go at any price, a normal amount of passengers around the normal prices and passengers who will only be persuaded by lower prices. Passengers or cargo should then always use a combination of acceptable rating and price to determine where to go first - but what happens if their preferred route is full - do they try another?. I think simulating this type of demand could be difficult.

The one other aspect which would need to be considered at the same time is the subsidy system. If I set my prices, a subsidy cannot simply pay quadruple my own rates (there are actually much better ways to do subsidies, but there are "easy" fixes available).

This would really add a great competitive edge to the game and it's not something which seems like it would be too much micromanagement (I mean, there's a whole thread on programmable signals - that imho is too much micromanagement!). Price competition also makes later games much more interesting, because at the moment if you survive for a few months, have a few long routes, money stops being a concern. If you have to constantly remain price-competitive, it becomes slightly more realistic like real companies.

[kutagh]

@Mulder: w.r.t. calculation of demand management: As I mentioned before, we can likely reuse part of CargoDist already for this: It likely models the routes in a graph, with every route consisting of speed and capacity. They use saturation thresholds which basically saturates the fastest route first and once the saturation on that route reaches the threshold, it looks for alternative connections with less saturation. What you need to do is to enhance that code to only saturate with passengers that are willing to take that route at the current price.

[Frodolf]

May I also point out expected waiting time, which you haven't factored in yet? Because if a thousand pax are waiting on a train with 250 pax capacity that has a direct connection to their destination, while there is a regular 400 pax capacity train that takes a bit longer, wouldn't part of the pax choose to take the longer route in exchange for less time taken overall? ;) (CargoDist solves this with saturation thresholds).

Yes, you could use that value for an average/expected travel time.

And you need to not only make the decision on the route taken, but ensure that it is still a viable option. Routes can change, be eliminated, yadda yadda yadda. I'd say check at every hop in the journey whether the journey is still valid.

Valid point.

So basically you need someone who is interested into coding this, which is not a trivial task as I think I pointed out. But since you have some programming experience, you might want to give it a go yourself.

I'd love to, tbh. But even if I had the coding abilities needed for this, I've got so much on my plate atm, I don't even get to reply to this thread in a timely manner (which I feel awful for) :(

Can I also recommend you to not use the station window to set the ticket price, instead using the timetable window, because you can have multiple trains with different capabilities running on the same traject that you might wish to differentiate in pricing? For examlp a normal train versus a low capacity high speed train.

Makes sense!

And I haven't heard you on how to approach delays. Currently if you have a significant delay, you get less money for the same cargo delivered. However, with fixed ticket prices, you need some way to encourage players to avoid regular delays because they're not being 'punished' for subpar service anymore.

You save the calculated travel time for each pax and when he reaches his destination, you look at how long it actually took him to get there. For each tick delay you substract a certain amount of the players earnings (basically: make the pax pay less).

[kutagh]

Don't worry about replying in a timely manner, life happens And you don't have to work alone, but I think you would significantly improve the chances of this actually happening by starting the project and finding other people that want to collaborate on this. It is going to take a significant chunk of time to really outline how it is going to work, due to the research into how CargoDist works and how you can adapt it to suit your needs.
I just got to say that if you want this happening, it is far better to at least play a role in it than just asking all the time whether someone will do it. People don't really like to work on projects just because someone wants it, but they don't mind working as much on interesting projects where they're not the sole developer but rather just helping out (read: where they're not the lead nor responsible for keeping the project alive, so they basically can join and leave at any time, basically how OpenTTD development works with patches ). And yes, it will cost time too. Just like OpenTTD did cost a lot of time to get to a playable state at all