Extension request (exp): Labour as economic factor

[sdog]

I've started to make a rough plan for balancing a fork of pak128 for experimental but stumbled over this topic (Labour as economic factor) again. It looks like it's not easily implemented only in the cost structure of the pak. I hope i don't bother you too much by requesting it again, even after it had been dismissed by james last year. Let me detail why i think it is required.

My approach for balancing costs for the pak was rather direct. Generate per km cost on the vehicles primary energy consumption and replacement parts (wear and tear). Monthly costs should be based on costs of labour. To achieve this i'm about to set up a table with the estimated number of workers a vehicle needs for it's operation. The assumption of two shifts, 16h operation, 8h idle is made for this. The factor loged in the table is the daily person hour. I create two values for operation and maintenance (Eg. a modern train with only one operator would have 16 person hours per day, factoring higher wage for the driver it would be 1.5 tims 24 man hours. A steam engine with 3 operators (1 driver) would be at 2*(8+8+1.5*8 )=72 person hours, but it also has to be pre heated 4h and oiled by the operating crew each day 2h result is 78 h) (Eg. Maintenance: number of personnel at repair shop divided by serviced trains [i need some data here])

The person hours should not change too much over a vehicles livespan. But my initial approach to calculate the cost of a vehicle from this directly fails, as the wages change greatly over a vehicles lifespan. Locos just live too long, much more so for ships.

What i would need now, and i think this would benefit pak britain even much more, with it's much longer scope, is to pass the work hours per month as a value to the game and calculate the monthly cost based on a normalized wages table. This is, i think, the only way to make steam engines suddenly uneconomic in 1960.

[Carl]

This is, i think, the only way to make steam engines suddenly uneconomic in 1960.

You could use the "increase_maintenance_after_years" feature to make the cost of steam go up sharply around that time (assuming the vehicles are no longer in production at that time) -- as described in this topic.

[sdog]

carl, this doesn't work for engines introduced only in the 50s. such engines are not that rare. it would also be some kind of deus ex machina approach.


my initial posting was a bit vague (i suddenly had much less time than anticipated to write it.) i think i need to clarify a few things.

A total work hour value h for each vehicle is specified in the dat file. The pak author chooses/calculates this at his own discretion.

A file with the development of the time dependent labour cost l(t) is provided. The values are normalized to 1000 for the value at year 2000 (a year most pak-sets will likely include). Foundations for reading such a file are likely already available from reading speed bonus files.

In the config.tab of the pak set a base cost value L for 2000 is provided.

The monthly maintenance M is calculated by
M = L l(t) h + m,
where m is the monthly maintenance specified in the dat file (addressing corrosion etc). It might be advisable to include an integer division by a 1e6 to allow full usage of integer in input files.

The calculation is done yearly (or every n years) and after each loading of a savefile. Values don't have to be saved in the savefiles. The calculation should be exactly reproducable and not very cpu heavy.


The would provide a consistent system of monthly costs that can be tweaked globaly with only one parameter, the base cost value L. This is also a major advantage compared to the usual way of balancing pak sets, where a script has to be run and recompiled for every new value. The system can be overriden by not providing the base cost value L or setting it to 0. This will also switch of reading of the input file. Not providing a total work hour value h or setting it to zero will disable it on a on vehicle basis.

[jamespetts]

Sdog,

thank you for your suggestion, and apologies for the delay in replying: a combination of being busy at work and wanting to get 10.0 out before concentrating on other difficult topics is responsible.

Two thoughts initially occur to me: firstly, the need for the code specifically to reflect the changing labour costs over time in this way might be dependant to some extent on the particular balancing method employed here, and may be less of an issue in an alternative model (such as the lifetime return on investment ratio system proposed by Moblet at the beginning of the year, for example); and secondly if something of this order were implemented, it would not make any sense to confine it to labour (or else one would have a piecemeal system that is hard to understand, and possible distortions as a result of labour costs inflating but not, for example, materials costs or fuel costs), but it would be necessary to replace entirely the existing system of direct specification of prices with a cost type/factors system.

