Towards a balancing spreadsheet for vehicles

[moblet]

Here's a simple and merely conceptual first draft. No real numbers in it, just some of the basic calculations; things like the speedbonus and a charge for infrastructure costs aren't in there yet. Wanted to get this out for review of the concept and also because it might help inform current discussion on game features.

Proposed methodology is to have the spreadsheet accept each unit's parameters, along with operating assumptions such as average speed and load factor, and compute its "lifecycle profit factor". The lifecycle profit factor is the lifetime revenue divided by the lifecycle cost of the unit. I propose this as the fundamental unit of comparison between units, benchmark value = 1. My little brain currently thinks that this produces a valid comparison between vehicles that may have very different technical and cost performance. Basically the task is to set the numbers for each unit to hit the benchmark, or whatever value we want that unit to have. High-speed vehicles can have their assumed average speed set higher; with this done they can be benchmarked to 1 and their cost structure will make them less economic for low-speed service. I'd expect benchmarking could be at least semi-automated by use of macros or VB coding and Excel's Goal Seek function, if not by some algorithm of our own design.

The vehicle's lifespan is a user-defined assumption in this draft, but a nagging voice is telling me that it is really an output of the other numbers in the spreadsheet, depending on the shape of the maintenance cost curve (and the still-in-progress discussion on handling maintenance costs with age). Either way the lifespan is a pivotal number, and my current belief is that balancing is impossible if vehicles don't have one.

I've not included overhauls in this draft. Overhauls would add to the complexity of the balancing task and probably not add any benefits in terms of levers, as I think we have enough levers there as it is. They are simple enough to add to the spreadsheet, though.

[ӔO]

for the trains, which can run quite an extensive variation in consists, power balance should be looked at too.

[jamespetts]

Thank you for that - that is most interesting. I notice that the revenue per kilometre is fixed, whereas, in Simutrans-Experimental, the revenue per kilometre can vary greatly (i.e., by orders of magnitude) depending on the average speed of the line and, for passenger vehicles, also the comfort of the vehicle. The computations for both are really rather complicated: the relevance of average speed to revenue takes into account the following:

(1) the "speed bonus" rating of the particular type of goods;
(2) a speed bonus speed level, set in speedbonus.tab, which varies with the year; and
(3) the length of the journey (the longer the journey, the greater the importance of speed).

The importance of comfort varies depending on the following factors:

(1) the length of the journey relative to a minimum tolerable comfort level set for that length of journey using parameters specified in simuconf.tab;
(2) the defined values for a discomfort penalty or luxury bonus for falling below or exceeding the tolerable values respectively (the discomfort penalty is usually about twice as much as the luxury bonus); and
(3) whether, and if so, the extent to which, a vehicle is overcrowded (all standing passengers have a maximum comfort of 10).

As to overhauls - I thought that those were important? That is a matter for the other thread, I suppose, but I'd be interested in your views on the latest discussions there.

You also refer to "scrap value". That is not at present how Simutrans works with respect to resale value, although I'd like to change that in the future. Currently, all vehicles have a linearly-depreciated age-based resale value, being identical to their purchase cost in the month after purchase. What I'd rather have is the ability for players to be able to trade secondhand vehicles amongst each other, and, in default of that, obtain only a scrap value for them, defined as a certain (low) percentage of their purchase price (perhaps 5% or so). However, the present state of affairs ought be borne in mind for the present.

One other complexity relates to capacity. This is all very well for 'buses, boats and aircraft, but falls apart with trains where there are often separate locomotives and carriages, which can be mixed and matched. One has to look at locomotives as having a haulage capacity (based on the weight of carriages available when they are new, I suppose: carriages get heavier throughout the game); but then carriages themselves need balancing. I wonder how one would incorporate that into a spreadsheet like this? (The same applies for horse-drawn 'buses, of course).

[ӔO]

One other complexity relates to capacity. This is all very well for 'buses, boats and aircraft, but falls apart with trains where there are often separate locomotives and carriages, which can be mixed and matched. One has to look at locomotives as having a haulage capacity (based on the weight of carriages available when they are new, I suppose: carriages get heavier throughout the game); but then carriages themselves need balancing. I wonder how one would incorporate that into a spreadsheet like this? (The same applies for horse-drawn 'buses, of course).

I would start off with a list of carriages available and their parameters. Sets can be rounded up into one entity and use a default % increase or decrease for certain configurations. Like a dining would be 5% more in cost and 15% more in maintenance over the stock configuration.

[jamespetts]

Ahh, yes, I forgot to mention the relevance of catering and TPO vehicles, which furhter complicate revenue calculation. They should be more expensive to buy and run, but increase a whole train's revenue (to a greater extent for longer journeys).

The complexity is, of course, that, for any given carriage type, different locomotives can haul different numbers of them at different speeds (and not just in a linear relationship to each other: some locomotives are good at hauling a large number at a low or moderate speed; some are good at hauling a small number at a high speed; some are good at hauling a large number at high speed; and some can only haul a few at low speed; and everything in between).

Then, we have multiple units which can either have fixed formations or have different numbers of non-powered vehicles to powered vehicles depending on the user's chosen configuration.

[The Hood]

Just a practical suggestion: I've found in the balancing I've done in Standard the spreadsheet method isn't infallible.  I'd recommend getting things approximately right with a spreadsheet and then testing them and seeing if they work in their intended way in game.  Also, given how journey times affect loadings etc in experimental, I'd also get the power/speed balanced as well as possible first, and only then try to do the speed.

[ӔO]

I think multiple units are easier, since they're very restricted in possible configurations and possible speeds, the unfortunate part is, they're only available later in the game.

[moblet]

the revenue per kilometre is fixed, whereas, in Simutrans-Experimental, the revenue per kilometre can vary greatly

Yes, I know enough to know that the revenue side is complicated so I left it for another day. The first question is whether the "lifetime profit factor" is the right measure to use as a benchmark, before getting too carried away. No one's shot that down so far, although sdog is yet to chime in...

Of course the trains have to be special . What's in my head at the moment is that passenger vs goods as a whole ought to be balanced so that a loco equally suited to either will do equally well hauling either. And we of course have to look at balancing within passenger service and to take into account ancillary carriages, pretty confident we can navigate that, AEO's idea of corralling them into sets might come in handy. Not sure where the comfort model fits into all this yet, I have to get my head around it, and the speedbonus, first. My feeling is that the comfort model won't make too big a mess, it just influences which configuration might be optimal behind a given loco.

I'm not sure all of the differences in loco capability are going to be very difficult to incorporate, since it sounds like they come down to assumptions of capacity and speed. Yes, locos have differential performance, but we handle that by benchmarking the loco on what it does best, since that's what we expect a skilled player to buy it for. We might do a bit of adjustment in the area of versatility, e.g. if a loco is really only fit for one kind of work there is a higher risk in purchasing it relative to a more versatile unit, so its profit factor should be relatively higher in exchange for that risk. Multiple units won't be hard - we select their optimal configuration, or, if we can't separate them, any one will do.

I've found in the balancing I've done in Standard the spreadsheet method isn't infallible

There are so many assumptions underpinning the balancing process that it would be a miracle it we got it right on the first iteration. I think this constitutes a good process for developing the first iteration, and also for converting the feedback from each set into a better subsequent set. We need to have the right levers in the spreadsheet so we can make any kind of adjustment we need to. Just on that point, can Simutrans write a log of journey speeds, loadings, cost, and revenue? Getting actual data out of the sim would help us punch accurate numbers into the balancing process, and to identify where our assumptions were barmy.

all vehicles have a linearly-depreciated age-based resale value

Ha! I just asked this question in the other thread. Real-world depreciation is a percentage of remaining value, so the value decreases at a decreasing rate. By scrap value I just mean depreciated value at the end of the nominated life. We don't have to use that terminology in the sim; I wouldn't change it.

carriages get heavier throughout the game

Something that helps weigh into replacement decisions, but since carriages should outlast locos it may not matter all that much.

[jamespetts]

Yes, I know enough to know that the revenue side is complicated so I left it for another day. The first question is whether the "lifetime profit factor" is the right measure to use as a benchmark, before getting too carried away. No one's shot that down so far, although sdog is yet to chime in...

I suppose that the question is this - in real life, are the lifetime profit factors of all (successful) vehicles of a certain type identical, or at least within a narrow range? If so, then that may be the way to go. If not, then, given that we're trying to simulate reality, we'll be failing if we adopt this model. My starting point would be to make the simulation as close to real life as possible in significant respects, then put in numbers as close to real-world numbers as possible and see what happens. Don't we want the outcome to be something that we learn from running the simulation on real data, rather than something that we stipulate from the beginning? Of course, if we then need to adjust the values after testing to make the game playable, that's another matter.

