News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Analysis: trip profitability, speedbonus, pakset balancing

Started by moblet, January 31, 2011, 12:14:21 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

moblet

Attached is a spreadsheet I built in an effort to understand trip profitability dynamics in Simutrans. I have been thinking about how to balance paksets, and also about how the non-linear nature of the speedbonus makes pakset balancing more difficult. From playing with numbers on this spreadsheet I am thinking that:
1. The speedbonus feature is not necessary as a reward system for operating faster vehicles, since faster vehicles can make higher profits per hour even if their trips are less profitable per km, because they can make more trips per unit of time. Is the speedbonus there for any other purpose?
2. The profitability performance of faster vehicles in the existing game engine is too sensitive to small changes in revenues and costs (and loadings during the game) to be effectively balanced in a pakset. Either they will end up losing lots of money or making too much money; in the latter case, in the absence of dynamics that significantly reduce the efficiency of faster vehicles on short runs, they will also be more profitable to use on shorter trips than anything else and become the best vehicles to use for almost any purpose.
3. It is possible to obtain some very nice non-linear trip profitability dynamics from a small number of linear parameters, most of which are already in the game. The spreadsheet is designed to explore what happens if there is a linear, time-based revenue decay for a trip. For example, the attached revenue.jpg is a plot of trip revenue vs distance based on three linear parameters: $/km revenue and operating cost, and linear decay of trip revenue with journey time. Each line represents a different average speed for the trip. (Such a revenue decay cannot simply be transplanted in place of the speedbonus as, for one, it has implications for trip generation.)
4. Pakset balancing needs to be considered in the design and execution of the game engine. I don't think that an approach of "code the game, and afterwards let balancing be entirely the pakset developers' problem" can work. If the mechanics of pakset balancing are not thought about in the design, it seems to me unlikely to produce a game where it is possible to balance paksets across 300 years of growth and technology.

Some notes on the spreadsheet:
- White areas are for parameter input
- Trip distances do not have to increment steadily. All charts are X-Y ("scatter") plots.
- The speedbonus is not modelled explicitly. For a very rough approximation, set a small decay and a high floor on the Revenue decay sheet. I can model the speedbonus if people really want to see it, it just makes all the calculations a bit more messy.
- The last sheet contains charts of both profitability per km and per hour. In a balanced game, with a balanced pakset, both of these would have sensible values within the vehicles' practicable operating ranges. I'm not yet sure if it's possible to get both of these charts into sensible territory with the existing game engine.


Spike

Quote from: moblet on January 31, 2011, 12:14:21 PM
Is the speedbonus there for any other purpose?

Players demanded it. Early Simutrans versions did not have it. If I remember correctly I did not do any further analysis, since the feature didn't seem unreasonable at first sight (e.g. tickets for faster trains are more expensive in real life too, express cargo costs more ...)

Edit:

Quote from: moblet on January 31, 2011, 12:14:21 PM
I don't think that an approach of "code the game, and afterwards let balancing be entirely the pakset developers' problem" can work.

A very long time there was no split between program developers and pak set developers. There was only one team until pak128 came into existence. So there was no such intention or thought initially. (I agree that balancing is an issue of coding and data design matters).

Edit 2:

Quote from: moblet on January 31, 2011, 12:14:21 PM
it seems to me unlikely to produce a game where it is possible to balance paksets across 300 years of growth and technology.

The timeline was not part of the initial game design. It came relatively late (from my point of view). The years from 1997 till late in 2004, there was no timeline and evolution. This means that all time-dynamic features that we see nowadays were built onto a game core that was not designed for that.

I do not quite know how relevant this is. The game engine underwent big changes I presume in the past 6 or 7 years, but from other software projects I know that some of the basic designs can be very persistent against change. So maybe we have such a case here, that nowadays it seems to be expected that 300 year of evolution are possible with the game, but the game started with a totally static design (no time dependent changes at all), and it might still not fit well together.

moblet

