News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Idea: New revenue system

Started by gerw, January 15, 2009, 03:10:33 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gerw

Since the current system is a little bit counterintuitive, I would suggest the following:

If a passenger (or wathever) is created, he calculates the ticket price, which he will pay for the whole route (by distance start - end) and remember it. Everytime he arrives at a station, he will pay some money, but overall not more than he has calculated at the beginning of his journey.

So the ticket price will not depend on your transport system, only one the distance.

[Comment about programming: this can be done with an additional variable in ware_t. If goods are merged, you add the two values, if some money is payed, you will decrease this value. So it is small effort.]

prissi

OpenTTD has a similar system with transfer money and the like. It did not work well there.

Also I doubt I can either choose airplane or intercitybus for the same price when going from Berlin to Moscow ...

I am not sure i what aspect the system is counterintuitive. You are payed the distance you are traveled (with or without a speedbonus, that depends on the pakset makers.) You can see the money you get from the goodlist, even with speedbonus.

I fail to see how a box of books paying the price per leg travelled would be different from a game, where the speedbonus is just set to zero.

gerw

It is counterintuitive that a convoi can have a negative income at a station. The reason for this is clear.

prissi

How much would you pay then in your system?

The old system just payed for the distance traveling (thus always positive). But it had to be changed to avoid cheating by just bouncing a fully bus between two stations endlessly. Furthermore it tells you, that this routing of the vehicles is probably not the most clever arrangement anyway.

jamespetts

Whilst I do agree that the current revenue system is counter-intuitive (both the speed bonus and the negative revenue), the system proposed would also be counter-intuitive because it is too simplistic: as Prissi pointed out, in reality, people do pay more for one sort of transport than another based on the quality of that mode of transport, and that is an important aspect to simulate in the game.
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.

Zeno

Actually I find current system fine. It's quite simple: more speed, more income, and it's not so far from real life. Maybe something could be done to negative incomes, but if transport is slow and running cost is greater than ticket income... that's what you get ::)

isidoro

The present system is not much different from the proposed one.  The net amount the company gets depends only on distance from origin to destination.  What happens is that the partial amounts can be negative.  Let's say that in one step the route gets away from destination.  Company then gives money to passengers because they will be charged again when coming back from the detour, so that the net amount is zero...


robofish

I prefere the current system as well.
Furthermore we shouldn't change this core elements of the game too often and too much.

gerw

Maybe I will explain it with an example.

Imagine you have three stations ABC, all distances are one. A pax want to go from A to C. A airplane is going between A and B and a bus between B and C.
When created, the pax calculates his ticket price as 1. When he go from A to B he will pay 0.5 (maybe multiplied by speed-bonus) and he will pay 0.5 when he go from B to C. Here it is mainly like the current system.

Now imagine, the distance between A and C is 0.1, but the only connection is with transfer in B like above.
In my system the pax will totally pay 0.1. In the current system he will pay the same as in the above example, because he will pay for each transfer.

Or in other words: A pax traveling form A to F with transfers in BCDE will totally pay (without considering speed bonus):
current system: d(A,B) + d(B,C) + d(C,D) + d(D,E) + d(E,F), so it is route dependent
my proposed system: d(A,F), so it is route independent

jamespetts

Hmm, I am not sure that that is correct in relation to the current system, after Isidoro's patch from October, at least: is not each step now calculated as a proportion of the entire journey, such that some steps can even be negative?
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.

prissi

Well, this was also suggested. But in real life, people do to do the same (like going from Berlin to Helsinki via Frankfurt and they pay a higher price than they would have to pay for a direct connection). So not completely unrealistic (and it avoids all hassle with keep track of origins.) Furthermore with the current system the income at B is negative and the total income (suppose they use the same plane) is nrealy the one you proposed, without the hassle of tracking origins.

gerw

#11
Quote from: prissi on January 16, 2009, 09:37:10 AM
Furthermore with the current system the income at B is negative
But the income is positive, if the pax changes convois at B, isn't it?

If a pax travels to D, next via is C, last halt A, then he will pay (current system) at station B:
d(A,C)-d(B,C)

Am I right?

isidoro

What you propose is what we have now, imho.  Imagine A-B-C-D.  You pay:

  • d(A,D)-d(B,D) in B
  • d(B,D)-d(C,D) in C
  • d(C,D) in D

Some of them may be positive, some negative, no matter.  If you add them all, it gives d(A,D), just what you are proposing.
That's a clever way for the company to receive only that amount without keeping the origin station in the data.  If origin is kept, data structures will grow a lot.  Now, all passengers with same destination although different origin are merged together.  If that were not the case, there should be a data structure for all possible origin-destination combinations.  Too much...

prissi

Well, I looked in the code; The revenue is based on the Zwischenziel (intermediate destination). Maybe we should base it on the final one? Change is only two lines in calc_gewinn.

