[Gameplay discussion]: Better modelling of overheads

[jamespetts]

Reading books on transport economics recently, one thing that strikes me is the prominence of general overhead costs that do not scale directly with the number of vehicles or amount of infrastructure, both overheads for vehicle maintenance facilities, and more generally. I strongly suspect that these will have to be modelled in order to get a well-balanced economy in game.

An idea is this: set a cap on the number of vehicles of any given type (and traction type) permitted to each player based on the number of depots of the relevant type (and traction type) that that player has. This would then enable the cost of depots (to which specific reference is made in my transport economics texts) to be pegged proportionately to the network size: as things currently stand, there is, in theory, no need for players to have more than one depot of a given type, save that there will be inefficiencies that are very hard to quantify financially of having a depot very far away from the place where vehicles are deployed.

Then, to model general overheads, one could, in turn, tie the number of depots permitted to a particular level of headquarters, the maintenance cost of which represents the general overhead costs of a transport company. This would have the added advantage of giving a function to headquarters, which are currently a merely cosmetic feature.

So, for example, one might start with a level 1 headquarters, which allows 7 depots. One particular depot might allow, for example, 15 steam locomotives and 100 unpowered rail vehicles/carriages; another might allow 30 horses and 50 unpowered road vehicles/carriages/trailers. Buying two of the first type of depot would allow 30 steam locomotives and 200 unpowered rail carriages, and so forth. To prevent irritating micromanagement, the caps would be global figures, and vehicles would not be tied to particular depots. To prevent players building then deleting depots to reduce their maintenance cost, it should only be possible to delete a depot if doing so would not cause the number of vehicles in circulation to exceed the cap as it would be with that depot deleted.

I should be very interested in people's thoughts on how well that this would work; and also any offers to code this feature, since I am afraid that I have rather a backlog at present.

[ӔO]

I think it's a good idea.
as an aside, how about allowing multiple sub-headquarters? It is kind of similar to how you will have a local HQ in each region/province/state which manages just that location and one grand HQ for the entire country that manages the finances and resources.

- A local HQ will allow you to build more depots. Presumably, you'd only need 1 local HQ per city.
- A grand HQ will boost the maximum vehicles per depot by a percentage. Presumably, you'd want a grand HQ to reduce inefficiencies, which frees up extra resources and gives more overhead.

[sdog]

i'm not so sure if it is such a good idea. If you base the maximum number of vehicles on the depots, you make the overhead in effect also dependent on the number of vehicles. A fixed monthly cost would cover this much more directly. Creating a complicated system, difficult to explain, that is also just a pseudo-representation of the overhead doesn't really get you anywhere.

Some of the constraints of the player are also a bit strange. How do you explain less experienced players they can't remove that depot that's in the way until they built a new one somewhere else before? Constraints only put by some game rules on the player lead to strange behaviour too, eg. a bunch of dormant depots in a row without track connected etc.

If you want a more complex overhead model -- in other words a monthly cost for convoy isn't enough -- why not just include it in the financial calculation. You could show the result on the financial tab, perhaps give users the ability to see the details.

[jamespetts]

AEO,

that is an interesting idea, but I do wonder whether it adds much in gameplay or economic terms in return for the added complexity both of use and implementation; what gameplay advantage would there be to building multiple local office buildings as over upgrading a single headquarters?

sdog,

I do not think that these relationships are arbitrary: one really does have to have a certain depot capacity to look after a given number of vehicles in reality, an, in the books that I have about actual transport companies, I have figures about the cost of having depots. There is no possible way in Simutrans to model the depot cost without a mechanism for requiring players to have a particular number of depots as their network grows. This cost will scale to some extent with the number of vehicles, but it will not (as in reality) scale exactly with each vehicle, but rather go up in large steps and not be able to respond quickly to a diminution in the number of vehicles, as well as attracting significant capital cost with each step which will not be refunded to any extent if the number of vehicles is subsequently reduced. It introduces planning requirements and inefficiencies that are present and economically significant in reality.