Quote from: Hajo on January 31, 2011, 12:32:49 PM
tickets for faster trains are more expensive in real life too, express cargo costs more
The catch in Simutrans is that revenue is a flat $/km regardless of the trip distance, so the revenue dynamics aren't the same as the real world. The real world $/km for a 3km urban bus trip and a trans-oceanic flight are very different. That can be compensated for in the sim either by adopting a non-linear trip revenue curve or adjusting the pakset (I would first try to make the latter approach work).
Quote from: HajoThere was only one team until pak128 came into existence....
The timeline was not part of the initial game design.
Ah, I did not know the history that well.
Quote from: HajoSo maybe we have such a case here, that nowadays it seems to be expected that 300 year of evolution are possible with the game, but the game started with a totally static design (no time dependent changes at all), and it might still not fit well together.
My gut feeling is that if a pakset can be adequately balanced at a moment in time, from urban buses to airliners, then provided there are consistent mechanisms for handling wear and ageing, and that historical changes are linear, then it can probably be balanced across 300 years without serious difficulty. The game engine would need some revising, enhancing and tweaking to achieve this, but my sense at the moment is that most, if not all of the game core, would still be there at the end. I don't see that the basic design of Simutrans has to be altered to support this objective.
I must say from a dynamical point of view, from my first game I was impressed at how well, in just-in-time mode, it replicates MIT's beer game, which is used in supply chain education.

prissi

The timeline dependent speed bonus is only used to award the use of newer engines and change the "ideal" engine. With constant timeline, the ideal engine for a certain relation (constant transportation assumed) would be always the same. Something like "people prefer new vehicles".

QuoteThe spreadsheet is designed to explore what happens if there is a linear, time-based revenue decay for a trip. For example, the attached revenue.jpg is a plot of trip revenue vs distance based on three linear parameters: $/km revenue and operating cost, and linear decay of trip revenue with journey time. Each line represents a different average speed for the trip. (Such a revenue decay cannot simply be transplanted in place of the speedbonus as, for one, it has implications for trip generation.)

Maybe there is a misunderstanding. The linear decaying profit make the slower vehicle even less proftiable. (And not to mention: The infrastructure needed for fast vehicles is really expensive. This is an important part when balancing a pak set.)

So I fail to see the suggestion here.

In pak64, the fastest vehicles are the one with the lowest number of passengers. That way the fastest is not the most profitable on short lines with high demand, especially if the infrastructure is made expensive.

moblet

Quote from: prissi on January 31, 2011, 03:57:11 PM
The timeline dependent speed bonus is only used to award the use of newer engines and change the "ideal" engine. With constant timeline, the ideal engine for a certain relation (constant transportation assumed) would be always the same. Something like "people prefer new vehicles".
So if I understand correctly, the role of the speedbonus is to deliberately distort relative performance in favour of a particular vehicle in a particular era, to enforce a timeline dynamic in a game where the player has chosen not to be subject to the timeline. Because if the timeline was enabled, the pakset parameters could achieve this without the speedbonus feature: newer vehicles could have cost and performance parameters that made them ideal until something better became available.
Quote from: prissiMaybe there is a misunderstanding. The linear decaying profit make the slower vehicle even less proftiable.
Decaying profit means slower vehicles earn less revenue, but if their costs are proportionally lower, their profitability can be higher. In other words, in a balanced pakset faster vehicles would have to cost more to run. I am not insisting that decaying revenue is the best approach, just using it to demonstrate how complex non-linear game behaviour can be achieved with simple linear assumptions, to show that it is not always necessary to use a complex non-linear game design to get complex non-linear results.
Quote from: prissiThe infrastructure needed for fast vehicles is really expensive. This is an important part when balancing a pak set
Aircraft infrastructure is cheap. For the purposes of this analysis infrastructure costs can be represented within the $/km and/or $/hr. Infrastructure costs don't change the fundamental issue about the profit sensitivity of fast vehicles, nor can they alone make it uneconomic to use fast vehicles on short runs while remaining profitable on long runs.
Quote from: prissiIn pak64, the fastest vehicles are the one with the lowest number of passengers. That way the fastest is not the most profitable on short lines with high demand, especially if the infrastructure is made expensive.
Again, this is not the case with aircraft, especially compared to land vehicles. I can see how this helps to compensate for the profit sensitivity problem - small capacity vehicles will be much more likely to carry full loads, meaning their revenue performance is constant and maximal, making it easier to balance the pakset, but what should a pakset developer do if they want high speed, high capacity vehicles?