I have made a change; if pay_for_total_distance=1 in simuconf.tab, price is calculated for the distance you got nearer to destination. This will make most games extremely unprofitable though.

isidoro

#14
There is a typo in vehicle/simveikel.cc: is_pay_form_total_distance...  The 'm' should be deleted.

EDIT:
Looking back at the code, isn't it the other way round?  Now, it says:
if (is_pay_for_total_distance())
   use transfer
else
   use destination

Should it be the opposite?
By the way, I've tried with total_pay and, it's true, all my passenger companies went into deficit at once.

EDIT 2:
Now I understand gerw point.  I was wrong.  I didn't understand...

jamespetts

The discussion of the revenue model is a most interesting one: paying for the final rather than the intermediate destination is an interesting idea, but, as Prissi pointed out, that is not necessarily how it is always done in reality: if people need to take a circuitous route, they have to pay for it. (They may be far less inclined to take public transport to that destination at all if the route is too circuitous - if it is possible without slowing the game too much, it might be worthwhile making a comparison between the as the crow flies distance and the route distance part of the quality of service metrics that are being developed by Isidiro).

Incidentally, I was having a very interesting conversation this evening with a gentleman who works for the Department of Transport. He explained that the main factors affecting revenue-per-mile for passenger journeys were comfort and journey times. Business travellers will often do a substantial amount of work on long-distance trains (often in first class), and are prepared to pay good money for the ability to do so. He thought that a system for revenue calculation based on top speed alone might be a little crude (it is certainly, as has been suggested elsewhere, counter-intuitive and confusing for newer players).

There may be some real merit in carefully re-considering the revenue model for Simutrans, and perhaps initially implementing the new model alongside the old with an option for users to choose between them, and doing a considerable amount of play testing to compare the both both for fun and realism. It would have to be sufficiently simple to be quick for the computer to calculate, and easy for the player to understand (preferably, the player should have a vague idea how it works just by looking at the interface, without even reading documentation: something that is not true of the speed bonus system), it would have to work appropriately without requiring all the vehicle assets to be re-coded (that does not rule out adding new asset parameters - it just means that there would have to be some intelligent guessing as to the new parameters based on existing parameters where the new ones are not specified), and also easy enough for Pakset authors to understand and make the task of balancing the sets not unduly difficult.

One possible model to consider is something like this: revenue is still calculated per unit of cargo per kilometre, and there is a base price for each type for each type per kilometre, as there is now. There might be some merit, however, in having a system that provides a non-linear curve for very short and very long distances: a passenger taking a 100 mile coach trip will rarely pay 100 times what a passenger taking a 1 mile 'bus trip would pay. Instead of having the concept of a speed bonus, there would instead be (1) a level of "accomodation"; and (2) a revenue bonus/penalty depending on either the actual journey time, or the average journey time for that line, per leg of the journey (the former is easier to code, the latter is in some respects more realistic and more stable, but would be harder to make work well).

Accommodation is the extent to which the vehicles are accommodating to the cargo. For passengers, it would be the level of comfort; for manufactured goods, the ease of loading and unloading and the level of breakages; for farm produce, the level of spillage, and so forth. Some products, such as bulk goods, would not really have a concept of accommodation. Different cargos would have different levels of accommodation - indeed, the existing data for the speed bonus percentages could perhaps be used without modification for this purpose. Having a catering vehicle (for passengers) or a travelling post office vehicle (for mail) could add a further revenue bonus (indeed, this could work with the current speed bonus system, too - I am working on coding that at present).

The accommodation level would be something set in the .dat file for the vehicles. A value expressly set at 0 would be the lowest level of accommodation that the passengers/senders of the goods are prepared to accept. Adding something to .dat files, of course, raises the possibility of having to re-do existing work in great quantities, which is where a function for making intelligent extrapolations comes in. It should not be too hard to code a function (1) to detect whether there is any level of accommodation specified in the .dat file; and (2) if there is not, to calculate one based on the capacity of the vehicle divided by its weight (the latter being an approximate indication of its size). So, older vehicles that had no accommodation value expressly set could still have an intelligent accommodation value and work properly with the proposed revenue system.

I know that the issue of the revenue system has been raised a number of times before, and no changes made to it so far; it is something that is difficult to balance to get exactly right, and so I can understand the reluctance to change something that evidently works well enough now to produce an enjoyable game, but I think that there is value in at least investigating experimentally alternative options (by coding them and letting beta testers try them in practice to see how they work) because there are a number of disadvantages with the current system. The fact that the issue is often raised for discussion is perhaps an indication that the revenue system could benefit from some degree of improvement. I know that an area of core game mechanics ought be approached with some caution, but I think that it is worth trying.

