News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Cost balancing - the great project

Started by jamespetts, January 07, 2022, 06:51:17 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Introduction

For many years, Pak128.Britain-Ex was not balanced, using figures loosely extrapolated from Pak128 from which the pakset was long ago derived (having started as a Standard pakset, initially having been British vehicles addon to pak128 in circa 2006). Some years ago, when introducing the fare stages feature, I balanced all the relative revenues of passengers/goods/mail based on historical data (although the data for passengers are complex, so it is possible that the per kilometre revenues for passengers have been overstated: more on htis below). More recently, circa 2019/2020, Dr. Supergood did some useful work in creating an interim balance for costs in the pakset, removing many of the anomalies that had existed before. This has produced a game more playable than before, but some meta-level anomalies still remain, and there still comes a point when a player with a large network for most practical purposes has unlimited money so great are the profits, as is the case on the Bridgewater-Brunel server at present (in-game year: 1876).

One of the longstanding high level design goals for Simutrans-Extended has always been highly realistic economics, with players having incentives to do in the game what they would have incentive to do in reality, including making nuanced and interesting choices between different vehicles and infrastructure types which might be only marginally optimal or suboptimal, allowing players who make modestly suboptimal choices to remain profitable, albeit less profitable than they would have been with an optimal choice. With this aim, it has always been intended to balance the pakset based on real life data, which I have been gathering for over 10 years now on this thread for the purpose.

For a long time, I have not done work towards balancing the costs because a number of balance critical features remain outstanding. However, recent development on the piers/elevated way supports feature and the discussion here about how to balance it have caused me to consider undertaking the balancing work in stages: balancing what can be balanced by historical figures now (or at least at the time of the introduction of the elevated way supports feature), erring on the side of being generous to the player where features currently do not exist (e.g. inflation and vehicle wear/overhauls), and adding more detail to that balance when the feature-set permits. I had originally thought of doing this just for infrastructure costs (as, when the elevated way support system is integrated, all of the infrastructure specific balance critical features will be complete), but, following investigations, it seems as if it may be worthwhile at least to consider balance more generally at this stage. However, there are far, far more vehicle types than way types, and one of the planned features is to break down vehicle costs into more categories than at present, so it may be difficult to rebalance all the vehicles now without automation; somebody did write an automation script once, but I cannot recall where it and instructions for using it can be found.

With all that in mind, I present my findings so far for the purposes of discussion and record.


Spreadsheet

During the course of this post, I will be referring to a spreadsheet in which I have undertaken balancing calculations. I will post a number of screenshots of the spreadsheet in this post, but the actual spreadsheet itself, with all of the formulae, can be found here. This is a link to it on Github, so this may well change as I undertake more work on this project.


Calibration

One of the important tasks is to calibrate and normalise the figures so that meaningful comparison be possible. Two important things must be taken into account in the calibration: (1) the difference between the numbers specified in the .dat files and the numbers in the game, owing to automatic adjustments for the meters per tile and bits per month settings; and (2) the fact that we have months consisting of 6:20 hours rather than of 730 hours (365 / 12 * 24) as in reality. To deal with the former, I have decided to use consistently the in-game figures for balancing calculations; .dat file figures are only show to allow conversions. The latter means that we need to calibrate to two different scales: all the revenues and all the costs expressed per kilometre must be calibrated to the short timescale, and all the capital costs and the costs expressed per month or per annum must be calibrated to the long timescale. Staffing costs potentially fall somewhere between the two, in that they can in principle be calibrated either as an annual salary on the long time scale or as an hourly charge on the short time scale; which is appropriate is likely to depend on whether the number of hours worked per day makes any difference: it will for people like signallers, drivers and conductors; less so for administrative staff, albeit we are not considering them at this early stage.

Thus, when comparing to real life figures, we need to be able to have a system for converting between the Simutrans currency (SimuCents: ¢ - the symbol being conventionally shown after the number in Simutrans) and real life currency, which, for the purposes of this pakset, will be GBP (£). In doing this, we need to take account of inflation to make meaningful comparisons. The straightforward way of doing this is to pick a date to which to normalise all figures. Inflation can then be added in the code later starting from this point. I have chosen the year 1900 for this purpose. For inflation generally, there is a very good online resource in the form of the Bank of England inflation calculator, which will give figures between 1209 and 2020 (and will be updated soon for 2021). However, this is a general inflation figure; in reality, different things inflated or deflated at different rates, so, ideally, we would have different indices for the price of coal, steel, labour, oil, wood, horses and so forth. Finding these data, however, is difficult, so if anyone has any good source for general tables of prices of those commodities in particular in the UK in the 1750-date period, that would be very helpful indeed. For the present, I will use the BoE calculator, but strongly prefer data that is as close as possible to 1900 to minimise the effect of differential inflation making the BoE's calculations inaccurate. This is likely to be especially acute for labour costs.
Edit: I have found a useful resource linked in the original pricing information thread that I had forgotten about that is very helpful for inflation, particularly of labour costs: it is the measuring worth website, which gives separate measures of inflation for average earnings, GDP, GDP per capita, the RPI and the GPD deflator. It also gives historical currency conversion data, allowing the use of US data for comparison.

As stated above, I have long since balanced revenues based on real life figures, so there is already an implicit conversion between SimuCents and pounds. The calculation is shown here:



In simple terms, the calibration is thus: the .dat file specified passenger revenue for 1 kilometre (for the second fare stage) is 0.50¢. This is intended to convert to 1d (that is, one old, pre-decimal penny, being 1/240th of a £GBP) per mile, which was the fare prescribed by the Regulation of the Railways Act 1844 as a maximum for what became third class passengers (equivalent to the "low" wealth passengers in the pakset). This still prevailed in 1900, although, the actual fares charged to passengers were complex and often lower than this. A mile is about 1.6km, so the 0.50¢ per km converts to 0.80¢ per mile. The .dat file 0.80¢ is rendered in game as 0.24¢, so 0.24¢ is equivalent to £0-0s-1d, or £0.00416 in decimal currency.

That is the calibration for the short timescale, and conversion ratios are given for use elsewhere in the spreadsheet.