prissi

Instead of a speed bonus there could have been inflation, which will also decrease income from older vehicles. Actually, the speedbonus was there when I took over development. It was introduce in 82.13exp on dec. 2003.

Quotebut what should a pakset developer do if they want high speed, high capacity vehicles?
If he/she/it wants to disturb the balance by such a thing, it could be made very very expensive, so it would take years to pay it back. And you can do it like pakgerman/pak64 planes and ships: They are only profitable for 70% or 90% load.

paco_m

Quote from: prissi on January 31, 2011, 03:57:11 PM
The timeline dependent speed bonus is only used to award the use of newer engines and change the "ideal" engine. With constant timeline, the ideal engine for a certain relation (constant transportation assumed) would be always the same. Something like "people prefer new vehicles".
New vehicles and faster vehicles are not the same. The fastest passenger airplane was built in 1969, the fastest ships (hovercraft) until 1968 - both are retired and current airplanes or ships are travelling at 50% or less of their speed.
Street vehicles, especially buses and trucks and this are our player vehicles (not cars), are limited by law; for example in Germany 80km/h or 100km/h for buses (only when all passengers are seated) and 80km/h for trucks (both on highways).
All highspeed railways I know had been reduced in their maximum speed within the last 20years for security reasons after some crashes.
So whatever way of traffic we watch there was no speed improvement in the last 20-40 years and from the current point of view won't be in the next decades. Imho is the speed bonus as the one and only function to make "newer" vehicles attractive completely unrealistic, however I would appreciate it together with other mechanics like higher maintenance costs for obsolete vehicles.

Quote from: prissi on January 31, 2011, 03:57:11 PM
Maybe there is a misunderstanding. The linear decaying profit make the slower vehicle even less proftiable. (And not to mention: The infrastructure needed for fast vehicles is really expensive. This is an important part when balancing a pak set.)
This is again a problematic point because you actually don't need any (expensive/fast) infrastructure to get the speedbonus as the actual driven speed is of no importance. The speedbonus for a highspeed train travelling 50km/h on sandtrack rails is the same as for a train really using 300km/h.

TurfIt

Quote from: moblet on January 31, 2011, 02:04:10 PM
The catch in Simutrans is that revenue is a flat $/km regardless of the trip distance, so the revenue dynamics aren't the same as the real world. The real world $/km for a 3km urban bus trip and a trans-oceanic flight are very different. That can be compensated for in the sim either by adopting a non-linear trip revenue curve or adjusting the pakset (I would first try to

Don't forget about the strange/weird/wonderful

return (value+1500ll)/3000ll;

in the payment calculation.

Short trips result in a lower 'value' here, and hence get a boost in revenue. IIRC when I worked through some pak128 numbers, urban buses that stop every ~5 tiles were getting ~10-15% bonus over long distance schedules due to this. pak64, with it's 3x higher base rate (for passengers) reduces this bonus to less significance.

prissi

Quotereturn (value+1500ll)/3000ll;
This is just the equivalent of round(value/3000.0) to avoid rounding errors. THe maximum change in income this get is 0.01cr. I fail to see how shorter busstop can improve this.

QuoteThis is again a problematic point because you actually don't need any (expensive/fast) infrastructure to get the speedbonus as the actual driven speed is of no importance. The speedbonus for a highspeed train travelling 50km/h on sandtrack rails is the same as for a train really using 300km/h.
No but then your train will not transport as many passengers. WIth 55km/h only one eightth of 450km/h tracks. THus the total revenue over time would be also only one eightth. Ergo: YOu could use cheaper to operate slow train also.

Zeno

One thing that worries me is the bonus speed ranges based on vehicle type: between a "slow bus" and a "fast bus" there may be... 50 or 60 km/h of difference; between a "fast airplane" and a "slow airplane" there might be 200 or 300 km/h. I really think *that* has ruined all my tries to balance the plane set, because all other vehicles are quite reasonably balanced but fast planes earn zillions and slow planes loose tons of money.