Of course the trains have to be special . What's in my head at the moment is that passenger vs goods as a whole ought to be balanced so that a loco equally suited to either will do equally well hauling either. And we of course have to look at balancing within passenger service and to take into account ancillary carriages, pretty confident we can navigate that, AEO's idea of corralling them into sets might come in handy. Not sure where the comfort model fits into all this yet, I have to get my head around it, and the speedbonus, first. My feeling is that the comfort model won't make too big a mess, it just influences which configuration might be optimal behind a given loco.

Further complexities are introduced as there are different types of goods traffic: a locomotive good for hauling vast amounts of coal may be less than useful for hauling a fast fish train, and so on. As to comfort (and also to be considered: loading times), that is intended to be able to differentiate between suburban, semi-fast and long-distance travel (and various gradations in between in some cases), so different configurations will be differently profitable depending on the sort of journey for which they are used: train A might be highly profitable on an express, but lose money on a suburban stopping service, whereas train B might be ideally suited to a local stopping service, but be hopeless (and unprofitable) on an express. Running costs, loading times and comfort all have a part to play in this equation (running costs in that local trains will generally have lower revenue but be able to use slower, less powerful and less comfortable vehicles).

I'm not sure all of the differences in loco capability are going to be very difficult to incorporate, since it sounds like they come down to assumptions of capacity and speed. Yes, locos have differential performance, but we handle that by benchmarking the loco on what it does best, since that's what we expect a skilled player to buy it for. We might do a bit of adjustment in the area of versatility, e.g. if a loco is really only fit for one kind of work there is a higher risk in purchasing it relative to a more
versatile unit, so its profit factor should be relatively higher in exchange for that risk. Multiple units won't be hard - we select their optimal configuration, or, if we can't separate them, any one will do.

We also have to bear in mind that newer (and often heavier) rolling stock will be introduced after a locomotive is introduced, although I suppose, as in real life, that is not accounted for when building the locomotive.

There are so many assumptions underpinning the balancing process that it would be a miracle it we got it right on the first iteration. I think this constitutes a good process for developing the first iteration, and also for converting the feedback from each set into a better subsequent set. We need to have the right levers in the spreadsheet so we can make any kind of adjustment we need to. Just on that point, can Simutrans write a log of journey speeds, loadings, cost, and revenue? Getting actual data out of the sim would help us punch accurate numbers into the balancing process, and to identify where our assumptions were barmy.

I don't think that it can output a log, but the line statistics in the line management window are useful.

Ha! I just asked this question in the other thread. Real-world depreciation is a percentage of remaining value, so the value decreases at a decreasing rate. By scrap value I just mean depreciated value at the end of the nominated life. We don't have to use that terminology in the sim; I wouldn't change it.
Something that helps weigh into replacement decisions, but since carriages should outlast locos it may not matter all that much.

Given that I hope eventually to change this to an internal market for secondhand vehicles and scrap value, there is no need to tinker with this now.

[sdog]

No one's shot that down so far, although sdog is yet to chime in...

well, you know german brainstorming? link

i'll avoid to look into the spreadsheets now, i have to distract myself a bit less. It is not good that i already accumulated quite a backlog in the first week of the year.

[moblet]

I suppose that the question is this - in real life, are the lifetime profit factors of all (successful) vehicles of a certain type identical, or at least within a narrow range?

Probably. They must have been profitable, and even if they weren't, from a playability perspective we have to make sure that every vehicle is profitable if operated sensibly, but at the same time that no vehicle wallops all the others of its era in terms of cost performance. Hold that thought. In the real world different owners operated under different local economic and operating conditions so I wouldn't try to simulate actual profitability.

If not, then, given that we're trying to simulate reality, we'll be failing if we adopt this model.

"This model" is not a single set of answers, it is a process for generating consciously constructed, and playable, parameter sets. We will almost certainly fail if we don't have any such process. This is an effort to bring some order and efficiency to what is a very large and intricate task, on a "first crawl, then walk, then run" basis.

My starting point would be to make the simulation as close to real life as possible in significant respects, then put in numbers as close to real-world numbers as possible and see what happens. Don't we want the outcome to be something that we learn from running the simulation on real data, rather than something that we stipulate from the beginning? Of course, if we then need to adjust the values after testing to make the game playable, that's another matter.

I don't hear anyone else saying that the ultimate goal is that every number in the sim matches the real world. I believe what people want is a sim that behaves like the real world. Simutrans is a simple model of the real world; to get that model to mimic the real world in the ways we'd like, we have to understand what it does and doesn't capture, what assumptions underpin it, and adapt its inputs accordingly. I believe the goal is to have the sim respond to player decisions in manner similar to how the real world would, and the way to achieve that is not to fixate on real-world numbers, but to identify the real-world dynamics that warrant capture and find the most realistic and efficient way to mimic them. This then drives the data gathering requirements.

Further complexities are introduced as there are different types of goods traffic: a locomotive good for hauling vast amounts of coal may be less than useful for hauling a fast fish train, and so on.

What I've already said still applies - we benchmark a loco on the assumption that it will be used for what it does best, e.g. we assume the slow loco hauls something non-perishable, and compare that with the profitability of the faster loco hauling something perishable. If they can't be balanced sensibly then we would have to revisit the goods pricing.

train A might be highly profitable on an express, but lose money on a suburban stopping service, whereas train B might be ideally suited to a local stopping service, but be hopeless (and unprofitable) on an express. Running costs, loading times and comfort all have a part to play in this equation (running costs in that local trains will generally have lower revenue but be able to use slower, less powerful and less comfortable vehicles).

Again, I thought we'd already covered this with the idea of benchmarking a vehicle on what it does best. If something isn't technically capable of earning large revenues then it will have to be cheaper to own and run, while if something is capable of earning large revenues it must cost more so it is only worth buying if those revenues will be realised. This benchmarking process can tell us what those cost differences should be, but can only do so after, as a couple of people have observed, the technical performance of the vehicles has been specified. If the cost disparities required to balance the profitabilities of disparate vehicles seem too large, or too small, compared with what they were in reality, or more importantly what makes for good gameplay, then the revenue model(s) can be adjusted to alter the relative profit outcomes in the desired manner.

EDIT/AFTERTHOUGHT: In accordance with a basic modelling principle of starting off simply and adding complexity, I suggest that we stop confusing ourselves by trying to start with the most complex balancing task, i.e. trains, and focus on mastering the concept and practice of balancing with the simpler modes. Once we have them in our pocket the rail task won't seem so daunting.

[moblet]

i'll avoid to look into the spreadsheets now, i have to distract myself a bit less.

No problem. Your incisive (German?) analysis is worth waiting for.

[neroden]

Here's a simple and merely conceptual first draft.

I haven't looked at yours, but please look at the spreadsheet I created for this purpose, which is actually in SVN if I remember correctly.

I went to some effort to work out the infrastructure cost model and the number of vehicles using the infrastructure, which is crucial for getting a good sense of the actual revenue and costs (infrastructure cost matters!).

I agree that we should do "single-unit" vehicles before trains.  I suggest doing ships/boats first, as their infrastructure cost model is simplest, then buses (with a more complicated set of infrastructure choices).

I would like to emphasize again that there is no point in balancing prices until carrying capacity, vehicle weight, power, and tractive effort have been set, and these are supposed to be set "realistically" for pak128.britain.  

Carrying capacity should come first, and I think carrying capacities are close to correct.

However, tractive effort has not been set yet for the majority of buses and lorries, so I feel that we have a long way to go before we're really ready to balance prices.

EDIT: If you're going to work on balancing, I suggest working on infrastructure maintenance costs first.  I am really unsure how to balance them properly, but every good way of balancing vehicle prices depends on balancing infrastructure maintenance first.  :-P

I know bridge prices need to be scaled to the scale because elevated track prices are, that would be a start...

[jamespetts]

Probably. They must have been profitable, and even if they weren't, from a playability perspective we have to make sure that every vehicle is profitable if operated sensibly, but at the same time that no vehicle wallops all the others of its era in terms of cost performance. Hold that thought. In the real world different owners operated under different local economic and operating conditions so I wouldn't try to simulate actual profitability.

In many cases the profitabilities would have been comparable; two transport companies in the same country in the same era would all have more or less comparable profit, would they not? Further, different sorts of vehicles may well have been differently profitable by orders of magnitude; local 'buses, for example, may never give anything like the return on investment as airliners (even taking into account capital depreciation), but they are necessary in order to get the passengers to and from the airport and enable the aircraft to carry enough passengers in order to be profitable. That a vehicle is profitable does not tell us how profitable that it is: a set of different profitable vehicles, each potentially the best in any given situation (including budgetary constraints) at a given point in time might be orders of magnitude different in profitability. Some types of transportation might well be orders of magnitude different in profitability to others, but that does not make the less profitable ones not worth pursuing, not least because either they are necessary for linking to the more profitable types to make them work, or because, in a competitive environment, all the opportunities for the more profitable type of transport have been taken away, so the only remaining opportunities are for transportation types with lower profitability.

