Topic: Handling Investment in Simutrans.

[AvG]

I am in a contstant process of updating PAK-files.
My present scenario is a NW-Europe-map of 2075*2423, quite exactly on scale (1 tile=125m) , gamespeed 24 BpM.
All coordinates via google and citysizes via Wiki. (populationgrowth 2%/yr)
This scenario is now 35 years old and I am still happy with it.
I am running EXP 11.34, wich is very stable. This is important, because such a low speed scenario makes it often
necessary to let it run in the background. This low 24BpM speed, combined with better PAK's, makes it great fun to play
with. The goal is: Simulate the real world in all era's as good as possible. Also financialy.
In 1894 I use as passenger fee: <5km=0,11HCr; <10km=0,08HCr; <100km=0,05; and >100km=0,03.
This is still more than Acworth indicates. I have however a monthly profit of ~700K, so I will make the fees lower.
I aim for: <16km=0,05HCr; <32km=0,04HCr;  >32km=0,03. This is roughly the Acworth indication.


Working on this I noticed that my steamloc formula for fuel-consumption was based on a coalprice-inflation of 3%.
In reality this was however comletely different. Untill ~1930 coalprices hardly changed due to competion and
mechanisation. After 1930 prices were going up. This has a large impact on runningcost so I am studying on a better
approach.


During this reflctions I noticed a new problem: How do you handle investments.
If you look at prices for building railway in the year 2000 you see that you are talking about millions instead of
hundres. The depreciation of those expensive items has to be covered by : Operating profit - maintenance (in-
frastructure+vehicles). I have in my runningcost formula also here a mistake, by putting the depreciation in the running-cost.
So a little to gain.
The infrastructure-maintenance issue is quite simple: I use 2%/year. This is a lot less than the original PAK-files use.


After a lot of thinking I concluded that all investments have to be calculated with prices for the era. I use an
inflation percentage of 3%.
I use for conversion: 1 HCr = 1 Euro = 1 USD. Until 1940 1 Pound = 5,68 HCr  Pound after 1940 tbf.


The problem in Simutrans is the use of different time-scales at the same time.
The execution (actual transportation of items) is 1 on 1. The financial timescale (depreciation) is 1 on 150 (at 24BmP)
Example: Rail in 2000 cost 1.000.000 HCR/km (light rail)
The price for that rail will be in 1890 : 1.000.000*0,97^110= ~35000 HCr/km.


An hour at gamespeed 24BpM takes ~24 sec real time. So you have 3600/24= 150 = timescale.
This 150 timescale means that, in the example, you had in 1890 (in reality) 150 times more time to cover your
depreciation or in other words you are not able, if you are using fees of the era, to cover your depreciation
of 35000HCr/km
A solution can be to use 1/150 part of the investment. So 35000/150= 233 HCr/km combined with 2%
maintenance makes 4,66/12= 0,39 HCr/km/month.


I think that the same theory can be used for vehicles. However, if you do this in the program as is, you will be
confronted with very low prices for vehicles. (All of era-reality/150 at 24BpM)
Especially for vehicles this approach will not give you the right "feeling".
A solution can be here to enter the era-price between brackets in the name and at the cost-entry the 24BpM-price.
This way it will fit in the existing .exe.


It may be clear that these values are specific for 24BpM.


Please comment!!!

[jamespetts]

Thank you very much for your comments. One of the many important things that will need to be done before I can balance Pak128.Britain-Ex is to simulate inflation. This will need to be done for a variety of types of costs and revenues, although I have not yet decided on quite where the demarcations should be yet.

As to the differences in time scales and the effect on the relationship between capital cost and revenue, this is an unavoidable part of the game. The idea of having some sort of equivalent cost is an interesting one, but I find it difficult to see that this would be particularly helpful: it would have no function and would be likely to confuse players as to what this extra number means.

[Aquin]

Looking at historic inflation rates for the UK, especially in the years before 1900, I don't think these should be simulated. Inflation rates of +30% and -20% were alternating within few years.
From a balancing point of view I would start with inflation corrected prices, these can later easily be multiplied with a factor for the corresponding year, like AvG proposed.
This would allow for no, smooth or historically correct inflation rates without rebalancing.

[jamespetts]

Looking at historic inflation rates for the UK, especially in the years before 1900, I don't think these should be simulated. Inflation rates of +30% and -20% were alternating within few years.
From a balancing point of view I would start with inflation corrected prices, these can later easily be multiplied with a factor for the corresponding year, like AvG proposed.
This would allow for no, smooth or historically correct inflation rates without rebalancing.