Let me note that the key fact here is time: it can be ok for a certain year, but few years later your economy might change from tycoon to bankrupcy in same time you blink twice ;D

The bonus system works based on how many km/h is over/below the bonus speed, am I right? I wonder if it could be eventually changed to some kind of percent instead of fixed value (10 km/h over 1000km/h are unsignificant; 10km/h over 50km/h is a lot --> 1% vs. 20%, so that would do the job). Or maybe you could give me advise on a balance trick to help me with this... :)

paco_m

Quote from: prissi on February 02, 2011, 09:12:35 AM
No but then your train will not transport as many passengers. WIth 55km/h only one eightth of 450km/h tracks. THus the total revenue over time would be also only one eightth. Ergo: YOu could use cheaper to operate slow train also.
Yes and no xD
The train will transport always the same amount of passengers, just slower - in other words you need more trains to have the same throughput. The only point were this results in higher costs are the purchase costs of the train - running costs remain the same as they are paid for the distance (per km). Normally you don't care about the purchase costs as they are paid only once so you can actually run 12 highspeed-trains at 50km/h at the same running costs as 2 highspeed-trains at 300km/h and will transport the same amount of people but with much lower infrastructure costs.

Zeno

But in general terms prissi is right: you would have 12 high speed trains, very expensive, running at 50 km/h, thus transporting same amount of passengers, but they would have a payback period 12  times bigger... so at the end is aprox. the same :)

edit: well, maybe not 12 times longer, but 5 or 8 or 18, dunno...

prissi

@Zeno:
The speed bonus is relative. This 10% speed increase gives the same bonus, not 10 kmh. And if you do not like speed bonus, then just define it as zero.

In pak64 vehicles are balance in such a way that a vehicle is profitable when it is available until its retire date. Beyond that, it is not generally profitable any more. (Of course with track engines this is very difficult, as it depends on what cars you put after them).

@paco_m
More trains (if made expensive enough) will cost you much more money and they will loose their value faster. And if a train cost like millions, you can make track upgrading cheaper than buying 12 of them.

Actually the purchase costs of pak64 of the advanced stuff are way to low and of some entrace stuff too high. One of the areas that I need to work on.