If a player joins a multiplayer game, for example, 50 or 100 years after it's started, and all that's realistically left for that player to do is add some local 'bus networks to outlying areas not served by other players, then that operation may (even taking into account capital depreciation) be orders of magnitude less profitable than the existing players' rail/air/boat routes, or bus/tram routes in more densely populated areas; but, as long as it is at least a little profitable, it will be worthwhile the johnny-come-lately player performing that type of transportation, and there might well be vehicles that are optimally suited to just that task  and little else (minibuses, for example). If we balanced the minibus so that its profitability was, taking into account capital depreciation, identical to that of an airliner, there would be some significant distortion. Availability of the market is as important a choice for businesses making decisions about where to invest as profit margin, if not more so.

So, indeed, we should balance things that, in the right conditions, no types of vehicles, infrastructure or cargo are, in their own time, impossible to use profitably, but it would be somewhat arbitrary to equalise the profitability of all types of vehicles, as they may well not have been equal in reality, and, in so far as they are not equal in reality, a simulator purporting to simulate that reality should not portray them as equal. That being so, however, it is not necessarily the case that an algorithm that will tell us what would balance things equally is useless. It might be a helpful calibration tool (not least to compare with the profitability of the real thing), and a means to check whether things are indeed profitable within a sensible margin; but the aim of the exercise should be to balance things so that they are as close to reality as possible whilst still being playable. A spreadsheet of the sort that you are devising may, therefore, very well be useful, as long as it is designed such as to ensure that all vehicles are somewhere between (and not including) unprofitable and excessively profitable, rather than aiming to equalise the profits entirely. Where within that range that the vehicles fall should resemble real life as much as possible.

"This model" is not a single set of answers, it is a process for generating consciously constructed, and playable, parameter sets. We will almost certainly fail if we don't have any such process. This is an effort to bring some order and efficiency to what is a very large and intricate task, on a "first crawl, then walk, then run" basis. I don't hear anyone else saying that the ultimate goal is that every number in the sim matches the real world. I believe what people want is a sim that behaves like the real world. Simutrans is a simple model of the real world; to get that model to mimic the real world in the ways we'd like, we have to understand what it does and doesn't capture, what assumptions underpin it, and adapt its inputs accordingly. I believe the goal is to have the sim respond to player decisions in manner similar to how the real world would, and the way to achieve that is not to fixate on real-world numbers, but to identify the real-world dynamics that warrant capture and find the most realistic and efficient way to mimic them. This then drives the data gathering requirements.

Yes, indeed - although I take the view that, when in doubt, one should always err on the side of reality, not least because reality is already balanced for us! If we have a specific reason to fudge the real numbers in a particular way because we know that using the real numbers will result in a particular inaccuracy in gameplay incentives (and, yes, I do agree that the ultimate goal is to make the incentives rather than the numbers themselves realistic), then we can then decide how and how far to depart from reality. So the next issue, then, is this: where are the economic drivers in Simutrans distinctly different from those in reality? And, in each such case, is it better fixed by changing the figures or changing the programme itself? I know that we are discussing a number of potential coding changes in the other thread for just this reason.

What I've already said still applies - we benchmark a loco on the assumption that it will be used for what it does best, e.g. we assume the slow loco hauls something non-perishable, and compare that with the profitability of the faster loco hauling something perishable. If they can't be balanced sensibly then we would have to revisit the goods pricing.

This seems sensible - vehicles were, after all, bought and built with particular purposes in mind.

Again, I thought we'd already covered this with the idea of benchmarking a vehicle on what it does best. If something isn't technically capable of earning large revenues then it will have to be cheaper to own and run, while if something is capable of earning large revenues it must cost more so it is only worth buying if those revenues will be realised. This benchmarking process can tell us what those cost differences should be, but can only do so after, as a couple of people have observed, the technical performance of the vehicles has been specified. If the cost disparities required to balance the profitabilities of disparate vehicles seem too large, or too small, compared with what they were in reality, or more importantly what makes for good gameplay, then the revenue model(s) can be adjusted to alter the relative profit outcomes in the desired manner.

This is interesting: I started off thinking about replying, "but what if it wasn't like that in reality?", but then realised that it almost invariably is - that things capable of earning greatly higher revenues do, indeed, cost much more than those that aren't. Of course, this isn't always a simple model: a 'bus in a densely populated town might earn vastly more than the very same 'bus in a small village, such that the smaller 'bus built just for small village use will not be less expensive in proportion to its reduced profitability; but, within bounds of very broad approximation, it does generally hold that higher revenues can be earned from more expensive vehicles, no doubt at least in part as a result of price competition (if the competition can do it much more cheaply, then they can undercut and still maintain a good profit margin; so part of the reason for the ability to generate a high revenue in the first place is the high cost that that revenue must offset for that form of transport). This would suggest that profitability levels within a fairly broad (but defined) band are indeed what one would expect in reality.

EDIT/AFTERTHOUGHT: In accordance with a basic modelling principle of starting off simply and adding complexity, I suggest that we stop confusing ourselves by trying to start with the most complex balancing task, i.e. trains, and focus on mastering the concept and practice of balancing with the simpler modes. Once we have them in our pocket the rail task won't seem so daunting.

This could work, although the note of caution that I'd sound in relation to that is that we must know in advance that our model will scale in complexity well: it is possible for any given model to work very well on the simpler tasks, but to fail completely on the more complex ones, so we have to consider the complexities (at least in the abstract) before we finalise the design for our model such as to ensure that it will, indeed, account for those complexities.

[moblet]

I haven't looked at yours, but please look at the spreadsheet I created for this purpose, which is actually in SVN if I remember correctly.

Thanks neroden. It's a bit similar to the one of The Hood's I saw. What I'm proposing is a bit different; it uses some of the same data, but the unit of benchmarking is very different, being based on lifetime economic performance. My spreadsheet won't take long to understand, certainly faster than me trying to explain it. There is a fatal problem for it at present, as it relies on the idea that a unit has economic lifespan, something that does not currently exist in Simutrans, as maintenance costs do not increase with age.

I would like to emphasize again that there is no point in balancing prices until carrying capacity, vehicle weight, power, and tractive effort have been set

I would like to second that, and add that I cannot see how to balance prices if units do not have a economic lifespan.

If you're going to work on balancing, I suggest working on infrastructure maintenance costs first.  I am really unsure how to balance them properly, but every good way of balancing vehicle prices depends on balancing infrastructure maintenance first.

I just discovered that myself! I guess the first question is how to simulate the degradation of infrastructure, i.e. fixed and variable costs, and replacement. There are currently no usage-based infrastructure costs, which unbalances early vs mature gameplay (makes it harder to make a profit when you start out), and also doesn't capture the reality that trains wear out rails but boats don't wear out water. If vehicles inflicted wear on their infrastructure that would be simple to include in balancing. One simplistic idea I have is to consider that each mode is, by nature, differentially infrastructure-intensive, and apply an infrastructure capital charge that is the same for each unit of a given mode. So we would benchmark a tram as if its purchase price included a portion of the infrastructure it required. The outcome of this is that the tram would be made cheaper than a bus to buy and own as an individual unit per passenger-km, to compensate for the fact that the player has to pay for more infrastructure to run the tram. The infrastructure loading would be set at a level that assumed a certain level of infrastructure utilisation; the player would not realise the benchmark return on the infrastructure investment if they did not achieve this utilisation (the lower cost of the trams would not offset the infrastructure cost unless a minimum number of trams were bought and used).
I haven't reached a conclusion as to whether infrastructure also needs a finite life for balancing to work.

In many cases the profitabilities would have been comparable; two transport companies in the same country in the same era would all have more or less comparable profit, would they not?

Why? If you are making a killing tramming people around London, and I am barely profitable hauling coal through the Midlands, what's going to cause us to have comparable profitabilities? Our equipment and markets are neither comparable nor transferrable, so why should we automatically achieve the same outcome? One might as well compare a steel mill and a pharmaceutical company.
Alternatively, we could both be hauling coal in different parts of the country, using identical equipment, but be getting paid a different price/km. If one of us therefore makes a lower profit than the other, is that the equipment's fault?

local 'buses, for example, may never give anything like the return on investment as airliners (even taking into account capital depreciation), but they are necessary in order to get the passengers to and from the airport and enable the aircraft to carry enough passengers in order to be profitable.

If we balanced a mode of transport on the assumption that it is only viable if cross-subsidised, how much fun would that be? If no bus could be profitable of its own accord, no matter what its loading? Each unit will require a certain utilisation to operate profitably. An operator could choose to assign it to a task with lower utilisation as part of a bigger network picture, but if a bus cannot make a profit under any circumstances, it is a lemon.

Some types of transportation might well be orders of magnitude different in profitability to others, but that does not make the less profitable ones not worth pursuing, not least because either they are necessary for linking to the more profitable types to make them work, or because, in a competitive environment, all the opportunities for the more profitable type of transport have been taken away, so the only remaining opportunities are for transportation types with lower profitability.