I should be very interested in people's views on possible alternative models at this stage, so that something worthwhile can be coded and tested so that, in deciding whether to adopt a revised revenue model, we are in the best possible position to do so.
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.

Roads

I don't see a real problem with the system now.  That said I'm a newbie and also run a small transport system so money is always tight.  That's good. :)

However I am not at all opposed to a complex system of revenue if it is very transparent to the player.  What I would like to see is when you click on an industry, there is an amount shown on the industry popup window that indicates how much that industry will pay per unit for transport to the consumer.  Let the player decide if he can profitably transport the goods.  Actually the player could just try it and see if the transport was profitable or if transporting at an unprofitable rate was worthwhile because of the good's impact on more advanced production.

I would assume that transporting goods for a long distance would pay more than transporting them a short distance but only proportionally.  The amount the supplier pays could remain static throughout the game or could fluxuate.  This could be an option for the player to set/change.

Of course we would need to know how much a loading bay was costing...

gerw

Quote from: prissi on January 16, 2009, 09:47:32 PM
This will make most games extremely unprofitable though.
This I had expected. The advantage of my suggestion is, that all involved convoys get some money.

Example:
A B                                C D
Pax travelling from B to C: B->A bus, A->D plane, D->C bus.

With pay_for_total_distance=1 the buses won't get any profit (even loss), but with my suggestion they do.

z9999

@grew
How do they divide their money ?
If they have only money from b to c, they exhaust their money when they arrived at d.
They don't know how many time they will transfer in the future, don't they ?

isidoro

The problem I see with the destination option is that the companies cannot refuse to load low-profitable passengers.  Even, in multi-player, one company can induce deficit to another by carrying low-profitable passengers to a public station served by the latter...

gerw

Quote from: z9999 on January 17, 2009, 12:18:55 PM
@grew
They don't know how many time they will transfer in the future, don't they ?
If a passenger search his route, he know the entire route. Therefore he can remember the total distance to travel and can calculate an individual price per distance.

Quote from: isidoro on January 17, 2009, 08:11:27 PM
The problem I see with the destination option is that the companies cannot refuse to load low-profitable passengers.  Even, in multi-player, one company can induce deficit to another by carrying low-profitable passengers to a public station served by the latter...
But then it will make deficit itself.

The disadvantage of the current revenue system is, that ring shaped lines won't make profit anymore. So you are forced to build straight lines or direct connections between stops.

prissi

They still make money. Albeit much less. The total income with this setting (which is off as defualt) is the same than you proposed, if I did not got you wrong.

gerw

Quote from: prissi on January 18, 2009, 11:28:01 PM
They still make money. Albeit much less.
My ring lines in cities make deficit. Even the ring lines in yoshis game do so.

QuoteThe total income with this setting (which is off as defualt) is the same than you proposed, if I did not got you wrong.
Yes, that's right.

Fabio


isidoro

Quote from: gerw on January 18, 2009, 08:44:48 PM
If a passenger search his route, he know the entire route. Therefore he can remember the total distance to travel and can calculate an individual price per distance.

Not quite so.  If a passenger has to remember something, then he cannot be merged with passengers with the same destination in the same "packet" as they are now.  Therefore, data stored per passenger would be a lot more and the game would get "heavier".

Goods and passengers with the same destination are merged in a single packet in stations and vehicles.


Quote from: gerw on January 18, 2009, 08:44:48 PM
But then it will make deficit itself.

Sure, but imagine a very big company with a lot of money.  The company can risk to lose some in order to make another weaker company go bankrupt.  That wouldn't be fair, perhaps.


jamespetts

Quote from: isidoro on January 19, 2009, 06:57:04 PM
Not quite so.  If a passenger has to remember something, then he cannot be merged with passengers with the same destination in the same "packet" as they are now.  Therefore, data stored per passenger would be a lot more and the game would get "heavier".

Ahh, yes and no. Yes, the memory usage would increase if it was no longer possible to merge all goods/passengers together and, in effect, have all a vehicle's cargo stored just as a two-dimensional array of integers (x number of cargo type y heading for destination z); but no in the sense that having cargo remember their entire route would reduce the processing overhead. Currently, the cargo's route is recalculated every hop. That is, if there is a local passenger train, for example, each passenger recalculates the whole route every station. If cargo was able to store its route, it would not be necessary to do so much recalculation.

Besides, memory now is far cheaper than it was in 1999. What was excessive overhead then is not excessive overhead now. The time has come, I think, to use more complex data structures for storing information about the cargo carried in vehicles.
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.

gerw

Quote from: isidoro on January 19, 2009, 06:57:04 PM
Not quite so.  If a passenger has to remember something, then he cannot be merged with passengers with the same destination in the same "packet" as they are now.  Therefore, data stored per passenger would be a lot more and the game would get "heavier".
No. You can just merge cargos with same destinations, since they have the same distance left. And you wouldn't save the price per tile, but just the total price and the distance.

