Topic: How to get started on balancing properly

[moblet]

Mod note: split from this topic.

Haven't played Experimental yet but have read the overview, meanwhile just wanted to comment on equipment purchasing and network performance in the real world vs Simutrans. Some of this will go off-topic, sorry  

We have an obvious goal of trying to make Simutrans play as realistic as possible without it becoming horribly complex. When we talk about capital vs operating costs we're moving into business simulation territory; presumably there's already been a fair bit of discussion about where to draw that boundary. If not, there needs to be.

In the real world one of the basic corporate measures - and one that's relevant to Simutrans - is return on investment (ROI), but this is not even reported to a Simutrains player. The only way this can be simulated otherwise to finely balance all the prices so that the player goes broke if their ROI is uncompetitive, which is how I would describe what you're trying to do here. The catch here is that when the prices are that finely balanced, a minor error or oversight on the player's part, or bug in the sim, can easily bankrupt the player, creating a fickle game that only the most obsessive players would tolerate. It would be simpler to measure the player's ROI as something for them to compete against, and to continue to provide a challenge when highly profitable. This would also make it possible to implement variable economic conditions - another huge factor in real world decision making and operation - in a future version of Simutrans, which could be done pretty simply by dynamically altering demand and/or price parameters.

I certainly agree that we can improve the realism of equipment choices, but I feel that there's some really fundamental stuff that can be tackled before fiddling at the margins of locomotive prices. Putting my management consultant's hat on for a minute, here, in no particular order, are some crucial factors in real-world transport equipment purchasing and operation that aren't influencing outcomes in Simutrans. I've stated the bleeding obvious in places but have included it for completeness:
1. Labour costs.  2x 30 pax buses vs 1x 60 pax bus means paying two vs one drivers, so the difference in costs should not be linear. Vehicle operating costs in general in the Britain pakset don't seem to include labour, which can easily be 50% of operating costs for a vehicle. This doesn't automatically mean that the largest vehicle is the best, as smaller vehicles provide more frequent service (faster journeys, higher revenue) and deliver in smaller lumps, which reduces station congestion and hence infrastructure costs. More smaller vehicles also provides morre scope to adjust capacity. Labour costs favour faster vehicles, subject to #2...
2. Time-based vs mileage-based costs, e.g. costs such as labour mean that if a journey takes longer because of congestion the per-km costs end up higher. Punishes congestion no matter what the vehicle is carrying, or even if it's running empty. Congestion should be economically critical, not a mere nuisance, also helps to keep the player challenged throughout. Experimental is tackling this from the revenue side, so half the necessary calculations are now in place to hit it from the cost side. If this was implemented then vehicles would have to be specified with separate distance and time-based costs; would have implications for #1.
3. Increase in maintenance costs over equipment life. This is a big driver of real world replacement decisions. The further a vehicle has travelled, the more load it has carried, and the worse the operating conditions (e.g. asphalt vs cobblestones), the more money it costs to keep it running, and it eventually becomes economic to replace it even with a new vehicle of the same type. The absence of this factor is a big reason why Simutrans profits pile up unrealistically - every piece of gear runs like new even when it's not. I see that Experimental ramps up the maintenance rate after obsolescence, but it would be more realistic to have it increase with age regardless, better done as a per-vehicle or per-mode parameter than as a flat rate game-wide. It could be ramped more steeply after obsolescence, but that's fine-tuning.
4. Reliability. Nothing ever breaks down or otherwise disrupts the network in Simutrans, which feels really weird. Operational reliability is a product of build quality (= purchase cost), redundancy (e.g. two smaller locos double-headed vs one larger one, alternative routes, spare capacity), and ongoing maintenance spend (e.g. can reduce maintenance costs to save money in the short term but future reliability suffers). Many factories, especially raw materials suppliers who have to negotiate with Mother Nature, also experience variable rates of output.
5. ROI and financing costs, the latter now being introduced with Experimental.

Looks to me like most of these are Simutrans rather than pak level, the exception being #1. Happy to help with any of them. They wouldn't have to be included in extraordinary detail, just present in some form or another. e.g. Railroad Tycoon incorporates reliability by assigning each loco type a discrete reliability factor (from Poor to Near Perfect) that's shown to the player in the purchasing dialog, and then having the locos break down at random on track.

If Simutrans continues to develop as a transport network simulator it's almost inevitable that most or all of the above will be included. The structure and optimum values of the vehicle parameters are therefore likely to change, so if it was me doing it I'd:
a) compile the data to give myself the best chance of later extracting cost and performance parameters that I can't currently forsee
b) not worry too much about pinning down perfect numbers for v102.

[sdog]

The catch here is that when the prices are that finely balanced, a minor error or oversight on the player's part, or bug in the sim, can easily bankrupt the player, creating a fickle game that only the most obsessive players would tolerate.

We had such a state a bit short of a year ago, with much less pax and low travel time tolerances. Very interesting and quite tedious to play. A single blocked line could destabilize the whole network and often enough cause bankruptcy.

1. Labour costs [..] Vehicle operating costs in general in the Britain pakset don't seem to include labour, which can easily be 50% of operating costs for a vehicle.  ...

Is this now or roughly constant over time? Wages 100 years ago were low, but quite a lot of people were required to run one loco. I'd like to bring up an old suggestion of mine, which was considered not useful at that time. Include in experimental labour costs. It is easier to specify e.g. 4 workers for a loco, 0.3 for every carriage, 1 for a platform tile etc. Having either a function or a table for the development of the wages. This is in particular easier for vehicles that are in service for a very long time frame or during strong social changes. (End of steam aera) The whole thing is easy to code and historic personnel demand and wages should be much more easy to research. Implementation into the pak set could be on a step by step basis, first introduce a default value based on general rules.  (eg. steam loco 4, diesel/electric 1.x, bus before Atlantean 2, later 1, steam boats 3 plus 0.x per ton plus 1 for every 50 pax etc) Second step refine it for those deviating from the defaults.

[moblet]

Is this now or roughly constant over time? Wages 100 years ago were low, but quite a lot of people were required to run one loco. I'd like to bring up an old suggestion of mine, which was considered not useful at that time. Include in experimental labour costs.

I think the most elegant solution is roll everything into two costs: one per unit of distance, and one per unit of time, and have the sim calculate each journey cost accordingly. Keeps the sim and paks simple, light, and easy to understand. The pak developers can arrive at those numbers however they please, using as simple or as complicated a formula as they like. Labour is the biggest per-time cost but if you were going to get into that level of detail you'd have to look at others too, such as administrative overhead, and leave open a can of worms about what costs should or shouldn't be included in Simutrans itself.
All the money issues are still confusing for me because I'm not used to thinking across time without inflation, but I believe they can be resolved within those parameters. As far as I'm aware the trend in real terms has been for transport equipment to become more complex and expensive to buy per unit, but cheaper to operate and maintain per unit of work (both on a time and distance basis), and this can easily be captured through the parameters of purchase price and time & distance operating costs. Earlier kit is cheaper to buy but has higher operating cost per performance, as newer models come along they become more expensive to buy but their operating costs per unit of work are lower. It also fits with the real-world experience of something newer and more efficient coming along that induces companies to upgrade their vehicles.
The only other factor I would nominate to play with is energy consumption and cost, which has huge implications for transport choices.

[sdog]

As far as i understand there is no desire by the lead devs to increase the economic complexity of standard simutrans. Experimental has already two cost factors, a distance based cost per km and a fixed monthly cost. At the moment only the first one is set for pak britain ex. There is a 19th century experimental addon pak for 64 where fixed costs are also enabled. I don't think it is still maintained, if it is compatible to 9.2 is not certain.


I suggested treating labour differently mainly because of it's change often happening rather quickly, and only triggering adoption of new technology. Eg. in my game it is already 1960 and i don't have an incentive to replace my steam locomotives, since they operate rather cost efficient. A figure that is very well tuned to the 40s. However wages raised considerably and caused some massive cost increase. Coal prices must have plummeted at that time, since there was a major closure of collieries in europe. (Were they firing with lumps of coal, briquettes or even pulverized coal?)

The other reason is instead of developing a price for every locomotive it might be easier to do this based on general principles as much as possible. It should be much easier to estimate the demand of primary energy of an early 19th century locomotive than getting reliable running costs. It should be possible to get upper boundaries for the engines efficiency and we already have defined the torque and power in the dat files.

[jamespetts]

Moblet raises some very interesting issues. The first is the issue of the overall game balance between being easy and difficult. The suggestion made, as I understand it, is that any set of balancing parameters sufficient to give a real chance of failure if players make poor choices are such that will make the game too difficult to be interesting. I am not sure that I agree with that suggestion, as, if true, it would make most games of this genre of limited value. In order for a game to be fun, both success and failure must be real possibilities, and it should be the player's choices that make the difference between the two. Failure does not have to mean becoming insolvent within a short time of making a bad decision, but it should mean something like not having enough money to be able to afford to upgrade or extend one's network. Since the act of upgrading and extending the network is what players find fun, success and failure which relates to this activity is the most motivational. Players are far less likely to be motivated by the difference between making a very large profit and a very, very large profit where, even with the lesser amount, they have more than enough money to buy everything that they could reasonably want in the game. I should certainly find any such game very boring. Ideally, what I think would work well is one in which any player making reasonably sensible choices should be able at least to scrape by, but that one has to work a little harder to get a really successful, flourishing network that turns enough profit to be able to invest in substantial capital expansion (which would, in turn, enable one to make yet larger profits, and finance further expansion).

Going from making a profit to making a loss should always be possible, but, of course, a larger network can absorb a loss rather better, having, one supposes, greater capital reserves and also the ability to cut back unprofitable operations and still have a core of profitable operations remaining. I very much intend for players to have to close down parts of their network that become unprofitable over time (for example, because of competition from private cars or other players), and this would not be so if there was not some real risk of losing money. I do not think that it is impossible to achieve these incentives without making the game unduly difficult; after all, historically, it was not that difficult to make a profit by running a canal or a railway in the days when these were the primary forms of transport. Making it too difficult in that respect would make it unrealistic; yet some of these companies did sometimes make a loss, some of them failed entirely, and all of them had limited means with which to expand, and so did so gradually (some more gradually than others).

One balance issue in this respect seems to be the ratio of earnings to capital costs, which appears at present too high. It is one thing to have things balanced so that there is a good chance that one will make some profit from a moderately well-thought out operation, but that is not incompatible with also balancing things such that one has to make more than just some profit if one is to be able to afford to turn one's local 'bus network into a national coaching line, or one's branchline railway into an inter-urban mainline.

Another important element of overall balance is competition. Quite recently, Simutrans has been made possible to play over the internet between different players. A set of balancing parameters that make it easy for a single player with a monopoly can make it quite difficult for players playing with real competition. The competition itself is an important balancing factor that should be taken into account (such that, when set realistically, it should be possible for a monopoly player to turn a significant profit relatively easily).

Finally on price balancing, there is an element of difference between players as to how easy or difficult that they would like their game to be. Standard has a neat way of addressing this (which is incorporated in Experimental) by allowing players to play in "beginner mode", which multiplies the revenue from all operations by a fixed amount specified in a configuration file (simuconf.tab). The default such factor is 1.5. This is a useful mechanism for accommodating easily players with different preferences as to how easy that they would like their game.

Turning to some of the more specific issues, I entirely agree with the section on labour costs: the difficulty is how to model them, and how to balance that modelling with modelling variance of other costs; for example, one of the steam locomotives that I have recently produced is the London, Brighton and South Coast Railway I3 class, the first UK locomotive with a significant production run to use superheating. It was significantly more economical on coal than other locomotives of its size at the time, and this was of very great interest to other railways. Obviously, however, the labour cost would not significantly change; if anything, the slightly more complicated locomotive would cost a bit more to maintain. How best to approximate these various competing factors when accounting for the fixed monthly and variable per kilometre cost?

As to the time versus mileage costs, this is an interesting thought. It is certainly possible to implement this feature, but I am somewhat wary of putting in further new features at this stage that affect the balance before ever having properly tested what we have (viz. fixed monthly costs). Also, I do worry that the user interface for this feature would not be as easy to understand as it might be; people already get confused by the two different measures of time in the game (years/months for technological progress versus hours/minutes for journey times and loading). If we were starting from scratch, I'd choose not to have fixed prices for things at all, but relative factors for labour, materials, fuel (etc.) costs specified for each vehicle, the means by which those parameters convert into actual game money being determined computationally, simulating not only inflation over time, but also differential inflation in different commodities. This is very difficult to put in retrospectively, however, on a game that was first programmed in 1997 with no such ideas, and there is an extent to which we must work with what we have. Are we going to have real trouble making things more or less realistic with per kilometre and per month running costs?

As to increasing equipment maintenance over the lifetime of vehicles, I had initially considered doing this, but was dissuaded from doing so when confronted with the following issue by a seasoned player of both Simutrans and OpenTTD: suppose that one sets up a line of 10 lorries in year 0. In year 5, one buys 6 more lorries, in year 7 a further 8, and in year 10 a further 9. Come the retirement point of those lorries, there will be four separate batches of lorries on the same line to replace individually. If this is repeated throughout an enormous network, the micromanagement would become unbearable. A good compromise was thought to be increasing maintenance costs after obsolescence, which seems to be a workable solution. It must be remembered that a degree of abstraction is necessarily involved, and one Simutrans vehicle does not necessarily in all economic senses represent exactly one real world vehicle (and so one must take into account with maintenance costs, for example, that to run a certain service with less reliable vehicles takes more vehicles overall than to run it with more reliable vehicles).