If I were starting from scratch with a game such as this, it would be a cost type/factors system that I should use, specifying for each asset a cost level for each of several types (unskilled labour, semi-skilled labour, skilled labour, fuel (of various types) and materials (of various types)), then factor those costs over time using the same sort of CSV lists used for the speed bonus, etc.. That would change the system of balancing rather substantially. The difficulty is likely to be that it is going to be very labour-intensive to implement, especially as I anticipate paksets will have to be converted all at once: I expect that it will simply not work to have a mix of type/factor prices and directly specified prices. Then, one has to add to that the revenue side: the factoring of the speedbonus over time then comes to look crude (and might well produce distortions when combined with a factoring system for expenses), and one might instead consider a combination of a further type/factor system for revenues (perhaps for each type of cargo separately), and then a more sophisticated speed bonus system, where the bonus value is based on speed relative not to a pre-set list but actual average speeds achieved in game (and then the question would be whether those should be global speeds, or local values, and, if local, how the locality is isolated, etc.).

Another matter to consider is this: I am still planning to implement some of Moblet's economic suggestions, particularly relating to the increased maintenance costs based on use for ways and vehicles (and overhauls for vehicles). This is likely to make a very substantial (and hopefully positive) difference to the balance of the game, and it is likely to be hard to assess what, if any, other fundamental economic changes are necessary until those changes have been made (and also possibly a somewhat vexed exercise to balance an Experimental pakset before this system is introduced only to have to rebalance it after it is implemented). Unfortunately, this is likely to take a very long time to implement because of the necessary knock-on changes to other parts of the code, such as the vehicle replacer and depot system better to accommodate overhauls, to allow buying/selling second-hand vehicles, to allow cascading, etc.. Also, I wanted to implement a better model of braking physics for rail vehicles before instituting balancing/economic changes, as things affecting the distance that any given convoy can cover in any given time is likely to affect balance substantially, too. These matters may be hastened significantly if anyone is able to work on the code of these things with me, but doing it alone is, alas, a very slow process: the point to point timings have been in progress, for example, since late spring and only released on Saturday.

Finally on obsolescence: I am not sure that it is quite as deus ex machina as you suggest to make 1950s steam locomotives obsolete by the 1960s; this is indeed done in Pak128.Britain-Ex, although I acknowledge that this has not been tested yet.

In summary, a type/factors approach will probably work better if there is enough development effort to put into it, but the likely enormously large amount of development effort (both pakset and code) required for it to work makes it a very difficult proposition, which, when combined with the impending necessary changes relating to asset lifespans, might very well not be worth the outlay.

[sdog]

James,
thank you for taking the time to read my suggestion and reply to it in a detailed message. It took me some time too before i could get back to it too. I'm not giving my request up already, mostly because i think were not thinking of the same system here.
(Emphases in quotations by me.)

Two thoughts initially occur to me: firstly, the need for the code specifically to reflect the changing labour costs over time in this way might be dependant to some extent on the particular balancing method employed here, and may be less of an issue in an alternative model (1) (such as the lifetime return on investment ratio system proposed by Moblet at the beginning of the year, for example); and secondly if something of this order were implemented, it would not make any sense to confine it to labour (or else one would have a piecemeal system that is hard to understand, and possible distortions as a result of labour costs inflating but not, for example, materials costs or fuel costs), but it would be necessary to replace entirely the existing system of direct specification of prices with a cost type/factors system.

a1 I think i will use this livetime return of investment suggested by moblet too in my approach. The revenue side is much more difficult however, so i go for the expenses and determine the revenue with moblets approach.

a2 It would be nice to include fuel costs also, but it might be more complex. It is less of an issue however since fuel costs are rather stable when lifetimes are long and labour is cheap. When they increase greatly unit life is also shorter. (no issues with steam engines that could run for up to a century without much cost increase if wages are extremely low). I can include the fuel cost increase easily enough in the per km costs in the pak.

If I were starting from scratch with a game such as this, it would be a cost type/factors system that I should use, specifying for each asset a cost level for each of several types (unskilled labour, semi-skilled labour, skilled labour, fuel (of various types) and materials (of various types)), then factor those costs over time using the same sort of CSV lists used for the speed bonus, etc.. That would change the system of balancing rather substantially. (1) The difficulty is likely to be that it is going to be very labour-intensive to implement, especially as I anticipate paksets will have to be converted all at once: I expect that it will simply not work to have a mix of type/factor prices and directly specified prices. Then, one has to add to that the revenue side: (2) the factoring of the speedbonus over time then comes to look crude (and might well produce distortions when combined with a factoring system for expenses), and one might instead consider a combination of a further type/factor system for revenues (perhaps for each type of cargo separately), and then a more sophisticated speed bonus system, where the bonus value is based on speed relative not to a pre-set list but actual average speeds achieved in game (and then the question would be whether those should be global speeds, or local values, and, if local, how the locality is isolated, etc.).