isidoro

I cannot agree with any   ;D

There is not such a bidimensional array in current implementation.  Let's take a station.  There we have 12 passengers to A, 15 to B.  Once stored in the station all particular information of those passengers is lost.  Some came from X, some from Y, etc., but nobody knows.

If now 17 passengers from Z going to A arrive, they are merged with the 12 in the station.  Simply the number of passengers going to A are increased to 29 and no extra memory is needed.   Even, James, no new route is calculated.  The one of the passengers waiting at the station is reused.

If you want to keep particular information, that merging process is not possible any more.  The 29 passenger packet would be split in several packets, depending on the extra information you want to store.

Memory is time and time is money.  The more bits saved, the better.  The dream of infinite memory produces monsters, Vista-like monsters.   :P

jamespetts

The more bits saved the better, indeed - but only in so far as it does not unduly limit functionality, otherwise we'd all be using DOS ;-)
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.

gerw

Quote from: isidoro on January 19, 2009, 11:35:32 PM
If now 17 passengers from Z going to A arrive, they are merged with the 12 in the station.  Simply the number of passengers going to A are increased to 29 and no extra memory is needed.   Even, James, no new route is calculated.  The one of the passengers waiting at the station is reused.
You can still join it. The passengers waiting at the station will pay 100$ and the remaining distance is 10. So we have a price per distance and pax: 100/10/12=0.83. Now the passengers from Z arrive, they will pay 200$ for the remaining route. Since now they take the same route like the passengers waiting, we join them:
29 pax to A, remaining distance: 100, money: 300$

We get a (average) price per tile and pax: 300/10/29 = 1.03.

prissi

But then the revenue of a convoi will be different each run depending on where the people came from. (Well, same for the setting with only distance to destination.) And you would still get positive money for moving people  half a map in the wrong direction.

Airplane companies doing that will charge usually more for this compared to the case of direct connections available. Thus like the current system.

gerw

Quote from: prissi on January 20, 2009, 09:48:11 AMAirplane companies doing that will charge usually more for this compared to the case of direct connections available. Thus like the current system.
Of course. But people will refuse travelling from Berlin to Munich via LA. In simutrans they don't care.

isidoro

Quote from: gerw on January 20, 2009, 07:59:00 AM
You can still join it. The passengers waiting at the station will pay 100$ and the remaining distance is 10. So we have a price per distance and pax: 100/10/12=0.83. Now the passengers from Z arrive, they will pay 200$ for the remaining route. Since now they take the same route like the passengers waiting, we join them:
29 pax to A, remaining distance: 100, money: 300$

We get a (average) price per tile and pax: 300/10/29 = 1.03.

Well, that method is what I used to keep track of average waiting time for passengers in the QoS patch...

But the main point about how other player can take your finances down persists...  I like the present system because you can foresee your profit if you combine it with the wait till 100% loaded...

And one last comment.  With your system, let's say that every packet of passengers has some money attached to it.  The next step would be to put a configurable ticket price in vehicles so that passengers with less money will not be transported, wouldn't it?

Fabio

Quote from: isidoro on January 20, 2009, 08:48:10 PM
The next step would be to put a configurable ticket price in vehicles so that passengers with less money will not be transported, wouldn't it?

finally!!! this is coming to what i was asking in another thread...

whoami

Quote from: isidoro on January 20, 2009, 08:48:10 PM
The next step would be to put a configurable ticket price in vehicles so that passengers with less money will not be transported, wouldn't it?
Actually, people who can't complete the journey with my connections shouldn't start with my company at all.
But the idea is nice, and this could even be combined with a degredation of the remaining amount over time: People will eventually be fed up by the time spent (waiting, on slow vehicles or on detours), and continue with a taxi or by hitchhiking - people would disappear from the station, but thereby increasing the remaining (average) amount per person. It can also be combined with QoS (comfort+speed) rating.

The problem is with assigning transportation performance to vehicles - if one (which itself doesn't reduce the remaining distance) is necessary within the whole route, it has to be kept to get the whole revenue, even if it has to be subsidized. The need for the latter could be seen by having a variable (with chronology) per vehicles that records actual utilization - it might even exist already - in a way that the current revenue is calculated for: reduction of distance to the next transfer station.

Most of these things have been written about in earlier discussions about changing revenue. The crucial point is to not extend the size of the goods packet data structure (ware_t) without real good reason (because of this, patches to change revenue calculation didn't make it into the trunk). Memory is extremely cheap nowadays (about 10,000 times less than when I bought RAM for the first time), but all the bytes in question have to go through the CPU and its caches, and that costs performance. Whether a computer is (and feels) really fast just depends on map size and the number of lines/vehicles on the map.