As to deleting depots - is it not realistic that one cannot, in practical terms, demolish a maintenance depot when, if one did, one would not have sufficient facilities properly to maintain one's vehicles? The only alternative gameplay representation of the consequence of not having enough depots would be vehicles becoming less reliable, but it is considered (appropriately) undesirable to have a direct representation of reliability in the game. Indeed, without sufficient depots, some vehicles may become completely unserviceable (for example, for lack of fuel or parts that routinely need to be replaced very frequently). As to how to explain it to players, a dialogue box presented when one tries to remove a depot in something like the following terms should suffice:

"You cannot remove this depot as there would not be enough depots to maintain all your vehicles. You would need to sell 16 steam locomotives and 7 unpowered rail carriages before this depot can be deleted".

As to the suggestion of simply having an overhead charge without depots or headquarters; this, I think, would be less transparent to the player; it would also not model the capital requirements of headquarters and depots adequately.

[ӔO]

@james with the multiple local HQs, you won't run into a maximum. If you use only a single HQ that needs to be upgraded, eventually, you will run out of depots and convoys that you can build. At least, that's what it sounded like when you first described it.

[sdog]

The aliasing effect of the depot requirement compared to an increased monthly maintenance is only relevant at the very beginning of the game. It does not matter later on. The same is true for buying the depot. Thus the large steps you described are rather small ones lateron.

Example if you have 10 engines and need a new depot to get the 11th it is relevant. If you have 200 engines and need to build depot 21 to get the 201 the change of your monthly costs is almost indistinguishable from a monthly cost.