As to reliability, the issue is the same as above: having actual individual vehicles break down from time to time would entail too much micromanagement (players could, for example, gain an advantage by re-routing vehicles around the broken down unit; generally, the rule is that, if players can gain an advantage by micro-managing, it disadvantages the players who do not micromanage, and makes the game less fun for them, and micromanaging is itself not very fun, so it makes the game less fun for everyone). Again, abstraction is involved: Simutrans does not purport to simulate every outing of every vehicle (not least because doing so in a simulation where there are two contradictory time scales would cause perverse outcomes; I remember once playing Tropico, for example, and running a very successful island, then suddenly going broke and being thrown out of office when all the stevedores took a tea break at the same time; I never played that game again). Unreliability is instead intended to be reflected in higher maintenance costs, which probably approximate the overall effect of unreliability accurately enough.

As to funding costs, I do wonder whether Experimental could benefit from some form of long-term loan system in addition to what is effectively an overdraft at present (such that players start with very little money of their own, and have to borrow most of their initial capital outlay), but that is not an immediately pressing concern at this stage.

In any event, to return to where we started with pakset price balancing: it is an interesting insight (and one that I suspected) that infrastructure and vehicles become more expensive to buy and cheaper to maintain as time goes on. Might that itself account for the order-of-magnitude difference in the inflation-adjusted price of a BR Mk. III carriage in the early 1980s and the corridor carriage of 1924? Would the maintenance costs be divided by 2.3 just as the purchase costs were multiplied by 2.3, or is the relationship more complicated? Maintenance costs are the harder to gauge, I think, so your help (and evident knowledge of the subject) would be of particular assistance there. Capital costs can more readily be researched (I am in the process of planning a trip to the National Railway Museum and its library for just such a purpose), and the costs of all things in the game fairly readily extrapolated and interpolated from a few choice examples, just as Sdog suggests.

Before we can set actual in-game prices, we need to set up a basic calibration between the price and the revenue (as discussed at the beginning of this post), so what we really need to start with is an idea of the relative costs of things: in other words, what is the ratio between the capital cost and the per month maintenance cost of various types of vehicles; the ratio between the per month cost and the per kilometre cost; the relationship between the revenue per passenger or tonne of coal per kilometre and the cost of a kilometre of road or track, etc.? Once we have these ratios, we can then fit in the actual numbers to a system that balances the prices in a sensible way and hopefully arrive at a fun and challenging game at the end of things!

[inkelyad]

people already get confused by the two different measures of time in the game (years/months for technological progress versus hours/minutes for journey times and loading).

We can drop eye-candy and print internal 'minutes' instead date/hour/minutes clock.

[jamespetts]

We can drop eye-candy and print internal 'minutes' instead date/hour/minutes clock.

That's an interesting suggestion: have the years/months on the existing system, but the hours/minutes on the same measure as journey times? That might work.

[moblet]

I'll see if I can clarify what I mean about the player's risk of failure. The character of Simutrans, like SimCity, is such that survival is difficult at the beginning, but if one gets established then money just keeps flowing in without any great challenge. This is encapsulated in this post. I believe that as a result of this dynamic, the value of these games is limited. How to address this? Some considerations:
1. If it's not addressed, then in multi-player games whoever gets established first can pull in enough money to suppress the competition, which also limits gameplay.
2. One way of stating the problem is that the price factor needs to be above a certain value for the player to have any chance of getting a start, but that value is too high to challenge a player with an established network. This is because...
3. Most of the real-world dynamics that increase profits for established networks are present in the game, but most of the dynamics that would reduce profits are absent. When an operation first starts up, its capital utilisation is usually quite poor, but as traffic builds utilisation improves, fixed costs are spread, and profit and return on capital increase. In the sim, one builds infrastructure and buys vehicles, and these things just keep going forever, whereas in the real world both of these things would wear out, and wear out in proportion to their usage. Road and rail needs to be relaid after an amount of traffic, busier lines have smaller maintenance windows requiring more intensive and out-of-hours (i.e. expensive) maintenance operations, busier lines need to maintain higher standards of individual unit reliability to maintain network reliability, there's the congestion operating cost issue I mentioned above, and so on. In the sim, infrastructure maintenance is a fixed cost over time, so if, say, I send 100t or 1,000,000t over a track in a year, I pay the same track maintenance cost.

I fully agree about the micro-management issue but the obsolescence ramp-up seems to me to cause much the same amount of micro-management as a simple age-based one would anyway - the player still has to weed out the individual vehicles that are costing too much to run. The only difference in the current sim is that the filter is already able to identify obsolete vehicles, and doesn't have the ability to, say, rank vehicles by their proportional maintenance cost. But I have thought of a different approach that might be simpler...

The upshot of increasing maintenance costs is that everything has a lifespan, so why not cut to the chase and impose a lifespan on every vehicle and way? You buy a loco that has a lifespan of, say, 1,000,000 km, and once that's up, you have to replace it or lose it. Same with road, rail, and runways, with lifespan measured in tonnes. For the player to be able to manage it the sim would have to be able to provide the following:
1. A list of all vehicles and infrastructure, ideally also colour-coded on the map, that are approaching expiry
2. A budget forecast of replacement expenditure
3. An option to have the sim automatically replace everything of each type or to prompt the player for a decision. Vehicles could be replaced in transit to avoid micro-managing them in and out of depots.
This would be highly realistic and do a great job of keeping rampant profits in check on a large network. Different modes have different lifespans (e.g. road vehicles less than rail ones). Maintenance costs could also increase with age but not be critical for replacement, that way the player's intuitive thinking that "this thing's getting old, it'll be costing more to run and soon I'll have to replace it anyway" is correct.

On balancing costs between vehicles of the same mode, I've had the idea of setting up costs such that every vehicle's life-cycle cost pans out vaguely similarly under a standard, "average" set of conditions, but that the different technical specifications mean that certain vehicles will have relative advantages/disadvantages under different conditions (e.g. long high-speed hauls, hilly routes, congested routes), with different ratios of capital vs operating costs to offer the player options financially. I've built a little spreadsheet for comparing vehicles, attached. One advantage of this approach is that we only need a few numbers for a few locos and we could legitimately make up sensible numbers for the rest. Not sure yet how to incorporate technological advancement - which should cause a step-change in life-cycle cost - without unbalancing the game between earlier and later eras.

I think there are several factors at play in making the 1980's carriage relatively more expensive that the 1920's one. The newer one will certainly be more efficient and require less maintenance due to things like wheel bearings, which cost money, but I suspect a few other things might be more significant:
1. Who let the contracts? Was the 1920's a private sector contract, and the 1980's a govt one? There was probably a lot more competition in the carriage-building business 90 years ago, too. I remember a transport engineer telling me 15 years ago that public transport vehicles cost 2-3 times as much as they should because of all the bells and whistles that find their way into govt contracts.
2. Higher construction and fitout standards. Modern rail carriages have to be comfortable to compete with private cars, and need to meet impact strength standards. I doubt the 1920's versions had climate control.
3. Safety and environmental regulations increasing costs at the workshops. I'm sure a lot less people, and perhaps whales  , were harmed constructing the newer ones.

On fixed vs variable, time vs distance costs, what is the fixed monthly cost intended to capture? In the real world it would cover ownership costs such as financing, insurance, and spare parts inventory, but would not cover most maintenance cost, which is a function of usage. Nor would it cover operator costs, since these aren't incurred when the vehicle is idle. The only incentive it provides in the game is to discourage players from holding on to vehicles they don't need, but the introduction of interest rates provides this incentive anyway, so I'd question the value of having a fixed monthly cost at all. As for the cost per hour of operation, I've built a spreadsheet, attached, to demonstrate its significance, You could also use the spreadsheet to compile the total operating cost, may help to answer the question of how to model labour costs. I've made the numbers up, but try any numbers you like, the relationship between congestion and cost-per-km is exponential, and if a working vehicle is stationary its cost-per-km goes to infinity. In the meantime one could input an assumed average speed for a vehicle and come up with a cost-per-km that includes labour.

On revenue vs capital vs operating costs, in real terms revenue per tonne-km has fallen historically as transport has improved and costs have fallen. Is there a Simutrans development philosophy on handling this over time, or is that still being figured out?

[sdog]

The upshot of increasing maintenance costs is that everything has a lifespan, so why not cut to the chase and impose a lifespan on every vehicle and way? You buy a loco that has a lifespan of, say, 1,000,000 km, and once that's up, you have to replace it or lose it. Same with road, rail, and runways, with lifespan measured in tonnes. For the player to be able to manage it the sim would have to be able to provide the following:
1. A list of all vehicles and infrastructure, ideally also colour-coded on the map, that are approaching expiry
2. A budget forecast of replacement expenditure
3. An option to have the sim automatically replace everything of each type or to prompt the player for a decision. Vehicles could be replaced in transit to avoid micro-managing them in and out of depots.
This would be highly realistic and do a great job of keeping rampant profits in check on a large network. Different modes have different lifespans (e.g. road vehicles less than rail ones). Maintenance costs could also increase with age but not be critical for replacement, that way the player's intuitive thinking that "this thing's getting old, it'll be costing more to run and soon I'll have to replace it anyway" is correct.

While i greatly appreciate the consequences for the game's economy, i think the micromanagement is still enormous. Replacing a vehicle type on a developed map can easily take two hours for rail vehicles. To resolve blockages, send them back on their route and so on. Also replacing main lines interrupts service greatly. And can bring down revenues by one half for 1 to 3 consecutive months, when it happens at lines at the core. This has no comparison to normal real life operations, where this is done more smoothly.

Can't this be included in the maintenance costs only? I understand that doing it directly would cause some very nasty consequences for early games. However, we could make the running costs more dynamically, define a max lifespan as length in km. When the odometer reaches it the running cost per km is increased by the replacement (price+interest)/lifespan. To simulate with every km traveled you pay back the loan taken to buy the vehicle. This is not very elegant however.

An alternative would be charging the replacement cost to the player account, without doing a 'physical' replacement. This however could happen en-masse and drive a player into bankrupcy.

Oh, just had another idea, make a user action where player can select to replace all old vehicles, old vehicles of a line or a single convoy WITHOUT actually replacing it, just reseting the 'age' (e.g. odometer, resale value).

EDIT: over-looked the line now marked in bold in the quote.

On costs for rolling stock:

3. Safety and environmental regulations increasing costs at the workshops. I'm sure a lot less people, and perhaps whales  , were harmed constructing the newer ones.

The price of raw materials has greatly decreased. Whalebone and ivory (and rubber) were also quite expensive, since the 60s synthetic polymers do the job better and much more cheaply.

[moblet]

Replacing a vehicle type on a developed map can easily take two hours for rail vehicles. To resolve blockages, send them back on their route and so on. Also replacing main lines interrupts service greatly. And can bring down revenues by one half for 1 to 3 consecutive months, when it happens at lines at the core. This has no comparison to normal real life operations, where this is done more smoothly.

Have to say the complications of replacing vehicles are horrendous in this game, and the worst culprit in the micro-management stakes. I've not played a game long enough to have to do replacements en masse, but I think if I got to that point I would simply give up. It's not at all realistic to throw a line into chaos for months just to upgrade the machinery. I'm a bit surprised that there isn't an option, when clicking on a vehicle, to instantly replace it without interrupting its work - is there a reason why not?

An alternative would be charging the replacement cost to the player account, without doing a 'physical' replacement. This however could happen en-masse and drive a player into bankrupcy.

I'm saying this is exactly the kind of hit we need to build into the game so that you're not home and hosed if you make it through the first couple of years, and so profits don't keep spiralling upwards. It's 100% realistic to have to plan for, and finance, equipment and infrastructure replacement, and a budget forecast going out a few years would be needed to help the player do that. Very unlikely, if wear was based on km and tonnage, that everything would die at once anyway. There'd be something dropping off every month.

[sdog]

I'm a bit surprised that there isn't an option, when clicking on a vehicle, to instantly replace it without interrupting its work - is there a reason why not?

only a part of devs and players is interested in an economic sim quite a lot see it as something  similar to a H0 modelrailway, others as some kind of transport tycoon. My impression so far is those streams are roughly 1/3 each. They are also equally valid. Perhaps the trend will be that the economic third moves towards experimental. (this split is a concern to some)

[moblet]

They are also equally valid.

Absolutely, and they don't need to be incompatible either, so long as there's a sandbox mode where the economics can be turned off. The "instant replace" button can be ignored by anyone who doesn't want to use it, or is there philosophical opposition to the prospect of its very existence?

[sdog]

To be honest, I'm not sure
Try an extension request. This would be discussed more broadly.

[jamespetts]

I'll see if I can clarify what I mean about the player's risk of failure. The character of Simutrans, like SimCity, is such that survival is difficult at the beginning, but if one gets established then money just keeps flowing in without any great challenge. This is encapsulated in this post. I believe that as a result of this dynamic, the value of these games is limited.  How to address this? Some considerations:
1. If it's not addressed, then in multi-player games whoever gets established first can pull in enough money to suppress the competition, which also limits gameplay.
2. One way of stating the problem is that the price factor needs to be above a certain value for the player to have any chance of getting a start, but that value is too high to challenge a player with an established network. This is because...
3. Most of the real-world dynamics that increase profits for established networks are present in the game, but most of the dynamics that would reduce profits are absent. When an operation first starts up, its capital utilisation is usually quite poor, but as traffic builds utilisation improves, fixed costs are spread, and profit and return on capital increase. In the sim, one builds infrastructure and buys vehicles, and these things just keep going forever, whereas in the real world both of these things would wear out, and wear out in proportion to their usage. Road and rail needs to be relaid after an amount of traffic, busier lines have smaller maintenance windows requiring more intensive and out-of-hours (i.e. expensive) maintenance operations, busier lines need to maintain higher standards of individual unit reliability to maintain network reliability, there's the congestion operating cost issue I mentioned above, and so on. In the sim, infrastructure maintenance is a fixed cost over time, so if, say, I send 100t or 1,000,000t over a track in a year, I pay the same track maintenance cost.