The idea behind inflation is to do precisely this, if I have understood you correctly: to use historically accurate (relative) prices and for the executable itself to simulate inflation by multiplying those prices with a factor based on the proportional divergence from prices normalised at 1900 levels.

[sdog]

Variable inflation can be easily replaced by normalised prices, only shrinking (or increasing for deflation) liquidity and debt. The nice thing is, that assets stay constant. This would be much less work and much easier to understand for all users.

[jamespetts]

I had considered merely normalising, but it does not account for relative variations in the cost of things, which can make a very large difference: trams, for example, became unprofitable during the 1920s because of wage inflation, leading to their eventual replacement by trolleybuses, and, in turn, diesel 'buses.

[rdepass]

I don't know if this is precisely the right place for this comment, but I have often thought about what if I could pay my maintenance to 'public' so that they didn't go broke so terribly! You chaps seem to know what you are talking about so you are probably the right people to ask? I noticed that after i asked about something similar before, you added 'Road toll'. I was actually asking about wages costs and was told the maintenance covers it and that its addition would be merely eye candy. That is not a problem, I can't argue with that, though this maintenance thing is at the back of my mind, and if I could modify the game so that 'human' paid more tax, I would, because when you have a billion Crs you either want to invent space travel or something very expensive or buy everything again, just to be sure you own it!

------------

Sorry but there is zero depreciation in simutrans, I mean you buy a H-Trans bus in 1953 and it is still going 30 odd years later, never once going to the garage for fixing or filling up with petrol. Seeing as the refinery makes gas, you could make the vehicles fill up at a stop or depot, though it would probably make everything in the game exceedingly complicated...

[Sarlock]

With speed bonus and obsolescence, these are two good mechanisms to simulate the tram conversion.  Early trams can be cheaper to run at the speed bonus levels at the time.  As time wears on, the speed bonus for trams increases and so can the operating costs for new trams for that era.  The player that tries to hold on to obsolete trams will incur the penalty to operating cost, so between these two systems the player will be naturally encouraged economically to move away from trams to other transportation choices in that era.  The same can occur with trolleybuses.

AvG, great calculations.  It is important to include the 1/150 calculation that you highlight to account for the time differential between actual and gameplay.  We are simulating a transportation system in 1/150th of the actual time, so everything should be scaled economically to account for that.  If prices seem incorrect because they depart too far from reality, the whole economic model can be modified by a factor to return to numbers that "make more sense" to the player.  The addition of an inflation figure may end up adding a multiplier to the system that isn't necessary and can be simulated with what exists currently.  More complexity usually doesn't improve things -- it just makes it more difficult to arrive at the desired gameplay balance.  Inflation can be correctly accounted for by increasing capital purchase costs, operating costs and revenue (speed bonus).

1/150th time compression would also mean in theory that 1 convoy really represents 150 of that convoy type.

[DrSuperGood]

Economically inflation is a decrease in the value of money. To keep numbers reasonable one can model it as negative interest. This prevents numbers growing as time progresses, something people might find difficult to deal with or annoying. One has to remember that inflation is pretty universal so although something costs more, you also earn more proportionately so the only change is that the money you have saved up becomes worth less.

Basically one could model the player's currency as a normalized currency unit. This would mean that the displayed costs remain reasonably stable no matter the year. A old horse pulled coach back in 1800 used to cost several years salary to buy, similar to a bus in 2000 which also costs years of the average salary.

What the player has to deal with then is deflation of income. As time progresses stuff becomes cheaper so earning money becomes harder. Running that horse drawn coach in 2000 might cost the same as a bus, however where as the coach can only move 4-6 people who might pay less for the low speed, the bus can move several dozen and earn more due to better speed and comfort.

The same applies to industry. Moving those spices in the 1700s will earn you a lot to cover the costs. In 2000 the same amount will earn you a lot less (a tiny fraction) however the costs are much lower as your huge ships can move considerably more of it.

One must ultimately remember that the amount people pay to have something moved is based on the cost to move it. If you paid enough you could send something to the moon, not that it is "economical" to do so. One could model everything as various desirability factors and ultimately place the amount of profit earned directly into the hands of the player.