Well, it's always nice to have a perfect model james, you won't reach it. If you would have liked to get into what you mentioned you have to check first if it is relevant. (eg. three types of labour, is an average good enough?)

b1 I wouldn't suggest it if it was very labour intensive on the pakset side. I'm way too lazy

The proposed system can very well run beside the system as it is now, the value calculated from the labour-cost-function is only added to the monthly cost. If there is no factor in the simuconf.tab provided it is just ignored.

b2 speedboni i will likely drop alltogether, or reduce to a rather small factor in revenues. As written above, revenues i will come up from lifetime costs.

Another matter to consider is this: I am still planning to implement some of Moblet's economic suggestions, particularly relating to the increased maintenance costs based on use for ways and vehicles (and overhauls for vehicles). This is likely to make a very substantial (and hopefully positive) difference to the balance of the game, and 1 it is likely to be hard to assess what, if any, other fundamental economic changes are necessary until those changes have been made (and also possibly a somewhat vexed exercise to balance an Experimental pakset before this system is introduced only to have to rebalance it after it is implemented). Unfortunately, this is likely to take a very long time to implement because of the necessary knock-on changes to other parts of the code, such as the vehicle replacer and depot system better to accommodate overhauls, to allow buying/selling second-hand vehicles, to allow cascading, etc.. Also, I wanted to implement a better model of braking physics for rail vehicles before instituting balancing/economic changes, as things affecting the distance that any given convoy can cover in any given time is likely to affect balance substantially, too. These matters may be hastened significantly if anyone is able to work on the code of these things with me, but doing it alone is, alas, a very slow process: the point to point timings have been in progress, for example, since late spring and only released on Saturday.

c1 that is good news. When the game balances changes i shall change the parameters of the pak to addopt to it. Since i don't plan to touch any dat file directly or individually, it should be quite a bit less work than doing so for pak.britain. Remember, i only set some flags and parameters defined by the physis of a vehicle and plan to get the parameter in the dat through formulae. (main reason is to achieve consistency)

Finally on obsolescence: I am not sure that it is quite as deus ex machina as you suggest to make 1950s steam locomotives obsolete by the 1960s; this is indeed done in Pak128.Britain-Ex, although I acknowledge that this has not been tested yet.

If i set obsolecense so that it gets quite uneconomical to use it after 10 years, i'm in big trouble for any other parts of the timeline where they should live more than 10 years. Realistic values are more in the 50 to 100 year range for steam engines. (a normal mechanic can copy all steam engine spare parts.). If i would like to have variable obsolescence i would need a very complicated function

It would also be quite difficult to change the setting, by replacing the wage function, we can easily switch from 1st world to 3rd world countries, or from free market economies to socialist systems. This is quite interesting for a non-country specific pak like pak128.

It shall get even worse, if you ever decide to actually implement a used engine market as you considered in a couple of threads.

In summary, a type/factors approach will probably work better if there is enough development effort to put into it, but the likely enormously large amount of development effort (both pakset and code) required for it to work makes it a very difficult proposition, which, when combined with the impending necessary changes relating to asset lifespans, might very well not be worth the outlay.

I can't see this to bee much work to implement on the code side? I'm not deep enough into simutrans code (and c) to really see it, but reading 2 new parameter and one extra file, calculating a value in a linear equation and adding it to a parameter already read from the dat file, seems from the outside rather straight forward? I don't want to sound like lacking respect for your work and much more your time, i mostly write this as i'm not sure if we are talking about the same extension here.

[jamespetts]

