Thoughts on factoring costs/revenues

[jamespetts]

Previously, there has been some discussion of a feature that I suggested to aid pakset balancing, which I call "factorials", which would enable the costs/revenues of groups of things to be adjusted at once by a parameter in simuconf.tab. For example, a setting of cost_factor_station_purchaes = 200 would cause the purchase cost of all stations to be double that set individually in the .dat files, and a setting of cost_factor_way_maintenance = 50 would cause the way maintenance cost to be half that set in the individual .dat files, and so forth.  The idea  was to  aid  a trial and error based approach to balancing by allowing constant re-adjustment of the relative costs of whole groups of things without  having constantly to alter the prices set in hundreds of .dat files manually. There was some discussion at the time, I think, of whether it was best to do this (as I had suggested) in the program code itself, or whether it was prefreable instead to use separete scripts automatically to modify the .dat files (it being suggested that hte latter approach provided more flexibility).

Separtely, there has in the past been call for a means of simulating the varying (usually rising) cost of labour through time, which I have so far rejected on the ground that it would be impracticable to implement it without reworking the whole pricing and revenue model from the ground up to work on a factor/multiplier approach rather than using singular direclty specified prices.

However, recently a thought occurred to me that might be of interest to those who promote the idea of a variable labour cost: if the originally proposed method of price factorials were implemented (viz. using the main Simutrans code rahter than .dat file modifying scripts, but instead of singular values in simuconf.tab for the factorials, each factorial were to have its own .tab file enabling a different value to be set by date, then this might go some way towards simulating the effect of varying labour costs without incurring the labour cost (if you will excuse the pun) of re-writing the entire pricing structure in the program and all paksets (and causing furhter compatibility issues between Standard and Experimental).

I should be interested in any feedback on this idea, and in particular on the following questions.

1. How fine a grain of detail do we need for the different categories? For example, will it suffice to have operating_cost_rail_vehicle = 1820, 1, 1850, 3... (etc.), or do we have to have something like fixed_monthly_cost_steam_locomotive = 1820, 1, 1850, 3... per_km_cost_narrowgauge_passenger_carriage = 1863 = 10, 1879  = 12... (etc.), or somewhere in between?
2. How best to deal with purchase costs? Currently in Pak128.Britain (both Standard and Experimental), purchase costs of all types of transport infrastructure are inflated through the ages to take account of therise in prices. My historial research on the relative prices of things will result in the purchase costs of each item beingcalirated by that tiem's as new cost when first built. This is not compatible with a straightforward factoring system, and it is difficult to make it compatible. One possibility would be to have a different factoring system for capital items, with each being calibrated to "1" for their introduction year, so that, for example, if the factor for, say, diesel 'buses is 100 in 1920, 110 in 1930 nd 120 in 1940, a type of 'bus introduced in 1920 costing 100c would cost 110c if purchased in `930 and 120c if purchased in 1940, whereas a 'bus introduced in 1930 costing 200c would only cost 120/110ths of 200c in 1940, not 120% of its 1930 price. Does this seem to be a workable solution?
3. Any suggestions on whether and if so how this can be directly represented in the GUI? Bear in mind that anything complicated would add orders of magnitude to the labour cost of implementing this feature and will not be feasible unless somebody else volunteers to do the work.

Comments much appreciated!

[colonyan]

Previously, there has been some discussion of a feature that I suggested to aid pakset balancing, which I call "factorials", which would enable the costs/revenues of groups of things to be adjusted at once by a parameter in simuconf.tab. For example, a setting of cost_factor_station_purchaes = 200 would cause the purchase cost of all stations to be double that set individually in the .dat files, and a setting of cost_factor_way_maintenance = 50 would cause the way maintenance cost to be half that set in the individual .dat files, and so forth.  The idea  was to  aid  a trial and error based approach to balancing by allowing constant re-adjustment of the relative costs of whole groups of things without  having constantly to alter the prices set in hundreds of .dat files manually. There was some discussion at the time, I think, of whether it was best to do this (as I had suggested) in the program code itself, or whether it was prefreable instead to use separete scripts automatically to modify the .dat files (it being suggested that hte latter approach provided more flexibility).

This is an interesting tool. I can not guarantee I will make use of this now. If I'm confident that I've progressed enough on the work, I will make an official request. Just to let you know that there is a potential. I'm currently making rough plan over all. (I want to make Simutrans my life long hobby. So I will go steady.)

As of cost inflation.
Well from a user point of view, inflation of cost is not a priority. I will go far enough to say a source of unnecessary complication. I want to values to be fixed for an item which does same effect through out the game. User will grow sens of value scale, price of investment gradually. This is my current personal view.

I understand there is an interest in representing real world phenomena. Meanwhile, this does not really help game play.

[jamespetts]

Thank you for your thoughts. The feature is, I think, potentially important for ganeplay in that, in reality,  some types of services which had once been profitable ceased to be profitable because of increasing labour cost even though the ridership did not reduce. This was the  case for trams in the late 1920s, for example, which was a factor in the conversion of many tram routes to trolleybus operation, trolleybuses being cheaper to operate. This sort of decline (and the challenge to the player in responding and adapting to it) can only be simulated by some representation of the rise in certain sorts of costs. This would, of course, be optional to pakset authors.

I should be interested in other views on the desirability of such a feature.

[MCollett]

The feature is, I think, potentially important for ganeplay in that, in reality,  some types of services which had once been profitable ceased to be profitable because of increasing labour cost even though the ridership did not reduce.
...
I should be interested in other views on the desirability of such a feature.

I think that the game already has enough levers to produce more-or-less the effect you are looking for, at least to the extent that it is relevant to gameplay.

There is clearly no game benefit to including overall inflation, but relative rates of inflation are not so obviously ignorable.  In particular, as you say, wage costs go up (in relative terms) over the period of interest, while the cost of mass-produced goods goes down.   So if we want costs in constant 1900 (say) dollars/pounds/credits, the question arises as to what inflation rate to use for the normalisation: price inflation and wage inflation are different.   

If we say that we are implicitly using the rate of wage inflation, then non-wage costs and prices should tend to go down over time.  But this is in fact what already happens: later vehicles do in general deliver 'better bang for your buck', while the customers have rising expectations of speed (and comfort? — or is that constant in time?) and thus pay less for the same service.  This is not just a coincidence.  The better value of later vehicles and the greater demands of the customers are precisely special cases of the industrialisation and technological development which are driving the differential inflation rates in the first place.   Taking the specific example you gave of trams being outcompeted by trolley-buses, if that isn't happening in the game at present, then either increasing the expected speed of trams or decreasing the costs of the buses should fix it without needing an extra 'wage inflation' variable.

Much, perhaps most, of the distinction between wage and non-wage costs is below the resolution of the game model anyway.  If you as a railway company hire a contractor to build a mile of track in 1850, he will use a hundred men with picks and shovels; if you hire his grandson to do a similar job in 1950, he will use ten men well-supplied with heavy machinery:  in real terms the cost is similar and no other differences are visible in the game.

Best wishes,
Matthew

[ӔO]

If there is competition, in general, what a company will do, is cut into its margin slightly. This can be done in a number of ways, such as increasing service quality or lowering fares so that it can win back ridership.

Faster is better, but only if it's worth the cost to the rider. This is why there is such fierce competition between airplanes and high speed rail for train rides under 4hrs.

[jamespetts]

Matthew,

interesting thoughts. This is more or less the principle in use at present. However, as others (I think SDog) have pointed out, there is a substantial weakness with this system, in that, in reality (and to an extent that very substantially affected transport planning), the costs of operating certain sorts of assets increased materially during their normal economic life. The method that you describe can be used without difficulty for all capital items, but it does not translate too well to maintenance costs. One kilometre of old-fashioned track may well cost several times more in real terms to maintain in 1960 than it did in 1860. Similarly, the cost of operating steam locomotives increased enormously after the Second World War owing to rising labour costs. The method for attempting to simulate this now is by using the obsolescence system, but this does not allow for an easy way of increasing the maintenance costs of non-obsolete items and items that are still in production, as with the tram example. Indeed, the point about trams was not just that they were out-competed by trolleybuses, but that, with identical ridership and equipment to that which they had had decades earlier, started to make a loss when formerly they had made a good profit. It is that dynamic that would be more accurately captured by this system.

I should add that I am not firmly wedded to this system  yet, and have yet to decide whether it is worth implementing, but thought that I had better point out what it brings to the simulation that cannot be achieved by the methods suggested so that full evaluation can be conducted on whether it is a worthwhile thing to implement. I should also note that what is being proposed is not, a simplified, a single wage cost variable, but the ability to alter the relative costs of different sorts of item (both capital and ongoing) (1) in groups (to enable easier game  balancing); and (2) dynamically with passing time (to simulate the effects of relative inflation).

It's rather a pity that we have yet to hear from SDog, who was the original proponent of an actual labour cost variable to which this system is a proposed alternative.

[jamespetts]

One or two further thoughts on this. Firstly - the GUI. A useful way to represent this to the user, I think, would be to have a table (an additional item in the "list" menu, along side the goods list, etc. - perhaps called the "inflation table" or similar). It would look something like this:

	Now	1 year ago	5 years ago
Way construction	100	95	89
Way maintenance	105	100	91
Vehicle purchase	45	43	43
Vehicle maintenance (per km)	100	112	113
Vehicle maintenance (fixed)	100	100	100

(But obviously with a few more rows and columns).

Secondly, a thought on absolute inflation. Contrary to earlier thoughts, it might have considerable practical significance. The recent Experimental network game has shown how players often accumulate such vast wealth in the early stages of the game that there reaches a point when they can sustain massive losses for the remainder of the playable period of the game (often with many decades left) without running out of money. The network game has also shown that even modest credit interest rates of 2.5% (a realistic, even conservative, investment rate) enable huge amounts of money to be made by simply doing nothing with the initial starting capital. In real life, interest is offset by inflation, and accumulated wealth in the form of cash is eroded by inflation. It should not be possible to make a massive profit from a canal business, shut up shop in 1830, remain dormant until 1960, then have enough money to start a huge airline. The factor model that I suggest here should prevent that from being possible. Indeed, it would enable pakset authors to choose whether or not to model absolute as well as relative inflation, depending on the particular figures selected.

I should be very interested in any feedback on any of these ideas.

[sdog]

firstly, i have to apologize for having only browsed over the postings after mathews, i'll catch up with reading this more thoroughly when i get enough sleep again. I'm only replying on James' question with regard to my previous posts.


i think with a bit effort, the effect of rising labour costs on different classes of vehicles can be simulated with only one time dependent global factor g(t).

the cost model i was thinking about for monthly maintenance:
M(t)=l(t) w + f(t) u + m
l(t) cost of labour
w required workforce (eg. 1.x for diesel engine, 3.x for steam, man hours per day divided by 24h)
f(t) fuel cost
u fuel use
m fixed maintenace cost

M(t)=g(t) (w'+u'+m') = g(t) (v)
v is the only variable we can change in game, but construct it from those single values beforehand.

The introduction of new vehicles allows to use values normalized for an introduction date,
the simplest way to do so:

w=w'  thus l(t)=g(t)
u' = u f(t)/g(t)|t_intro
m' = m/g(t)|t_intro

for times long after introduction the costs would raise too quickly. Finding a better g(t)
This means in an example from 1945 to 1965 g(t) would rise significantly, but the v_steamX of an arbitrary steam engine X would be much higher than v_dieselY of an diesel engine Y.


still don't consider this a very major change to the game, also no impact on performance. simple calculation, only a few required and rarely (once a year)


ps.: i should make it clearer, from above only
M(t) = g(t) v
would be in the game, the rest are calculations done by the poor lad doing the pak balancing.


pps.: factorial is a bit missleading name: n!


ppps.: is there interest from anyone doing this
(my interest does not count, as i don't realise anything [i started too many things at the same time and completely stalled me with all things, including the really important] (i've been rather glad my request back then were not implemented, as this would have created an obligation for me to make good use of it.


corrected some mistakes, v and g(t) named now (that is the cost variable and a global factor respectively)

[jamespetts]

Hmm, I'm not sure that I fully understand your formulae - what do the letters g and v represent? And how do we deal, say, with changing costs of material over time, or the reducing gap between the costs of skilled and unskilled labour?

I'd be interested in your thoughts on the original idea. Thank you for replying, however!

[el_slapper]

It would probably exponential, with very small values in the 1800s & very high in the 2000s.

just an idea like that :

*Way construction
*Way maintenance
*Vehicle purchase
*Vehicle maintenance (per km) Biologic
*Vehicle maintenance (per km) Steam
*Vehicle maintenance (per km) Electric
*Vehicle maintenance (per km) Oil
*Vehicle maintenance (fixed) (one per transport way, also)
*Interest Rate
*Urban real estate prices(would influence HQ building, house demolition for laying tracks)
*Rural real estate prices(would influence price of laying long, cheap roads/railroads in the countryside)

Like I said, that's just an idea that comes like that. Just I think it would be cool. And hell to balance also.....

[jamespetts]

Like I said, that's just an idea that comes like that. Just I think it would be cool. And hell to balance also.....

Would it not be easier to balance than a flat system if I can get hold of real prices?

[sdog]

Hmm, I'm not sure that I fully understand your formulae - what do the letters g and v represent? And how do we deal, say, with changing costs of material over time, or the reducing gap between the costs of skilled and unskilled labour?

I'd be interested in your thoughts on the original idea. Thank you for replying, however!

corrected above post.

with original you mean the idea in this thread or a previous thread.
this is what i understand your idea to be:
M(t) = g(t) v
where M(t) is the effective maintenance cost of a vehicle, v is the specific base cost of that vehicle and g(t) is a function of time, and a factor for all vehicles.

the other time dependent aspects can be covered in the same way as labour, the basic idea is not different there. several time dependent factors could be taken care of at the same time. it stays a crude model in any case tweaked exactly to one's needs. in the end the complexity is in the variation of base cost v between vehicles and the arbitrary form of function g(t)

crude: what would work is having steam locomotives become very expensive at one time. but, since not the engine type is the relevant factor, but the change of g over time with lower v chosen later, it would also greatly increase the costs of diesl or electric units intruduced together with steam units.

increase in parts cost ought to be covered by compensating for inflation, they likely have a tendency to get cheaper though.

[jamespetts]

Apologies for not having replied earlier: I have been very busy this week!

To answer your question, I meant the original idea in this thread. I'm not sure that I fully follow the equation, but that's probably because I find things easier to understand in words than equations, not being the world's best mathematician.

However, let me try to understand this:

M(t)=l(t) w + f(t) u + m
l(t) cost of labour
w required workforce (eg. 1.x for diesel engine, 3.x for steam, man hours per day divided by 24h)
f(t) fuel cost
u fuel use
m fixed maintenance cost

Firstly, this appears to reduce the separate per kilometre cost and monthly fixed cost to one figure by multiplying the fuel use and fuel cost into one. Ought not the fuel cost instead be related to the per kilometre cost, and the distance represent the fuel usage? The per kilometre cost should also contain the wear based maintenance figure, which is partly related to labour and materials cost.

Secondly, this seems to be specific to vehicles, whereas my idea was for factors for all types of costs, as indicated here. Inflation - both relative and absolute - could then more fully simulated, allowing the pakset author to simulate, for example, the increasing cost of canal construction and horses during the Napoleonic wars, which a system simulating only labour cost could not do. Likewise, this system's simulation of absolute inflation would militate against very great accumulations of wealth by players in the early part of the game which can then be carried through to much later in the game, making players almost invulnerable to any economic adversity, thus eliminating the challenge.

It would, of course, be possible to use a spreadsheet which would use a factor for labour, fuel, material (etc.) costs as an input, and which would output the price index figures, and perhaps that spreadsheet would use a formula similar to some of those that you have suggested.

More generally, it seems to me that further small refinements are needed to what has been suggested before. Firstly, vehicle purchase/maintenance costs will need to be divided between traction types to give factorials for "vehicle_maintenance_cost_fixed_steam", "vehicle_maintenance_cost_variable_sail", etc. Secondly, it seems to me that it is sensible to allow for all prices (not just prices for capital items) to be calibrated by their introduction date, as described above. By this, I mean that an item will always have its actual .dat file specified price (adjusted only for the pakset's scale) as at its introduction date. So, if, for example, a particular type of road has an introduction date of 1900 and a monthly maintenance cost of 200c, and the road_maintenance_cost_monthly index in 1900 is 20, the actual maintenance cost of the road in 1900 will indeed be 200c; the maintenance cost of that same road in 1960, when the road_maintenance_cost_monthly index is (say) 50 would be 500c (200 x 50 / 20). This would make it much easier to calibrate prices based on historical costs generally, and make it easier for pakset authors to work out the actual game price of items without having to resort to the use of a calculator.

Thoughts on all of the above would be most welcome!

[sdog]

Firstly, this appears to reduce the separate per kilometre cost and monthly fixed cost to one figure by multiplying the fuel use and fuel cost into one. Ought not the fuel cost instead be related to the per kilometre cost, and the distance represent the fuel usage? The per kilometre cost should also contain the wear based maintenance figure, which is partly related to labour and materials cost.

Yes, i mixed things up very badly. Fuel cost goes to per km costs, while labour costs factor in monthly maintenance. Writing half of it i forgot that we have two different variables to change. This makes things much easier by the way.

You can just increase the global factor for km cost over time to reflect rise in fuel cost and increase monthly maintenance global factor to account for labour costs.

Secondly, this seems to be specific to vehicles, whereas my idea was for factors for all types of costs, as indicated here. Inflation - both relative and absolute - could then more fully simulated, allowing the pakset author to simulate, for example, the increasing cost of canal construction and horses during the Napoleonic wars, which a system simulating only labour cost could not do.

i'd rather recomend to have an inflation compensated currency. What you have to address then is only the relative change of prices compared to average prices. Factoring the building costs of different waytypes is easier to do than engine, just by introduction date. I don't have an idea on how much labour costs would change the relative maintenance differences Secondly, this seems to be specific to vehicles, whereas my idea was for factors for all types of costs, as indicated here. Inflation - both relative and absolute - could then more fully simulated, allowing the pakset author to simulate, for example, the increasing cost of canal construction and horses during the Napoleonic wars, which a system simulating only labour cost could not do. between different waytypes. (Eg are canals more likely to require more manual labour than railways?) Thing is, when you read in global cost factors anyway (the ones you call factorials) you can always use a time-dependent cost factor at the pak level, in other words when you implement it anyway, it wouldn't make a lot of sense to make differences between vehicles and other types of objects in the game.

More generally, it seems to me that further small refinements are needed to what has been suggested before. Firstly, vehicle purchase/maintenance costs will need to be divided between traction types to give factorials for "vehicle_maintenance_cost_fixed_steam", "vehicle_maintenance_cost_variable_sail", etc. Secondly, it seems to me that it is sensible to allow for all prices (not just prices for capital items) to be calibrated by their introduction date, as described above. By this, I mean that an item will always have its actual .dat file specified price (adjusted only for the pakset's scale) as at its introduction date. So, if, for example, a particular type of road has an introduction date of 1900 and a monthly maintenance cost of 200c, and the road_maintenance_cost_monthly index in 1900 is 20, the actual maintenance cost of the road in 1900 will indeed be 200c; the maintenance cost of that same road in 1960, when the road_maintenance_cost_monthly index is (say) 50 would be 500c (200 x 50 / 20). This would make it much easier to calibrate prices based on historical costs generally, and make it easier for pakset authors to work out the actual game price of items without having to resort to the use of a calculator.

that makes things much easier, and the approach i wrote before would not be required. Note that it only meant it is possible to do, not that i would have any idea how to get to an appropriate set of parameters.


The nice thing with global parameters is, that you do not have to change them you can always leave them at a neutral value 1, until you need to increase the costs for a whole group of objects. What you have to find is a good balance between having it too fine-grained and too general.

A cost factor for each major traction type and waytype (b)iological, (s)team, (d)iesel, (e)lectric, (h)hydrogen/future
rail: 5 (b,s,d,e,h)
road: 5 (b,s,d,e,h)
water: 5 (sail,b,s,d,h)
narrow gauge: 1 (s) [join with rail?]
maglev: 1
tram: 3 (b,s,e) [join with rail?]
flight: 1 (d)

21 for vehicles in pak-britain

16 when joining all rail-related waytypes
what's with other types, not used yet, eg hydrogen fuel cell aeroplane? consequence build in same global factors for all waytypes. (steam 'planes -- ahoi!): 20
now we want unpowered for each waytype too, likely always left at 1, but perhaps convenient for some fine-tweaking or change of rolling stock costs compared to others:
24
now x2 since we have monthly and km costs.
48

I'm not sure how many factors you want for infrastructure, likely ways, tunnels and bridges for each period.
+8
56

The more free parameters you get, the more you can model your simulation to a specific condition, but you run in a couple of problems. Pre-determining the outcome through a choice of parameters, this doesn't really matter, with the trivial exceptions of always going bankrupt or always winning. Instability of the simulation, with surprising and unexplained effects, that's always a problem when dealing with complex systems, changing A doesn't necesarrily influence A' but B, C and D. Very major increase of workload when balancing (but perhaps, with a good model behind it, this also makes it better manageable to do it.)

This is likely rather interesting for Experimental, due to your desire to have an economic simulation over a very long, changing timeframe. It most certainly is undesireable for standard, where the change of time ought only bring a bit of change in the appearance of the game (cf the reason given for the introduction of speed-bonus.)

Oh, and i agree on the example with roads, the historical approach might be rather helpful with balancing the game with so many knobs to turn.

[jamespetts]

The idea, actually, is that this will make the balancing easier, rather than harder, as one will simply be able to use real prices based on research (which is how one goes about getting an appropriate set of parameters - the good thing about history is that it comes pre-balanced). I am not sure what you mean by "an inflation compensated currency" - do you mean not having absolute inflation? That causes problems with long-term accumulations of wealth making the later parts of the game unchallenging, as discussed above.

The idea for the syntax, incidentally, is to re-use the existing code for the .tab files, i.e.

Code Select Expand


vehicle_maintenance_cost_fixed_steam=1800,70,1850,95,1870,107,1880,112,1900,135...
vehicle_maintenance_cost_variable_steam=1800,100,1845,120,1890,180,1900,195...
...


And, yes, indeed, as you point out, pakset authors can choose not to implement these fully, so as to give maximum flexibility.

One detail - do you think that we need different factors for different waytypes of vehicles as well as different traction types? Do we need, do you think, "rail_vehicle_maintenance_cost_fixed" and "road_vehicle_maintenance_cost_fixed", etc.? I had not initially thought this to be necessary, but what you write above about steam powered aircraft (!) suggest that you think that it might be.

[sdog]

it might be rather desirable to balance the cost of road vehicles in relation to rail vehicles at once and globaly. The long lasting in-balance for pak128, greatly favouring road immediately comes to my mind.

Of course could have both, a global way-type factor and a global traction-type factor.
what i was tinking above was  "rail_steam_vehicle_maintenance_cost_fixed" but two multiplicative factors would work as well, or even better.

[jamespetts]

Hmm, interesting. I shall give that consideration. Incidentally, what are your views on the simulation of absolute inflation?