Ahh, yes, this is the crucial issue, and one of the things that I set out to address in Experimental in the first place. The original intention was to make things relatively easier for a new player, thus making it possible to have a lower price factor (as you call it in the post above) overall to increase the challenge for an established player whilst enabling a new player to get started: the idea of alternative destinations and having a higher proportion of passengers using local transport was intended to have that effect, although I did not take into account the capital utilisation issues that you address above.

I had not really finished testing the existing model: the previous version of Pak128.Britain-Ex that I released was set with quite tight journey time tolerances, so I relaxed them considerably for 0.7, which turned out to be too much of a relaxation, and now passenger numbers are excessive, which leads to high profits on a passenger network. I have not yet tested it with an intermediate level (which will be necessary in any event to get a realistic number of passengers). However, as stated above, I had not considered the points that you make in relation to the constraints on profits of a larger network/organisation compared to a smaller one (I had tried to think of such constraints, but had not come up with the particular things that you mention), and the points that you make are very interesting and merit further consideration.

One idea in particular interests me of that which you have espoused, which is tonnage based infrastructure maintenance cost. This would be relatively easy to implement and for players to understand, and it would also indeed act as a balancing constraint against the improved resource utilisation of players with a larger network. This would, of course, be in addition to the per month maintenance costs, as there are some tasks that need doing no matter how much or little that a way is used. One interesting consequence of this is in relation to canals, which, presumably, would have a zero per tonne maintenance cost, as canals do not wear out, as such, although they do need regular de-silting and weed-killing along the towpaths, etc.. This would, I suppose, add to canals' existing dynamic as being very expensive to build but very cheap to maintain compared to other types of way. How much of a difference would this particular item have to the overall dynamic of the exponential increase in profitability that you describe above, do you think?

One thing that would have to be considered as a consequence is re-adjusting the existing per-kilometre cost in order to balance properly with the per tonne cost. Another question is what one does about airport runways; presumably, they are also more expensive to maintain the higher the tonnage of aircraft that use them in any given period?

Another thought in relation to reducing the relative profitability of larger organisations is to give them an ever higher administrative overhead. One neat way of doing that in Simutrans would be to use the existing feature of headquarters (which currently has a cost - generally a high cost - but no real game function (aside from generating passengers and mail itself), serving in effect as a sort of status symbol). Players could be required to have a headquarters building of a certain level in order to build more than a certain number of convoys, for example, level 1 headquarters to build more than 5 convoys, level 2 to build more than 100 convoys, level 3 to build more than 250, and so on. I'd be interested in your views on whether this would be realistic and workable.

I fully agree about the micro-management issue but the obsolescence ramp-up seems to me to cause much the same amount of micro-management as a simple age-based one would anyway - the player still has to weed out the individual vehicles that are costing too much to run. The only difference in the current sim is that the filter is already able to identify obsolete vehicles, and doesn't have the ability to, say, rank vehicles by their proportional maintenance cost. But I have thought of a different approach that might be simpler...

The upshot of increasing maintenance costs is that everything has a lifespan, so why not cut to the chase and impose a lifespan on every vehicle and way? You buy a loco that has a lifespan of, say, 1,000,000 km, and once that's up, you have to replace it or lose it. Same with road, rail, and runways, with lifespan measured in tonnes. For the player to be able to manage it the sim would have to be able to provide the following:
1. A list of all vehicles and infrastructure, ideally also colour-coded on the map, that are approaching expiry
2. A budget forecast of replacement expenditure
3. An option to have the sim automatically replace everything of each type or to prompt the player for a decision. Vehicles could be replaced in transit to avoid micro-managing them in and out of depots.
This would be highly realistic and do a great job of keeping rampant profits in check on a large network. Different modes have different lifespans (e.g. road vehicles less than rail ones). Maintenance costs could also increase with age but not be critical for replacement, that way the player's intuitive thinking that "this thing's getting old, it'll be costing more to run and soon I'll have to replace it anyway" is correct.

This issue is not so straightforward. The problem with the approach of requiring that vehicles be replaced at a certain point in their lifecycle is somewhat arbitrary, as, in reality, transport operators would have the choice to keep them going at higher cost or invest the capital (if they can afford it) in new equipment. What you describe as the simple approach gives rise to arbitrary outcomes.

There is also this to consider: suppose that a vehicle costs 10c/km to maintain. After 100,000 km, it requires an overhaul costing 100,000c. That could be simulated by, as you suggest, making the player pay 100,000c all of a sudden after 100,000km of use. But is not requiring an overhaul after a fixed amount of time not equivalent to the vehicle having a higher maintenance cost; in other words, can one not simply amortise the cost of all major overhauls during the vehicle's natural lifecycle into its per kilometre maintenance cost, so that, in the above example, the maintenance cost is 11c/km rather than 10c/km? (The purpose of the current obsolescence increase is to reflect the increase of cost after a vehicle's normal lifecycle has expired). Indeed, would amortising the cost in this way not also account for the budget forecast of which you wrote (which would otherwise take a lot of programming work to set up)?

On balancing costs between vehicles of the same mode, I've had the idea of setting up costs such that every vehicle's life-cycle cost pans out vaguely similarly under a standard, "average" set of conditions, but that the different technical specifications mean that certain vehicles will have relative advantages/disadvantages under different conditions (e.g. long high-speed hauls, hilly routes, congested routes), with different ratios of capital vs operating costs to offer the player options financially. I've built a little spreadsheet for comparing vehicles, attached. One advantage of this approach is that we only need a few numbers for a few locos and we could legitimately make up sensible numbers for the rest. Not sure yet how to incorporate technological advancement - which should cause a step-change in life-cycle cost - without unbalancing the game between earlier and later eras.

Is there a particular reason for having all vehicles having the same lifecycle cost? I don't think that this was how things panned out in reality, was it; some vehicles had a far higher life-cycle cost than others. I'd rather simulate that reality if possible, and I don't see any particular reason why it's not possible.

As to technological change, as you observed earlier, the idea is to have higher capital but lower maintenance costs in later eras. This would have an interesting effect on gameplay in any event: successful players would have enough of a capital reserve to afford the ever increasing capital costs, and their investments would, if managed wisely, pay off (as a result of the lower maintenance costs) and enable them to have enough money to invest in the next and even more expensive capital project, whereas companies that did not make enough profit would be unable to afford sufficient capital investment and would be forced to shrink their operations in order to survive (in other words, make a capital investment in the core parts of their operations, and abandon those that can no longer remain profitable without a capital investment greater than the company can afford). As to the issue of players starting in different eras, that is easily handled by the mechanism, already built into Standard (and thus incorporated into Experimental, although not yet implemented in Pak128.Britain, either Standard or Experimental) of having players starting with different amounts of capital at different times in history.

I think there are several factors at play in making the 1980's carriage relatively more expensive that the 1920's one. The newer one will certainly be more efficient and require less maintenance due to things like wheel bearings, which cost money, but I suspect a few other things might be more significant:
1. Who let the contracts? Was the 1920's a private sector contract, and the 1980's a govt one? There was probably a lot more competition in the carriage-building business 90 years ago, too. I remember a transport engineer telling me 15 years ago that public transport vehicles cost 2-3 times as much as they should because of all the bells and whistles that find their way into govt contracts.
2. Higher construction and fitout standards. Modern rail carriages have to be comfortable to compete with private cars, and need to meet impact strength standards. I doubt the 1920's versions had climate control.
3. Safety and environmental regulations increasing costs at the workshops. I'm sure a lot less people, and perhaps whales  , were harmed constructing the newer ones.

Factors 2 and 3 are worth replicating (comfort has an actual effect in the game, and higher safety standards are simply represented by having higher costs in later years), but we should really try to factor out the first element if we can, as that does not really apply to Simutrans, where vehicles are procured through what are, in effect, private companies.

On fixed vs variable, time vs distance costs, what is the fixed monthly cost intended to capture? In the real world it would cover ownership costs such as financing, insurance, and spare parts inventory, but would not cover most maintenance cost, which is a function of usage. Nor would it cover operator costs, since these aren't incurred when the vehicle is idle. The only incentive it provides in the game is to discourage players from holding on to vehicles they don't need, but the introduction of interest rates provides this incentive anyway, so I'd question the value of having a fixed monthly cost at all.

I am reliably informed by somebody who works in transport that there are many things on vehicles (rubber seals are apparently one example) that need maintaining just as much if a vehicle is sitting idle as if it is being used. As to interest rates, interest is only presently relevant when a player is overdrawn. Would there be merit in adding a credit interest rate to the player's bank account balance, too? This would be quite simple to acheive.

As for the cost per hour of operation, I've built a spreadsheet, attached, to demonstrate its significance, You could also use the spreadsheet to compile the total operating cost, may help to answer the question of how to model labour costs. I've made the numbers up, but try any numbers you like, the relationship between congestion and cost-per-km is exponential, and if a working vehicle is stationary its cost-per-km goes to infinity. In the meantime one could input an assumed average speed for a vehicle and come up with a cost-per-km that includes labour.

That's a very interesting set of calculations. How much effect do you think that the per hour cost would have in a Simutrans environment? That one would be harder to implement than some of the other suggestions mentioned above, and so would require some careful thought.

I also notice that you include debt servicing cost, which, in Simutrans, of course, should not be bundled up with the vehicle costs, as a player may well not be in debt at all (indeed, usually is not).

On revenue vs capital vs operating costs, in real terms revenue per tonne-km has fallen historically as transport has improved and costs have fallen. Is there a Simutrans development philosophy on handling this over time, or is that still being figured out?

This is an interesting point, and I was not aware of the economic details of this. There is one mechanism in Simutrans which has some potential bearing on this, although it may not replicate it accurately. That is the speed bonus. It is a speed per type of transport (road, rail, air, etc.) that varies (that is, generally increases) by year against which revenues are pegged. The default revenue is achieved if that speed is equalled; it is reduced if the speed is less, and increased if the speed is more. In Standard, the speed is measured on the basis of the maximum speed of the slowest vehicle in the convoy. In Experiential, it is based on the average speed of the line (or, if the convoy is not in a line, the convoy). A very easy way of reducing the revenue in real terms over time would be to increase the speed bonus speeds at a higher rate than actual speeds are likely to increase. If this, if properly tuned, can be made more or less accurate, I'd rather use this than have to program something else.

[moblet]

the idea of alternative destinations and having a higher proportion of passengers using local transport was intended to have that effect

I think this is in essence realistic and a nice feature, but wouldn't try to use it as major weapon against a larger network. The definition of "local" to a passenger is usually based on travel time as per the isochrones in one of AEO's links, rather than drawing a circle around one's current location - can't recall whether your "localisation" model is based on distance or travel time.

This would, of course, be in addition to the per month maintenance costs, as there are some tasks that need doing no matter how much or little that a way is used. One interesting consequence of this is in relation to canals, which, presumably, would have a zero per tonne maintenance cost, as canals do not wear out, as such, although they do need regular de-silting and weed-killing along the towpaths, etc.. This would, I suppose, add to canals' existing dynamic as being very expensive to build but very cheap to maintain compared to other types of way. How much of a difference would this particular item have to the overall dynamic of the exponential increase in profitability that you describe above, do you think?

A canal, like any other way, only needs to be maintained in usable condition if it is being used. It can silt up all it wants otherwise. If canals had a high fixed maintenance cost regardless of use then they all would have been filled in when the railways came. With most ways there are tasks that need doing even if it's not in use, but their cost is negligible compared with maintaining them in use. For the sim, any cost that is shifted from fixed to variable will help balance the challenges of early and mature gameplay, and importantly provides a simple mechanism to balance them. So if implementing only one way maintenance cost calculation, make it variable. The only role of a fixed cost for way maintenance in the sim is to discourage over-building, and to encourage the player to bulldoze anything they think they no longer need. So the question for implementing fixed maintenance cost is: do we want to force the player to bulldoze every canal/road/rail tile they no longer need? If that's not important, don't bother including a fixed cost.

EDIT: sorry, slightly misinterpreted what you wrote. The only way I can see of capturing that cost otherwise is if there's a way of determining which tiles are part of existing lines, and charging fixed maintenance costs to those tiles only.

Another question is what one does about airport runways; presumably, they are also more expensive to maintain the higher the tonnage of aircraft that use them in any given period?

Yes, they will deteriorate faster. Runways, like roads, rails, and bridges, are built to loading specifications. Many had to be widened to accommodate the A380, for example. Yes, they will become more expensive to maintain, but of course this will not impact significantly on the overall cost of air operations. The dynamics of the air industry are quite different, and most sensitive to fuel costs, which aren't explicit in the sim. The cost of real estate and ground infrastructure are comparatively less significant.

One neat way of doing that in Simutrans would be to use the existing feature of headquarters