Yes. This is in contradiction to your opening argument about all transport companies having comparable profitabilities. Choosing to provide a transport service or not is a binary decision, and in a perfect world will be done wherever there is profit to be made, and regardless of the magnitude of the profit available.

If we balanced the minibus so that its profitability was, taking into account capital depreciation, identical to that of an airliner, there would be some significant distortion.

In dollar terms yes. As a ratio of profit earned to capital cost, no. Return on capital is the actual leveller in the real world, that causes money to be shifted from one industry or operation to another. If the airliner had much higher return on capital, more investors would pile into the airline business, and none into the minibus business, until the airline market was sufficiently saturated that return on capital fell to the minibus level. The number of planes would increase until utilisation fell to the point that one got the same return on a dollar invested in the minibus business as they did on one invested in the airline business. This is the theory. In practice the market is never perfectly balanced because of uncertainty, time delay, imperfect information, and various forms of variability.

Availability of the market is as important a choice for businesses making decisions about where to invest as profit margin, if not more so.

How could one estimate a profit margin without first estimating the market?

So, indeed, we should balance things that, in the right conditions, no types of vehicles, infrastructure or cargo are, in their own time, impossible to use profitably

Yes

but it would be somewhat arbitrary to equalise the profitability of all types of vehicles,

No

as they may well not have been equal in reality,

Because reality was heavily determined by local operating and economic conditions

It might be a helpful calibration tool (not least to compare with the profitability of the real thing), and a means to check whether things are indeed profitable within a sensible margin

Yes

the aim of the exercise should be to balance things so that they are as close to reality as possible whilst still being playable

Hence the need for a tool that allows us to massage numbers as easily as possible

A spreadsheet of the sort that you are devising may, therefore, very well be useful, as long as it is designed such as to ensure that all vehicles are somewhere between (and not including) unprofitable and excessively profitable

This is exactly what I'm aiming to present in an easily digestable format, and to support easy calibration of units that we want to move away from the benchmark.

rather than aiming to equalise the profits entirely.

Profits in the game should be an outcome of seeding and player choices, a bit like the real world. Proscribing profits in the determination of the vehicle parameters means it doesn't matter what the player does, the outcome is predetermined.

Yes, indeed - although I take the view that, when in doubt, one should always err on the side of reality, not least because reality is already balanced for us! If we have a specific reason to fudge the real numbers in a particular way because we know that using the real numbers will result in a particular inaccuracy in gameplay incentives (and, yes, I do agree that the ultimate goal is to make the incentives rather than the numbers themselves realistic), then we can then decide how and how far to depart from reality. So the next issue, then, is this: where are the economic drivers in Simutrans distinctly different from those in reality?

