The International Simutrans Forum

 

Author Topic: Idea: New revenue system  (Read 10439 times)

0 Members and 1 Guest are viewing this topic.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Idea: New revenue system
« on: January 15, 2009, 03:10:33 PM »
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.]

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9518
  • Languages: De,EN,JP
Re: Idea: New revenue system
« Reply #1 on: January 15, 2009, 03:17:58 PM »
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.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #2 on: January 15, 2009, 03:24:33 PM »
It is counterintuitive that a convoi can have a negative income at a station. The reason for this is clear.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9518
  • Languages: De,EN,JP
Re: Idea: New revenue system
« Reply #3 on: January 15, 2009, 03:28:35 PM »
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Idea: New revenue system
« Reply #4 on: January 15, 2009, 07:21:45 PM »
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.

Offline Zeno

  • ENASSA Designer
  • Devotee
  • *
  • Posts: 1997
    • Zeno's Simutrans Creations
  • Languages: ES, EN, CAT
Re: Idea: New revenue system
« Reply #5 on: January 15, 2009, 07:30:57 PM »
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 ::)

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #6 on: January 15, 2009, 08:12:47 PM »
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...


Offline robofish

  • Devotees (Inactive)
  • *
  • Posts: 130
  • Languages: DE, EN
Re: Idea: New revenue system
« Reply #7 on: January 15, 2009, 10:43:46 PM »
I prefere the current system as well.
Furthermore we shouldn't change this core elements of the game too often and too much.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #8 on: January 16, 2009, 07:58:15 AM »
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

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Idea: New revenue system
« Reply #9 on: January 16, 2009, 08:56:12 AM »
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?

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9518
  • Languages: De,EN,JP
Re: Idea: New revenue system
« Reply #10 on: January 16, 2009, 09:37:10 AM »
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.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #11 on: January 16, 2009, 10:16:20 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?
« Last Edit: January 16, 2009, 10:19:57 AM by gerw »

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #12 on: January 16, 2009, 08:05:46 PM »
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...

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9518
  • Languages: De,EN,JP
Re: Idea: New revenue system
« Reply #13 on: January 16, 2009, 09:47:32 PM »
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.

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #14 on: January 16, 2009, 10:45:14 PM »
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...
« Last Edit: January 16, 2009, 11:31:59 PM by isidoro »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Idea: New revenue system
« Reply #15 on: January 17, 2009, 12:00:58 AM »
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.

Offline Roads

  • Devotees (Inactive)
  • *
  • Posts: 645
Re: Idea: New revenue system
« Reply #16 on: January 17, 2009, 02:16:52 AM »
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...

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #17 on: January 17, 2009, 08:22:32 AM »
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.

Offline z9999

  • Devotees (Inactive)
  • *
  • Posts: 848
Re: Idea: New revenue system
« Reply #18 on: January 17, 2009, 12:18:55 PM »
@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 ?

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #19 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...

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #20 on: January 18, 2009, 08:44:48 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.

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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9518
  • Languages: De,EN,JP
Re: Idea: New revenue system
« Reply #21 on: January 18, 2009, 11:28:01 PM »
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.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #22 on: January 19, 2009, 01:03:08 PM »
They still make money. Albeit much less.
My ring lines in cities make deficit. Even the ring lines in yoshis game do so.

Quote
The 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.

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Idea: New revenue system
« Reply #23 on: January 19, 2009, 01:44:17 PM »
My ring lines in cities make deficit. Even the ring lines in yoshis game do so.

see here for sugestions
http://forum.simutrans.com/index.php?topic=1194.msg12378;topicseen#msg12378


Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #24 on: January 19, 2009, 06:57:04 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.


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.


Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Idea: New revenue system
« Reply #25 on: January 19, 2009, 08:09:36 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.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #26 on: January 19, 2009, 08:21:37 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.

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #27 on: January 19, 2009, 11:35:32 PM »
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

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Idea: New revenue system
« Reply #28 on: January 20, 2009, 12:00:20 AM »
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 ;-)

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #29 on: January 20, 2009, 07:59:00 AM »
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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9518
  • Languages: De,EN,JP
Re: Idea: New revenue system
« Reply #30 on: January 20, 2009, 09:48:11 AM »
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.

Offline gerw

  • Coder/patcher
  • *
  • Posts: 618
Re: Idea: New revenue system
« Reply #31 on: January 20, 2009, 10:06:05 AM »
Airplane 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.

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Idea: New revenue system
« Reply #32 on: January 20, 2009, 08:48:10 PM »
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?

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Idea: New revenue system
« Reply #33 on: January 20, 2009, 09:06:30 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...

Offline whoami

  • Devotees (Inactive)
  • *
  • Posts: 693
Re: Idea: New revenue system
« Reply #34 on: January 21, 2009, 02:34:55 AM »
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.