A good example would be milk from cattle ranches to a dairy which is only connected with water. The dairy desires only cheap milk so it can rule out all the far away cattle farms (think other side of map) as their milk is not desirable (more distance means more cost). It can then rule out links to dairies where the journey time exceeds the spoilage time of the product (milk has to be fresh). It can then go based on the cost to deliver, resulting in it sourcing milk from a ranch just 10-20 km away. Since the route is short and not making much profit the greedy player decides to raise his margin from 0% (no profit, revenue covers running cost) to 2,000% (like some payday loan provider). The dairy now sources from a cattle ranch 40 km away from an operator running at a 100% margin because it will still be cheaper per unit than from that dairy 10-20 km away through the greedy operator. However the ranch 10-20km away suddenly starts producing special extra tasty milk (more desirable than other ranches) so the dairy decides to switch to it even though it costs more to transport because the product from that ranch is better.

The difficulty in this model would be the computation of all the desirability factors as well as working out how to define the margin (infrastructure or journey cost alone?).

[Sarlock]

In Simutrans there is no margin that the player can control per se.  What they can control is the cost per km of the convoy being used to transport the chosen goods and how full the convoys are during both legs of the journey (though finding goods for a return trip can be tricky in many instances).  Often the cost per km is proportional to the speed that the convoy can travel -- more expensive trains often cost more, but arrive faster and may receive a speedbonus (if the good(s) in question have a bonus).

Tweaking the revenue/cost model can result in an easy or challenging pakset.

The influence of the speedbonus has some of the effect of technological advancement on transportation revenues that you cite.  As industrial customers (and passengers and mail) realize that faster/cheaper methods of transportation are available, they will pay less revenue per good*km to the player.  This incentivizes the player to upgrade their network to faster and more cost effective (per good*km) vehicles.  One idea, which I have seen seldom used with paksets, is to have many speedbonus levels occur through history instead of just 2 or 3 big jumps.  A line that was profitable at one point may become marginal after 10 years and unprofitable after 20 years, encouraging continual upgrading with new convoy types or even switching to a different type of transportation system.

Since Experimental has an obsolescence system that increases the operating cost of convoys after a certain age, this penalizes the player if they keep around old technology (though ship operating costs are so low right now that even with the increase it still pays to keep old technology around in many cases).  Combined with speedbonus increases, if operating costs for more modern vehicles are more aggressive (requiring a higher percentage of capacity in order to turn a profit) then the player will be forced to streamline and continually improve their system.  In an aggressively built pakset, the speedbonus may almost be required in order to turn a decent profit -- unless the player keeps chasing the speedbonus and upgrading, their lines will quickly slide in to unprofitable ventures.

[jamespetts]

Trying to model inflation indirectly will actually be much more difficult and complex, especially as regards calibration, than modelling it directly. Modelling it directly, one can just use historical figures, take account of the differences in time scales between capital and running costs, and then make slight adjustments to the overall balance based on gameplay testing. Trying to model inflation indirectly using obsolescence, a negative interest rate and the speed bonus will be almost impossible to calibrate accurately, as they do not do exactly the same thing as differentiated inflation rates (and a negative interest rate is likely to be inscrutable to most players). Using these measures are also likely to have side effects that are not related to inflation effects: e.g., using the speed bonus would have a disproportionate effect for lines that are slow because they have frequent stops rather than because they use old vehicles, or conversely have insufficient effect for faster lines.

Incidentally, it is necessary to have a multiplier system for all costs in any event to enable batch balancing: it should be possible, for example, to reduce the cost of all steam locomotives by 20% by changing one number in simuconf.tab. This is the only way to have a system in which the game can be balanced accurately (and then later rebalanced as new features are added or experience shows that the original balance was not right) in a reasonable amount of time.

[DrSuperGood]

Trying to model inflation indirectly will actually be much more difficult and complex, especially as regards calibration, than modelling it directly. Modelling it directly, one can just use historical figures, take account of the differences in time scales between capital and running costs, and then make slight adjustments to the overall balance based on gameplay testing. Trying to model inflation indirectly using obsolescence, a negative interest rate and the speed bonus will be almost impossible to calibrate accurately, as they do not do exactly the same thing as differentiated inflation rates (and a negative interest rate is likely to be inscrutable to most players). Using these measures are also likely to have side effects that are not related to inflation effects: e.g., using the speed bonus would have a disproportionate effect for lines that are slow because they have frequent stops rather than because they use old vehicles, or conversely have insufficient effect for faster lines.