Reality is not static, it is in a constant state of flux, shifting away from, and back towards, equilibrium, sometimes in small steps (Patricia buys some shares), sometimes in large ones (Global Financial Crisis). The Simutrans world is, by contrast, extremely static. One can't choose a moment in history and claim that everything was in balance at that moment, therefore it's difficult to pluck numbers from history and expect them to represent a balanced set of game parameters.
A non-exhaustive list of real-world drivers that aren't represented in Simutrans, but which are consequential for transport operators:
- Inflation
- Economic cycles
- Stock and capital markets
- Exchange rates
- War and pestilence
- Government regulation, taxation, or other interference
- Variations in energy costs
- Variations in the cost and availability of labour
- Geographical variation in the value of transport due to local economic conditions
- Significant variations in terrain
- Wear on vehicles and infrastructure
- Equipment failure
- Cost of land
- Variability in industrial output, both short-term (e.g. mining stops due to rain, production increases for Christmas) and long-term (e.g. I built a railway to this factory but it's now closed down)
- Range of cargoes
- Complexity of supply chains
- Demographic variations and trends
- The fact that most of the above, along with the actual performance of anything untried, are uncertain within the typical investment horizon. Not only that, the level of uncertainty of each has changed through history.
I'm not suggesting that all, or even most of these, get modelled in Simutrans, but I will say that when you look at real-world outcomes, especially ones like profitability that are derived from a myriad of factors, you would have to account for all of them to know that you were comparing apples with apples.

And, in each such case, is it better fixed by changing the figures or changing the programme itself? I know that we are discussing a number of potential coding changes in the other thread for just this reason.

Worthy of consideration, but initially not in reference to the existing sim, and certainly not on the basis of "well, we've already coded this other thing". To come up with a good simulator, it is necessary to first decide what a good simulator should model. Once that is clear then go back to the Simutrans engine and see how it can meet that specification.

things capable of earning greatly higher revenues do, indeed, cost much more than those that aren't.

Even if they don't cost more to produce. Because they are worth more to the buyer a premium can be charged for their superior performance. A rational buyer will pay up to what the unit is worth relative to the alternatives.

Of course, this isn't always a simple model: a 'bus in a densely populated town might earn vastly more than the very same 'bus in a small village, such that the smaller 'bus built just for small village use will not be less expensive in proportion to its reduced profitability

If the small village cannot achieve the same utilisation as the city, even with a downsized vehicle, then it should generate lower profitability than its city cousin. But that is a function of the environment, not the vehicle. Take the bus to the city and utilise it more fully and its profit should increase. If the vehicle's pricing is distorted away from realistic operating parameters because it was historically used in a particularly profitable or unprofitable environment it will cause distortions in player choices in other environments. Price a minibus to be admirably profitable at low utilisation and it will be outrageously profitable at high utilisation, and suddenly it will become the most profitable bus to use even in the big city. If the minibus is priced so that it is a better economic choice for the village than a double-decker, then the player will automatically choose it over the double-decker. There's no need to try to pre-empt how the player will use the vehicle, the price and the market will take care of that.

This could work, although the note of caution that I'd sound in relation to that is that we must know in advance that our model will scale in complexity well: it is possible for any given model to work very well on the simpler tasks, but to fail completely on the more complex ones, so we have to consider the complexities (at least in the abstract) before we finalise the design for our model such as to ensure that it will, indeed, account for those complexities.

She'll be right, mate. The trains will require more computations, probably an additional model, but the numbers will be reducible to the inputs for the balancing spreadsheet.

[ӔO]

seeing as the game does store odometer data, could it be possible to increase maintenance after the vehicle hits a certain mileage?

the cost could increase either through two dat values or the game could just assign an average fixed value. The increase should be exponential.
For example after each 50000km, a 5% increase in maintenance cost compounded: 105% @ 50000km -> 110.25% @ 100000km -> 115.7625% @ 150000km.

or the math behind it: (1.05^(n/50000))

but I don't know how much memory this will eat.

[moblet]

I haven't reached a conclusion as to whether infrastructure also needs a finite life for balancing to work.

I have now, and I think it does need a finite life.

Here is a simple real-world example of the market taking care of the purchasing decision, and of different equipment buyers making different choices according to their operational needs and philosophies. It's slide presentation by loco manufacturer EMD, look at slides 36 to 41. Operators can choose between AC & DC traction in their diesel-electrics, with AC performing better under most conditions but costing more. The brief summary of each operator's purchasing choices shows how different buyers will make different choices when confronted with the same options (presumably each locomotive's price is much the same for each operator, although I don't know their respective credit ratings). The cost of each option is constant between operators, but the value of each option differs between operators because of differences in their haulage tasks, operating environments, and infrastructure. In the sim, different parts of the map will offer different haulage tasks and constraints, and once a player has built some infrastructure this will influence subsequent choices, just like in the real world, so those elements of realism are already in place. Beyond that, I think only the following need to be balanced:
- The revenue model should reward each haulage task roughly equally if the player has fulfilled them equally. E.g. distributing from a steel mill should offer the same profit potential as distributing from a pharmaceutical plant. The sim already has the capability to differentiate those tasks by quantity, price per quantity, and perishability, which is all that's required. Differential tonnage vs speed requirements for different cargoes guarantees that for different tasks, a player will calculate the value of the same equipment differently. Balancing the parameters means setting the relative quantities and perishabilities, and then making some assumptions about achievable average speeds to arrive at benchmark prices per quantity for each commodity. Simple enough to do in a spreadsheet. I think this allows the relationship of price to distance to be the same for all commodities.
- Equipment & infrastructure costs should be such that if the player calculates the value of different items differently for different tasks, this will cause them to make different equipment choices accordingly. This demands tuning the relationship between increased performance and increased costs. This could be done by, for example, comparing vehicles by their performance of a "standard" haulage task, or by their return on capital when assigned to the task for which they are best suited. This spreadsheet applies the latter method.

[jamespetts]

I haven't been ignoring this discussion, but have been somewhat preoccupied with work and building a new computer (which, when finished, should make compiling Simutrans and other things considerably faster), but I shall respond in due course when I get a chance. Thank you all for your input so far!

[moblet]

I haven't been ignoring this discussion

You can ignore it all you want!

Another possibility that just popped into my head would be to rent everything instead of buying it. The rental charge could be included in the monthly fixed cost. There could be nominal entry and exit fees for each rental agreement to discourage frequent swapping. Methinks balancing would be a bit simpler under this arrangement, certainly there would be fewer parameters involved. Buying feels nicer from a gameplay perspective but isn't necessarily realistic, especially for vehicles, which are typically leased rather than bought outright. The biggest advantage of renting over buying is cashflow - you pay for the vehicle as you earn revenue from it, not all up front before it's made as much as a penny - which is worth considering as another lever to balance early vs mature gameplay.

[sdog]

Leasing is not a bad idea, this could also be done purely on the pak-set level making it viable for standard too. Or would it require the monthly cost, instead of 1/km based costs?

Huge ships waiting two months to load would be economical than, but aren't not necessarily now. For instance in pak128 depreciation slowly drives one bancrupt. This is not an issue in experimental though.

[moblet]

Leasing is not a bad idea, this could also be done purely on the pak-set level making it viable for standard too. Or would it require the monthly cost, instead of 1/km based costs?

Without the fixed cost the player could acquire excess vehicles without penalty, so the fixed cost would have to be there to force the player to be efficient with their acquisitions. And the variable costs are indispensible to force the player to be efficient with their operations, so I don't see it working too well without both.

For instance in pak128 depreciation slowly drives one bancrupt.

How does that happen? Is depreciation a cash charge or something? (I've not played 128 as I'm not yet ready to tackle the combination of complex supply chains and my lack of knowledge of German at the same time.)

[sdog]

in standard bankruptcy is caused by the net wealth being below zero after a month change. The worth of the vehicle is counted as the players assets. Buying a vehicle doesn't really cost any thing in standard, as this will reduce cash, but increase the assets, the net wealth stays the same. So for a typical game at the beginning it's not unusual to build for about 350k of the 400k one has, and buy vehicles for some 5M.

Since the value of the vehicles depreciate at a constant rate (a few percent p.a.), one is forced to earn enough to compensate depreciation, so one is forced have more monthyl net income than depreciation. (In the example some 50k to 100k) The actual cash doesn't matter at all in standard, the only thing to monitor is net wealth.

[moblet]

Thanks for that explanation.

at the beginning it's not unusual to build for about 350k of the 400k one has, and buy vehicles for some 5M.

I would prefer that at the beginning I could only afford to take one opportunity, and would have to operate that profitably before earning - literally - the ability to take the next one.

[ӔO]

With the current speed bonus and goods settings, it's not very hard to make a profit on express passenger lines, even if they cost $60/km in maintenance per train. This holds true for 1930 and onward, although you really only see $60/km maintenance with the APT and TGV.


I also found this page on horse drawn carriage ability, if they are to be used as a base line for calibrating capacity of vehicles.
http://www.antiquecoach-carriage.com/faq.html

[moblet]

With the current speed bonus and goods settings

Just thinking about the speedbonus concept, would it not be more realistic for the speedbonus to be independent of mode? In other words, for trip revenue to be a function of actual average speed, in a straight line from origin to destination, regardless of the mode (or combinations thereof) used. This would would increase the challenge to the player to build and service the most direct routes possible, using the most efficient modes, for the greatest number of passengers, especially as the passengers' expectations could not be influenced by what modes the player chose to provide (except in "Soviet-era" mode, perhaps ). It would also be simpler in concept and, by eliminating the vehicle speedbonus, reduce the number of vehicle parameters to be juggled. The speed expectation would change with time just as the current speedbonus does. It would however require some sort of algorithm to compensate for geographical barriers (e.g. bodies of water).

I also found this page on horse drawn carriage ability, if they are to be used as a base line for calibrating capacity of vehicles.

Wow, I never thought about how much weight a horse could pull, but I was surprised to see a factor of six. Then again, have seen photos of horses pulling massive and clearly well-laden carts. I expect it would get very nasty very quickly if the vehicle's brakes failed on a descent. The first road over the Blue Mountains west of Sydney (1815) had a long descent on a 1 in 4 grade; to provide braking it was routine practice to drag a log behind the carriage/wagon. Needless to say this section of road was by-passed as soon as an alternative route could be developed.

[ӔO]

I thought about, and did try using a stricter speed bonus setting, by raising the average speed needed for the bonus to be paid and found that it cuts off anywhere from 5 to 20% of income.

Then I read this part:

8.2 - Use recorded car journey time to compare against players' transport's travelling times rather than speed bonus rating for road transport when passengers decide whether to take their car or players' transport.

which must mean that passenger speed bonus is calculated differently. The one thing I don't understand, is the payout of the speed bonus. I hope james can elaborate more on if the percentage value plays any role, other than wait times.

That and you also have to factor in the fact that freight trains are slower, but they too have speed bonuses on perishable items, like food.



As a starting point, I think, with the current way the speed bonus is implemented, we can take a look at the power/weight ratio of the locomotive, and where it falls in line in relation to top speed when introduced.

If the locomotive, when introduced, is on the higher end of the speed limits or is the fastest, then maintenance should cost at least 2x power/weight. If in the middle range of speed, 1.5x power/weight. If in the lower range of speed, 1x power/weight. Or as many divisions as needed, I think about 5 to 7 would do. Express locomotives are able to sustain more than 60.00c/km of maintenance.

I think there also needs to be some exponential decay slope for reducing cost mid to late game, because the power to weight ratio growth appears to be exponential as well. Actually, the multiplier should also probably be an exponential function, but this linear one works well enough.

Taking a few examples

GWR Star 4-6-0
currently 15.18c/km maint. with top speed of 130km/h, and is one of the fastest when introduced.
1600kW/75t = 21.33kW/t
base line maint. = 21.33 * 2 = 42.66c/km

GWR 3150 2-6-2T
currently it has 5.94c/km maintenance with top speed of 105km/h when introduced, but somewhere around the middle. Multipurpose locomotive.

1375kW/78t = 18.33kW/t
base line maint. = 18.33 * 1.5 = 27.50c/km


GWR 2800 2-8-0
Currently, it has 8.58c/km maint., with top speed of 90km/h when introduced, and puts it near the bottom. It is an express use freight locomotive.

1900kW/75t = 25.33kW/t
base line maint. = 25.33c/km

even at 33.69c maint, the GWR star is quite lucrative. It doesn't need to be a double header to pull this length, but was done to raise the cost.


Concerning horses and other biological vehicles:
The current horse drawn carriage settings are a bit unrealistic, with a single horse producing 10kW, but that can't be helped, because the smallest weight allowed in simutrans is 1t, which is also why the mail bicycle weighs 1t. In real life a mail bike would be no more than 120kg with the rider and mail. A horse in real life would produce about 750W, and an average human on a bike would produce less than half of that, about 250W.

[jamespetts]

A few brief observations on some of the main issues raised here for the time being (the other thread is the priority for the time being).

Firstly, it might be worthwhile considering this discussion in conjunction with this discussion in relation to industry, as the two are connected to some extent (especially in relation to goods revenues).

Secondly, to clarify an issue raised by AEO:

8.2 - Use recorded car journey time to compare against players' transport's travelling times rather than speed bonus rating for road transport when passengers decide whether to take their car or players' transport.

does not mean that the calculation of the revenue has changed at all; rather, that, when deciding whether or not to use private cars, the game will now compute the approximate time that it would take to travel from the origin to the destination by private car using a model of the route distance and car speed (based on the road speeds and the maximum speed of the current city cars), rather than the previous method, which had involved using the speed bonus speed to calculate a far more approximate journey time. This does not affect the calculation of the speed bonus for passengers or any other cargo.

Thirdly, Moblet's idea of speed-bonus being independent of mode is more or less implemented in Pak128.Britain-Ex by the simple expedient of having the speed bonus figures set identically for each different mode (other than water). This requires no change in the code. Water is set differently, as water use in latter times usually indicates the existence of the sort of geographical barrier to which Moblet refers (and in earlier times, the water speed bonus is much closer to the land speed bonus). It would, however, be horribly difficult for the game to try to detect in each specific case whether there is some sort of obstacle, and, if so, how much of an obstacle that it would be and how that should affect the speed bonus. Indeed, it would be easier than that simply to replace the entire speed bonus system with a competitive system, such that the price depends on how fast that a player transports goods from any given A to any given B compared with all other available modes of transporting those same goods between that same A and that same B, although that would itself be very difficult, as it would require a whole new mechanism of goods/passengers having different price tolerances as well as different time tolerances, and adding the possibility of price competition would increase exponentially the complexity as players see it and the potential for monotonous micromanagement. I think, therefore, that for the time being, the present approach is to be preferred.

Fourthly, I am not quite sure what Moblet means by infrastructure having a limited life - can you elaborate, Moblet? Certainly, there are bridges tunnels, cuttings, embankments and stations out there well over a hundred years old in regular and intensive use, not likely to be replaced any time soon.

Fifthly, one issue in relation to the use of purchase price to equalise the relative economic performance of vehicles is this: although that model might make sense where the ultimate user of the vehicle has to buy it from a third party manufacturer, in olden times, many vehicles were either built to order or built by the operators themselves (most major railway companies had their own works, for example, although they also subcontracted frequently), and so the purchase cost was not subject to market sensitivity as to its ultimate value. It would seem arbitrary to ignore this significant driver, which might have made a substantial difference to the fortunes of many a transport operator. Not only that, but the cost of vehicles are often set when they are new and before their real success in service has been determined, so even then, the true market value of new vehicles is very unlikely to be reflected in their actual purchase costs.

Sixthly, there may have been some confusion as to the meaning of comparable profitabilities: I understood the idea to refer to it being meaningful to compare one level of profitability to the other such that the different levels of profitability make sense given the different circumstances in the same ultimate context - in other words, I had understood the word "comparable" literally. I think that Moblet may have used the word in its more informal sense to mean "similar", which is not the way in which I had intended the term. Ultimately, I had intended to state no more than that, if there was a substantial difference in profitability, it would have been due to factors that are simulated or ought to be able to be simulated in Simutrans (other than relatively arbitrary factors that we probably don't want to simulate, such as management administrative competence, trade union bargaining power, etc.).

Seventlhy, on cross-subsidisation, the suggestion was not that certain modes of transport could only be profitable at all when cross-subsidised, but rather the potential for one mode of transport positively to affect the profitability of another must be taken into account in circumstances where the two are likely often to be used in conjunction with each other, or distortions are likely. For example, before the second half of the 20th century, many railway branch lines were, of themselves, barely profitable or even unprofitable, but railways kept them going because they fed the far more profitable main lines. These economics of interconnexion are, to use Moblet's phrase, "primary drivers" in the economics of transport and must be simulated in order for the player's incentives in the game adequately to match real-world economic incentives, and for the transport networks produced by a competent player to be sufficiently similar to those produced by competent managers of transport companies in reality.

In any event, this should have stimulated discussion sufficiently for now. I should be interested in responses to these thoughts; thank you to all participants so far for their careful analysis of these important issues.

[moblet]

Fourthly, I am not quite sure what Moblet means by infrastructure having a limited life - can you elaborate, Moblet? Certainly, there are bridges tunnels, cuttings, embankments and stations out there well over a hundred years old in regular and intensive use, not likely to be replaced any time soon.

This arose from my trying to think through balancing vehicle costs, in this case between modes. You mentioned in relation to the rail revenue model's impact on balancing that sometimes it's necessary to work through the whole process to check that it will work before coding anything - I want to raise a red flag here and say that I think we need to work out how we're going to balance vehicle and infrastructure costs before doing any more work on coding revenues and costs. Otherwise we may end up with a sim in which it's impossible for us to balance costs effectively. From above

There are currently no usage-based infrastructure costs, which unbalances early vs mature gameplay (makes it harder to make a profit when you start out), and also doesn't capture the reality that trains wear out rails but boats don't wear out water. If vehicles inflicted wear on their infrastructure that would be simple to include in balancing. One simplistic idea I have is to consider that each mode is, by nature, differentially infrastructure-intensive, and apply an infrastructure capital charge that is the same for each unit of a given mode. So we would benchmark a tram as if its purchase price included a portion of the infrastructure it required. The outcome of this is that the tram would be made cheaper than a bus to buy and own as an individual unit per passenger-km, to compensate for the fact that the player has to pay for more infrastructure to run the tram. The infrastructure loading would be set at a level that assumed a certain level of infrastructure utilisation; the player would not realise the benchmark return on the infrastructure investment if they did not achieve this utilisation (the lower cost of the trams would not offset the infrastructure cost unless a minimum number of trams were bought and used).

I don't know how much sense this makes without a spreadsheet to demonstrate it - if it needs better articulation, say so - but it's the only method I have thought of so far for balancing costs between modes.
Since the relative infrastructure costs are significant in this equation, one has to pin down what the infrastructure costs actually are. This is not possible if infrastructure never ages, since, say, the cost per passenger, or cost per tram km, or whatever measure of usage you care to employ, of a tramline built in 1920 and operated until 2050 will be a lot lower than one built in 2010 and equivalently operated to 2050. In reality that 1920 tramline will need to have its foundations broken up and relaid a couple of times in its life, and presumably its catenary system would need replacing too. If everything has a life, or some reliable mechanism for charging the player for its age, we can then calculate benchmark infrastructure costs for fulfilling a given transport task, and thus calculate a logical balance between modes. If it doesn't, I don't have any answers yet.

Fifthly, one issue in relation to the use of purchase price to equalise the relative economic performance of vehicles is this: although that model might make sense where the ultimate user of the vehicle has to buy it from a third party manufacturer, in olden times, many vehicles were either built to order or built by the operators themselves (most major railway companies had their own works, for example, although they also subcontracted frequently), and so the purchase cost was not subject to market sensitivity as to its ultimate value. It would seem arbitrary to ignore this significant driver, which might have made a substantial difference to the fortunes of many a transport operator.

The decision of whether or not to purchase, in a commercial organisation that has capital available, is foremost driven by return on capital. The unit could be made by Santa's elves, it doesn't matter, the question investors ask is "what will be the return on my capital?". Don't fixate on how the vehicle is produced or acquired, especially as nothing was genuinely mass-produced before the 20th century. I mentioned before that transport costs have fallen over time - one of the drivers of that has been mass-production of transport equipment, which has reduced capital cost per unit of work, which means revenue per unit of work can fall and return on capital remains constant. You won't get good return on capital buying and operating an 1870's steam engine today, and that has to be the case in the sim. In their day, though, the 1870's steam loco and the 2010 diesel should, under equivalent operating conditions, generate similar return on capital. Return on capital is the simplest, most realistic, and most reliable benchmark that I can see. To deviate from that risks arbitrariness.

Not only that, but the cost of vehicles are often set when they are new and before their real success in service has been determined, so even then, the true market value of new vehicles is very unlikely to be reflected in their actual purchase costs.

I thought we covered this before. Simutrans doesn't model uncertainty, so we can't do anything about this. If a vehicle generated a different return on capital to expected, because it didn't perform as expected, we can't mimic that in the sim because that unit will be out of balance and be excessively attractive or unattractive to use. In practice, if it became apparent early in a vehicle's life that it was performing better or worse than expected, demand for that vehicle would increase or decrease, and thus its price would be expected to increase or decrease. In theory the price would rise or fall to the point where the vehicle's return on capital was equivalent to its competitors', its performance advantages/disadvantages fully counterbalanced by its higher/lower price. I'm sure you've found in your explorations of history that certain vehicles performed poorly and the manufacturer had to drop the price to maintain sales, or in extreme cases couldn't give them away.

Sixthly, there may have been some confusion as to the meaning of comparable profitabilities

Forget profitability, think return on capital.

Seventlhy, on cross-subsidisation, the suggestion was not that certain modes of transport could only be profitable at all when cross-subsidised, but rather the potential for one mode of transport positively to affect the profitability of another must be taken into account in circumstances where the two are likely often to be used in conjunction with each other, or distortions are likely. For example, before the second half of the 20th century, many railway branch lines were, of themselves, barely profitable or even unprofitable, but railways kept them going because they fed the far more profitable main lines. These economics of interconnexion are, to use Moblet's phrase, "primary drivers" in the economics of transport and must be simulated in order for the player's incentives in the game adequately to match real-world economic incentives, and for the transport networks produced by a competent player to be sufficiently similar to those produced by competent managers of transport companies in reality.

I don't see why it's necessary to worry about this. If a representative selection of vehicles is provided at sensible relative costs, that includes units suitable for branch line use, and the geographical arrangement suits branch line operations, then players will build branch lines, and they will do exactly this. This is a natural economic outcome, not something we have to contrive or manage. It already happens in Simutrans as it is, and nothing we're talking about doing is going to erode that. Note that branch line stock is characterised by lower utilisation (and/or revenue km over time due to lower speeds) than mainline stock; that's why it loses money, not because the stock is inherently unprofitable. If you put the branchline stock on mainline operations it would make more money, although in practice different stock might be used because its characteristics make it even more profitable than the branchline stock would be.

[ӔO]

for lorries and buses, their capacity and power will need to be reworked a bit to fit inside the legal limits for realism purposes.

I've searched, and have found the legal limits for UK/EU trucks.
http://www.roadtransport.com/RoadLegal/11947/weights-dimensions-plating.html
I think the max speeds of the trucks and buses do follow the limits, but here it is for reference.
http://www.roadtransport.com/RoadLegal/11954/speed-limits-overtaking.html

[jamespetts]

I have split the lengthy discussion about how fast that postman can pedal their bicycles here so that we can concentrate on general balancing discussion here.

Since the relative infrastructure costs are significant in this equation, one has to pin down what the infrastructure costs actually are. This is not possible if infrastructure never ages, since, say, the cost per passenger, or cost per tram km, or whatever measure of usage you care to employ, of a tramline built in 1920 and operated until 2050 will be a lot lower than one built in 2010 and equivalently operated to 2050. In reality that 1920 tramline will need to have its foundations broken up and relaid a couple of times in its life, and presumably its catenary system would need replacing too. If everything has a life, or some reliable mechanism for charging the player for its age, we can then calculate benchmark infrastructure costs for fulfilling a given transport task, and thus calculate a logical balance between modes. If it doesn't, I don't have any answers yet.

I think that I understand the point: infrastructure, generally, like vehicles needs to be renewed regularly? In other words - its upkeep cost is not static over time, but increases with age? I think that that can probably be simulated, but it's harder than for vehicles. We can't force players to re-lay the tracks every few years, and it's important to avoid players having to micromanage the renewal schedules for each tile (and there's no way of defining sets of tiles without more coding work than I am able to undertake in a reasonable timescale), but I suspect that there may well be a way around this with sufficient abstraction. In any event, implementation can be considered once we have determined that it is a good idea to implement this dynamic in the first place.

One point of some significant note, however, is that, whilst tracks, roads, catenary, etc., are regularly renewed, bridges and tunnels, generally, aren't (although they are maintained, of course). Just as it is unrealistic to have roads last forever, so too it is unrealistic to have to replace one's tunnels every so many years (incidentally, how does one account for special infrastructure such as bridges and tunnels when balancing?), so we must account for that aspect of things, too.

The decision of whether or not to purchase, in a commercial organisation that has capital available, is foremost driven by return on capital. The unit could be made by Santa's elves, it doesn't matter, the question investors ask is "what will be the return on my capital?". Don't fixate on how the vehicle is produced or acquired, especially as nothing was genuinely mass-produced before the 20th century. I mentioned before that transport costs have fallen over time - one of the drivers of that has been mass-production of transport equipment, which has reduced capital cost per unit of work, which means revenue per unit of work can fall and return on capital remains constant. You won't get good return on capital buying and operating an 1870's steam engine today, and that has to be the case in the sim. In their day, though, the 1870's steam loco and the 2010 diesel should, under equivalent operating conditions, generate similar return on capital. Return on capital is the simplest, most realistic, and most reliable benchmark that I can see. To deviate from that risks arbitrariness.

I'm no economics expert, so forgive me whilst I attempt to get to grips with how your suggested ROI equalisation would actually impact the economy of the game being played. Let me give two historical examples and see whether your model would produce the same results. The first is the development of the trolleybus. In London (and many other UK cities) in the 1930s, trolleybuses rapidly replaced trams: they were, from the transport operator's point of view, in no way inferior to trams (they were no more expensive to buy and run), they had the same passenger carrying capacity, they were considered more comfortable by many passengers (although opinions do vary), and, crucially, they did not require rails, which were expensive to purchase and maintain. In effect, they had the same economics as trams except without the capital and maintenance cost of rails. As a result, they were very popular with transport operators and replaced trams very quickly in many places. Before the 1930s, trolleybuses were simply not made: people had not thought of the idea, so trams were the best available option Would the ROI equalisation model not demand that trolleybuses cost more somewhere to compensate for their advantages? And, if it did so demand, would that not produce a result significantly at variance with reality because the driving force behind the conversion to trolleybuses was precisely that they were, in their time, no worse than trams in some areas and better in others with few, if any, significant disadvantages (including in monetary terms)?

The second example is electrification of suburban railways. Before the early 20th century, this technology was not available. During the first half of the 20th century or so, different railway companies adopted different strategies towards such electrification, but the most notable adopter was the Southern Railway, which extensively electrified its suburban then main line networks from its creation in 1923 until the outbreak of war. The Southern was the smallest of the "big four" post grouping companies and was, when it was formed, not wealthy. Indeed, many of its electric trains were simply rebuilt steam-hauled carriages by reason of budgetary necessity. As a consequence of its electrification, the Southern became considerably more profitable by the later part of the 1930s, and was able then to afford more easily to build more new and better vehicles. Its overall profitability had substantially increased as a result of the economies achieved by electrification, in ways which would not have been possible if it had stuck with steam. Other railway companies that made larger profits on longer distance routes did stick with steam on their suburban routes to a far greater extent, and were still in many cases (especially that of the LMS) more profitable overall than the Southern (one might speculate that they would have been more profitable still had they electrified their busier routes (electrification only being economical in areas of relatively high utilisation)). Would this dynamic be modelled in your system, or would equalisation of ROI require that steam and electric profitability be more evenly balanced (or alternatively, that the electric units/infrastructure be so much more expensive to buy as to consume any additional profit that they generate)?

[moblet]

I have split the lengthy discussion about how fast that postman can pedal their bicycles here so that we can concentrate on general balancing discussion here.

Sorry, we got a bit carried away there...

I think that I understand the point: infrastructure, generally, like vehicles needs to be renewed regularly? In other words - its upkeep cost is not static over time, but increases with age? I think that that can probably be simulated, but it's harder than for vehicles. We can't force players to re-lay the tracks every few years, and it's important to avoid players having to micromanage the renewal schedules for each tile (and there's no way of defining sets of tiles without more coding work than I am able to undertake in a reasonable timescale), but I suspect that there may well be a way around this with sufficient abstraction. In any event, implementation can be considered once we have determined that it is a good idea to implement this dynamic in the first place.