Your suggestion is that only vehicles' fixed monthly costs scale with the labour cost? I don't think that that would work, since labour costs also affect the per kilometre cost (which represents in part cost of fuel and in part cost of repairs, the latter of which is heavily dependant on labour). What's more, different vehicles will have a different proportion of their per kilometre costs taken by repairs and fuel; worse still, even the per month cost is not entirely labour, as some maintenance tasks need to be undertaken regularly no matter how much a vehicle is used (replacing perishable rubber seals, for example, some of which cost represents materials cost rather than labour). Also, way maintenance is very labour intensive, especially in the early days, but later methods, introduced in the 1950s, reduced the labour intensiveness of way maintenance - but at the cost of considerable capital outlay for the machines; and I don't think that the machines entirely offset the increased cost of labour, either.

The problem is, I think, that a partial implementation of a labour costs model would be worse than not implementing it at all, as it would introduce new relative distortions into the economic model. This is the sort of thing, I think, that has to be done completely or not at all.

As to obsolescence - you can specify the number of years before obsolescence individually for each vehicle, which I do for steam locomotives in Pak128.Britain-Ex, which will circumvent the issue that you describe here (and was intended for just that function).

[sdog]

James,
thank you for taking the time to read and reply again to my request. I shall reply in turn, let me know if you consider the discussion on this to be over, you have the last word.

Your suggestion is that only vehicles' fixed monthly costs scale with the labour cost? I don't think that that would work, since labour costs also affect the per kilometre cost (which represents in part cost of fuel and in part cost of repairs, the latter of which is heavily dependant on labour).

Yes vehicles need more maintenance when used more. But if you don't use them you still have to pay the workers doing the maintenance for sitting around and playing cards. Same for the crew of the vehicle, it doesn't matter if it drives or stands, the crew's shift is roughly the same. Neglecting overtime and things like hire-and-fire policies as unimportant details.

Same for your rubber seals. If we want to be picky, we can have a fixed maintenance cost part for parts. I suppose however rubber seals etc make less than 10% of the maintenance costs of a vehicle, i'm happy with some per km costs there. Don't forget we never get a model to be accurate in detail, the trick is what to ignore as non-significant and what not.

To state it clearly, i put all labour costs (including mechanics repairing) in the monthly costs. Only material and fuel costs as running cost. This is of course not correct. But it is an approximation, that shouldn't be too bad. This is especially so if the vehicles run for average milages.

Also, way maintenance is very labour intensive, especially in the early days, but later methods, introduced in the 1950s, reduced the labour intensiveness of way maintenance - but at the cost of considerable capital outlay for the machines; and I don't think that the machines entirely offset the increased cost of labour, either.

i shall bear that in mind when setting prices for earlier ways. However here the work involved is not a constant, it went down as prices went up (this is most likely causal). For steam engines the labour was constant however.

As to obsolescence - you can specify the number of years before obsolescence individually for each vehicle, which I do for steam locomotives in Pak128.Britain-Ex, which will circumvent the issue that you describe here (and was intended for just that function).

I am  more than reluctant to do this, firstly as i need to introduce a new arbitrary parameter for all units, secondly for the units were clearly not obsolete from a techincal point of view. Socioeconomic factors killed them of in the first world. But not in second and third world.
It would not be simulating an economic system and get as a result the dissapearance of steam or not(!) but rather hardcoding the dissapearance of steam. The latter is rather pointless. I don't care if someone plays with steam engines in 1970, i want to see if they dissapear.

The problem is, I think, that a partial implementation of a labour costs model would be worse than not implementing it at all, as it would introduce new relative distortions into the economic model. This is the sort of thing, I think, that has to be done completely or not at all.

That's something the pak sets would have to cope with, if they decide to turn it on. Here where i propose it, it should be noticeable as a clearly highly labour intensive system and high labour costs had an actual real world effect. If it actually works, as a proof of concept, one could always think of other areas or not.

[jamespetts]

Apologies again for the delay in replying; busy at work and working on the next release. The problem with what is proposed is not so much the basic idea of simulating inflation (although that would have its own difficulties), but in the fact that only the vehicle monthly costs would be increased. In reality, an increase in the cost of labour would affect way and building construction (construction workers), vehicle construction (factory workers), vehicle per kilometre costs (maintenance workers: the repairs element of the per kilometre cost is significant; also, the cost of fuel itself is influenced by the labour cost, as somebody has to dig the coal out of the ground, etc.), way maintenance costs (maintenance gangs), and, to some extent, the prices that can be charged (as people earn more, they can spend more). The complexity is that each of these things would be affected to a different extent, as technological development is able to varying degrees partially to offset the increased cost of labour, each of the different activities involve differing amounts of labour in the first place, and certain things can in later years be imported (fuel, vehicles, construction materials).