Except without an accurate economic model realistic data is useless.

In Simutrans there is no margin that the player can control per se.  What they can control is the cost per km of the convoy being used to transport the chosen goods and how full the convoys are during both legs of the journey (though finding goods for a return trip can be tricky in many instances).  Often the cost per km is proportional to the speed that the convoy can travel -- more expensive trains often cost more, but arrive faster and may receive a speedbonus (if the good(s) in question have a bonus).

In real life everything is cost driven. Using the fastest engine or the slowest engine does not matter as ultimately the amount you earn is based entirely on how much the customers are willing to pay for the service. As time progresses the customers have become more strict as to their requirements. If a train service is too slow they might not bother taking it let alone paying for it when they could drive their private cars everywhere. This applies to goods as well with factories expecting more to be moved cheaper towards the present day.

The amount of profit you get in the end of the day is based on the difference between what you could get away with charging the customer and the amount it cost to preform a journey.

The most important difference this makes is with route directness. If you have a long windy track from two points the customer should be charged for the entire distance the train took to deliver the goods, not just some straight line distance (after all, nothing is for free). It should be up to the industries involved to decide if the journey is reasonable to make and not make them if not. The end result is that a nice straight route you could get away charging more profit margin for than a long curvy route as your delivery costs are higher so the clients have less tolerance for profit margin.

Oh but it is not this simple either. If the client's journey involves bad geography (desert, mountain jungle etc) then they are willing to pay more for deliveries as they know that making such deliveries will always cost more due to the geography. As such a wondering mountain route would still make you tons of profit as the client will give a higher expectation for cost.

Using such a system one could do away with industry links entirely. Instead links get automatically made based on what makes economic sense rather than some dice roll.

[jamespetts]

Except without an accurate economic model realistic data is useless.

This is why I am working on an accurate economic model, which includes the simulation of inflation: that is why it is necessary to have intermittent renewal of ways, the upgrading cost of ways being different to their initial construction cost and all the myriad other things that have either been added recently or are due to be added before the next release.

[sdog]

I had considered merely normalising, but it does not account for relative variations in the cost of things, which can make a very large difference: trams, for example, became unprofitable during the 1920s because of wage inflation, leading to their eventual replacement by trolleybuses, and, in turn, diesel 'buses.

That is not really going to get fixed by an overall inflation model.

I think we discussed a separation of labour and energy costs at lengths a few years ago. In particular in view of steam obsolescence.

The obsolescence model already nicely models technological obsolescence, and cost increase due to lack of spare parts. Speed bonus is not as relevant in experimental as it is in standard. Travel and waiting time limits, refunds, obsolescence make speed boni useless.

This is why I am working on an accurate economic model, which includes the simulation of inflation: that is why it is necessary to have intermittent renewal of ways, the upgrading cost of ways being different to their initial construction cost and all the myriad other things that have either been added recently or are due to be added before the next release.

It is unfortunate that the economic model and related aspects, eg, pax routing, distance calculations, are so thoroughly interwoven with the rest of the code, that you tend to spend more time mergin standard than actually working on experimental.

[jamespetts]

That is not really going to get fixed by an overall inflation model.

That is why I am not planning an overall inflation model, but a model that will allow different rates of inflation on different types of cost and revenue.

I think we discussed a separation of labour and energy costs at lengths a few years ago. In particular in view of steam obsolescence.

The obsolescence model already nicely models technological obsolescence, and cost increase due to lack of spare parts. Speed bonus is not as relevant in experimental as it is in standard. Travel and waiting time limits, refunds, obsolescence make speed boni useless.


It is unfortunate that the economic model and related aspects, eg, pax routing, distance calculations, are so thoroughly interwoven with the rest of the code, that you tend to spend more time mergin standard than actually working on experimental.

Maintaining and developing a project such as this is challenging, especially when there are so few people to assist. One of the problems is that, for any of the more complex projects, I have to have a large stretch of clear time in which to do any given thing, as I need to remember clearly all the other things that I have done and plan to do, which memory will fade if I spend an hour or two a day a few days a week and do other things in between. Such larger projects also need a single-minded intense focus, which is difficult to achieve when other things, such as refurbishing and, in due course, moving into my house, are preoccupying my mind. For that reason, it can be difficult even to get started on larger projects, and this is one reason why I was able to make good progress during the Christmas period when I had a long time away from work. If there were others working on the code, these things might prove easier.