Fundamentally we need a reliable means of equalising the combination of infrastructure and operating costs. That is the statement of the problem. There are at least two approaches to this, of which ageing infrastructure is one; I will start a topic on fundamental approaches to balancing in the near future to articulate these and see what other options can be generated.

One point of some significant note, however, is that, whilst tracks, roads, catenary, etc., are regularly renewed, bridges and tunnels, generally, aren't (although they are maintained, of course). Just as it is unrealistic to have roads last forever, so too it is unrealistic to have to replace one's tunnels every so many years (incidentally, how does one account for special infrastructure such as bridges and tunnels when balancing?), so we must account for that aspect of things, too.

This is no big deal if the dynamics of the code, and the parameter set, allows for differences in lifetimes and construction and maintenance costs. It's one of the trees that has to be kept in sight during the design process.

Let me give two historical examples and see whether your model would produce the same results.

From the two examples you've selected, I think you grasp the concepts and trade-offs in ROI, but are perhaps struggling to see how easily they can (and almost currently do) play out in the sim. If one has a faithful model of the dynamics of ROI, then every outcome can be explained in terms of captial vs operating costs, just as you have done here. Capital and operating costs are parameters, and therefore every decision the player makes gets steered by the actual values of the capital vs operating costs. These actual values are something the developers can choose (and, of course, knowledgeable players can manipulate). So let's look at your examples:

Trams vs trolleybuses

Firstly, there were possibly technological improvements that enabled the trolleybus, most likely in adapting and squeezing the mechanicals of a tram into the more constrained chassis area and axle-loadings of a bus.

Would the ROI equalisation model not demand that trolleybuses cost more somewhere to compensate for their advantages?

We need to separate some concepts here. What you call "the ROI equalisation model" is not a model, it is a step towards a realistic set of capital vs operating costs. I have proposed a spreadsheet model that can perform ROI comparisons of different vehicles and modes. This spreadsheet does not demand anything, and we can put whatever numbers into it that we wish in order to get the relative ROI that we want.

How I am proposing we use the concept of "ROI equalisation" is not to simply equalise everything's ROI and stop there. If we did that then yes, trolleybuses would have to cost more to compensate for the tram tracks they don't need. Since that isn't the case, we would then adjust the trolleybuses' capital cost downwards, and/or the trams' capital cost upwards, to bring it more into line with reality. Using a model such as the one I've proposed, we would be able to decide and state by what percentage the trolleybuses' ROI should outperform the trams', which gives us a really efficient means of calibrating it for optimal gameplay. It will be much eaiser to use an equalised ROI as the starting point for adjusting the relative economic performance of modes and vehicles, than it would be to use zero. The absolute numbers in the sim matter far less than their relative values.

Remember too that even though trolleybuses were, from that point on, the chosen and presumably the best option, trams were still an option, and the economics of trams were presumably unchanged. Operators didn't think, "oh, trolleybuses are here, forget trams", they would have done their sums and concluded, independently, that the buses were more economic. It was also still the case that the higher the utlisation of the tram line, the more economic trams would be, and the more economically competitive trams would be compared to buses, even if they were always the poorer option. With ROI represented in the sim, and the parameters set correctly, these dynamics will be there.

Rail electrification

Firstly, the divergent strategies of the different companies would have been the result of different assumptions, and presumably different operating conditions, such as:
- Expected future costs of fuel and labour
- Expected future technologies and their dates of availability
- Borrowing costs
- Current and expected utilisation
- In-house knowledge & skills
- Relative performance of steam & electric traction for their particular transport tasks
- Community/operator impact of emissions