The effect of inflating just the vehicle fixed monthly cost, therefore, would be to create distortions in the relationship between the fixed monthly cost and all the other costs that have no relationship either to the real economy or any fixed balanced ratio in the game. It would then be nearly impossible to balance the various costs in a way that would achieve a realistic or even playable outcome.

The only way to do this properly, as previously indicated, would be to replace fixed prices entirely or almost entirely with ratios and factors: but that would be a gargantuan amount of work. It might be possible one day, but it is not a priority.

[sdog]

Thanks for the reply James.

I did not intend to apply inflation to labour costs. The idea is to display only the distortion the increase of the labour cost caused beyond the general inflation it probably drove. The increase of construction costs, primary energy, etc i would implicitly average and hide it in inflation which i don't apply.

The price or the change of their prices have mixed causes, they consist of capital cost, labour costs or sometimes, and that might be the most common just market prices. (eg coal) The labour cost for operating those engines are pure labour costs however, so the full increase of labour cost applies to it.

What i want to model is the distortion caused by the increase of labour costs above inflation. I think it would be called costs in nominal curency units.
The following image from wikipedia shows what i mean:
http://en.wikipedia.org/wiki/File:History_of_US_federal_minimum_wage_increases.svg

The model is of course a reduction. It assumes that all things in the pak follow average inflation. Labour cost of per man hour does not, but this is compensated by a reduction of man-hour requirement for newer vehicles.

The only way to do this properly, as previously indicated, would be to replace fixed prices entirely or almost entirely with ratios and factors: but that would be a gargantuan amount of work. It might be possible one day, but it is not a priority.

Not necessarily. The fixed prices you have in the pak are nothing else than factors too. Secondly, my hunch is, that making energy cost and labour cost independent from the rest of the prices would cover everything to a very high detail. Those are the two factors that mainly deviate from normal inflation.

It would then be nearly impossible to balance the various costs in a way that would achieve a realistic or even playable outcome.

sounds challenging, might be one reason more to be interested in trying it.

[jamespetts]

I think that the difficulty that I explain above still remains, especially relating to way construction costs, etc.. For example, supposing that the fixed maintenance of vehicle X is 100 in year 1, the running cost of vehicle X is 5 in year 1, and the cost of building one km of way Y is 2,000 in year 1. Suppose also that the fixed monthly cost of the vehicle is 100% labour, the running cost is 30% labour and the way construction cost is 60% labour. Suppose further that the nominal labour cost (i.e., its increase above the general level of inflation) increased by 25% between year 1 and year 10.

In that case, in year 10, the fixed maintenance cost of the vehicle would be 125, the running cost would be 5.375, and the way construction cost would be 2,300. Because transport is relatively labour-intensive operation, the fares, too, might have gone up above general inflation, but this might still mean that the fares would be less in proportion to all elements of costs other than the interest charged on borrowed capital than it was 10 years previously. If all that was to happen was that the fixed maintenance cost of the vehicle were to increase from 100 to 125, whilst the running cost remained at 5 and the construction cost of this particular way remained at 2,000, the building of ways would have become too cheap in comparison to the fixed costs of vehicles (and so forth).

The existing prices cannot themselves be seen as factors because they do not give a proportion of labour charges: in the model given above, there are no date in the game that could apportion 60% to the way, 30% to the running costs and 100% to the fixed costs. Further, it will not be sufficient simply to provide constants for every type (i.e., have all way construction costs at 60% labour, all running costs at 30% labour, etc.) because the proportions change with newer technology (so later ways would have a lower proportion of labour costs than earlier ways, for example), and different vehicles would have different proportions (for example, a superheated steam locomotive has a lower running cost than a non-superheated steam locomotive solely because it is more fuel efficient, which difference in running cost is rather significant: however, it does not alter to any extent the cost of repairs, which is also a per kilometre cost, and which is about 80% labour; the consequence is that superheated steam locomotives have a higher proportion of the labour charge in the running cost than non-superheated steam locomotives, and this is but a small example: any difference in reliability or in fuel efficiency between vehicles, and the differences at the extreme ends can be orders of magnitude, will have this effect), and that's not to mention things like buildings. Further, it might be that fuel price inflation deviates from the average, construction materials inflation deviates from the average, and so forth. Indeed, in so far as one factor differs from the average, it follows that all other factors must also differ, since the average, by definition, takes into account the deviating factor(s). It is not very likely that there is one rate of inflation for labour and another rate for everything else: each sector has, in effect, its own rate of inflation.