Cute, but sounds really messy and arbitrary, and complicates gameplay, especially for newbies, who have enough to get their heads around as it is. Would be simpler to charge an admin cost on all vehicles/infrastructure, but of course this would be a linear cost in relation to network size.

The problem with the approach of requiring that vehicles be replaced at a certain point in their lifecycle is somewhat arbitrary, as, in reality, transport operators would have the choice to keep them going at higher cost or invest the capital (if they can afford it) in new equipment. What you describe as the simple approach gives rise to arbitrary outcomes.

Granted, but this is much more realistic than no lifespan, and I as a player would find it more acceptable than having to micro-manage replacement decisions. It's also very simple to understand. I'm not talking about replacing them at a certain point of their life-cycle, but at the end of it - their kilometres are up. This is not the same as manufacturing obsolescence, will get to that in a minute.

There is also this to consider: suppose that a vehicle costs 10c/km to maintain. After 100,000 km, it requires an overhaul costing 100,000c. That could be simulated by, as you suggest, making the player pay 100,000c all of a sudden after 100,000km of use. But is not requiring an overhaul after a fixed amount of time not equivalent to the vehicle having a higher maintenance cost; in other words, can one not simply amortise the cost of all major overhauls during the vehicle's natural lifecycle into its per kilometre maintenance cost, so that, in the above example, the maintenance cost is 11c/km rather than 10c/km?

Good example, and one that strikes at the heart of the early vs mature game issue. Paying for the overhaul after 100,000km, as would happen in the real world, gives the player the opportunity to raise the money to pay for it. to make the vehicle pay for itself. Asking the player to put money aside from Day 1 for an overhaul that's years in the future cripples early gameplay. If the player fails to make the vehicle pay for its overhaul in 100,000km of use, that's the player's fault. We'll get better gameplay if maintenance in year 1 costs, say, 3c/km, and creeps up year on year, after the player's been able to make some money out of the equipment first.

The purpose of the current obsolescence increase is to reflect the increase of cost after a vehicle's normal lifecycle has expired