As you've observed, higher utilisation spreads the infrastructure costs and makes higher-infrastructure, lower operating cost options more attractive. The attached spreadsheet demonstrates this. One can always find a set of assumptions at which either steam or electric is uneconomic, and there is typically a threshold level of utilisation at which the higher capital cost becomes worth it, so it comes down to what one's assumptions and operating conditions are. If the sim is scaled correctly and the relative costs are about right, then the player's trade-offs will look similar to the real world's.

When it comes to analysing history, we must remember that we aren't faced with the uncertainties that these operators had when they made decisions on electric vs steam, and that the outcomes they experienced were a product of how things actually panned out. For example, if fuel and labour costs had been lower than they actually were, steam would have been relatively cheaper to run. If someone had invented some amazing battery that could fit in a locomotive and run it for a day, the catenary infrastructure would have become obsolete overnight. Presumably also if diesel engine technology had progressed much faster, or nuclear powered locomotives had emerged (sounds silly now, but I'm sure in 1950 some would have seen them as inevitable). Another issue is that these companies weren't in direct competition for traffic, since they ran to different places, so geographical changes in demand also impacted their utilisation and revenue opportunities. One thing's for sure - if electrification would have been the most economic choice for all of them, and they had known that when making their decisions, they all would have chosen it.

In applying this to Simutrans, the same trade-off needs to be presented to the player - will this line see enough traffic to justify the capital investment in electrification? The player needs to be confronted with parameters that produce a nice trade-off curve, so that if the player electrifies and the line is poorly utilised the player loses money, but if it is highly utilised they make more money than they would have with steam. Note the risk profile here - if you electrify and don't utilise you make a loss, whereas if you don't electrify and highly utilise you don't make a loss, you simply make less profit. Bottom line there is no matter where the trade-off lies, the rational decision is not to electrify unless you're absolutely sure you're going to utilise it adequately for quite a long time. Steam was still a competitive technology, so Southern would still have made a profit using it, and who knows, maybe they would have made more profit had they done so. Electrification is an obvious point of differentiation, but it wasn't the only contributor to the difference in profitability, and without data of their accounts and operations one couldn't say for certain whether electrification increased or decreased their profitability.

To equalise ROI in the sim, hopefully that spreadsheet has demonstrated that the ROI outcome depends critically on cost and utilisation assumptions. In the sim this will mean that a player's actual ROI will depend, just like the real world, on utilisation. The point where the steam vs electric ROI's meet is the only point where the ROI outcomes will be equal. At lower utilisation steam has a higher ROI than electric, and at higher utilisation, electric has the higher ROI. We need to find a set of numbers that produces a realistic threshold value, which we can do consciously, and if the sim has ROI or some proxy built into it, the player's outcome will follow the curve.

[ӔO]

some of the main reasons to use electric over steam.
- better acceleration (good for short station intervals)
- climbing ability (no need to use a banking engine)
- extensive use inside tunnel
- easy to maintain system (not very far from cities or towns)
- cleaner to immediate vicinity.


I think it's easier to compare diesel to steam, than electric to steam.
Electrics were still an emerging technology in the golden days of steam, and they just weren't as fast.
Eventually, the technology caught up, which is why companies started expanding their electrical network.

[jamespetts]

Apologies for the slow reply - has been a busy week!

From the two examples you've selected, I think you grasp the concepts and trade-offs in ROI, but are perhaps struggling to see how easily they can (and almost currently do) play out in the sim. If one has a faithful model of the dynamics of ROI, then every outcome can be explained in terms of captial vs operating costs, just as you have done here. Capital and operating costs are parameters, and therefore every decision the player makes gets steered by the actual values of the capital vs operating costs. These actual values are something the developers can choose (and, of course, knowledgeable players can manipulate).

Aha! I may have been misunderstanding a little what was suggested: this all makes more sense now. The ROI equalisation/comparison process that you suggest is not, after all, opposed to an historical model of transportation economics in which the ROI is not necessarily equal (and is unequal in a number of specific, important respects, as in the examples), but is a process of ultimate calibration that can work in harmony with it? That being the case, there seems to be everything to recommend your method in principle, and the only remaining discussion being as to the details of its implementation. I still think that there is much value in historical research as to prices where possible: the results of that research can easily be used in conjunction with the ROI model to tell us how to equalise the ROI when we equalise it, and when to deviate from it when we need to deviate, whilst the ROI mathematics can keep such deviation within playable limits. Indeed, we can use the ROI model, can we not, to model incentives that we knew were present historically fairly accurately even if we don't have the figures? Have I understood this correctly now?

As you've observed, higher utilisation spreads the infrastructure costs and makes higher-infrastructure, lower operating cost options more attractive. The attached spreadsheet demonstrates this. One can always find a set of assumptions at which either steam or electric is uneconomic, and there is typically a threshold level of utilisation at which the higher capital cost becomes worth it, so it comes down to what one's assumptions and operating conditions are. If the sim is scaled correctly and the relative costs are about right, then the player's trade-offs will look similar to the real world's

The spreadsheet was most interesting (I assume that all the various steam graphs are on top of each other in the straight line in the middle?). I have wanted for a long time to be able to model accurately the utilisation incentives with electrification to incentivise players to make economically sensible decisions. One thing that is really very interesting about electrification are the economics at the margin: it's easy to work out that an ultra-intensive inner-suburban line should be electrified and that a long distance line to a tiny town in the sticks should not be electrified, but on the margins, where electrification will yield a greater profit, but only very slightly greater and a long way in the future, how different player strategies will play out (which may depend on capital availability, of course) is very interesting.

The player needs to be confronted with parameters that produce a nice trade-off curve, so that if the player electrifies and the line is poorly utilised the player loses money, but if it is highly utilised they make more money than they would have with steam. Note the risk profile here - if you electrify and don't utilise you make a loss, whereas if you don't electrify and highly utilise you don't make a loss, you simply make less profit.

Presumably, there are cases on the margins where one doesn't make a loss by electrifying, but also just makes less profit? I always think that it is very interesting to see consistent differences over time between players and how they handle the marginal cases, which would be especially interesting to see emerge over a long-term network game (e.g., player A tends against capital investment in cases of doubt, whereas player B tends in favour of capital investment in cases of doubt, consequently player B's network has electrification in places that player A's network wouldn't have them, etc.).

Steam was still a competitive technology, so Southern would still have made a profit using it, and who knows, maybe they would have made more profit had they done so. Electrification is an obvious point of differentiation, but it wasn't the only contributor to the difference in profitability, and without data of their accounts and operations one couldn't say for certain whether electrification increased or decreased their profitability.

The books that I have read expressly attribute the improved profitability to the electrification, and I hope that I am reasonable in assuming that their authors, learned in the subject of railway history as they are, did not make the elementary mistake of inferring causation from mere correlation.

We need to find a set of numbers that produces a realistic threshold value, which we can do consciously, and if the sim has ROI or some proxy built into it, the player's outcome will follow the curve.

Yes, indeed! The next question is how we go about doing that starting from where we are now...

some of the main reasons to use electric over steam.
- better acceleration (good for short station intervals)
- climbing ability (no need to use a banking engine)
- extensive use inside tunnel
- easy to maintain system (not very far from cities or towns)
- cleaner to immediate vicinity.

I do try to model some of these in Experimental - the different acceleration performance is implemented, as is climbing ability (although currently hills do not have enough of an effect on fast-moving trains, something that I am hoping to resolve in a future version); it is difficult to simulate a disincentive to make extensive use of steam in tunnels as there is no precise boundary between acceptable and unacceptable levels of usage, particularly as unacceptable levels of usage were tolerated until alternatives were found; the ease of maintenance in some areas rather than others is an interesting idea that I had not hitherto considered (but might be hard to simulate), and the local environmental impact (of which the tunnels issue is, in reality, a part) strikes me as rather a nebulous a thing to attempt to draw out into a workable algorithm in a transport game.

[sdog]

It is difficult to simulate a disincentive to make extensive use of steam in tunnels as there is no precise boundary between acceptable and unacceptable levels of usage, particularly as unacceptable levels of usage were tolerated until alternatives were found;

You already have the tool, way restrictions. Introducing a non-steam tunnel (eg. subway tunnel) with lower maintenance costs but a way restriction not to allow steam (and diesel) to use it.

[jamespetts]

You already have the tool, way restrictions. Introducing a non-steam tunnel (eg. subway tunnel) with lower maintenance costs but a way restriction not to allow steam (and diesel) to use it.

Ahh, that can work up to a point, and that is exactly what I was planning to do for the deep level "tube" lines that require much smaller trains (all of which will be electric), but won't work for the equivalent of sub-surface lines, which actually were worked by steam until the late 19th century (indeed, Pak128.Britain includes a steam locomotive (the Metropolitan "E" class) that was designed specifically for use on the Metropolitan Railway, part of the London Underground.