In a way, it would be easier to model actual inflation than a deviation from average inflation, as it will not always be easy to track which factors do what in proportion to the inflation of everything else (and some things might deflate relative to the average, which is more fiddly to model and harder to understand than just inflating things). Modelling actual inflation would also prevent players building up an enormous war chest in 1880 and spending it all in 1965 on an extensive airline network.

[sdog]

disclaimer sorry for the tl;dr, it got out of hand

I still don't see why you consider what you describe in the first section as problematic. You just show an example where it works out nicely.
"[...] the building of ways would have become too cheap in comparison to the fixed costs of vehicles (and so forth)." You can phrase it in a different way, the monthly cost of the vehicle has become too expensive, it thus is likely to be replaced by a less labour intense vehicle. You also show that it's a very good approximation to consider running costs constant, even if you assume the labour part to be 30% (i'll come back to this below).

Track laying became less labour intense as labour costs increased. I would guess this fairly well compensated the cost rise, taking construction cost constant might be a good enough assumption. (we could check it perhaps.) There is a rise in track complexity and quality with later years, requiring higher construction costs.

Further, it will not be sufficient simply to provide constants for every type (i.e., have all way construction costs at 60% labour, all running costs at 30% labour, etc.) because the proportions change with newer technology (so later ways would have a lower proportion of labour costs than earlier ways, for example), and different vehicles would have different proportions

Look that's the very point here. If you have your new way built, you have your call of bids and get a company to construct your way to the best price available. This means the company can't build it in the way they did 30 years ago if labour costs exploded in the meantime. The technological state is always recent. Even if you build your track to the same 30 year old specification.

What does not change however, is the labour requirement for maintenance and operation of an engine. It stays constant. It only changes from one model to another, if there is economic pressure for reduction. If you have a 30 year old engine, it is at a 30 year old technological state. This is also true for the superheated steam loco, eg. running costs. If you look at historical examples like: SR Leader class you will also find that in the late age of steam quite a lot of effort was made in loco design to reduce labour demand.

With runing costs for building it is the same. The labour is not constant. For a village station you have a few man hours per week now to swipe it and get money from the ticket machines. In 1970 one had several permanent employees to sell tickets and operate switches. Cost of labour was the economic pressure leading to this, it is i think a sound assumption that the reduction of labour compensated it.

I don't concur that the labour of maintenance cost is a km based cost. It is a per engine monthly cost, as you need the workforce regardless if you run the engine or don't. The workers are not payed by the maintenance they do, but being employed for fixed working hours. If the engine is standing still for two months, you still have to pay their wages. The labour (man hours) for maintenance depends on the operation time, but the cost of that labour is mostly constant. (This changes for the individual unit if there is a large number of units, but it is compensated for the whole fleet. You only notice it as a synergetic effect of decreased maintenance costs if your fleet is large. You move from paying wages for maximum utilization to paying wages for average utilization. IF our model was fine enough, we could model this easily by using fixed monthly costs for the expectation value.)


"It is not very likely that there is one rate of inflation for labour and another rate for everything else: each sector has, in effect, its own rate of inflation."
Yes. But we can pick the most massively deviating factors. That would be labour cost and likely the price of oil/energy. A model needs reduction. If one wants to model a factor with a bit more detail does not mean that all less influential factors have to be modeled in more detail too.

I think it could be worthwile to model the price of oil, and to a lesser extent coal and electrical power too. It leads to far though.

I don't understand your last paragraph. What benefit would modelling inflation bring, except lowering debt? (that you can do by reducing interest)
"Modelling actual inflation would also prevent players building up an enormous war chest in 1880 and spending it all in 1965 on an extensive airline network." We don't have interest on positive balance. If we had a savings account with the starting money from 1880 interest would be quite a lot in 1965. You can consider this lack of interest as inflation plus dividend.