Obsolescence and unit lifecycle are totally different concepts. Think of them completely separately. Obsolescence means the manufacturer no longer makes it (although spare parts usually remain in production for some time), Lifecycle means the period over which something is economic to own and operate. Something that's obsolete may still be fit-for-purpose and economic to use - most of the vehicles you see on land and sea are obsolete. If you have an IT background you may be used to thinking of obsolete as being equivalent to "inadequate and uneconomic", but with transport infrastructure and equipment things don't (can't) change that quickly. Obsolescence usually only impacts on lifecycle when parts become expensive and/or difficult to obtain, which is typically many years or decades after the unit became "obsolete". To say "I can operate a vehicle for peanuts for decades longer than a real one would last, until the manufacturer stops making new ones, then I can't afford to run it" is a long way from reality, and misses an opportunity to challenge mature gameplay with the simple but intuitive concept that "the more I use it, the faster it wears out".

Is there a particular reason for having all vehicles having the same lifecycle cost? I don't think that this was how things panned out in reality, was it; some vehicles had a far higher life-cycle cost than others. I'd rather simulate that reality if possible, and I don't see any particular reason why it's not possible.

It's certainly possible, but I don't believe it's desirable. This is a fundamental philosophical issue for historical sims - do you model things as they actually panned out, or as people at the time thought they would pan out? We might know now that loco x built in 1926 was a lemon, it ended up costing its owners three times as much to maintain as its competitor loco y. But did the sucker buying loco x in 1926 know that? Would anyone have bought loco x in hindsight? Would it even have been made? Half the joy of playing historical sims is to make decisions as if one was there at the time, with the information known at the time. If loco x is given parameters that make it uneconomic, because in the real world it turned out to be uneconomic, then one of the game rules becomes "never buy loco x, you'll go broke". Is that desirable?
In practice there was/remains uncertainty in every equipment purchase, uncertainty that's not modelled in Simutrans - you buy something and it performs exactly as the manufacturer said it would.
The goal, as I understand it, is to offer a range of vehicles with performance that's sufficiently differential to make some items more suitable for some purposes than others, but not so differential that some of those vehicles are practically useless (for economic or technical reasons). It also strangles gameplay a bit if there's only ever one choice for any given application; for one we won't get to see the full variety of trains that have been made for the sim. You are trying to obtain and use all historical numbers, but if they don't produce the right gameplay you'll have to change them anyway. I can see that Simutrans is an outlet for your love of rail history but I suggest drawing a boundary between total historical accuracy and gameplay here
There's also a catch here with the current obsolescence model - we might know now that loco y was manufactured from 1919 to 1936, but did anyone buying the loco in 1924 know what the obsolescence date would be? In practice it didn't matter, since, as explained above, the working life of the loco had little to do with the cessation of manufacture of new ones, but the way the sim is set up the obsolescence date is critical, and historically would not have been known in advance. The same applies to technological advance - we might know now that technology z arrived in 1906 and greatly reduced operating costs of new locos, so in 1903 we might need new locos but hold off on purchasing because we know what's coming up. Would a real-world operator in 1903 have had the same knowledge?

I am reliably informed by somebody who works in transport that there are many things on vehicles (rubber seals are apparently one example) that need maintaining just as much if a vehicle is sitting idle as if it is being used.

True. Now ask them how much those things cost compared to the costs associated with usage (if they work on the shop floor they probably won't know any more than how many hours it sits in the shop, usually only the accountants and managers know the costs). When it's in use it's probably getting a major engine service and a brake system overhaul on the same frequency as the rubber seal replacement. It's not the number of things, it's the cost of them. As I said last post, the dynamic and incentives of the fixed ownership costs are already captured by attaching a cost to money, so maintaining an additional parameter is just extra work.

Would there be merit in adding a credit interest rate to the player's bank account balance, too?

I vote yes. Makes the player think more about the time value of money and stengthens dynamics like the one above.

How much effect do you think that the per hour cost would have in a Simutrans environment? That one would be harder to implement than some of the other suggestions mentioned above, and so would require some careful thought.

I'll answer that with a question. You've seen what congestion can do to $/km - how much effect would it have if operating costs were increased by 25%? Or 50%? Or 100%? This is what will happen to any player who fails to manage congestion adequately. The beauty of it is that it has about zero impact early game, when there's near zero congestion, but kicks in when lines get busier. It's a dynamic that increases in impact with, and in direct opposition to, capital utilisation, so it's a great balancer in a mature game. It's also a really simple mathematical concept (can be explained as being a bit like a taxi meter, which most of us are familiar with) that has powerful and non-linear effects.
I had assumed this would be really easy to compute, as I thought Experimental was already tracking journey times to calculate the revenue for each trip. At the end of each journey (all journeys: loaded, empty, or depot) the journey time is multiplied by the hourly cost of every unit in the convoy, and billed to operating costs. Is it not this simple? Waiting time would ideally be included but it's not critical.

I also notice that you include debt servicing cost, which, in Simutrans, of course, should not be bundled up with the vehicle costs, as a player may well not be in debt at all (indeed, usually is not).

I included it because there are costs associated with money - interest, and opportunity cost - that have a bearing on a player's decision-making. It is not to be included in the cost of the unit, but rather to calculate its life-cycle cost so as to balance the costs between units. If two vehicles cost the same total number of dollars over their lives, but one has higher purchase price in exchange for lower operating costs, then their true life-cycle costs are not the same when the time value of money is taken into account. Real-world purchasing decisions are driven by NPV analyses that consider not just the number of dollars, but when those dollars need to be spent, because deferring expenditure either reduces interest costs or frees up cash to take other profit-making opportunities (the latter being a big issue in the early game, hence one always goes with low purchase prices to maximise the amount of equipment one can buy). If I buy the loco with the higher purchase price, that price needs to reflect the fact that I've forgone interest or opportunity in the present. In practice this means that to be economic, the more expensive loco needs to be cheaper than it would be if the expenditure was calculated without respect for timing. If we build relative pricing without considering this then the lower purchase price, higher operating cost locos will have an unintended cost advantage.
You can explore this dynamic with the comparison spreadsheet:
1. Set the interest rate to zero.
2. Configure vehicles 1 & 2 with identical parameters, except vehicle 2 has lower operating costs. Adjust the purchase price of vehicle 2 so the lifecycle costs come out equal. Copy vehicle 2's parameters to vehicle 3 for reference.
3. Now introduce an interest rate. Both lifecycle costs increase, but vehicle 2's has increased by more. Vehicle 2's purchase price needs to be reduced for the lifecycle costs to come out equal.
So what I'm proposing is that this dynamic is factored into calculating the purchase prices for the pakset. In the spreadsheet purchase price is an input, but what I'm saying is that it is meant to be an output. This spreadsheet was built for demonstration purposes; to price the pakset I would specify the lifecycle unit cost as an input, being roughly the same for all units. Then either purchase or operating cost would be an input, and the other would be the output.
Of course, this is of limited use if vehicles don't have a realistic lifecycle, as they currently don't. In Standard it's infinite, while in Ex it's arbitrary, being the number of years until manufacturing obsolescence rather than the amount of work done until it wears out. The whole idea of balancing purchase and operating costs is dependent on things having a finite operating life, so if this isn't built into the sim in a realistic manner, those parameters won't produce realistic outcomes so there's no need to worry about them too much.

Sounds to me like the speedbonus can capture technological progress pretty well, so that should be enough. As far as I can see it also means that it's not necessary to make later, higher performing units more expensive than earlier ones.

[jamespetts]

I think this is in essence realistic and a nice feature, but wouldn't try to use it as major weapon against a larger network. The definition of "local" to a passenger is usually based on travel time as per the isochrones in one of AEO's links, rather than drawing a circle around one's current location - can't recall whether your "localisation" model is based on distance or travel time.

The local/midrange/long-distance passengers are based on distance, not time, but they all have different ranges of journey time tolerances, so it is, in practice, a mix of both.

A canal, like any other way, only needs to be maintained in usable condition if it is being used. It can silt up all it wants otherwise. If canals had a high fixed maintenance cost regardless of use then they all would have been filled in when the railways came. With most ways there are tasks that need doing even if it's not in use, but their cost is negligible compared with maintaining them in use. For the sim, any cost that is shifted from fixed to variable will help balance the challenges of early and mature gameplay, and importantly provides a simple mechanism to balance them. So if implementing only one way maintenance cost calculation, make it variable. The only role of a fixed cost for way maintenance in the sim is to discourage over-building, and to encourage the player to bulldoze anything they think they no longer need. So the question for implementing fixed maintenance cost is: do we want to force the player to bulldoze every canal/road/rail tile they no longer need? If that's not important, don't bother including a fixed cost.

I think that we really do need to disincentive players from putting unused ways all over the place: placing a way in Simutrans means that other players cannot place a way there themselves, nor can cities build on the land, so the land is a valuable resource. More importantly, however, there is no reason why Simutrans should not simulate the reality that maintaining a way in a state that does not require significant capital investment before it is able to be used again costs money.

There is a difference between costing something to maintain to a usable standard at all (as opposed to letting the way fall into disuse entirely) and the cost varying proportionate to usage, and only the former can apply to canals: it would not be realistic for a player to have to pay twice as much to maintain a canal that has twice as much traffic!

EDIT: sorry, slightly misinterpreted what you wrote. The only way I can see of capturing that cost otherwise is if there's a way of determining which tiles are part of existing lines, and charging fixed maintenance costs to those tiles only.

The easiest way of doing this is simply to record the tonnage as it passes over each way tile and add it up every month, then charge an amount at the end of the month based on the tonnage multiplied by the per tonne cost.

Cute, but sounds really messy and arbitrary, and complicates gameplay, especially for newbies, who have enough to get their heads around as it is. Would be simpler to charge an admin cost on all vehicles/infrastructure, but of course this would be a linear cost in relation to network size.

If one is incorporating such costs into vehicles, one can just use the existing maintenance costs and take into account administrative overhead. Is being linear a good or a bad thing here? I am presuming a bad thing, as we need something to balance exponential profit growth. In a game, "cute" ideas can work sometimes, and, conceptually, it's not too complex or hard to understand.

Granted, but this is much more realistic than no lifespan, and I as a player would find it more acceptable than having to micro-manage replacement decisions. It's also very simple to understand. I'm not talking about replacing them at a certain point of their life-cycle, but at the end of it - their kilometres are up. This is not the same as manufacturing obsolescence, will get to that in a minute.
Good example, and one that strikes at the heart of the early vs mature game issue. Paying for the overhaul after 100,000km, as would happen in the real world, gives the player the opportunity to raise the money to pay for it. to make the vehicle pay for itself. Asking the player to put money aside from Day 1 for an overhaul that's years in the future cripples early gameplay. If the player fails to make the vehicle pay for its overhaul in 100,000km of use, that's the player's fault. We'll get better gameplay if maintenance in year 1 costs, say, 3c/km, and creeps up year on year, after the player's been able to make some money out of the equipment first.
Obsolescence and unit lifecycle are totally different concepts. Think of them completely separately. Obsolescence means the manufacturer no longer makes it (although spare parts usually remain in production for some time), Lifecycle means the period over which something is economic to own and operate. Something that's obsolete may still be fit-for-purpose and economic to use - most of the vehicles you see on land and sea are obsolete. If you have an IT background you may be used to thinking of obsolete as being equivalent to "inadequate and uneconomic", but with transport infrastructure and equipment things don't (can't) change that quickly. Obsolescence usually only impacts on lifecycle when parts become expensive and/or difficult to obtain, which is typically many years or decades after the unit became "obsolete". To say "I can operate a vehicle for peanuts for decades longer than a real one would last, until the manufacturer stops making new ones, then I can't afford to run it" is a long way from reality, and misses an opportunity to challenge mature gameplay with the simple but intuitive concept that "the more I use it, the faster it wears out".

Ahh, a very interesting point indeed. Firstly, however, a clarification: in recent versions of Simutrans-Experimental, the obsolescence increase in maintenance costs starts a certain number of years after the vehicle has stopped being produced: there are defaults for certain types of vehicles (30 for rail, 15 for road, etc.), but these can be set individually in the vehicles' .dat files. These numbers are not revealed to the player in the GUI, although, of course, a player who has played before will remember them, and .dat files are available for inspection in open-source paksets such as Pak128.Britain in any event.

The interesting part is the relative effect on players of increasing the maintenance cost with usage, as opposed to obsolescence. The reason that this was not done (as I had originally planned) was because of the micromanagement issue: anything that either forces players to micromanage or gives them any incentive at all to do so is to be discouraged, even if it gives players an incentive to micromanage but then does not allow them to do so, as this is likely to frustrate players and produce arbitrary results (this is why I am quite strict about not putting in any mechanisms that would give the players any incentive at all to adjust the price charged, for example).

The real question is this, therefore: compared to the present model (when the price will increase with age from a certain point after the vehicle stops being produced, such that the incentive to replace all vehicles of a particular type arises at the same time), is the additional incentive created by increasing maintenance costs later to replace vehicles one by one (which, on a large map, would be a gargantuan task) worth in profit-balancing terms what it costs in incentive to micromanage? I suppose that one way of doing it would simply be to create a concept of an overhaul (which does not require a trip to the depot in the game), a fixed lump sum cost that must be paid by the player every x kilometers that is deduced automatically from that month's maintenance, and where players are given some sort of indication when looking at the convoy that some of the vehicles are coming up for their overhauls. Do you think that that might be a suitable way of doing things?

(Incidentally, on vehicle replacement, have you yet tried Experimental's automatic convoy re placer?)

It's certainly possible, but I don't believe it's desirable. This is a fundamental philosophical issue for historical sims - do you model things as they actually panned out, or as people at the time thought they would pan out? We might know now that loco x built in 1926 was a lemon, it ended up costing its owners three times as much to maintain as its competitor loco y. But did the sucker buying loco x in 1926 know that? Would anyone have bought loco x in hindsight? Would it even have been made? Half the joy of playing historical sims is to make decisions as if one was there at the time, with the information known at the time. If loco x is given parameters that make it uneconomic, because in the real world it turned out to be uneconomic, then one of the game rules becomes "never buy loco x, you'll go broke". Is that desirable?
In practice there was/remains uncertainty in every equipment purchase, uncertainty that's not modelled in Simutrans - you buy something and it performs exactly as the manufacturer said it would.
The goal, as I understand it, is to offer a range of vehicles with performance that's sufficiently differential to make some items more suitable for some purposes than others, but not so differential that some of those vehicles are practically useless (for economic or technical reasons). It also strangles gameplay a bit if there's only ever one choice for any given application; for one we won't get to see the full variety of trains that have been made for the sim. You are trying to obtain and use all historical numbers, but if they don't produce the right gameplay you'll have to change them anyway. I can see that Simutrans is an outlet for your love of rail history but I suggest drawing a boundary between total historical accuracy and gameplay here
There's also a catch here with the current obsolescence model - we might know now that loco y was manufactured from 1919 to 1936, but did anyone buying the loco in 1924 know what the obsolescence date would be? In practice it didn't matter, since, as explained above, the working life of the loco had little to do with the cessation of manufacture of new ones, but the way the sim is set up the obsolescence date is critical, and historically would not have been known in advance. The same applies to technological advance - we might know now that technology z arrived in 1906 and greatly reduced operating costs of new locos, so in 1903 we might need new locos but hold off on purchasing because we know what's coming up. Would a real-world operator in 1903 have had the same knowledge?

Ahh, I think that there may be an element of a false dichotomy here. On the one hand, you suggest that we make all vehicle lifetime costs more or less the same, and on the other, suggest (quite plausibly) that it would not make any sense in a game like this to have "lemons". That is true enough (and we avoid it in Pak128.Britain simply by not producing the graphics, etc. for the "lemons" in the first place). However, there is a difference between having no "lemons" and having all lifetime costs the same. There can still be variation within the "non-lemon" zone, such that, for example, the best vehicle available for a particular task on a particular date might have a significantly higher lifetime cost than other vehicles. Often, only sub-optimal (but still serviceable) vehicles were the only things around for a particular task for a long time, and there is no reason that this should not be simulated; likewise, players with very limited capital might be forced into buying cheaper but otherwise universally sub-optimal vehicles that they certainly would not buy if they could afford the better option; similarly, players in a highly competitive situation might want to buy slightly faster but otherwise sub-optimal vehicles (or ways) in order to get market share in circumstances where they would not otherwise use those vehicles (etc.). All of that is a long way from being a lemon simulator!

True. Now ask them how much those things cost compared to the costs associated with usage (if they work on the shop floor they probably won't know any more than how many hours it sits in the shop, usually only the accountants and managers know the costs). When it's in use it's probably getting a major engine service and a brake system overhaul on the same frequency as the rubber seal replacement. It's not the number of things, it's the cost of them. As I said last post, the dynamic and incentives of the fixed ownership costs are already captured by attaching a cost to money, so maintaining an additional parameter is just extra work.
I vote yes. Makes the player think more about the time value of money and stengthens dynamics like the one above.

Ahh, this chap was definitely not a shop floor chap :-) Senior civil servant working in transport. The fixed costs are significant.

I'll answer that with a question. You've seen what congestion can do to $/km - how much effect would it have if operating costs were increased by 25%? Or 50%? Or 100%? This is what will happen to any player who fails to manage congestion adequately. The beauty of it is that it has about zero impact early game, when there's near zero congestion, but kicks in when lines get busier. It's a dynamic that increases in impact with, and in direct opposition to, capital utilisation, so it's a great balancer in a mature game. It's also a really simple mathematical concept (can be explained as being a bit like a taxi meter, which most of us are familiar with) that has powerful and non-linear effects.
I had assumed this would be really easy to compute, as I thought Experimental was already tracking journey times to calculate the revenue for each trip. At the end of each journey (all journeys: loaded, empty, or depot) the journey time is multiplied by the hourly cost of every unit in the convoy, and billed to operating costs. Is it not this simple? Waiting time would ideally be included but it's not critical.

This is interesting, and will have to be considered carefully. The tricky bit is the interface relating to time, as there are currently two different time scales (one that measures years and months for the purposes of technological change, etc., and also things that happen monthly, and one that measures journey times, waiting times, vehicle movement and speed), and the latter would have to be represented to the player in an accessible way which is not done at present. That might be worthwhile in itself, but it would be quite tricky to do properly.

I included it because there are costs associated with money - interest, and opportunity cost - that have a bearing on a player's decision-making. It is not to be included in the cost of the unit, but rather to calculate its life-cycle cost so as to balance the costs between units. If two vehicles cost the same total number of dollars over their lives, but one has higher purchase price in exchange for lower operating costs, then their true life-cycle costs are not the same when the time value of money is taken into account. Real-world purchasing decisions are driven by NPV analyses that consider not just the number of dollars, but when those dollars need to be spent, because deferring expenditure either reduces interest costs or frees up cash to take other profit-making opportunities (the latter being a big issue in the early game, hence one always goes with low purchase prices to maximise the amount of equipment one can buy). If I buy the loco with the higher purchase price, that price needs to reflect the fact that I've forgone interest or opportunity in the present. In practice this means that to be economic, the more expensive loco needs to be cheaper than it would be if the expenditure was calculated without respect for timing. If we build relative pricing without considering this then the lower purchase price, higher operating cost locos will have an unintended cost advantage.
You can explore this dynamic with the comparison spreadsheet:
1. Set the interest rate to zero.
2. Configure vehicles 1 & 2 with identical parameters, except vehicle 2 has lower operating costs. Adjust the purchase price of vehicle 2 so the lifecycle costs come out equal. Copy vehicle 2's parameters to vehicle 3 for reference.
3. Now introduce an interest rate. Both lifecycle costs increase, but vehicle 2's has increased by more. Vehicle 2's purchase price needs to be reduced for the lifecycle costs to come out equal.
So what I'm proposing is that this dynamic is factored into calculating the purchase prices for the pakset. In the spreadsheet purchase price is an input, but what I'm saying is that it is meant to be an output. This spreadsheet was built for demonstration purposes; to price the pakset I would specify the lifecycle unit cost as an input, being roughly the same for all units. Then either purchase or operating cost would be an input, and the other would be the output.
Of course, this is of limited use if vehicles don't have a realistic lifecycle, as they currently don't. In Standard it's infinite, while in Ex it's arbitrary, being the number of years until manufacturing obsolescence rather than the amount of work done until it wears out. The whole idea of balancing purchase and operating costs is dependent on things having a finite operating life, so if this isn't built into the sim in a realistic manner, those parameters won't produce realistic outcomes so there's no need to worry about them too much.

This is interesting, and merits further consideration when the prices are balanced; but see above in relation to obsolescence, etc.

Sounds to me like the speedbonus can capture technological progress pretty well, so that should be enough. As far as I can see it also means that it's not necessary to make later, higher performing units more expensive than earlier ones.

That's interesting; presumably, though, we do make them more expensive if they were, in real terms, actually more expensive? The speed bonus is, after all, only intended to deal with revenue, not cost.

[inkelyad]

I suppose that one way of doing it would simply be to create a concept of an overhaul (which does not require a trip to the depot in the game), a fixed lump sum cost that must be paid by the player every x kilometers that is deduced automatically from that month's maintenance, and where players are given some sort of indication when looking at the convoy that some of the vehicles are coming up for their overhauls.

I don't understand discussion. Why we need specific point for overhauls? Where is difference with
"Any overhaul/vehicle replacement is done transparent to player. Depreciation/replacement cost is part of running cost. And that is reason simutrans vehicles is running forever."

[moblet]

"Any overhaul/vehicle replacement is done transparent to player. Depreciation/replacement cost is part of running cost. And that is reason simutrans vehicles is running forever."

Where is that from, inkelyad? It is a nice simple assumption but it is unrealistic and distorts gameplay for anyone paying attention to money. If running costs are high enough to cover indefinite replacements then they are artificially high and cripple early gameplay relative to mature gameplay, an imbalance we are trying to address. And, for example, under this assumption, when I retire a vehicle, I should be able to recoup whatever money had been saved for its next replacement.

[moblet]

I think that we really do need to disincentive players from putting unused ways all over the place: placing a way in Simutrans means that other players cannot place a way there themselves, nor can cities build on the land, so the land is a valuable resource. More importantly, however, there is no reason why Simutrans should not simulate the reality that maintaining a way in a state that does not require significant capital investment before it is able to be used again costs money.
There is a difference between costing something to maintain to a usable standard at all (as opposed to letting the way fall into disuse entirely) and the cost varying proportionate to usage, and only the former can apply to canals: it would not be realistic for a player to have to pay twice as much to maintain a canal that has twice as much traffic!
The easiest way of doing this is simply to record the tonnage as it passes over each way tile and add it up every month, then charge an amount at the end of the month based on the tonnage multiplied by the per tonne cost.

This all sounds really good to me. The mechanism is already there for fixed costs, so if a tonnage-based mechanism was added then there is scope to apply any combination thereof to a way. Are you saying that canals need to carry a fixed cost regardless of usage for the gameplay reason of preventing them being used as weapons? If so, and we therefore need to bulldoze canals we don't use, can we have a button to restore the stream/river that may have been there originally, so we don't end up with a map full of dry valleys? Alternatively there could be no fixed maintenance charged against canal tiles that (1) carried no tonnage and (2) were originally waterways. If the sim can identify all canal tiles with tonnage > 0 then it can easily work on a basis of applying full fixed costs to used canal tiles and no fixed costs to unused ones.

If one is incorporating such costs into vehicles, one can just use the existing maintenance costs and take into account administrative overhead. Is being linear a good or a bad thing here? I am presuming a bad thing, as we need something to balance exponential profit growth. In a game, "cute" ideas can work sometimes, and, conceptually, it's not too complex or hard to understand.

Linear with respect to revenue is neutral I think, linear with respect to operating/maintenance costs hurts when loads are light (e.g. early game), linear with respect to capital hurts early on with low capital utilisation. The headquarters concept could be used as a non-linear tool against mature play, e.g. you don't need an HQ in the early game and carry no overhead (your office can be at the back of a depot as it would be in a real-world small operation) but to cross certain thresholds you need to build/upgrade your HQ, and it incurs admin overhead in proportion to other costs. Couldn't legitimately have a big non-linear influence, though, so I wouldn't consider it a priority for balancing early vs mature gameplay.

The real question is this, therefore: compared to the present model is the additional incentive created by increasing maintenance costs later to replace vehicles one by one (which, on a large map, would be a gargantuan task) worth in profit-balancing terms what it costs in incentive to micromanage?

It's unavoidable it if we want purchasing vs operating costs to mean anything, and it's helpful to burdening mature game performance in a fair, realistic and meaningful way (I think the obsolescence model could distort equipment choices). The reason this seems like such a problem is because replacing vehicles in Simutrans demands intense micro-management and significant network disruption, for which there seems to me to be a simple solution. I'm used to Railroad Tycoon 3 where I can click on a loco, click the replacement button, up comes a list of available locos, I select one, my account is debited and the loco is replaced without interrupting the train's journey. A process like this would not be too onerous for the player. At the end of each month a dialog for each expired unit could pop up and the user could decide to scrap or replace each in turn (note that not every unit in a convoy will expire at the same time, e.g. carriages last longer than locos). Ex's automatic convoy replacer is halfway there, it just doesn't replace in-situ. I guess if it's necessary for a convoy to return to depot to replace any unit therein, so be it, but I think it would be too disruptive under a lifecycle replacement scenario. In-situ replacement is equivalent to what you're describing as an in-situ overhaul but with the difference that the player could replace the unit with a purchase of anything currently available. Always limiting it to an identical replacement wouldn't work anyway because the original unit might be obsolete.
I would consider this the maximum tolerable level of micromanagement of replacements, which is why I propose a fixed lifespan instead of just ramping up maintenance costs and asking the player to monitor the maintenance cost of every vehicle (or vehicle type) and make a judgement on replacement, which sounds migraine-inducing to me (and I don't get migraines!).

...and where players are given some sort of indication when looking at the convoy that some of the vehicles are coming up for their overhauls

I mentioned this a couple of posts ago. The sim would have to be able to filter units by their % life remaining, and also project their expiry dates. If we apply the same concept to way (road and rail also needs complete replacement, and again, this would provide for lowering maintenance costs in early game and then hitting up the player for replacement in mature game) then colour-coded mapping would be needed too, I'd say. Colour-coding units that were close to death might be fun, too, and make it easier to recognise opportunities to replace aging units with idle ones in depots and get the replacement unit in place before the old one dies.

On the one hand, you suggest that we make all vehicle lifetime costs more or less the same, and on the other, suggest that it would not make any sense in a game like this to have "lemons".

I thought both those points were on the same hand!

the best vehicle available for a particular task on a particular date might have a significantly higher lifetime cost than other vehicles

I agree, and would articulate that as that the vehicle is the best for the task because it generates the highest profit. So it costs more to own and run, but it is so much better at that task than anything else that the revenue premium it can earn outweighs this extra cost. Hold that thought.

Often, only sub-optimal (but still serviceable) vehicles were the only things around for a particular task for a long time, and there is no reason that this should not be simulated; likewise, players with very limited capital might be forced into buying cheaper but otherwise universally sub-optimal vehicles that they certainly would not buy if they could afford the better option; similarly, players in a highly competitive situation might want to buy slightly faster but otherwise sub-optimal vehicles (or ways) in order to get market share in circumstances where they would not otherwise use those vehicles

All good, and that can be accommodated. What I'm proposing is a process for arriving at all of this in a controlled, deliberate fashion that's as simple as possible. You've been grappling with the whole problem of relative costing, which is a big ugly beast, so big and ugly that I wouldn't try to slay it in a single blow. For this task I think it will be far easier to work relative to a benchmark than to try to work up every unit's numbers from scratch, not least because the unit's relative performance in the game will be a function of its costs relative to other units. I'd start simply and add complexity thus:
1. Set a benchmark (average?) lifecycle cost for each type of vehicle. Beast has been sighted.
2. Tune each vehicle's purchase and operating costs to match the benchmark (what the spreadsheet is a step towards). Beast has been tied up.
3. Some vehicles exhibit average performance and are happy being average, they're now done. Vehicles with particular characteristics can now have their parameters tweaked either side of the benchmark according to historical accuracy and/or gameplay considerations. Beast is slain.

The fixed costs are significant.

If they're significant, then chuck them in. I wouldn't rush to do so though because these costs are biased against early gameplay. Fixed ownership costs get spread across utilisation, the lower the utilisation, the higher the fixed cost per hour/km.

The tricky bit is the interface relating to time, as there are currently two different time scales (one that measures years and months for the purposes of technological change, etc., and also things that happen monthly, and one that measures journey times, waiting times, vehicle movement and speed), and the latter would have to be represented to the player in an accessible way which is not done at present. That might be worthwhile in itself, but it would be quite tricky to do properly.

It would certainly be nice to show any of this performance info to the player, I guess it would have to be on a line-by-line basis, but not necessary before implementing the dynamic in the game. For now the player just needs to know that time is money, any delay to a convoy will increase the cost of its trip, and large scale gridlock will result in bankruptcy (as it should!).

That's interesting; presumably, though, we do make them more expensive if they were, in real terms, actually more expensive? The speed bonus is, after all, only intended to deal with revenue, not cost.

Profit is the outcome that matters, and since that equals revenue minus cost, it doesn't matter whether it's cost or revenue that gets manipulated. The erosion of revenue at the same level of performance means the player has to run to stand still, which is realistic. If they were more expensive in real terms then yes, they should be made more expensive, especially if they're on offer contemporaneously with older units.

[inkelyad]

If running costs are high enough to cover indefinite replacements then they are artificially high and cripple early gameplay relative to mature gameplay, an imbalance we are trying to address.

Then running cost must be S-Shaped (like this)

And, for example, under this assumption, when I retire a vehicle, I should be able to recoup whatever money had been saved for its next replacement.

Retired vehicle is sold,right? And at the same cost as you buy it. So you will get money back.

[sdog]

On fixed vs variable, time vs distance costs, what is the fixed monthly cost intended to capture? In the real world it would cover ownership costs such as financing, insurance, and spare parts inventory, but would not cover most maintenance cost, which is a function of usage. Nor would it cover operator costs, since these aren't incurred when the vehicle is idle. The only incentive it provides in the game is to discourage players from holding on to vehicles they don't need, but the introduction of interest rates provides this incentive anyway, so I'd question the value of having a fixed monthly cost at all.

I quite don't understand why you consider fixed monthly costs for a vehicle useless, but want a time based cost for vehicles.

It's almost the same just one is incremental the other not. Also wouldn't the fixed monthly cost cover the real time based costs (that would be mostly wages for operators and maintenance crews) reflect reality much better than an incremental cost?

The other argument for monthly costs is, it doesn't matter if the convoy is the whole time in a traffic congestion and would need no maintenance, you have to pay the maintenance crew still, even when they were playing cards for a month.

So fixed monthly costs would cover wages while km based costs the fuel consumption and wear by using the convoy.

I suppose that one way of doing it would simply be to create a concept of an overhaul (which does not require a trip to the depot in the game), a fixed lump sum cost that must be paid by the player every x kilometers that is deduced automatically from that month's maintenance, and where players are given some sort of indication when looking at the convoy that some of the vehicles are coming up for their overhauls.

This has a bit of arbitrariness, since it will suddenly come up and cause immense costs. In real life i could just postpone this replacement for a month or a year if the company is in a tight situation. With the automated cost it could just hit the player out of the blue. And it can be quite expensive early on, when for example at one point all of the convoys bought in the first year incur this cost at almost the same time. If it is based on the odometer they will only have minor differences depending on the km between stops and congestion. (which is likely low at the beginning)

addition i think inkleyads sigmoid function could work quite nicely.

The easiest way of doing this is simply to record the tonnage as it passes over each way tile and add it up every month, then charge an amount at the end of the month based on the tonnage multiplied by the per tonne cost.

It's not completely clear, i understand you right that you want to save the value for each convoy, not for each way tile? When you wrote tonnage did you mean the maximum tonnage of the way?

We need functions to base those costs differently for different ways. For roads the damage done is not a linear relationship with the weight. I just have the typical numbers from the news that one 40t lorry causes as much damage as 1000 (other source 10000) cars. A brief googleing didn't get me any substantial information.

One possible way would be to use linear costs but have max weight based limit below which it will not incur extra costs. This would require a conditional check for every tile, and ifs are slow.

I have no real idea of wear of rails. Inclines have increase wear through sanding. Wear on rails comes mostly from milling [grinding?] them. Old goods trains and extremely old passenger trains without disc brakes modulate the surface that require this milling. Usually the ballast has to be replaced the most offen, and this shouldn't depend on track utilisation. What's with points? Trains also remove the corrosion products from the tracks, will this increase corrosion compared to a dormant track? (i doubt it, for steel, would be different for aluminum)
Does high track utilization influence track maintenance costs significantly, when trains stay below the weight limit?

Perhaps it would be sensible to introduce this system only for lorries above a certain weight limit.

ps.: james, moblet, inkelyad, would it be sensible to bifurcate this up into different threads, since we have some diverging sets of problems here?

[moblet]

Then running cost must be S-Shaped (like this)

Or simply linear, just so long as it increases with age. Linear would be easier for the player to visualise when managing their fleets. But it would be very messy to expect the player to manage the maintenance cost of dozens or hundreds of units over time and make replacement decisions, so introducing a lifespan (in km) for each vehicle would serve as a proxy for that. Either way we force players in mature games to replace worn equipment, which helps to contain profits and is 100% realistic.

Retired vehicle is sold,right? And at the same cost as you buy it. So you will get money back.

I forgot about the resale thing. Resale value is a bit less than purchase cost, but near enough. The resale value should decline as the vehicle wears. At the end of its life it has only scrap value.

[sdog]

Or simply linear, just so long as it increases with age. Linear would be easier for the player to visualise when managing their fleets.

Linear would again be a burden at the early game. Inkleyads function is also quite what a player would expect, and should be used for example from japanese cars.

Are you sure this replacement problem does really apply to rugged industrial transport, like trains etc? It seems that steam engines can be maintained almost infinitely by a decently skilled railway shop. Same holds for quite a lot of robust street vehicles. (Toronto TTC operates a large fleet of buses from the 60s. Military planes have airframes in use for over 60 years. Some Kukuruznik (eg. An-2 been flying more than 50 years. So the maintenance cost increae would perhaps reflect real behaviour better than assuming complete breakdown after reaching a maximum lifespan.

[moblet]

I quite don't understand why you consider fixed monthly costs for a vehicle useless, but want a time based cost for vehicles.

Well put. If we used one or the other, the monthly vs hourly based costs would only be different for a vehicle that wasn't utilised for 100% of the month, which shouldn't be the case for 90+% of the vehicles that the player owns. I have been getting confused on this between the sim (where every hour is peak hour) and the real world (where demand varies over 24 hours and 7 days and urban public transport vehicles spend half their time idle in depot). Given that Simutrans vehicles in service run 24/7 and that the monthly fixed cost feature is already built into the sim, then this monthly cost feature should serve adequately to capture the time-based running costs that would have to be measured hourly for many real vehicles. It should also penalise congestion in the required fashion, making this whole hourly cost thing redundant. We can put the operator costs into the monthly fixed cost. James, have you done any trialling of numbers for the monthly fixed cost?

This has a bit of arbitrariness, since it will suddenly come up and cause immense costs. In real life i could just postpone this replacement for a month or a year if the company is in a tight situation. With the automated cost it could just hit the player out of the blue. And it can be quite expensive early on, when for example at one point all of the convoys bought in the first year incur this cost at almost the same time. If it is based on the odometer they will only have minor differences depending on the km between stops and congestion.

I don't think it will be this bad, since:
1. Everything will last many years. By the time your first bus expires after, say, 15 years, you should either be well able to afford it, or long gone bankrupt.
2. You should be able to see it coming and plan for it, and also to take out an overdraft if need be.
3. Even if every vehicle travelled the same distance, it won't be "all of the convoys in the first year" expiring at once. It would be "all the buses with the same lifespan", or "all the locos with the same lifespan" (the carriages & wagons would have different lifespans). The replacements of the first year purchases would be scattered from about year 10 to perhaps year 50.
If it did turn out to be a problem - perhaps we could make it a problem by increasing the purchase prices, which may need to be done anyway - then one workaround would be a "defer" button on the expiry dialog that buys another year of operation for a high maintenance cost.

Are you sure this replacement problem does really apply to rugged industrial transport, like trains etc?

Anything can be kept going, but at what cost? We could still run 1910 buses in 2010 if we really wanted to, but we don't. It's a question of whether it is economic to keep something running. Rail carriages and wagons can easily remain worth keeping for 50 years, and I would set the pak's parameters accordingly. A few DC-3's are still in commercial use last I heard, the question for the sim is how to handle the aging of equipment such that it costs the player in a mature game, either in higher maintenance costs or the need to purchase replacements, without turning the game into a nightmare of micromanagement. In my opinion anything more complicated than specifying an economic life will require excessive micromanagement, but that's just my opinion. Perhaps there could also be a "defer indefinitely" button for those who really want to keep running their DC-3's until 2010

It's not completely clear, i understand you right that you want to save the value for each convoy, not for each way tile? When you wrote tonnage did you mean the maximum tonnage of the way?

Total tonnage actually carried over each tile of the way. Variable maintenance expense then charged to each tile accordingly.

We need functions to base those costs differently for different ways.

I'm not sure we need to get into that level of detail. At the moment there is no wear-based way maintenance at all, we just need something sensible. Linear, and same for every piece of road/rail of the same type, is easy to program and easy for the player to visualise even if it's not 100% faithful. But to address a couple of your questions:
- Real world rail wear is also higher on curves. The grinding is necessary to even out the wear that has occurred. Not sure of much else.
- I believe road damage is fundamentally a function of axle loading and speed, along with things like the type of suspension of the vehicle. I think here in Australia you can increase your axle loads if you have air suspension, for example. In Simutrans most of the motorised road vehicles are medium or heavy vehicles so we're not comparing cars with lorries, we're comparing lorries with lorries. The city cars can be ignored, of course. I presume that horses can dislodge cobblestones, too.

Linear would again be a burden at the early game.

Don't forget that what we have now is a flat line. Linear would make a significant difference for the first half of the unit's life, which is going to be the first five years of the game minimum. That should be good enough to deliver the game dynamics that we want, without imposing too much complexity, but hey, it's the programmers' call! Remember too that any function that increases steeply at end of life has the potential to spring on the player the sudden changes in costs that you've expressed concerns about, and it will occur immediately before they require the capital to fund the replacement. If it was me programming I'd start with a linear curve, because it's simplest and I'd expect it to work fine, and see how it goes.

[inkelyad]

But it would be very messy to expect the player to manage the maintenance cost of dozens or hundreds of units over time and make replacement decisions, so introducing a lifespan (in km) for each vehicle would serve as a proxy for that.

I very much doubt sgod want to answer "vehicle should be replaced" for every convoy on his map. There is no decision until better model is available.
And S-shaped running cost will fix early gameplay problem.

Resale value is a bit less than purchase cost, but near enough. The resale value should decline as the vehicle wears. At the end of its life it has only scrap value.

Think like that: vehicle depreciation fund(sorry, don't know right English terminology) + current vehicle cost= vehicle original cost. So when player sell vehicle, he get money from depreciation fund too.

ps.: james, moblet, inkelyad, would it be sensible to bifurcate this up into different threads, since we have some diverging sets of problems here?

I agree, topic should be splitted.

[neroden]

In the real world one of the basic corporate measures - and one that's relevant to Simutrans - is return on investment (ROI), but this is not even reported to a Simutrains player. The only way this can be simulated otherwise to finely balance all the prices so that the player goes broke if their ROI is uncompetitive, which is how I would describe what you're trying to do here.

On the contrary....
...if we had a proper borrowing model, we could track ROI pretty carefully, without requiring the player to go broke if he makes uncompetitive choices.  The initial 'free' capital provides a cushion against poor ROI, while any future 'borrowed' money requires a higher ROI to pay back the interest costs.  I routinely check the monthly profit of my vehicles and divide by the initial capital costs I spent on them-plus-track....

I still think we aren't actually ready to balance the pricing yet, however.  Balancing of vehicle power/weight/speed is still not finished, and balancing of industry production vs. appropriate number of vehicles to handle the supply is just clicking into place now.  I don't think goods prices are balanced against each other either, and that would be the next step.  In the balancing models I've come up with, getting reasonable values for depot, station, track, and road maintenance comes next, and those are still way off.... anyone got a source for prices for such things?

...and by the way, James, you need to make bridge maintenance proportional to the pak scale, because *elevated rail* maintenance is proportional, and at the moment that means bridges are never usable at 4 tiles to the km, because elevateds are always cheaper.  I realize the other decision was made earlier, but that was before elevated track existed.  With elevated track in existence, you *have* to keep the el/bridge prices appropriately proportional to each other.

In response to something Inky said, rail wear is proportional to the fourth power of axle load to a first approximation.  If that's any help.  :-)  The same is true of road surface wear.  In simutrans this would need to be figured into *vehicle* running costs.  The "fixed component" of wear, with no trains or cars running -- damage due to weather etc. -- is relatively low, though eventually asphalt will be cracked by plant growth and rail sleepers will rot.  (Canals will fill in and must be dredged repeatedly).  I really don't know where to look up these "with no vehicle" maintenance costs.  They vary a lot by climate (I guess in pak128.britain you only have the one climate, which should help.)

[moblet]

I still think we aren't actually ready to balance the pricing yet, however.  Balancing of vehicle power/weight/speed is still not finished, and balancing of industry production vs. appropriate number of vehicles to handle the supply is just clicking into place now.  I don't think goods prices are balanced against each other either, and that would be the next step.  In the balancing models I've come up with, getting reasonable values for depot, station, track, and road maintenance comes next, and those are still way off.... anyone got a source for prices for such things?

As mentioned in another thread, real-world numbers aren't hard to come by, the issue will be how to use them. As the sim doesn't mimic every real world dynamic I, like prissi, would not expect great results from blindly plugging in real world numbers. Are there spreadsheets in use to collate and tune the parameters? If not I can build. Seems to me the way to go as then it's relatively easy to shift some or all parameter sets to balance the game, and also to see how the parameter values are constructed. Would also facilitate exploring different balancing philosophies.

Many sources (e.g. here and here) can help us pin down the fixed vs variable component of way maintenance. I've plotted the rail numbers in an attached spreadsheet to get an equation for fixed vs variable. Meanwhile the British roads link suggests a reasonable assumption of road maintenance being about half fixed, half variable, and costing 1.5%pa of the road's capital value (obviously for a mature road system, not one built yesterday). So much for the real world - if, for example, we want to weight the game to ease early and burden mature gameplay, we might find we're better off assuming something different.

One approach to balancing could be to set costs in relation to passenger fares and freight rates such that the player needs to achieve minimum loading factors to make an operating profit, and for these break-even loading factors to be as constant as possible from 1750 to 2050. Is there documentation lying around somewhere of how passenger and freight revenue is calculated in the sim?

[sdog]

we want to weight the game to ease early and burden mature gameplay, we might find we're better off assuming something different.

Would using a high maintenace cost in comparison to the construction cost be very dishonest when we know better? Since this would be an arbritrary burden, instead of a real one. If doing so one could as well use an arbitrary malus for large income. (Some empire building games have it as 'corruption')


You were also talking about capital cost. Wouldn't the investors of the initial investment demand some share of the profits? They might for a while reinvest all of their profit, but at some point there should be some drain of liquidity. (Railroad Tycoon had a dividend)

[jamespetts]

Dear goodness, this is a long and involved discussion! The first thing to pick out are those possible changes to the Simutrans-Experimental code and work out precisely what those code changes need to be if the model is to be implemented properly. The three areas that seem to have arisen from this discussion so far are:

• time based pricing
• weight based wear on ways; and
• non-amortised vehicle overhaul costs.

Time based pricing

This is the simplest. As SDog points out (and as I had rather daftly overlooked in previous posts), this is the same thing as the per month pricing already implemented. I think that somebody making this point about utilisation might have been the driver to implement this idea in the first place, if I recall correctly. The only place where it deviates from being able to use this as a labour cost only model is in charging the same monthly maintenance cost while in a depot. It would be quite easy, however, simply to remove the code that charged monthly maintenance cost to vehicles in a depot. Is this advisable, do people think?

Weight based wear on ways

The suggestion has been made that this could be built into vehicle maintenance costs, but I'm not sure that that would work very well: not only would it greatly complicate the process of computing vehicle maintenance costs, it would also have no differentiation between the per tonne cost of the ways that they use: way based maintenance costs should vary by way, not by vehicle. There is much to be said for maintaining a conceptual distinction here. It would be quite easy to code this, and quite transparent to the player.

Non-amortised vehicle overhaul costs

Hitherto, the idea of vehicle maintenance and wear has always been strictly amortised with the per kilometre cost of the vehicle; it had not been considered, I suppose, before the discussions on this thread that amortising the vehicle wear costs in this way can make it difficult or impossible to balance the game properly.

This is perhaps the one that requires the greatest thought, as there are quite a few very different suggestions here. I think that we need to reject anything that involves bombarding players with dialogue boxes that need immediate responses at the end of a month: in a large network, that sort of repetitive responding would be unbearably tiresome (imagine, for a moment, a map with many thousands of vehicles; there would be dozens of boxes to which to respond every single month). Suddenly presenting a player with an important decision that needs to be made immediately is very distracting and requires a high degree of mental context-switching which is arduous. This is the sort of micro-management that we need to avoid.

Connected to the micro-management issue is a need to avoid this mechanism requiring vehicles to have to go to a depot when their mileage has expired, as this can be a somewhat lengthy and disruptive process (especially to happen without player intervention).

What we probably also need to avoid is a player being stung suddenly by a large replacement/overhaul cost for a vehicle (or, worse, large set of vehicles) without having a decent chance to control things, as that would be frustrating and potentially arbitrary. If a player was just about to start replacing vehicles on a particular line, and was then charged a vast amount of money to replace/overhaul the existing vehicles on that line (perhaps such that the new fleet could not now be afforded), that would also be very frustrating for a player.

Finally, we need to avoid a solution that is obviously distant from reality, which rules out the original version of the simplified idea suggested by Moblet in which players must replace vehicles over a certain mileage with new vehicles entirely when, in reality, vehicles could continue to be used if enough was invested in their maintenance. Linked with this, there is something psychologically satisfying about there being some continuity of identity in the assets in which one has chosen to invest, which means that forcing a player to give up that identity at a certain point is potentially frustrating.

Might I suggest the following instead, which is in many respects functionally equivalent to Moblet's original simplified idea, but with a few refinements to make it work better in the Simutrans context. Every vehicle would have a "kilometres between overhaul" value specifiable in their .dat files. In the absence of specifying such a value, a default value based on the type of vehicle (boat, train, 'bus, tram, etc.) would be specified. This value would be visible to players when buying vehicles in a depot. Likewise, each vehicle would have an overhaul cost, specifiable in the .dat files, and again, in default of that, a value set as a fixed proportion of the purchase price (perhaps one quarter or one fifth). After the vehicle has travelled the specified number of kilometres between overhauls, the player would be charged the specified overhaul price, and the counter to the next overhaul would be reset. The date of the last overhaul would be stored and shown to players looking at the convoy detail window. Players would also be able to see the number of kilometres until the next overhaul in the convoy detail window.

This system would be in addition to, rather than instead of, the existing system of vehicle obsolescence. Indeed, the overhaul costs would increase by the same measure as the general maintenance cost for obsolete vehicles.

To give players more control over whether to overhaul or replace vehicles, players should be allowed to set convoys to "withdraw instead of overhaul", which would, instead of charging players an overhaul price when their kilometres had expired, send them to the nearest depot. There, they could be kept or sold. If a player were to cancel the order sending the vehicle to a depot or re-start the vehicle from the depot, the full overhaul price would then be charged, but the player would effectively get free (at least of the cost of overhaul) the additional kilometres necessary to send the convoy to the depot and empty its load first. Likewise, using the replace dialogue, a player should be able to set the additional option of "replace instead of overhaul", which would, instead of charging the player the overhaul cost, send the convoy to be replaced when its next overhaul is due. The overhaul charge would then not be applied unless the player cancelled the replacing command, or used in the replaced convoy any vehicles that had expired their overhaul limit (some careful thought would be needed on how to handle a situation where there are vehicles in need of an overhaul already in the convoy and vehicles in the depot to which the convoy is sent by the replace function of identical type that are not coming up for overhaul).

The idea of overhauling, rather than replacing, vehicles is more consistent with maintaining their identity and also fits well with reality, where vehicles very often are required to be overhauled after running certain fixed distances. Further, to this overhaul system could be added a "cute" idea that would not influence the economics of things at all, but is related to a feature that has been requested here in relation to vehicle liveries: the code could be changed so that, if the relevant images were specified in a vehicle's .dat file, vehicles of the type (1) built; or (2) overhauled after a date or date specified in the .dat file would have a different appearance to those built or overhauled earlier. Any number of date points and matching graphics could be specified in the .dat file. This would allow simulation of later type liveries on the same vehicles (which historically were often applied at the same time as a vehicle was overhauled), and would have the pleasing side-effect of showing visually the relative age of certain elements of the fleet.

I should be interested in feedback on the various matters discussed in relation to the overhaul costs, which is the one element of the three that needs the most consideration. Of course, if this were implemented, this would be two additional significant parameters for every vehicle that would need researching and implementing. Any ideas, anyone, on where to start with that?

Other matters

I still think we aren't actually ready to balance the pricing yet, however.  Balancing of vehicle power/weight/speed is still not finished, and balancing of industry production vs. appropriate number of vehicles to handle the supply is just clicking into place now.  I don't think goods prices are balanced against each other either, and that would be the next step.  In the balancing models I've come up with, getting reasonable values for depot, station, track, and road maintenance comes next, and those are still way off.... anyone got a source for prices for such things?

We do indeed need to balance all of these things, too: the next element of balancing vehicle power/weight/speed is in relation to steam railway locomotives, although some work needs to be done on boats as well, I understand. Balancing goods prices against each other is a more tricky affair (any thoughts, anyone, on how to go about doing that in as realistic a manner as possible?), and we certainly need to balance infrastructure costs as part of the general exercise.

One of the next things that I'll be doing with the pakset is changing industry production/consumption rates as suggested by, if I recall correctly, AvG so as greatly to reduce the production and consumption rates of farms and shops, and concomitantly increase their relative frequency so as both to match reality more closely and to allow for more interesting distribution networks.

Linear with respect to revenue is neutral I think, linear with respect to operating/maintenance costs hurts when loads are light (e.g. early game), linear with respect to capital hurts early on with low capital utilisation. The headquarters concept could be used as a non-linear tool against mature play, e.g. you don't need an HQ in the early game and carry no overhead (your office can be at the back of a depot as it would be in a real-world small operation) but to cross certain thresholds you need to build/upgrade your HQ, and it incurs admin overhead in proportion to other costs. Couldn't legitimately have a big non-linear influence, though, so I wouldn't consider it a priority for balancing early vs mature gameplay.

We can perhaps put this aside for the time being, but bear it in mind for the future.

All good, and that can be accommodated. What I'm proposing is a process for arriving at all of this in a controlled, deliberate fashion that's as simple as possible. You've been grappling with the whole problem of relative costing, which is a big ugly beast, so big and ugly that I wouldn't try to slay it in a single blow. For this task I think it will be far easier to work relative to a benchmark than to try to work up every unit's numbers from scratch, not least because the unit's relative performance in the game will be a function of its costs relative to other units. I'd start simply and add complexity thus:
1. Set a benchmark (average?) lifecycle cost for each type of vehicle. Beast has been sighted.
2. Tune each vehicle's purchase and operating costs to match the benchmark (what the spreadsheet is a step towards). Beast has been tied up.
3. Some vehicles exhibit average performance and are happy being average, they're now done. Vehicles with particular characteristics can now have their parameters tweaked either side of the benchmark according to historical accuracy and/or gameplay considerations. Beast is slain.

This seems like a sensible approach: that makes sense now.

Profit is the outcome that matters, and since that equals revenue minus cost, it doesn't matter whether it's cost or revenue that gets manipulated. The erosion of revenue at the same level of performance means the player has to run to stand still, which is realistic. If they were more expensive in real terms then yes, they should be made more expensive, especially if they're on offer contemporaneously with older units.

I think that we do need to distinguish properly between revenue and cost in the game so that we can make as much use of real-world figures for these things without adjustment. If we start accounting for cost as relatively negative revenue, then it will distort any attempt that we make to make use of real-world information about relative revenues. It is always much easier in the long-run to make the mechanism of the simulation as much like the mechanism of the simulated as possible, even if there is a short-cut that seems at first blush to produce the same outcome. This principle applies to many parts of this discussion (such as the suggestion above of making weight related way costs part of the vehicle running costs): the simplest way to balance a simulation of reality is to make it as much like reality as possible, then get the actual figures from reality. Even if one has to make adjustments thereafter, a very significant part of the work is already done by real life.

It's not completely clear, i understand you right that you want to save the value for each convoy, not for each way tile? When you wrote tonnage did you mean the maximum tonnage of the way?

We need functions to base those costs differently for different ways. For roads the damage done is not a linear relationship with the weight. I just have the typical numbers from the news that one 40t lorry causes as much damage as 1000 (other source 10000) cars. A brief googleing didn't get me any substantial information.

One possible way would be to use linear costs but have max weight based limit below which it will not incur extra costs. This would require a conditional check for every tile, and ifs are slow.

I have no real idea of wear of rails. Inclines have increase wear through sanding. Wear on rails comes mostly from milling [grinding?] them. Old goods trains and extremely old passenger trains without disc brakes modulate the surface that require this milling. Usually the ballast has to be replaced the most offen, and this shouldn't depend on track utilisation. What's with points? Trains also remove the corrosion products from the tracks, will this increase corrosion compared to a dormant track? (i doubt it, for steel, would be different for aluminum)
Does high track utilization influence track maintenance costs significantly, when trains stay below the weight limit?

Perhaps it would be sensible to introduce this system only for lorries above a certain weight limit

This is interesting, and leads to some additional complication. It would be very difficult to represent this to the player; a simple charge per ton would be closer to reality than what we have at present, and would additionally work effectively to compensate for the profit growth drivers described by Moblet. It may be a sensible compromise in the circumstances, especially if private cars (which we assume to be very light) are not counted, and so some element of differentiation is included.

...if we had a proper borrowing model, we could track ROI pretty carefully, without requiring the player to go broke if he makes uncompetitive choices.  The initial 'free' capital provides a cushion against poor ROI, while any future 'borrowed' money requires a higher ROI to pay back the interest costs.  I routinely check the monthly profit of my vehicles and divide by the initial capital costs I spent on them-plus-track....

Do you have any suggestions about what sort of borrowing model would be best here? I don't really want to introduce anything as complicated as the stock market, but there might be something to be said for fixed term loans.

[The Hood]

I like the ideas regarding overhauling - in fact I was going to suggest something similar.  I would also suggest that subsequent overhauls become ever more expensive otherwise you could still feasibly have steam puffing away in the year 2000.

My idea about liveries was entirely unconnected though - it would be mere eye-candy.  Think about the current British network - lots of vehicles get a repaint (or at least a new vinyl wrap) every 5 years or so because of changing franchises and corporate identities!  I was thinking of a drop down menu to choose (free of charge) which colours to have your vehicle in, and would be especially nice for those who want to recreate historically accurate scenarios (model railway style).  Also I don't think an overhall necessarily dictates a change in appearance anyway (where as a change of livery does).

[jamespetts]

I like the ideas regarding overhauling - in fact I was going to suggest something similar.  I would also suggest that subsequent overhauls become ever more expensive otherwise you could still feasibly have steam puffing away in the year 2000.

Isn't this covered by making overhauls more expensive for obsolete vehicles?

My idea about liveries was entirely unconnected though - it would be mere eye-candy.  Think about the current British network - lots of vehicles get a repaint (or at least a new vinyl wrap) every 5 years or so because of changing franchises and corporate identities!  I was thinking of a drop down menu to choose (free of charge) which colours to have your vehicle in, and would be especially nice for those who want to recreate historically accurate scenarios (model railway style).  Also I don't think an overhall necessarily dictates a change in appearance anyway (where as a change of livery does).

Ahh, I had wanted the liveries to reflect something about the in-game world, rather than to be completely arbitrary, and date of build or last overhaul is a useful thing to reflect. Besides, this would require no new GUI and thus be easier to program.

[sdog]

First a general remark, i do not concur with the notion* that linear relationships are per se easier to understand to players than non linear. This is especially true if the linear behaviour is contrary to people daily experience. (example maintenance of a car.) The actual relationship doesn't even have to be displayed in the game, as in reality it isn't transparent either, without research. A CEO or a car owner can dig up some statistitcs, papers or hire Moblet to find it out, the player can dig in the source code or read the documentation.

Weight based wear

Neroden posted above, the damage is in first approximation proportional to the fourth power of axle load.* This makes it fairly easy to get good results. (Does it open our year old debate about axle loads and total weight again?)

 Calculate (or define in .dat) this a**4 for every vehicle. Sum it for all vehicles in a convoy. Multiply for every tile the convoy enters with a way-type based maintenance factor. Cumulate all tiles passed.

The value is collected for each convoy, but this doesn't mean it has to be displayed in the convoy window. It would quite make sense though, as if you have excessive wear due to heavy convoys you could see immediately what vehicles are the culprits, and perhaps replace them. (A nice effect thereof is also that the fast and heavy express trains will have another cost factor, they are gold-coin-defecating donkeys at the moment)
Alternatively you could display the sum over all convoys in the budget dialogue.

What you can't get with this approach is a cost display for every tile. Such a thing would hardly be useful however, since the information one can get from clicking on a road tile is limited to this tile. Just looking at a stretch of road and watching the vehicles crossing it would be much easier.

A secondary advantage you have with this method is, that convoys from competition automatically incur the cost at the competition, not the player owning the road. This should make integration with standard when money is transfered for way usage.


Non-amortised vehicle overhaul costs
James your plan seems quite good.

I'll still post an idea for this i was thinking of last night.
Starting point for this thought is this quote by Moblet:

I'm a bit surprised that there isn't an option, when clicking on a vehicle, to instantly replace it without interrupting its work - is there a reason why not?

Firstly introduce a maintenance cost increase as a sigmoid function of distance travelled. Second highlight vehicles in the high cost part of this function. Add an option to your Vehicle replacer to replace all vehicles that are past their service life -- and importantly do all vehicle replacing instantly, without the tedious way to the depots! (i hardly ever use it because of this) The travel time of the passengers can be set to high values to eliminate them, and incur a refund.

Capital Cost

Do you have any suggestions about what sort of borrowing model would be best here? I don't really want to introduce anything as complicated as the stock market, but there might be something to be said for fixed term loans.

It doesn't have to be a stock market, our simutrans company doesn't need to be a public joint-stock-company. A general or limited partnership would be enough. Or rather a Private_company_limited_by_shares. So the initial investors (the first 500k the player gets) have the ultimate controll over the company. We just assume they are patient and wise. So they want a margin of the profit. This will be very major when the profits are very high. But nothing at all if the profit drops below a certain degree of the net worth. This way the unbalancing high profits can be magicked away, while it wouldn't hurt anyone struggling to survive.

This cash flow to the investors could be monitored and used to build something like a game score (summing it up), to facilitate competition in network games. The player can earn incredibly much but shan't have unlimited resources.

*i'm not quite sure about the appropriateness of this phrasing, it is not supposed to be aggressive or offensive. English requires quite a lot more subtleties in this regard than the more direct german, for a different mentality in regard to problem solving.

[inkelyad]

Add an option to your Vehicle replacer to replace all vehicles that are past their service life -- and importantly do all vehicle replacing instantly, without the tedious way to the depots! (i hardly ever use it because of this)

The problem with replacer is that convoy become empty at random point in schedule.
Maybe introduce flag in stations settings? Replacer will work only at flagged stations.
There convoy will unload all passengers and then go to depot for replacement.

[The Hood]

Ahh, I had wanted the liveries to reflect something about the in-game world, rather than to be completely arbitrary, and date of build or last overhaul is a useful thing to reflect. Besides, this would require no new GUI and thus be easier to program.

I still think it would be nice to choose from a range of liveries - e.g. the IC125 in Great Western, FGW, Midland, EMT, GNER, NXEC liveries, or allowing BR liveries for all the Big 4 locos post 1948.  It would also open the possibility of a choice between player colours or real life ones (which has been requested before).  Of course you could just specify a time range for each livery, but then you couldn't have the player colour option.

[jamespetts]

I shall reply in topics again.

Weight and wear

An axle load model presents a further complexity for pakset authors: somebody is going to have to go and define the number of axles per vehicle for every single vehicle in the pak (which can vary a great deal for rail vehicles and, I suppose, aircraft; and what do we do for boats?).

I don't think that it make any sense to have this cost charged to the convoy's account, not least for the reasons given in the previous post about maintaining all the conceptual distinctions of reality in order to maximise the usefulness of real life data, and the comprehensibility of in-game numbers: if money is being spent on gangs of workers going and fixing a road, it doesn't make any sense for that to show in a e convoy's operating costs graph even if the convoy caused the money to be spent. And what of public roads, the intention of which is that the cost of maintenance is separated from use (and in many cases socialised by a government charging tax in order to pay for it)?

Vehicle overhauls

I think that it's important to maintain a conceptual distinction between, on the one hand, the maintenance of existing vehicles in a convoy (which does not require vehicles to be sent back to the depot), and, on the other, the purchase of new vehicles, sale of old ones, upgrading vehicles between different types and the changing of the vehicles in a convoy, which should require a depot visit (that is, after all, what depots are for). The convoy replacer has been carefully designed, for example, to make use of any existing vehicles available in a depot (if the player so chooses) to make cascading easy (so, a player can upgrade all convoys on line A from vehicle type 5 to vehicle type 6, then upgrade all convoys on line B from vehicle type 4 to vehicle type 5, using the left over type 5 vehicles from the replacements on line A). Overhauls are intended to be part of maintaining existing vehicles, and thus should not require a depot visit for that reason; overhauling a vehicle is not the same as replacing it (although players should be given the chance to replace instead of overhaul, as suggested above).

As to sigmoid curves, from what I understand, the reality is that a vehicle's maintenance cost is actually more like a bathtub curve, as new types of vehicles have teething troubles that need to be ironed out before the type is fully reliable. Either way, however, having a non-constant maintenance cost makes it somewhat harder for a player to budget. Do we really need increasing maintenance costs as well as periodic overhauls to have the economic effect of balancing the excessive profit drivers for established games?

Cost of borrowing

I wonder whether even a private limited company dividend model would still be too complex (after all, in reality, the board of directors set the dividend; what incentive in Simutrans would a player have ever to pay a dividend?). A long-term loan or bond model might work, although capital financing cost is not the priority at this stage, since we haven't balanced profit to a reasonable level yet.

Replacer timetabling

I'd be interested in people's views on Inkelyad's idea on this issue - does this make things easier, or is it too much like micromanagement? I'm not sure at present where this one falls; may I ask - what is the incentive of having vehicles go to be replaced at a particular point in their schedule?

Liveries

It's an interesting thought that one might want to use Simutrans almost like a model railway to simulate the visual appearance of a particular era or region as an end in itself. That's not quite how I conceptualise the way that Simutrans works: I do take the view that all things should have some economic function in the game if possible, even if a relatively trivial one such as giving some approximate visual indication of the age of the vehicle or the time since its last overhaul; I do find something particularly satisfying about maximising the connexion between what can be seen in the game world and some actual in-game event or status, making the game as much of an internally coherent slice of simulated reality as possible. If a thing appears a particular way, I always like the thought that there is an answer to the question "why does it appear that way?" that has some relationship to the actual mechanics of the game: pedestrians, for example, appear in the game when and near where convoys load and unload at stops, or when packets of passengers are close enough to their destination to walk the whole way: city cars appear at the place where packets of passengers decide that they will travel by private car instead of the player's transport (and will tend to go in the direction of their destination), and so on.

Of course, an ideal transport simulator game would allow players to hire (computer controlled) designers to design new vehicles from scratch such that the vehicles were never the same from one game to the next, and apply their own company's livery which would have an effect on the PR of that company and thus passenger ridership (with changing fashions, etc.), but until a computer can satisfactorily design a plausible looking railway locomotive or boat, or judge how a particular colour scheme will appear to people accustomed to a particular fashion, then we shall probably have to stick to something like what we have now!