For the long timescale, we need to compare the number of hours in a year in reality with the number of hours per year in the game, and multiply by that ratio. However, we cannot simply use 24 hours as the figure, as for many of those hours, people are asleep and not travelling, sending goods, driving trains or similar. Since we do not simulate the day/night cycle, and assume that people are always active, we have to adjust for this. Thus, the assumption for many purposes (including passenger generation calibration) has always been that there are 16 active hours in a day (assuming 8 hours' sleep/inactivity per day; 24 - 8 = 16). This calculation, and the resulting ratios that it produces, can be seen in this sheet:



Applying those ratios to our converted currencies, we get the conversion ratios that we see in the first table above. As will be noted, the absolute value in SimuCents is not far off (about 1.3x) the actual value in £GBP in 1900 for capital and annualised costs.

Infrastructure costs

We now turn to apply this to infrastructure. Here are some extracts from the spreadsheet showing the current infrastructure costs in the game, both capital and maintenance:





Now, based on information summarised in this thread, originally gathered in this thread, here are some sample infrastructure capital costs from reality:



And here are some maintenance costs:



As will be seen, I have converted both sets of prices to SimuCents using the formula discussed in the calibration section.

A number of points emerge from this. First of all, some of the very modern figures (e.g. from 2011) may not be meaningfully comparable owing to the differential inflation discussed: the 21st century derived figures appear anomalously high by comparison to the other figures. Secondly, the current infrastructure costs are actually not very far off a realistic amount. Thirdly, the cost of bridges are far too low by comparison to that of ways. If anything, the costs of plain ways (railways, at least) in the game are somewhat high at present if the forge cost and land be included, suggesting that the 1,875¢ forge cost for railways may be too high. The track only cost of 520¢ for 80lb/yard cost in the game, by contrast, should actually be 1,028.20¢. We have a forge cost comparison for trams, suggesting that the actual forge cost should be 720.88¢ rather than the 500¢ forge cost for trams in game, suggesting that the current differential between rail and tram forge costs is too high. For reference, the land cost given is always that of open countryside in this table. Land cost in towns is higher.

As for bridges, the difference is very great. Take the brick arch viaduct, a common type of bridge built in game and in reality. The real life cost of this is calculated to be 23,902.72¢ per kilometre for construction. In game, the cost is just 9,000¢ per km. For tunnels the difference is somewhat more modest because they are already very expensive: the in-game cost of an ordinary brick rail tunnel is 27,000¢ per kilometre. In reality, tunnelling costs vary greatly, but the equivalent costs of two real tunnel projects, one straightforward and one very difficult, are equivalent to 7,949.79¢ per kilometre for the straightforward tunnel (the Liverpool and Manchester Railway's tunnel) to 50,969.56¢ per kilometre for the difficult tunnel (the Severn Tunnel). However, the latter figure may be preferred as it is closer in time to the normalisation date of 1900.

This set of differences may help to explain why elevated ways are currently very popular in towns on the Bridgewater-Brunel server: they are far cheaper than in reality, and, unlike in reality, can be built without demolishing buildings underneath them (this latter point will change for new games when the elevated way supports (formerly piers) system is incorporated).

Maintenance comparison is harder as there are fewer data for this, especially for bridges, tunnels and roads. However, there is some useful information for railways: the annualised labour cost for plain track has been calculated as being equivalent to 95.26¢, not including materials. This is routine maintenance only, not including renewals. The in game annualised cost of maintenance varies with the type of track (probably more than it should given the nature of routine maintenance rather than renewals) from 48.00¢ (for continuous welded low speed freight track) to 228.00¢ (for high speed track). Ordinary steel bullhead rail comparable with our real data varies from 86.40¢ to 156.00¢, so is not far off a real value.

Ratio of income to infrastructure cost

There is a very useful resource on JSTOR, being historical tables of railway financial statistics.

In order to compare whether infrastructure maintenance costs in Simutrans-Extended compare well with real infrastructure maintenance costs, I have extracted some of the data from those tables and put it in my spreadsheet, adding a number of extra ratio calculations not in the original tables:



By happy coincidence, the tables relate to railway companies in the 1870s. The current Bridgewater-Brunel online game is currently in the 1870s and the major companies are principally railway concerns, so I have been able to compile broadly comparable data from the game:



We can ignore the lines in red (Zook's company is currently making a loss) and grey (these are hypothetical calculations), and focus on other lines. As we see, of the three big railway companies in the game, United Albion, Urban and the Great Western, there is a range of ratios of infrastructure costs to revenue of between 7.44% (Urban) to 12.62% (GW) if we take railway figures only, or 7.64% (urban) to 9.41% (GW) for all operations.

By comparison, the real companies' ratios range between 5.7% for the Midland to 9.59% fo the London and South-Western, suggesting that the maintenance figures in the game at present are broadly in line with reality, which agrees with what we find when looking at the individual maintenance figures as discussed above.

This is encouraging, suggesting that, for infrastructure costs, the most major changes are likely to be in the capital cost of bridges and elevated way supports, and that other changes may need to be more minor. A reduction in the forge cost for railways in line with reality may well have the effect of helping new players who want to set up railways.

Balance more generally

However, beyond noting the broad conformance of infrastructure costs to reality in these tables, we notice something else, which accords anecdotally with what we see in the game: the overall ratios of operating costs to revenue of the big companies in the game are far lower than those of real railway companies of the same period in history, allowing them to make profits considerably in excess of that which a real company in this time would have been able to make.

All of the major real railway companies expended between 42.17% and 53.81% of their revenue on operating costs in 1871 (the LNWR and GWR were the largest companies in this period). By contrast, United Albion Railways spends only 25.28% of its total revenue on operating costs, or only 17.81% of its railway related revenue on railway specific operating costs. Urban Railways spends 28.20%. However, the in-game Great Western expends 42.98%, not far off the 45.83% of its real life namesake.

It is difficult to compare the non-infrastructure costs directly, as the categories are not directly comparable. The Board of Trade required expenses to be broken down into "locomotive and rolling stock" and "traffic charges", whereas, in Simutrans, we have "running costs" (the per km charge) and "vehicle maintenance" (the per month figure). For this reason, I have combined both of the two sets of categories in Simutrans and reality, as the totality of the two should be broadly comparable.

We see, for the company in reality with the greatest margin of profit in 1871, the Midland Railway, it combined ratio of "locomotive and rolling stock" costs plus "traffic charges" to revenues is 32.42%. The lowest ratio of all is that of the LNWR, with 30.92%. In-game, by contrast, United Albion's railway operations show a combined total of 12.54%, and of its general operations, 19.55%. GW's are 16.24% and 32.06% respectively - thus, GW's realistic economic performance is only accountable when taking into account its non-railway operations such as canals, shipping and road transport.

The only purely railway company with comparable figures to reality is the tiny Cambria Coastal Railway, with a 44.76% ratio of costs to revenues overall. Even this railway, however, with extravagantly constructed elevated ways to traverse large town centres and running multiple very short trains with large express engines, does not really conform to reality, for this cost is mostly made up of infrastructure cost (20.76%) and not operating cost (vehicle/running cost combined), making up only 22.54% of income.

Unravelling the discrepancy in operating costs

It is by no means obvious what the cause of the discrepancy in operating costs is. The first line of investigation was to examine the balance of individual vehicles, focussing on steam engines and rolling stock that would have been available in the 1870s. Here are some historical figures - the Stirling Single and Wilberforce are directly taken from historical records; other, more general, entries were created to give a test comparison:



As we see, the per km cost based on the actual historical figures for individual locomotives should be 0.23¢ for the 4-2-2 express engine of 1870. In game figures are as follows:



As we see, the Stirling Single actually has a per km cost of 2.46¢ per km. However, since the interim rebalance, unpowered railway rolling stock has had a zero per km maintenance cost. This is not realistic, since, as shown in some of the tables in the JSTOR archive linked above, and extracted in the real vehicles table above, UK average rolling stock charges  were generally equivalent to 0.40¢ per train mile. Note per train mile not per vehicle mile, meaning that, for rolling stock, but not locomotives (unless we have double heading, which was not very common), we have to divide by the average number of vehicles per train to get the vehicle cost, and this average is not easy to deduce. Nonetheless, this rolling stock expenditure was significant: about a third of the average per train kilometre cost for locomotives of 1.20¢.

We also note that this average figure from the tables disagrees significantly with the figure that I had calculated for the per km cost based on coal consumption (and finding a coal price in 1911) and the repair cost quoted; however, this is still lower at 1.20¢ than the in game cost of 2.46¢, so this does not account for the discrepancy. Indeed, even omitting the rolling stock cost does not account for the discrepancy, since the per km cost of the locomotive alone is more than the average combined per train km cost of locomotives and rolling stock in the UK as a whole in 1871.

The monthly cost is not much different: the in-game per month cost for the Stirling Single is 100.92¢. The monthly equivalent for a steam tram driver from the real life figures is 8.73¢. Even if we quadruple this figure to imagine a train driver who is better paid than a tram driver, and a steam locomotive with a crew of two rather than a steam tram engine with a crew of one, we get only 34.92¢, much less than the current figure. Even multiplying this by 1.5 again to approximate the presence of a guard would get us 52.38¢ - still not much more than half the current in game cost.

One thing that we do not have which would affect operating cost is vehicle overhauls. Overhauls to vehicles would generally be treated by railways as part of the revenue rather than capital account, and thus would show up under "locomotive and rolling stock" costs. I have not yet calculated precisely what effect that overhauls might have, however, since the combined vehicle/running costs are in many cases about or even less than half in Simutrans what they are in reality, and would be even less if realistic figures were used for per km charges for vehicles, overhauls alone would have to equal or exceed the current monthly and per km cost combined in order by themselves to account for this difference, and I am doubtful that realistic figures will allow this to be done.

One question that occurred to me is whether I had overestimated passenger revenue: according to W. M. Ackworth (see p. 69), average passenger fares, taking into account various season tickets and other discounts, had fallen from 2d/mile in 1842 to less than 0.5d/mile in 1903. We will recall from above that passenger revenue has been calibrated to 1d/mile for low/third class, and higher for the higher classes. We have the option for "very low", which is indeed less than 1d/mile (0.11¢/km in the first stage rather than 0.18¢/km for "low"), but even if players make use of this, the average per mile receipt per passenger is still likely to exceed 0.18¢/km (equivalent, we will recall, to 1d/mile).

It will be difficult to calibrate this without an inflation feature (which would also allow deflation). We will see from this table that I have computed hypothetical reduced passenger revenue based on UAR's figures with a reduction of overall revenue of 1/3rd:



This gives running and maintenance costs of 18.81% of revenue for railway operations; if all operations are included (not shown), this goes up to 29.32% - much closer to reality. But this would then put infrastructure costs higher than is realistic, as 11.43% or 12.42% of revenues in total (recall that real railways ranged from 5.7% to 9.59%). Perhaps this is because excessive income allowed United Albion Railways to have an unrealistically extravagant infrastructure provision, such as the 9.25km long Covhill Valley viaduct, the under-town tunnels and elevated tramway in Kingserpool, although the maintenance on these is not especially high, so that is not entirely likely. This is also without taking into account the need to reduce the per km and per month costs to bring these in line with realistic figures, which could very easily (and probably would) entirely offset any reduction in passenger revenue.

Another issue may be that way renewals are not currently accounted for as infrastructure maintenance, but rather capital expenditure, whereas in reality, they would have been charged to the revenue account. It is difficult to assess this, as the game does not separate these data. Assuming that way renewals are indeed charged as construction costs, as I would ordinarily assume, no such costs are recorded for United Albion in 1876, 1875, 1874 or 1873. It is not clear whether the 44,533.28¢ cost recorded in 1872 is attributable to renewals or new construction. However, such a cost would be trivial in comparison to the 1,125,299¢ spent on railway infrastructure maintenance by United Albion in 1874 and thus be unlikely to make a significant difference overall.

At present, it is very difficult to work out where the costs are too low in the operating cost element of this, which is the area of the greatest discrepancy. There are also "misc." costs and taxes to account for in the real railway figures, but these are very small compared to the operating costs, and, although features could be implemented to simulate these, this would have a very limited impact on overall balance compared with correcting operating costs.

Initial conclusion and summary

By calibrating costs in-game against real life figures, it is possible to work out how balancing of costs should be set. It turns out that, very broadly, infrastructure costs are not far off a sensible balance, albeit some adjustment is needed, especially to the forge cost and capital cost of bridges, but the operating cost is too low in comparison to revenue, and passenger revenue possibly too high.

It is still somewhat of a mystery quite why operating cost in relation to revenue is as far away from reality as it is, and more careful investigation will be needed in order to address this as balancing progresses.

If anyone is able to offer any quantitative data or analysis to assist this process, that would be most welcome.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

KneeOn

James,

I'd be grateful to use this work in my own pakset and would of course contribute to the work if that is acceptable?

This is a great project and I think unique in that it is truly uniform and consistent.

I'll have a proper read over the weekend and contribute my thoughts

jamespetts

Quote from: KneeOn on January 07, 2022, 10:03:43 PM
James,

I'd be grateful to use this work in my own pakset and would of course contribute to the work if that is acceptable?

This is a great project and I think unique in that it is truly uniform and consistent.

I'll have a proper read over the weekend and contribute my thoughts

Of course - please do use this in your own pakset. That openness is the joy of open source software. I should definitely be interested in your thoughts.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Passenger fares

In order to try to understand the discrepancy, I have been investigating further whether passenger fares are excessive. Here is a table of passenger fares in the pakset as it currently stands, with conversions from SimuCents per km to old pennies per mile to be comparable with historical figures:



As we will see, passengers are subject to the fare stages feature, with journeys or parts of journeys up to 16km charged at a higher rate, and journeys beyond 500km charged at a progressively lower rate than our paradigm 1d/mile calibration figure of the second fare stage for "low" class passengers.

In reality, as noted above, and as discussed further here, passenger fares were complex, with many discounts in various situations, such that the average third class fare (equivalent to "low") before the first world war (i.e. in our calibration period of 1900) would have been 0.55d rather than the nominal 1.0d, with workmen's fares (the equivalent of "very low") being even less than this (as discussed in that post, the evidence is that, for tram fares, workmen's fares were about half the ordinary rate).

In Simutrans-Extended, we have to fit all the nuancing of prices into just five classes, which can be difficult at times: take the trams, for example: their rates are already lower than railway rates generally, but they were halved again for workmen. We will have to use the future inflation feature to replicate the fact that, in circa 1844, an ordinary third class fare was in fact 1d/mile, a second class fare 2d/mile and a first class fare 3d/mile, even though this had greatly reduced by the time of Ackworth's work in 1904 (first ed.) and 1924 (second ed.).

To address this anomaly, I have devised a set of alternative figures for passenger fares assuming calibration to the year 1900:



As we will see, the average fares are about half the existing level (even lower for "very low", but the gradients between the classes are steeper to reflect reality: "very low" fares are now half "low" fares, and "high" fares twice "low" fares. This will allow the 1d, 2d, 3d gradient from the 1840s to be applied if players set their passenger classes to low, high and very high. I have also removed the difference in the fare stage to 16km to reflect the fact that this differential per mile pricing was not used in the UK for passengers, although it was extensively used for freight. I have retained the existing discounts for very long journeys, which are mostly likely to be sea or, later, air journeys rather than rail journeys.

It is difficult to compute at present to what extent that this would in fact redress the anomalies observed in the current Bridgewater-Brunel game, especially when other costs have been adjusted, but it is at least worthwhile considering this adjustment, especially as, at present, a high proportion of players' income comes from passengers.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

KneeOn

I've had a good read of this now and want to preface this response with a bit of background:
1. I've worked on the railway on two routes across the same TOC (albeit across two franchises) - these were the Brighton Main Line and the Great Northern local services at the London end of the ECML so I have a bit of somewhat outdated industry knowledge but i'm not an expert
2. I've played Simutrans for over 12 years however I am far from an expert. I wouldn't even describe myself as particularly good at the game. I tend to play with timeline off and freemode on, enjoying creating complex routes and national scale systems with a mix of transport types
3. I am not good enough at maths to be able to comprehend or contribute to specific calculations for costs. I don't have a strong enough understanding of how things mesh together at the back end which is one of the reasons why I'd like to use part of this in my own work. As an aside, I have restarted painting from scratch in a new scale with no time frames to hopefully make a better looking pakset.
4. I think I understand the issue as follows: despite using realistic costs where possible, profitability is too easily obtained to the extent that by 1875 money becomes no object. The challenge is working out what needs to be balanced and what isn't being simulated properly within the pakset (and Extended) and how to best simulate that (through compromise or new features, but for now it appears it may be through compromise for now)


I see a number of issues that will need considering when balancing the pakset and indeed any pakset. I don't think they can entirely be addressed and will require some level of creativity when calculating costs for individual items and a number of decisions to be made about where to incorporate them. Some of these issues reflect the imperfect nature of the sources, some relates to the game engine never being able to truly simulate a complex economy over centeries, some of it relates to decisions which need making around features and whether playability or reality are more important on a feature by feature basis.


TL;DR: It is impossible to balance the pakset using real costs without artificially inflating them/shoehorning costs in places because they don't exist in game elsewhere. Even if pakset used true to life costs and revenue, the game does not truly simulate the overheads transport companies have and this may be why profitability is easier achieved so quickly.


The first issue is around non-operational costs. I know I have mentioned this as part of my depot suggestion previously and I will mention that as well later. Within any transport company is an army of people, with costs which exist outside of the rolling stock or operational infrastructure. These can include (but are not limited to): cleaning crews, cleaning equipment (such as toilet cleaning equipment), management structures, non-revenue vehicles which are not used in game like mechanic or rescue vehicles, overtime, HQ (HR, finance, admin, planning), delay attribution (more on this below) and a list which could be as long as any post on here so far. Some of these will be somewhat negligible on their own but taken as a whole, non-operational or front facing costs are significant in terms of profitability. That is why HQ functions are often the first to go in modern railway reshuffling - managers need to apply for their jobs again fairly regularly. 


These costs are not reflected in the monthly upkeep because they aren't attributable to any one "thing". They grow with the size of the company. Each staffed station needs a roster but not its own roster clerk. A driver depot would need its own team however. These are invisible, impossible to simulate costs without adding a number of other features.


The second issue is similar to the above but slightly different. It is a feature which there is a standing denial on the Simutrans main feature request thread - events. From derailments and disasters to the growing trade union movements and strikes, through to major over running engineering works, through to stock market crashes and depressions, there is of course an entire world of things which would have had a marginal but visible impact on a companies annual profits at any time during history through to now. More recently are performance fines. None of these are not reflected in the game. One off large costs can be the difference between turning a profit and a loss in a single year. Even at €1 a month, it adds up.


The third issue is delay attribution. In modern times, train companies are fined up to £1,000 per minute, per train, per delay depending on the location. Entire departments of delay attribution clerks exist to track delay causes and argue with other TOCs delay attribution clerks to work out who is owed what during disruption. It is big money within modern railway operations. I think the same works in the air industry but I may be wrong. I am unsure if it is only post privatisation or if grouping and pre-grouping railway operations had this. I also don't know if BR regions were subject to this as well.


The fourth issue links in to the first issue but i've split because it is different and has a different possible fix and that is non-revenue earning but operational infrastructure. Currently for railways a depot is a single tile and a single track which will reflect depots of all sizes from places like Crown Point in Norwich, Selhurst TMD, Lovers Walk TMD, Fratton TMD and Crewe TMD. All of these have different sizes and wildly different costs. This applies to crew basis for air lines, bus depots, trams and to a smaller extent docks and harbours although more creative triple mooring could be seen on the Thames during the first lockdown. The more vehicles maintained at a depot, the larger the initial cost would be and ongoing costs to maintain a large enough depot. Buses require more places to park up over night, and more pits for mechanics to work on the vehicle underside. None of the costs associated with depots are accurately simulated as far as I know. This could be a feature extension as I've suggested before or it could be that the cost of a depot goes up exponentially.


The fifth issue is that Simutrans runs the exact same demand 24/7/12/365. There are no peaks. This has always had a massive influence on earnings. The 0907 service from Brighton to Bedford in 2013 was always full and standing by time it left Burgess Hill (only 3 stops out of Brighton). It was the first off peak service. Every other service after this was gradually more quiet until at least Gatwick Airport (if not further up the line) in the Up direction (i.e. to London) until the evening peak. Simutrans has no concept of this. Are the passenger numbers morning or evening? Although it is of course possible to average out the income of each industry per passenger to mitigate this, there are still issues caused by a lack of peak/off peak.


The sixth issue, linked to the fourth and fifth, is that because services are earning revenue 24/7/12/365, all upkeep costs are artificially low. Signals are a good and easy example. Each bulb on a colour light signal (or LED on a modern signal) will run for x hours until it needs replacing or fails. That signal will remain on but it won't always be during hours of operation. Simutrans lets every hour that signal is on be a revenue earning hour however. This isn't a problem in Standard because it doesn't have a pakset which strives for such economic accuracy - Extended does as a design goal. By using real prices, the fact 1/3rd of the time the infrastructure is incurring costs and not earning isn't reflected, leading to a higher profit than ever was actually attained.


This is by far not exhaustive and there are loads of factors around any profit for any company and how it gets reflected in a game however these I think are the big ones.


I think some solutions could be found by establishing a set cost for non-operational matters that is added to the upkeep of a tile or the per km cost of a vehicle that reflects how its mere existence would increase HQ costs.


Depots would require either the average cost of all depots of each way type being used or the depot mechanic I raised last year and including a maximum number of units that can be maintained in order to force players to have realistic depot facilities for their vehicles and thus realistic outgoings.


Vehicles needing to go to a depot for maintenance would also assist and provide another gameplay challenge in making sure enough services exist to satisfy demand without over saturating the route with units to compensate for the downtime.


Introducing a 3 day month (show month =1 on Standard does this, while I'm almost certain that this is default on Britain) and introducing peak flows would deal with having tracks/roads/lights/runways/docks not assisting in revenue generation while costing an amount a month and making the player decide on service end times.


I don't have the answers to this, it is a complicated challenge to get the pakset balanced in the context of the game but I hope this provides you with some areas which you will see where you can simulate them to bring costs more in line with reality.

jamespetts

Thank you for your thoughts on this highly complex and important topic. It is always useful for this to be discussed in detail.

Comparison of figures

The first important thing when considering potentially absent mechanisms which might affect the overall profit to income or income to capital ratios is to check the overall figures to see whether that mechanism (or class or category of mechanisms) is one that could affect the figures in such a way as to make a significant difference. There is little utility, after all, in spending much time and effort implementing a feature that will have only a trivial effect on the overall balance.

In order to do this, in turn, we need to understand more of what the real railway accounts mean when they refer to "locomotives and rolling stock" and to "traffic expenses" in the real railway accounts. Fortunately, Acworth provides a breakdown of this on pages 45-46 of his work.

"Locomotive running expenses" include:


  • Superintendence - salaries
  • Superintendence - office expenses
  • Wages connected with the running of locomotive engines
  • Fuel
  • Water
  • Lubricants
  • Other stores, including clothing
  • Miscellaneous

"Traffic expenses" include:


  • Superintendence
  • Stationmasters and clerks
  • Signalmen and gatemen
  • Ticket collectors, policemen, porters, etc.
  • Guards
  • Fuel, lighting, water and general stores
  • Clothing
  • Printing, advertising, stationery, stamps and tickets
  • Wagon covers, etc.
  • Expenses of joint stations and junctions
  • Cleansing, lubricating and lighting of vehicles
  • Shunting expenses (other than mechanical, including wages and other expenses)
  • Working of stationary engines, hoists, cranes, etc.
  • Coal, etc. tipping expenses
  • Railway Clearing House expenses
  • Miscellaneous expenses

This set of lists does not fit well into Simutrans accounting categories (although Acworth criticises this classification for being unhelpful, so I do not recommend modifying Simutrans to replicate old Board of Trade format accounts).

We will see that, under "locomotive running expenses" are included some categories, particularly "superintendence", about 2.5% of the total in quantity for the example given (the LNER in 1923) which would in Simutrans be recorded as "infrastructure maintenance" as they are in fact represented in the maintenance costs of depots. The "wages connected with the running of locomotive engines" (about 54% of the total in the example) would fall under "vehicle maintenance" in Simutrans-Extended (i.e., be the fixed cost), and the remainder, including fuel, would fall under the "running costs", being the per km charge. Fuel, incidentally, is about 54% of the total cost, or 88% of all the costs excluding wages.

Under "traffic expenses" is more superintendence, which would be best referable to the HQ in Simutrans, as should RCH expenses, to station and signalling staff, which would fall under the maintenance of stations and signalboxes respectively, and be recorded under infrastructure maintenance, and some expenses, such as guards, which should fall under vehicle fixed costs and cleaning, lubricating and lighting of vehicles which should fall under vehicle costs. All of the station, administrative and signalling staff together make up about 66% of the "traffic expenses" for the LNER's accounts in 1923.

What we can note from all of this is that a large proportion of "traffic expenses" and a small but non-trivial portion of "locomotive and rolling stock expenses" are overheads which in Simutrans would be charged as the monthly maintenance cost of stations, depots or the HQ. (Currently, of course, the HQ is not compulsory, but the plan is to change that to simulate overheads more effectively).

I think that some work will need to be done in producing better comparable sets of figures. Unfortunately, Acworth's accounts for the LNER in 1923 do not give the revenue for that year, so I cannot produce figures for expenditure in proportion to revenue broken down in a way that more accurately correlates with Simutrans categories. It may be possible to approximate this by extrapolation of percentages, but this may be inaccurate, as wages may be a higher proportion of expenses in 1923 than they were in 1871.

Acworth concludes by estimating that about half of all railway expenses are fixed overheads, and half are variable with the traffic.

Overheads as against traffic expenses

With this last figure, we can draw a comparison to real in-game figures. If we take United Albion Railways in our example from above:



Its total expenses are 4,189.558.81¢ for 1874, or 4,613,179.39¢ if we treat access charges as income rather than negative expenditure. That latter figure will be used for the following computations. Of that figure, only running costs varies with the distance travelled. Running costs are 1,570,719.68¢. This is in fact 34% of all expenditure. However, distance travelled is not the same as varying with the traffic, for lower traffic would mean fewer trains in total, and thus less expenditure on the monthly fixed costs of drivers, firemen and guards. Thus, the "vehicle maintenance" needs also to be included. Including this gives a figure of 77% for vehicle expenses over total expenses, rather than the circa 50% that we know we should be aiming for. This suggests that we do indeed need to seeking to simulate greater overhead expenses than is already the case.

One thing to consider is the maintenance cost for depots. Here is the set of historically based infrastructure maintenance figures and their conversion to SimuCents from above, but with the labour only rates updated to use the labour specific inflation figures from the Measuring Worth website:



and here is the comparable table showing signals, signalboxes and depots and their maintenance costs in Simutrans:



As will be seen, the depot maintenance in Simutrans is too low: it costs only 700.80¢ per annum to maintain a railway depot of the steam type in Simutrans, whereas the equivalent figure for a real depot costs 2,796.88¢. Furthermore, in reality, but not yet in Simutrans, there is a requirement to have enough depots to service all the vehicles. The maintenance of signals is slightly higher in Simutrans than reality; the small and medium sized signalboxes are a little too expensive in Simutrans, but the large is not expensive enough. However, the signalling sums are relatively trifling in comparison to the overall amounts.

What we do not have at present is any historical pricing information on the maintenance of stations. That would certainly be a helpful thing; care will need to be taken to unpick the staffing cost from the buildings maintenance: only the latter, for example, should be affected by whether the platforms are made of brick or wood. If anyone can find any historical information on station maintenance, that would be very helpful.

One point to note is that I have so far been undertaking the calibration based on 19th century railway practice. This may be very different for an 18th century canal company, a 20th century airline or a 21st century 'bus company. If anyone has any access to historical accounting information for these various concerns showing the proportion of various heads of costs to revenues, that would be most helpful.

Mechanisms

Adding new features is very time consuming, and debugging them hundreds of times more time consuming. As is well known, a large number of new features important for balancing, including inflation, vehicle repairs/overhauls, convoy/consist recombination, lay-over, compulsory headquarters and bank loans are planned. The balancing cannot really be finalised until this work is done, which may take a very long time indeed, but, pending that, we can (1) balance those aspects of the game where further features are not needed (especially infrastructure costs after the integration of the piers feature, as originally planned), and (2) prioritise the various balance features based on the calculation of how important that they are relative to each other.

I will deal now with some of the individual mechanisms discussed above.

Administrative expenses/the HQ

This is more complex than it looks. At one level, the solution is easy: use the existing HQ feature in the game to represent administrative costs. Make the HQ compulsory by preventing players building any depots until an HQ is built, and use the HQ costs to represent administrative overhead thereafter.

However, the problem comes in quantifying. As you point out, the administrative cost varies with the "size" of the transport concern - but what do we mean by size here? Geographical area covered? Number of vehicles? Number of depots? Number of stops? Number of lines? Some function of some or more of the above? Something else entirely?

Probably the simplest thing is to use the number of depots as a proxy. Once we have a system in which the number of depots must scale with the number of vehicles because vehicles will need to go there for regular maintenance, the number of depots becomes a reliable indicator of the overall size of the company. This can also represent size in a number of subtle ways that simply measuring, e.g., the number of vehicles or lines cannot: a company that operates more different transport types, or has many disparate or discontiguous networks, or operates over a larger geographical area will tend to have more depots for any given number of lines or vehicles than a company with the converse characteristics.

The basic solution (as has been planned for a very long time now) would then be simply to set a maximum number of depots for each level of headquarters, with the highest level allowing an unlimited number. There is a real risk, however, of this being too crude - but it is difficult to think of anything better that is not so extreme in complexity as to require nearly a ground-up rewrite of the whole economic system. The fixing a maximum number of depots per HQ may be the best solution available to us within reason.

Some administrative expenses, of course, can be incorporated in the upkeep of the depots themselves: the "superintendence" referred to in the LNER's 1923 accounts above will include middle managers of various kinds (foremen/women, inspectors, clerks, etc.) who would work at the depots rather than the headquarters. This would mitigate some of the crudeness inherent in the design suggested.

Events

There is a good reason that this is denied, as it would (1) be very complex to simulate accurately (especially with the split time scale); (2) be very difficult to balance effectively; and (3) make it very difficult for the player to deal with at the same time as planning the network.

It is not clear that major events are sufficiently frequent to warrant inclusion, or that minor events cannot simply be subsumed into the general costs (there is always a category of costs, for example, in the Board of Trade returns for compensation paid for personal injury and damage to property, which could realistically be added to the HQ or depot costs).

Delay attribution

Routine compensation for delays split among train operating companies is a distinct feature of the franchise system, and that a legion of people must be employed to attribute which train company caused which delay is almost certainly caused by the perverse system of having one company owning the track and signals and a variety of others running the trains. In days when railway companies owned both line and operated trains, this was simply not an issue.

However, there is, as we observe from the above, a large item of "Railway Clearing House expenses" in the "traffic expenses" in the accounts. This may be vaguely similar in overall nature. In any event, it belongs in administrative expenses and thus in the HQ maintenance cost.

Depot size

There are two aspects to this: (1) physical size; and (2) capacity. Changing the physical size would be a very large amount of work, both in code and pakset, as it would involve changing a large number of fundamental assumptions built into many parts of scattered code. The main economic effect of doing this would be to alter the land purchasing cost of depots. This might be worthwhile to an extent, but this is unlikely to be critical: the greater issue at present appears to be the excessively low operating costs (and probably overheads).

Capacity is another matter. It is possible to add a feature, when adding the feature requiring vehicles to be maintained at depots, to have depots of different capacities and costs (both capital and ongoing). This would make sense as it would allow small local outposts without requiring a very expensive depot. However, it would involve considerable pakset work, especially if there were to be different graphics.

This may be worthwhile, but may well not be critical compared to other issues.

Variable demand

Because of the way in which routing works, it is not feasible to have variable demand. The problem is this: for performance reasons, the routes that passengers and goods take between stops are pre-calculated slowly in the background. Every so often, they are refreshed. You can see when the game is running if you look at the bottom of "GUI settings" tab of the "display settings" dialogue the status of the part of the game that does this, called the "path explorer". Anything other than "stand-by" means that it is running and recalculating the routes. On a larger game, such as those played on the Bridgewater-Brunel server, it is running more or less constantly and takes a signifiant amount of time to recompute the routes.

If there were to be variable demand, there would need to be the facility for players to have variable levels of service to account for this, just as real transport companies do: many services are peak time only or run more frequently in the peaks. However, this would then affect the passenger routing: a route available at peak times might not be available off peak. This would require routing data to be updated more frequently than is possible within reasonable limits of performance on a very large map.

It is theoretically possible that somebody might find a workaround for this, but coding and properly testing and balancing this would be a truly gargantuan task, well beyond what I will have the capacity to do in the foreseeable future.

For reference, the demand is intended to be an aggregate of peak and off peak demand such that the actual overall passenger numbers represent the overall passenger numbers of reality.

Whether to adjust for this artificially by simply increasing infrastructure costs is a complex question, largely because working out by how much to do this is difficult, especially if by how much to do it may vary with the type of infrastructure. As noted, the current infrastructure costs as a proportion of revenue are not far off reality, although this may change as some infrastructure maintenance costs at present may be too high: 1km of railway, for example, should cost 78.95¢ per annum to maintain (labour only), whereas the actual cost in game is about 90.00¢ - 138.00¢, and the difference may well not be accountable for by materials (although the extent of material usage in maintenance, rather than renewal, of railway is at present unclear; if anyone has any historical data, this would be very helpful).

Freight handling charges

One mechanism not mentioned in your summary but which is potentially relevant are freight handling charges, sometimes known as terminal charges. Acworth notes that these can vary with the amount of freight being handled, but are not attributable to a particular vehicle, and can be significant.

Quite how to simulate these is a difficult question - they may well be significant so far as freight is concerned.

Next steps

What we have established by examining the question of overheads in more detail and also the composition of the expenses in the historical railway company accounts is that, to a significant extent at least, the discrepancy recorded in the original post might be a result of underestimating overheads, possibly combined with overestimating passenger revenue.

What that, in turn, means, I think, is that the original plan of rebalancing the infrastructure costs shortly and awaiting the planned vehicle maintenance etc. features before rebalancing vehicle costs may well be viable and sensible. It is still worth keeping a careful watch on economic balance to see whether incremental progress can be made towards a real figures based balancing system.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

wlindley

Maintenance figures also might include an allowance for economies of scale. Southwest Airlines in the USA, for example, flies only Boeing 737 derivatives as they share common parts and training procedures.  Likewise, one would imagine that a single Leyland in a fleet otherwise entirely of AEC stock would cost more to maintain. 

Indeed, one might also expect that purchasing the second, or tenth, identical locomotive or coach from the same supplier ought to cost slightly less than the first.  Together, these could enhance gameplay as well, with players feeling pressure to consider their equipment fleets as a whole rather than having unrealistic mixes of everything on the market.

Further, would it be British practise to separate depots into light-maintenance (as one might have, for example, on each of a group of small islands each with a tiny network) and heavy-maintenance (which would be where new equipment could be erected and outfitted)?  It really would be quite satisfying to purchase a coach at a mainland city depot and have it loaded onto a ship for service on an outlying island... yet having to keep a light-duty depot on the island for ongoing maintenance... with the coach's sale or scrap value being then much lower at the island's depot than if it were reloaded onto a ship and sold at the mainland depot... Perhaps that is stretching it all a bit for a game, but...

KneeOn

James, I do agree that the most realistic fixes are absolutely not the best ones - other because they're not good for game play, fundamentally shift the game or are way too complex to add for a very marginal gain.

If infrastructure costs are to be settled somewhat first including upkeep then the decision must be made whether a cost is going to get its own feature or if it will be absorbed in to the monthly upkeep or per km cost of a vehicle or not before hand.

That way you won't come to need to rebalance infrastructure

jamespetts

Economies of scale
This is possible in principle, but not planned because it is likely to be extremely difficult to balance properly and because the overall effect of this on balance is doubtful.

It would be very difficult to do this without plentiful historical quantitative data about the effect of economies of scale on lots of different types of vehicle in lots of different time periods. Would it produce an economy of scale for a stagecoach operator to have lots of the same breed of horse? To what extent does having lots of the same class of steam locomotive have a greater or lesser effect on economy of scale than having lots of the same type of aircraft? To what extent can different but related vehicles be treated as part of the same meta-class? To what extent do existing data about maintenance assume some degree of this economy of scale - do we add a discount (if so, how much?) for economy of scale to the existing figures, or do we add a penalty (if so, how much) for not having consistency? Or is it different for different figures - and if so, how different for which specific figures? If purchasing the second or tenth vehicle from the same supplier reduces the price, by how much does each purchase reduce the price when we cannot predict how many, if any, subsequent purchases that there may be? How long does the effect last - if I buy a Boeing aircraft in 1945 and then another in 1990, does the one purchased in 1990 cost less because of the 1945 purchase? What counts as the same supplier, exactly? If I buy a steam locomotive produced by the London, Tilbury and Southend Railway in 1910 and then another produced by the London, Midland and Scottish Railway in 1930, will this attract a discount because the LMS absorbed the Midland Railway in 1923, which had in turn taken over the LTSR in 1913?

We cannot answer these questions by guessing, or else we could just as easily have as bad or worse balance than not having the feature at all - we need specific quantitative data on these things. I have not found any such data in the last 10 years or so during which I have been gathering data on this subject, suggesting that this is likely to be very difficult.

Also, it is not clear that this makes enough of a difference to the actual margins of costs over revenue to have a substantial effect on the overall balance of the game to justify the very large amount of work that this would create (especially on the pakset side). It may be something to consider one day, but I do not think that it is necessary to get the overall ratio of costs to revenue right at this stage.

Types of depots
I am not sure to precisely what extent that different depots have different capabilities in the UK; it would vary, I suspect, by transport type and era. Certainly, there would normally not be different types of 'bus garages; but, typically, 'bus operators would not do heavy repairs on their 'buses at all. London Transport in the 1950s was the exception, with the Aldenham works, which performed heavy repairs on all of London's 'buses (including major overhauls involving separating body from chassis, often pudding a different body back on the chassis than it had come in with), but this was uncommon. Trams are likely to have been similar to 'buses. Railways in the days of steam trains had major works, generally one per company (e.g., Eastleigh for the LSWR, Brighton for the LBSCR and so forth) that would carry out major overhauls and construction of new locomotives; there were then the main sheds that would do most ordinary maintenance work, but also smaller sub-sheds that would carry out lighter maintenance work on the engines allocated there (but many were allocated to main sheds and would not have used sub-sheds at all). In more modern times on the railways, there are different grades of maintenance facilities for different purposes. For aircraft, I am not entirely sure how it works, but I think that aircraft generally receive light maintenance at any airport that they happen to be visiting (often subcontracted if a fault arises at an airport at which the airline has no dedicated facilities), and major maintenance at the airline's main facilities. Canals would not really have had any maintenance facilities at all for the boats and horses, as any maintenance would have been done wherever the boat happened to be at the time that any repair were found to be necessary. I suspect that modern shipping is similar to what I have described for aircraft, but I do not have the details.

In summary: the historical picture is highly complex and I am not sure that adding any of this detail will really add much to the game, save, possibly, if we have different levels of depots, allowing only some to perform overhauls. However, even this would involve complexity: if we have to have one type of depot for overhauls, does this mean that we need to enforce that players must have a certain number of these depots - or do we let players build networks incapable of overhaul, and, if so, how does this affect playability if players realise too late that their vehicles need overhauling? Or do we allow players to run without overhauling vehicles at all, treating them like 'bus operators other than London Transport in the 1950s?

Detail versus abstraction
As KneeOn points out, there is a limit to what level of detail can practically be simulated. Often, that we cannot simulate some or other mechanic does not affect overall balance, as it can readily be represented by abstraction: we need not represent specifically, for example, the need to change the oil regularly in 'bus engines because this is accounted for perfectly well in the per km running costs.

The decision as to whether to represent mechanisms directly or include them as part of an abstraction is based on the extent to which the mechanism can be abstracted without affecting balance, the extent to which the mechanism affects incentives for players, the extent to which it would make the game more interesting or more difficult to play if it were represented, the amount of work involved in representing it directly (both in pakset and code), and whether there is somebody with a particular interest in the mechanic who wants to take the trouble to write the code for it.

Ultimately, the aim is to find a way of achieving balance closely based on real figures, which does involve representing mechanisms that cannot effectively be abstracted without distorting incentives or creating imbalances elsewhere.

Infrastructure
I am not sure what KneeOn means when he writes of not needing to rebalance infrastrucutre - current infrastructure costs are not balanced based on real figures, and, although many of them are by chance not far off what they would be if they were, some (e.g. bridges) are not, and it would still be better to balance based on the real figures if possible.

Given that the lack of balance appears to be elsewhere, and is likely to need additional features to represent, which features are likely to take some time to code, it seems sensible to start with the infrastructure rebalancing and (probably) leave other aspects of balancing until more features are implemented; although it is still worth doing more quantitative investigations into more details as to which specific aspect of costs are not represented and/or the extent to which the revenues are not accurate.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Expenses breakdown

Further to the analysis above, I have taken the LNER's 1923 accounts from Acworth's second edition and broken them down as follows:



I have then converted these categories into Simutrans equivalent categories (see the categorisations in the right hand column) and mapped these to percentages as follows:



This should assist with the analysis of the relative significance of what mechanisms are missing.

If anyone has any comments on whether I have assigned the categories correctly, please let me know, as it is always useful to have good data/analysis on this.

Note that the "infrastructure maintenance" is not the whole of the infrastructure maintenance, but that part of "traffic expenses" that would in Simutrans be allocated to this category.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

KneeOn

James, for your reference when I say they don't need balancing, I misread and thought they were already using true to life costs.

The fact they're close to life (even by chance) pointed at other issues needing addressing.

PJMack

One thing that has not been brought up in this discussion yet is passenger generation rates.  If more passengers are taking the transit system per hour per capita than in reality, then the revenue would be proportionally greater even with realistic fares.  I have, in game, ran into several occasions where it was physically impossible to keep up with demand for passenger transport due to the loading times and technology of the era, particularly before subway and trolley systems (the tube and electric trams).  It also appears to me that the ratio of visitors to commuters seams quite off, however this could be due to comparing it to transit habits on the wrong side of the pond.

jamespetts

Quote from: PJMack on January 10, 2022, 03:31:32 AM
One thing that has not been brought up in this discussion yet is passenger generation rates.  If more passengers are taking the transit system per hour per capita than in reality, then the revenue would be proportionally greater even with realistic fares.  I have, in game, ran into several occasions where it was physically impossible to keep up with demand for passenger transport due to the loading times and technology of the era, particularly before subway and trolley systems (the tube and electric trams).  It also appears to me that the ratio of visitors to commuters seams quite off, however this could be due to comparing it to transit habits on the wrong side of the pond.

Passenger generation has already been calibrated and a great deal of work has gone into this over a number of years. If you think that there is an error in this, I will need to know quite a lot of detail as to how you compute what the correct rate should be and how this differs from the rate in the game.

Note that, in very early eras, no passenger transport would in reality have been affordable by anyone with a class lower than "medium". If you are trying to transport "very low" in the stagecoach era, this may well be why you are attracting more passengers than your network can handle. If transport of "very low" passengers in the stagecoach era makes a profit in Simutrans whereas it would not have done in reality, this is a problem with cost balancing, not with passenger generation rates.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

Quote from: jamespetts on January 11, 2022, 09:45:43 PMIf you think that there is an error in this, I will need to know quite a lot of detail as to how you compute what the correct rate should be and how this differs from the rate in the game.
I have done some "back of the envelope" calculations based nationally in Britain of 1.7 billion rail passengers per year in 2019 with a population of 67 Million.  Assuming 16 hours a day, 5 days a week, 50 weeks per year to give a conservative overestimate of less than passenger per hour per capita.  Using the town of Frome with a 200 thousand passengers per year and population of 26 thousand results in nearly 2 passengers per capita per hour.  In game, a town from 2020 with a population in 10 thousand generated 1000 rail passengers (departures) in a 6.4 hour month results in 15 passengers per capita per hour.  I did check against a few more ingame and real life towns to check that this is not an anomaly.  Although this is not a scientific test, a factor of 7 does seem a bit large.

Quote from: jamespetts on January 11, 2022, 09:45:43 PMNote that, in very early eras, no passenger transport would in reality have been affordable by anyone with a class lower than "medium". If you are trying to transport "very low" in the stagecoach era, this may well be why you are attracting more passengers than your network can handle. If transport of "very low" passengers in the stagecoach era makes a profit in Simutrans whereas it would not have done in reality, this is a problem with cost balancing, not with passenger generation rates.
This was primarily with horse omnibuses in that era.  It did occur to me that this could be a problem with the scale difference rather than passenger generation as in game only 2 'buses can fit in a 125m stretch of road whereas in reality, they can be packed much denser.

Quote from: jamespetts on January 11, 2022, 09:45:43 PMPassenger generation has already been calibrated and a great deal of work has gone into this over a number of years
I am just one person with one of many possible styles of playing simutrans.  It is completely possible that everyone else would confirm proper passenger generation in their maps, and if that is the case, I would not worry.  However it is also possible that something else changed (such as city construction) that could have messed with the calibration.

jamespetts

Using rail passengers is not a reliable basis for comparison, since the number of rail passengers will depend on the levels of service and competing transport (e.g. private cars) as well as the size of the town. We need to calibrate the actual number of trips generated per person per 6.4 hours, no matter what the mode (including walking trips not purely on private land).

This has been discussed extensively in the past, including here, here and here, mostly just before or at around the time of the new passenger generation mechanic from 2012/2013, and more recently in relation to later refinements or proposed refinements, here and here.

I would suggest continuing the discussion on one of those threads about passenger generation rates, and leaving this thread to focus on the balancing specifically of costs.

Incidentally, as to horse omnibuses, these definitely would not have been affordable to "very low" class passengers.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.