Additionally I rarely find any player exploiting this in pak64 or pak128. Just look at the savegames: Nobody(?) runs a shinkansen over extended stretches of dirt track. The only "erxploit" is using tramways on dirt track. But those run only 50-60kmh and can be also found in reality (like in Berlin http://de.wikipedia.org/wiki/Sch%C3%B6neiche-R%C3%BCdersdorfer_Stra%C3%9Fenbahn).

Zeno

Quote from: prissi on February 02, 2011, 10:50:27 AM
The speed bonus is relative. This 10% speed increase gives the same bonus, not 10 kmh. And if you do not like speed bonus, then just define it as zero.
Oh my... I didn't thought it was relative, because really *high* speed vehicles (trains and planes) are driving me mad. I thought it was because of that... I will have to start again with it, what else... :-/

TurfIt

Quote from: prissi on February 02, 2011, 09:12:35 AM
This is just the equivalent of round(value/3000.0) to avoid rounding errors. THe maximum change in income this get is 0.01cr. I fail to see how shorter busstop can improve this.
Correct of course in game.  My spreadsheet was missing a <<7 bringing the values down to where an extra +1500 is significant.   :-[

However, the effect of shorter intervals between stops boosting revenue is still present - albeit indirectly. Close together stops make it more likely that the manhattan distance between stops is equal to the distance the vehicle actually travels. Since payment is based upon manhattan distance, and vehicle running costs are based upon the distance actually travelled, profit can be quite significantly affected.

As a simple test case, I set two identical buses off on an identical route between two cities; One running express end to end, one stopping every 5 tiles. Total distance travelled = 82 tiles. Express bus received payment for 74 tiles, stopping bus for 80. Setting pay_for_total_distance = 1 or 2 equalized the reduction (in this case where the intermediate stops have no passenegers on or off) - both buses are paid for 74 tiles. So 74 tiles of revenue with 82 tiles of cost, on a route that was about as straight as you can get without major bulldozering of the landscape.

This effect is what paks need to take into account. It's not unreasonable for a vehicle to travel 20% further than the distance the payment is based upon in a 'real' game. Of course if costs are discounted by 20% for this, that's a large incentive to bulldoze everything and create perfect straight routes for everything...

prissi

Well you can set the setting harder, to only enforce the distance targe source, and not the manhattan distance between stops.

TurfIt

yes. That's what I meant by
Quote
Setting pay_for_total_distance = 1 or 2 equalized the reduction
this eliminates the boost, resulting in both the express and local buses earning the same.

The point I'm trying to make re pak balancing is: If a vehicle is designed with an operating margin of 10%, it's going to have to travel in a perfect straight line to actually achieve that margin in practice. In my example test case, the vehicle would have earned 0 profit for the trip. (74/82=90%). Hence, to be practical, the vehicle will have to be designed with a higher margin, but then it will earn too much if it actually gets used on a straight route.

sdog

just for reference here James and Combuijs based distance calculation in experimental on euclidian distance two years ago:
http://forum.simutrans.com/index.php?topic=1750.0

Perhaps it should be added to Hajo's list of simutrans dynamics, what geometry is used.

prissi

Since vehicles in simutrans have to travel manhatten distance (dependign on diagonal multiplier) using euklidian distance will even require a more straight way and make pak set balancing even more difficult ...

jamespetts

Quote from: prissi on February 02, 2011, 09:09:06 PM
Since vehicles in simutrans have to travel manhatten distance (dependign on diagonal multiplier) using euklidian distance will even require a more straight way and make pak set balancing even more difficult ...

We fixed that in Experimental, too: the way and vehicle maintenance costs on diagonals are reduced by fixed amounts to take into account the lesser distance travelled. From what I understand, physics has already been fixed in Standard.
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

Since vehcile prices are mostly not affecting creditability in standard. I was thinking that the resale value of a vehicle is decreased by say 30% as soon as it was running once. Thus buying very expensive vehicles with very little mony will leave to bankrupsy while misclicking in the depot and resale is still possible. This gives also a much higher incentive for buying cheap stuff.

jamespetts

Quote from: prissi on February 04, 2011, 10:36:27 AM
Since vehcile prices are mostly not affecting creditability in standard. I was thinking that the resale value of a vehicle is decreased by say 30% as soon as it was running once. Thus buying very expensive vehicles with very little mony will leave to bankrupsy while misclicking in the depot and resale is still possible. This gives also a much higher incentive for buying cheap stuff.

This seems like a good idea.
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.

moblet

Quote from: Hajo on January 31, 2011, 12:32:49 PM
A very long time there was no split between program developers and pak set developers. There was only one team until pak128 came into existence. So there was no such intention or thought initially. (I agree that balancing is an issue of coding and data design matters).
...
The timeline was not part of the initial game design...all time-dynamic features that we see nowadays were built onto a game core that was not designed for that.
In my opinion it would be valuable for the long-term future of Simutrans to do a project of thinking through the implications of these statements, and determining one or more designs that can preserve everything that's good about Simutrans while providing the dynamics necessary to cater for timelines, and for straightforward independent pakset development. Since these requirements were never considered in the design of the existing engine, the starting question needs to be "what would be the simplest possible engine that meets these requirements?", not "what can be added to the existing engine?" Properly documented, for example identifyng particular dynamics that are necessary to support timelines but can be switched off otherwise to simplify gameplay, this work could then guide the direction of future development. Also, if the worst case is true, that meeting these requirements is not possible without forcing players into unacceptable micromanagement, we should know this and change our expectations rather than keep working under the assumption that there is no problem.

Obviously such a project isn't critically urgent, so it needn't interfere with other Simutrans projects, but I think it is worth doing sometime, preferably before too many pakset developers become frustrated with the difficulty of balancing. If and when at least three other people are interested, we would have a big enough team to make a start.