The same is true for the capital requirement. Having a little more expensive engines (a tenth of the depot costs doesn't matter at all by the way.) is almost the same. The fact that a depot stays when you replace an engine, and it had to be payed if the depot costs was included in the engine price is a bit different though. But you can give, with some handwaving, as a reason that the depot has to be refitted.

In total i think this depot requirement suggestion would bring quite an increase in complexity, not very transparent rules for hardly any gain. It also goes in the wrong direction, burdening the player at the start, while not mattering later on. (In my games i built later on new depots just because i was to lazy to look for the nearest one!)

ps.: (If a proper capital cost was introduced with paying large chunks of money wouldn't be to different from an increased monthly maintenance anyway.)

[jamespetts]

Sdog,

an interesting analysis. By "aliasing", do you mean the up-front capital requirement? It is not a term with which I am familiar in this context.

One of the reasons for suggesting the depots is this: if depots are in reality a significant part of a transport company's overhead, then putting the cost into the running costs of vehicles will make it very difficult to use realistic figures to distinguish between the maintenance costs of different types of vehicles, as the depot costs will (unrealistically) be bundled with the vehicle costs. So, for example, sources suggest that the cost of running a steam locomotive is about two and half times more than that of running a diesel locomotive. This differential should be apparent in the actual unit maintenance cost in Simutrans. However, this would not be possible if the depot cost was lumped together with the locomotive cost, as the cost of depots does not scale in the same way.

A further problem is this: in Simutrans, there are depots and they do cost something (and something significant) to maintain. What should the cost of depot maintenance be if there is no meaningful relationship at all between the number of depots and the number of vehicles? It is impossible to balance the depot costs without a way of pegging them to fleet sizes, as in reality. Bundling the depot costs with the vehicle maintenance costs is inconsistent with the present situation of actually having depots in the game, which actually have a cost.

Why do you think that this would not be transparent? Each depot would have a display in it along the lines of:

Steam (73/115); Diesel (0/0); Electric (49/64); Unpowered (427/2,048)... (etc.)

Those figures would be the same accross all depots, and would increase as depots were added and decrease as deleted.

AEO's suggestion in relation to local headquarters being a way around either having an absolute cap on vehicle numbers or having the highest level headquarters as allowing infinite vehicles is an interesting one, although it would require some fundamental changes to the headquarters implementation that the former would not.

[sdog]

aliasing is an effect when continous functions are mapped on discreet distributions. You have a nice example on your screen. Just luck at any curve, if it's large enough the difference between the stepped pixelate curve and the curve it should be is not noticeable.

One of the reasons for suggesting the depots is this: if depots are in reality a significant part of a transport company's overhead, then putting the cost into the running costs of vehicles will make it very difficult to use realistic figures to distinguish between the maintenance costs of different types of vehicles, as the depot costs will (unrealistically) be bundled with the vehicle costs.

Don't put it in the running costs, but in the monthly maintenance. It is independent of the running cost.

Now what we look at when buying a new engine is the total cost of ownership. We would have a nice single figure for that already in the monthly cost. (capital cost and opportunity costs are missing of course). The depot limit idea however would just pull out one number from that and have it somewhere else. Now if i buy an engine (or two dozen) i would have to calculate depot maintenance/engines per depot and add that value to the monthly costs. Matters get worse, since those values are different for different types of vehicles. The result would be the same however, as having something like adding 500/15= 33 pounds (that's with 15 steam engines per depot and current depot maintenance) to the monthly cost. (The figure is so ridiculusly small by the way, that it's hardly worth do consider it at all)

The player is playing the head of a railway company, not the accountant! Let players creat complex networks, have them fight for their financial survival, but don't bother them with micromanagement.

Now for realism: How realistic is such a depot limit anyways? An A4 needs much more expensive servicing infrastructure than a Pannier Tank i suppose? Does same limit apply? Having different limits for different engines. would be a complete chaos.

My suggestion would even go into another direction. Since we can't get rid of the depots, which are just a token in game where trains enter the network, set their cost to some quite small amount and their upkeep to zero. Don't let the player bother if they should build one to have it a bit more convenient. Perhaps, at this occasion, would you have another thought about reverting the limitation of different traction types for the same way-type to seperate depots? It did not contribute in any way to gameplay. The costs are completely negligible. It caused just more clutter in the menues and extra work.

[jamespetts]

I had intended "running" cost here to mean both the per kilometre and per month charges, and the same applies to both: the monthly charge is intended to represent the distance-independent cost of running that particular vehicle that is only incurred when that vehicle is run, i.e., the cost of staff (mostly). The idea is that, if vehicle A requires two crew and vehicle B requires one crew, then it should be easy to calculate the difference in the monthly cost between vehicles A and B. Similarly, if vehicle X needs lots of people to undertake routine maintenance on it, whereas vehicle Y needs only a few people, again, the difference in monthly charge would be proportionate to those differences in maintenance requirements. The 2.5 figure quoted should apply both to the per kilometre and per month charges. If depot costs were (unrealistically) bundled into a per vehicle charge, the business of choosing between vehicles based on their maintenance cost (not to mention the business of setting those costs in the first place) becomes orders of magnitude harder.

Also, I take the view that, if, in reality a particular cost was an overhead, it should look like an overhead in the game. The aim when balancing will be to try to match the proportions of figures in players' accounts to the accounts of real life transport companies (in broad terms), and moving costs from one type of category to another makes that vastly more difficult.

[sdog]

If depot costs were (unrealistically) bundled into a per vehicle charge, the business of choosing between vehicles based on their maintenance cost (not to mention the business of setting those costs in the first place) becomes orders of magnitude harder.

I can't follow you there. The depot cost per engine would be just a simple calculation. Divide depot upkeep by max number of engines. I also don't see where the difficulty for the player is, the number would be quite obviously standing at the units dialogue.

If player A has 20 depots, each costing 500 a month, able to house 15 engines each the total cost is 10000 a month. If a player has 300 engines with depot cost included in their monthly maintenance it would be 500/15 * 300 a month, in other words 10000. If it's only 281 engines doesn't really matter, it'd be just 9367 a month, a 7% difference. This difference would be larger for small networks, but there those few 500 won't really matter anyways.

Also, I take the view that, if, in reality a particular cost was an overhead, it should look like an overhead in the game. The aim when balancing will be to try to match the proportions of figures in players' accounts to the accounts of real life transport companies (in broad terms), and moving costs from one type of category to another makes that vastly more difficult.

Yes? But that is exactly my point. If you move the costs for vehicle maintenance, which of course depends on the number of vehicles, and move it to infrastructure costs by introducing a new constriction you just obfuscate it. In the company you have such things of course, but you also have some people hired who put it into the correct category and get you the TCO. If they are large they have it in their business unit or subsidiary and send a bill within their company. I can't follow you now why you want to put those accounting tasks on the player (and the pak-maintainers).

The idea is that, if vehicle A requires two crew and vehicle B requires one crew, then it should be easy to calculate the difference in the monthly cost between vehicles A and B.

My hunch for this, if you want some good balance over those three centuries you'll probably have to go the way of assigning manpower to convoys. Putting a half realistic function for wages over time could free you from a good part of guessing of the running costs.
Adding energy costs could get you to a point where you get pretty good estimates for running costs.

[rsdworker]

so i think its good idea - cause if i build one large depot for Network - at one city - for example London city so line runs to France so i place 20 eurostars in it and depot max capatity would relate to Local HQ - the depot can be upgraded to accomate more so example - when depot reachs full state (no more eurostars stored in local area unless trains has servicing at depot) so then you will given option - set train's home depot at other place or upgrade depot
the screen would be shown - 10/10 Home trains - this trains housed here and used for service 5/0 serviced trains - this for maintence if train breaks down but player can config depot for example - 20 home trains or serviced - for example some places have serivce depot but also stabling well to keep train in for short period example train stabled at other end if train does not have any load and station is empty - rather waiting at station for more cargo so train can go to nearset stabling if there no stabing then train will have wait at station
but different for bus - bus can stable at speical bays (bus Stand) where bus just stables there till its needed
sometimes retired train or bus can be stabled for long time - there examples in real world - London undergound has old stocks stabling at depots as retired
so local HQ is nesscary but optional = example if you have a local office - simllar to local HQ but different fuctions - the local offices allow other players to use player's tracks or etc
i think you like this - its relates to overheads

[scud47]

Actually I think it is a good idea because it finally gives headquarters a proper use. Also, it will get annoying if each depot can hold only a predetermined number of each type. I usually use only diesel locomotives at first, so it would be frustrating for a depot to be open but all the spaces be for steam so I need more depots.

[fbfree]

I agree with others that the cost of the depot should be incorporated into the vehicle cost.  However, the cost of deadheading is not taken into account currently in the game.  If for every convoy, there was a monthly charge for the distance between the convoy's route and the nearest depot, that would provide an impetus for locating depots effectively.

[jamespetts]

There is, I think, a somewhat fundamental economic problem with apportioning expenditure to individual convoys/vehicles to a greater extent than was actually done in reality. Although, superficially, it might appear as though this would produce the same result as if general overheads were unapportioned, its actual effects can be strikingly different.

To take a simplified example: suppose that one has a depot, capable of supporting 10 trains. That depot costs 1,000c per month to run. One could, in principle, apportion the depot's charge amongst the 10 trains, adding 100c per month to each's fixed maintenance charge, and making the depot's monthly cost zero. But suppose that not all of the trains made as much as 100c's profit per month: in the apportionment model, those making not more than 100c in monthly profit in the non-apportionment model would be unprofitable and pointless.

But, one might retort, surely they would be equally unprofitable in a non-apportionment model, albeit the losses would be disguised? That is not necessarily so. If the only way of being able to run the profitable trains is to buy a depot capable of supporting ten trains, and if, in the present state of the network (which cannot be expanded at present until more money is earned), only six trains can be run that are profitable in the apportionment model, but a further four trains can be run which, although unprofitable in the apportionment model, do turn over a profit (albeit one of less than 100c) in the non-apportionment model, then there will be incentive to run the four less profitable trains in the non-apportionment model, but not in the apportionment model. In other words, convoys, which, in the apportionment model would always be unprofitable, might often be profitable in the non-apportionment model.

This reflects what is known to be the reality of transport economics. W. M. Ackworth wrote this in his "The Elements of Railway Economics" (1906) in the chapter on the model of charging "what the traffic will bear":

"The total railway revenue is made up of rates which, in the case of traffic unable to bear a high rate, are so low as to cover hardly more than actual out-of-pocket expenses; which, in the case of medium-class traffic, cover both out-of-pocket expenses and a proportionate part of the unapportioned cost; and which finally, in the case of high-class traffic, after covering that traffic's own out-of-pocket expenses, leaves a large and disproportionate surplus available as a contribution towards the unapportioned expenses of the low-class traffic, which such traffic itself could not afford to bear.

"This, in principle and in outline, is the system of charging what the traffic can bear. It is the system which - the point must be reiterated - is, always has been , and, as far as we can see, always must be adopted on all railways, whether they be State enterprises or private undertakings. It is a system at once in the interest of the railway, because even the lowest class traffic, by whatever small amount its rates exceed the additional cost of doing business, contributes to the general expenses of the undertaking; in the interest of the public, because traffic is thereby made possible which could not come into existence at all, if each item of traffic was required to bear, not only its own direct expenses, but its full share of all the standing charges; and in the interest of the high-class traffic, because everything which the low-class traffic pays beyond its own actual out-of-pocket expenses helps to defray the general expenses of the undertaking, which otherwise the high-class traffic would have to bear unaided". (pp. 77-78).

Later, Ackworth writes,

"Previous chapters have afforded a general survey of the essential features of the business of a railway. From the point of view of expenditure, we see that these features are a large preliminary expenditure of capital which once spent is fixed and irrecoverable, and a large current expenditure of income on the maintenance and operation of the line as a whole, independent in great degree of the volume, independent almost wholly of the particular categories of the traffic carried over it. From the point of view of income, we have come to the conclusion that, as the expenditure  belongs almost entirely to the line as a whole, it impracticable to fix rates with any approach to accuracy on the basis of what the traffic costs to carry. And further, if it were possible, it would not be expedient or in the public interest. For to charge against each category and item of traffic not only its own special costs, but also its full share of general expenses and interest on capital, would mean to shut out from carriage much traffic that in the interest of the community ought be carried it would mean, further, a great restriction of the total volume of potential traffic, and so a higher average rate on the traffic actually carried" (p. 99)

In this respect, it would seem reasonable to conclude that what applies to railways applies to a greater or lesser extent to all transportation undertakings (indeed, reference is made in Ackworth's work to a similar principle applying to canals). Accordingly, it is important not artificially apportion capital overheads, as doing so can have a very considerable effect on the underlying economics of the operation. For that reason, it seems obvious that it is necessary to retain the separate maintenance charge for depots, and, further, to restrict the number of vehicles that such a charge might support.

[sdog]

James i think what you describe in paragraphs two and three is without a question so. The point is however, is this a relevant cost factor at all.

The price for the workforce for maintenance scales directly with the trains. So does the machinery (which we can completely ignore, as those are assets and tax deductable. What is left is the maintenance cost for the building itself. That should be negligibly low, compared to train and track maintenance.

We already have this economic effect of infrastructure already in the game, in a very relevant way: Track utilization.

[zook2]

Sorry if it has been mentioned or implied in this thread before, but a rather realistic way to deal with that would be to require a vehicle to *pass near* a depot once a month. Actually sending it to a depot would be too much micromanagement, but for trains and trams you could tag the tile in front of a depot (or all tiles connected to the depot in a radius of X tiles) as "servicing point" and tag the train as "serviced" when it passed over the tile. Perhaps give the tile a special color, or newbies would get confused. If the train didn't get serviced at the end of the month, quadruple the maintenance cost of this vehicle. And include a "Not serviced!" warning on the vehicle screen, or a message.

That way I think the network layout would naturally dictate the number of depots needed, and thus the additional cost.

For ships, make the service interval considerably longer, or just say that a dock functions as a servicing point. That would be realistic, because I think you don't send ships to the shipyard in South Korea once a month to change the oil.

For road vehicles... I don't know. You don't want to clutter the map with depots. And I agree that a global limit doesn't make sense. On all but the smallest maps you have a dozen road depots, or two or three dozen. Building another doesn't really matter in terms of overhead.

[greenling]

Sorry the idea to combinate the parklimit from Depot with the bigness of the headquater it a bad idea!
Self a parkinglimit for a Depot it´s a bad idea.
I Try to cam out without to many depots and a headquater.
Each Depot do in the beginig of a new game cost very many money.
The headquter does too.
Since in Pak128.Britain Exp gives Depot for horses,steam,diesel and electic lokomotion its the playing for the player very heavy!
he must be look after the typ of the vehicles thats he get the right typ of depot!
I live in Germany there Gives Railwaycompanys they have no own Depot and no own Headquater!
The Railwaycompanys do only rent a Depot then she need to fix a Railroadvehicles!
Only big Railwaycompanys with enogth money build in big Station a Big Depot that than on little Railwaycompanys be rent then it be need it!
A Depot that be support of Trains do cost new over 10 millions of punds!

[rsdworker]

depends on company - its ideal have options - if public player (govement) placed depot and tracks and stations then a option to rent them till bankupt

[elthore]

the reliability feature in TTD was probably one of the few realistic features that simutrans has yet to implement....and collisions. This made depot placement and quantity way more important. Having vehicle limits on depots that are never used to service the vehicles it supports seems kinda silly to me. I dont know if the engine can handle a feature like this though, due to the way it handles routing.

[Junna]

the reliability feature in TTD was probably one of the few realistic features that simutrans has yet to implement....and collisions. This made depot placement and quantity way more important. Having vehicle limits on depots that are never used to service the vehicles it supports seems kinda silly to me. I dont know if the engine can handle a feature like this though, due to the way it handles routing.

The collisions were really a pain in the **** and nothing else. Remember how if you had any buses or trucks crossing a railway at some point, how they'd seem to crash all the time, like they almost were suicidal?

Anyway, as far as I understand it was intentional that Simutrans not have any crashes. That sort of thing are hardly possible to render very-well anyway and would mostly be a little side-thing, just like those alien ships in Transport Tycoon were, too.

Also note that, although the vehicles are not serviced in the tedious and disruptive fashion that almost required you to set up what looked more like motorway service areas than maintenance depots in TT, there is definitely times when trains are likely to need to visit them; to upgrade, to change the carriages, or disassemble and re-assemble it, so on so forth.

[jamespetts]

Apologies for not having replied to this thread earlier: I have been rather preoccupied with other matters. Sdog asks whether the non-apportioned overhead/depot charges are significant in amount. Although I cannot find the costs of depots specifically, Ackworth does report overhead charges at p. 21, where he compiles the accounts of the various railways then existing into a single cumulative table. Costs representing true overheads are marked as bold:

Maintenance of way and works                      £10,200,000
Locomotive power                                       £18,700,000
Repairs and renewals of carriages and wagons   £5,500,000
Traffic expenses                                         £20,200,000
General charges                                               £2,500,000
Rates and taxes                                         £4,200,000
Government duty                                           £350,000
Compensation to employees                             £140,000
Compensation to passengers for personal injury   £140,000
Compensation for damages to goods                  £480,000
Legal and parliamentary expenses                      £300,000
Miscellaneous                                                     £1,800,000
Expenditure not allocated                                      £60,000
Total                                                          £64,570,000

On that analysis, £4,360,000 out of a total of £64,570,000, or 6.7% of the total cost of running a railway in the early 20th century can properly be classed as overhead.

A more modern analysis, from 1994, presented in "Applied Transport Economics" by Stuart Cole (ISBN 978-0749439644) for railway cost analysis shows (page 176) 7.6% of expenditure under "operations control" (defined as "management, control, signalling operations"), 2.6% on "commercial", 7.4% as "general - management" and 7.0% as "general - other", making a total of 17.2% expenditure as overheads.

The same book at p. 151 gives figures for road passenger transport in a similar vein: 50% is recorded as "wages and labour/overheads" and 10% as "non-building overheads".

Likewise, for air transport, the same book gives the 2003 average figures for airlines: 6.5% sales and marketing, 5.0% "general and administrative" and 4.2% "other", making a total of 15.7% overheads as a proportion of overall costs. These overheads are costs that scale very approximately with the size of the undertaking generally, but are not allocated to any particular vehicle, convoy, way, station or terminal. The sums are significant, and therefore the unallocated cost effect described above is likely to be real.

As to the other suggestions - I don't have time to deal with them in detail, save to note that Simutrans generally (both Standard and Experimental) tries to avoid too much micromanagement as might be engendered if convoys had to visit (or even near) go near depots for regular maintenance.

[sdog]

How about modelling this by adding 5% to 10% overhead based on average yearly cost of the last n years? (for games younger then n, use average so far)

[jamespetts]

Hmm - why would this be a better way of modelling the charges than having them relate to something specific? Smaller companies are likely to have a higher overhead in proportion to their overall size, for example.

[Carl]

How about modelling this by adding 5% to 10% overhead based on average yearly cost of the last n years? (for games younger then n, use average so far)

This sounds approximately similar to how "overhead" worked in Railroad Tycoon 3.

[jamespetts]

The problem with this method is that it doesn't behave like an overhead: it is functionally equivalent to increasing all the costs by 5-10%. It does not, therefore, have the non-apportionment effect of overheads as described above.

[sdog]

if you subtract the linear cost increase from the non-apportioned overhead you have only a minor remaining difference, likely in the one percent range. This difference is also asymptotic towards zero for increasing company size.

My reasoning here is that for a rather small gain for the economic simulation you take rather big steps. Introducing constraints for the players in regard to depots. Reducing abstraction of the simulation game (we don't model the operational aspects of maintenance so far). Increasing the function of the depot from a token for the UI to an entity relevant in the game. Do you think this is worth it, especially in regard to the level of detail other aspects of the economic simulation are modeled?

[jamespetts]

Firstly, there is clearly no point in simply calculating overheads as x% of costs, since that is identical to having all of the costs x% higher. It adds valueless complication and obfuscation to the finances.

Secondly, overheads per se are almost all fully non-apportioned, so fully 10% will be a non-apportioned cost, with all of the non-apportionment effects that that has as described above.

In response to the suggestion that the non-apportioned cost incentives of the ways are sufficient (and they are indeed substantial in appropriate cases), three points can be made. Firstly, not all transport infrastructure has to pay for ways: sea transport and river transport gets its ways for free, as does road transport in many cases. Secondly, the costs of ways are not completely non-apportioned: they are apportioned at least to a particular route, if not to a particular service of type of traffic, whereas overheads are not apportioned by route. Thirdly, depots specifically need this non-apportioned cost effect.

The reason for this is part of the same reasoning as applied in creating different traction type depots to begin with. In Standard, it has been a long-time problem that one particular type of vehicle is always the obvious best solution for nearly everything, making vehicle choice oversimplistic and as a result uninteresting. In Experimental, I have sought to reverse this trend by many measures (weight limits, tractive effort, comfort, catering, loading times, overcrowded capacity, and, before long, brake force). However, one element that those things do not model is the effect of inertia: that is, the fact that, once a transport company has invested in a particular type of traction, it is, all other things being equal, cheaper for it to continue to use more of that sort of traction than to start using a different type, as the overheads associated with keeping up one traction type cannot generally be applied to keeping up other traction types.

So, for example, a road haulage company in, say, the 1920s with an investment in steam traction will find it more expensive to start using diesel lorries than to continue using steam, even if, all other things being equal, there would be an advantage to a transport company with no investment in either to use the diesel lorries. The consequence of this on game play is that something other than the inherent characteristics of the vehicles themselves, being in this case what depots that a player already has, govern vehicle choice. This, in turn, is likely to increase diversity in vehicle choice and make the game-play around vehicle choice more interesting.

This was partly achieved by the expedient of the traction types for depots. However, the problem with this is that there is no determinate link between the expenses related to depots and the economic output that they can assist the player to generate. Put another way, the cost of depots is fixed, but their benefit is indeterminate. This makes balancing using this feature impossible. Your suggested solution to this asymmetry - to remove all costs associated with depots entirely - would have the effect of neutralising the inertia element of the incentive when purchasing new vehicles, thus removing an interesting game play element and a driver of vehicle type diversity.

The only way to make the traction type system balancable in the way intended is to link the costs of different depots with a fixed maximum level of benefit - hence a fixed maximum number of vehicles that can be supported by them. This would also then have the consequence of enabling overheads more generally to be modelled at the same time and by the same means.