News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

How to get started on balancing properly

Started by moblet, January 05, 2011, 01:24:14 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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

QuoteThe 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.

Quote1. 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

Quote from: sdog on January 05, 2011, 03:54:12 AM
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

#3
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!
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

inkelyad

Quote
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

Quote from: inkelyad on January 05, 2011, 12:04:00 PM
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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

#7
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

#8
QuoteThe 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:
Quote3. 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

Quote from: sdog on January 06, 2011, 12:44:59 AM
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?
Quote from: sdog on January 06, 2011, 12:44:59 AMAn 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

QuoteI'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

Quote from: sdog on January 06, 2011, 04:11:44 AM
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

Quote from: moblet on January 06, 2011, 12:15:44 AM
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.

Quote
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)?

QuoteOn 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.

QuoteI 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.

QuoteOn 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.

QuoteAs 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).

QuoteOn 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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

#14
Quotethe 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.

QuoteThis 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.

QuoteAnother 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.

QuoteOne 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.

QuoteThe 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.

QuoteThere 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.

QuoteThe 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".

QuoteIs 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?

QuoteI 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.

QuoteWould 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.

QuoteHow 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.

QuoteI 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

Quote from: moblet on January 06, 2011, 11:55:27 PM
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.

QuoteA 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!

QuoteEDIT: 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.

QuoteCute, 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.

QuoteGranted, 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?)


QuoteIt'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!

QuoteTrue. 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.


QuoteI'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.

QuoteI 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.

QuoteSounds 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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

inkelyad

Quote
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

Quote from: inkelyad on January 07, 2011, 02:24:34 AM
"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

QuoteI 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.
QuoteIf 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.

QuoteThe 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!).
Quote...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.
QuoteOn 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!
Quotethe 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.
QuoteOften, 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.
QuoteThe 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.
QuoteThe 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!).
QuoteThat'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

#19
Quote from: moblet link=topic=6521.msg63511#msg63511
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)
Quote
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

#20
QuoteOn 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.

QuoteI 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.

QuoteThe 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

Quote from: inkelyad on January 07, 2011, 04:48:58 AM
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.
Quote from: inkelyad on January 07, 2011, 04:48:58 AM
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

QuoteOr 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

Quote from: sdog on January 07, 2011, 08:09:54 AM
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?
QuoteThis 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.
QuoteAre 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 ;)
QuoteIt'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.
Quote
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.
QuoteLinear 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

Quote from: moblet on January 07, 2011, 08:12:00 AM
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.
Quote
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.

Quote from: sdog on January 07, 2011, 08:09:54 AM
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

Quote from: moblet on January 05, 2011, 01:24:14 AM
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

Quote from: neroden on January 07, 2011, 10:12:47 PM
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

Quotewe 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

Quote from: neroden
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.

Quote from: Moblet
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.

Quote from: Moblet
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.

Quote
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.

Quote from: SDog
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.

Quote from: Neroden
...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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

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

Quote from: The Hood on January 08, 2011, 05:55:14 PM
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?

QuoteMy 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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

#31
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:
QuoteI'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
QuoteDo 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

Quote from: sdog on January 08, 2011, 06:36:40 PM
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

Quote from: jamespetts on January 08, 2011, 06:06:10 PM
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!
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

inkelyad

Quote from: jamespetts on January 09, 2011, 12:31:29 AM
Replacer timetabling
Not timetabling. User should be able tell "replace here" at stations near depot.
Quote
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?
Suppose we have looong line A-B-C-D. Where depot is near A.
In current implementation convoy can become empty at D. And then it will go (empty) to A. It will disturb schedules, spend unnecessary to running cost and take convoy out of service for long time.

moblet

#36
Quote from: The Hood on January 08, 2011, 05:55:14 PM
I like the ideas regarding overhauling
I agree. James, what you've outlined sounds to me like it has enough levers to mimic real-world dynamics, and none that are redundant. By my count that gives us four parameters that must be uniquely specified for each vehicle:
1. Fixed monthly cost $/month
2. Maintenance charge $/km
3. Operating cost $/km
4. Overhaul frequency /km
We'd also have two game-wide parameters
1. Overhaul cost % of capital cost
2. Something to increase overhaul or operating cost as the vehicle ages
Is that right? If some vehicles had more expensive overhauls than others then more frequent overhauls can serve as a proxy for this.
Quote from: The HoodI would also suggest that subsequent overhauls become ever more expensive otherwise you could still feasibly have steam puffing away in the year 2000.
More than that, to get the right game dynamics costs have to increase with age, to enforce an operating life, without which there is no trade-off between capital and running costs.
Quote from: JamesDo 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?
I'm pretty sure we do, otherwise we don't get the economic working life dynamic. Flat maintenance charge + flat price overhauls means that an overhaul returns the vehicle to new condition and at overhaul time, the decision is a simple choice between paying the cost of a replacement vehicle or paying the cost of an overhaul (the next overhaul will be due at the same time regardless). The overhaul is much cheaper so it is always the better option, leaving working life determined purely by obsolescence, not age. If an overhaul returns a vehicle to new condition then it should cost as much as a new vehicle.
It doesn't really matter whether increasing the maintenance charge per km or the overhaul cost that is used to increase maintenance cost with age, but as far as I can see (about 50cm without glasses) it is redundant to vary both. I think the maintenance charge is the better one to vary, as it is charged continuously so gives more control over game-play. As for increasing costs further once the unit is obsolete, again in principle it wouldn't matter whether this was done either way, and it shouldn't need to be done both ways. If the maintenance charge was a linear or otherwise increasing function then overhaul costs wouldn't need to increase and all that coding around obsolescence would become, well, obsolete. Even if the maintenance charge was sigmoid it could be set to level out at an uneconomically high rate so overhaul costs could still remain constant.
Quote from: JamesIt 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?
Or implement a game-wide multiplier that only charges a percentage of the monthly fixed cost while in depot, set at say 50% for starters. (I reckon we should think of that monthly fixed cost as being a "monthly fixed cost" incorporating all fixed costs, not just a "monthly maintenance cost".)
Quote from: Jamesa simple charge per ton would be closer to reality than what we have at present
I think the best way forward from a project management perspective is to introduce a linear way tonnage charge as a first step, and consider building a way maintenance cost module in some future version. To "really get it right" is going to mean coming up with a formula for the axle loadings of every vehicle as a function of its load, and building that into the sim.
Quote from: sdogconvoys 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.
In principle, if a vehicle uses someone else's way it should pay a toll that is equivalent to the way maintenance cost incurred by the trip plus a contribution to the road owner's return on capital, since the owner of the vehicle has saved capital by using someone else's way instead of building their own. The charge should perhaps also be even higher to compensate the owner for the costs of additional congestion. Otherwise it creates distortion, although one nice thing about this distortion is that it works in favour of players who can't afford to build their own infrastructure.
Quote from: sdoglinear relation ships 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
Funny you should say that, I have occasionally been hired to find things out ;) There is a fundamental contradiction between the sim and reality on maintenance expenditure, namely that in the sim it's certain, but in the real world it's not. In the real world we manage probability and consequence of failure, it's a game of risk management. In the sim we debit an amount of money from the player and the unit is guaranteed not to fail, but it would not be realistic to charge the player the equivalent amount of money that would achieve 99.9999999% reliability in real life. Daily experience with my 20yo Japanese car is that I can't accurately predict what's going to need replacing, and therefore what my maintenance cost will be, over the next 10,000km. In real-world maintenance management one would try to develop a probability distribution of outcomes and plan on the basis of that.
Without data I'm not going to argue about the exact shape of maintenance cost curves, which will be different between units anyway, but propose that we adopt a linearly increasing curve for the maintenance charge as a simple incremental step, being an enhancement over a flat rate, and retain the possibility of expanding that to a maintenance cost module that might try to accurately mimic real world average costs, or even introduce uncertainty into maintenance expenditure (bearing in mind that this would be expected to favour larger fleets in gameplay). I think we should see how the simple, easy-to-program-and-document linear assumptions work in gameplay before deciding whether we need to make them more complicated.
I will comment on the sigmoid, though, which intuitively looks OK to me, but I haven't crunched any numbers to check. In the real world, once that exponential rise kicks in, that would normally mean it's replacement time, so the back half of the curve would never be seen. In Simutrans we would need to cover the possibility of a player retaining equipment uneconomically, so we would need a curve that can stretch for 300 years. The sigmoid offers a powerful tool for forcing the issue of economic life in the sim, but we may not need such a heavy hammer. We'll find out as we go along.
Quote from: JamesWe 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?)
I have a few thoughts on balancing and how to progress it, continuing on the benchmarking theme. The notion of balancing implies that there is a set of circumstances under which competing options will come out equal. We can exploit this property to generate balanced parameter sets in a semi-automatic fashion, by throwing all the fundamental performance and cost parameters into a single spreadsheet, and linking them with appropriate formulae. The demands of balancing mean that, for example, if we change the power output of a single loco for historical accuracy but don't want that to alter the balance of the game, its cost performance parameters should automatically adjust to compensate for, and effectively cancel out, the change in technical performance. This is easily handled in a spreadsheet, and adding a new vehicle to the pak can be accommodated by adding a line to the spreadsheet and matching up the new unit's parameters. We could, if necessary, include revenue assumptions so as to balance out things like speed advantages. Basically such a spreadsheet would be an extension of the comparison one I attached in a previous thread, and is something I can work on. First though, I need to get hold of the .dat file(s), which I don't know how to find/isolate. Can someone point me at them?
For balancing goods prices, it's important that a player has roughly equal prospects regardless of what industries appear, since that's outside the player's control. That gives us a benchmarking target, so we shouldn't have to flail about too much on this one either. The balance can be upset by altering the productivity of an individual factory type, or the configuration of a supply chain, so I'm seeing another spreadsheet that contains factory, supply chain and price assumptions and helps us adjust them towards benchmarks that equalise financial outcomes between supply chains.
It might take us a few iterations of spreadsheet versions, and many iterations of adjusting numbers, to complete the job, but this is the only controlled process I can think of for arriving at a balanced set of game parameters. It integrates performance and cost and allows us to progress on both fronts simultaneously. As repositories of assumptions the spreadsheets would also facilitate discussion and collaborative effort.
These tools should also be equally useful to developers of other paksets.

sdog

#37
Worn out vehicles
QuoteI think that it's important to maintain a conceptual distinction between [...] [actions that do] not require vehicles to be sent back to the depot [...][things that] should require a depot visit

Why? In the paradigm we used of a convoy not representing a single entity, but a token for the transport capacity of a line. Which therefore does not have to go to a depot on a daily basis (to refuel for example) we already got rid of most of the depot interactions (unlike openTTD). The same line of argument also applies to buying convoys in Depots. Right now we're rather incosequent by being right in-between a complete abstraction and the openTTD approach. I think it is quite convenient to have a depot for creating convoys as new entities, since they will have a defined point of start. But for all other things this is superfluous.

Quote from: JamesAs to sigmoid curves, from what I understand, the reality is that a vehicle's maintenance cost is actually more like a bathtub curve
No, bathtub does not consider saturation of maintenance costs, they don't increase exponentially, but will be asymptotically to some value that would be at worst the cost for having your own production line for it. The initial very high costs also reflect the adoption of a newly developed model, not of another sample of the same model you've been running for years before. part of this bathtub approach is quite good for your obsolescence calculation. I thin you also have some saturation there. The bus should have for the first 200k km roughly the same maintenance, but then it will ramp up very steeply.

Quote from: JamesDo 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?
The increased maintenance cost should already address the costs of the frequent overhauls a new vehicle needs. Unless you mean with overhaul that everything is physically replaced and it is not the same afterward. What moblet suggested before was having to completely replace vehicles if they get too old. As i think doing this completely automaticaly, to have the decission by the player, i suggest to introduce a strong incentive to replace vehicles, but don't do the decission. Dropping the depot requirement makes things quite easy.

Your replacer dialogue doesn't need to be used for this. Having a button at the convoy, the line, and for all overdue vehicles would suffice. What really happen would be only resetting the odometer and incuring the vehicle buying cost. It is not necessary to have the replacers extended functionality to keep the replaced vehicles in a depot, as they would be next to useless already.

(I've got some feedback on the replacer, but it's not so important here. I'll only bother you with it if you want me to.)


capital cost
Quoteafter all, in reality, the board of directors set the dividend; what incentive in Simutrans would a player have ever to pay a dividend?
The player is just the CEO, not part of the board of directors. The program would set the dividend.

As i understood moblet balancing alone will not be sufficient to get a challenging game in all phases of the game. My understanding of the economic side is only very limited, and it is not unlikely at all that i completely misunderstood him.


Weight and Wear
It should suffice to use the total weight of the vehicles and use a factor a based on vehicle type (eg 0.3 for buses, 0.1 for steam train engines, 0.25 for carriages etc) and use the fourth power of the product with the mass: (a m)^4

It should not be neccessary to do this for aeroplanes, it would matter only for one runway tile. Boats need something completely different, most likely the vortices generated by the screws will erode the canals, it should likely depend on power? Luckily when motorised boats are available, the canals are not relevant at all anyways, so just omit boats.

For public roads, just set the cost factor for that way to zero.
The vehicle will not get
Now as i read it i think you were perhaps thinking about saving the costs for every tile? That would be about 10k to 100k entries with a couple integers, but were not in low ram or bandwith times anymore :-).
Where do you want to display the cost, except at budget window? Per tile will be easy, but won't be very informative, unless one sums it up for the whole way.
A waysearch could be used to get it for the patch of way between two intersections. This seems to be quite a lot for such a detail.

Replacer Timetabling
I think it will improve things a bit, but will not matter too much. The trains running around a bit until they are empty is a bit of a nuisance, but the real trouble is the blockages when they get back on track. Especially if they decide to go to exotic depots.

Edit:
Quote from: mobletIn the sim we debit an amount of money from the player and the unit is guaranteed not to fail, but it would not be realistic to charge the player the equivalent amount of money that would achieve 99.9999999% reliability in real life
The idea here was not having such highly reliable equipment, but that one of the vehicles in the game is a token for a small fleet of vehicles. Which would just get replaced or fixed as they break. This should be integrated in the maintenance cost. (If you want just imagine at one of the stops they just replace the vehicle and send it back while the other one continues seemlessly and invisibly. So we can just look at an average. This also makes your japanese car problem much easier, as we don't have to look at one that can cause random costs but on the average for a large enough set. This is a really nice thing, when confronted with random events, get enough of them :-). If you want to go back into the displayed single vehicle picture again just assume it is in a universe where everything always takes the expectation value.

ӔO

There is maintenance for runways and aprons, but these can be easily reflected in the maintenance cost of the way types. Particularly during snow fall and icing conditions, but that's a bit rarer for UK.
http://www.skybrary.aero/index.php/Runway_Maintenance

The airplanes themselves cost an arm and leg to purchase and operate, not to mention the flight and maintenance crews necessary.

I think, for flights during the golden age of airtravel, where expenses were less, you could run the aircraft at less than 50% capacity and still run a profit.

These days, from about the 90's, with all the clamp down on safety in maintenance proceedures and the rising cost of fuel, it's rare to have international flights with less than 80% capacity. Both domestic and international flights are also cut down in frequency. Not unusual to have international flights to a certain destination that only travel happen once a week.

It has apparently become tricky to maintain profit margins with airlines. Airplanes need to fly almost every day to maintain profit, as it really bleeds a lot of money by just sitting around, but more time in the air means more costly maintenance.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

sdog

Sorry AEO, i think what i wrote was easy to be misunderstood. I meant increased maintenance costs based on the weight of the planes could be ignored for simutrans.

ӔO

ah, that is mostly negligible, yes.
It really only matters on the landing portion, where it's about 250~300t hitting the tarmac at about 200~260km/h
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

Quote from: Jamesa vehicle's maintenance cost is actually more like a bathtub curve
The bathtub describes Mean Time To Failure (MTTF), not maintenance cost per unit of use.

Quote from: sdog
The increased maintenance cost should already address the costs of the frequent overhauls a new vehicle needs.
The Efficient One strikes again! If the maintenance charge has to increase with age anyway, do overhauls not become redundant?

Quote from: sdogbalancing alone will not be sufficient to get a challenging game in all phases of the game
Just realised we have two concepts of balancing flying about here, and perhaps reason to further bifurcate this thread. One balancing concept is early vs mature game (make it easier to survive at first and more challenging to prosper later on), the other is the relative profitability of cargoes/modes/vehicles (so that choices between modes and vehicles are realistic and intuitive). These are independent concepts. I melded them somewhat at the beginning by suggesting that some currently absent real world dynamics are needed to address the former, and these would impact on specifying the latter. In an effort to clarify which is for what:

Balancers aimed at making early play less costly and mature play more costly:
1. Age-based maintenance costs
2. Fixed time-based vehicle cost (coded)
3. Variable way maintenance costs

Balancing cargoes/modes/vehicles:
Build a couple of spreadsheets to contain all the vital parameters, linked by formulae, to easily adjust the relative technical and financial performance of cargoes, modes, and vehicles. Most, perhaps all vehicle and way parameters will need to be included in these spreadsheets, so the spreadsheets will have to change to mirror consequential coding changes (e.g. maintenance cost curves).

Quote from: sdogjust assume it is in a universe where everything always takes the expectation value
Done!

moblet

Just had a look around and found...a pak128.Britain balancing spreadsheet! It was always possible that someone had already had a go at this, and they've done a pretty comprehensive job. The Hood, are you the one to thank for this? Will chew on it for a while and see what I can do with it to try to streamline vehicle balancing.

jamespetts

Lovely to see the discussion flowing, although we do need to try to focus on specific things to do (and as parsimonious things as possible) to make the game mechanism such that it can be balanced efficiently with playability and challenge at all stages. We also need to minimise the level of programmatic upheaval necessary to implement these changes, since I return to work on Monday and my Simutrans time will again be severely limited; the fewer, the smaller and less significant (and therefore less likely to have large bugs when coded) changes that can be made to the code to implement these ideas, the better.

Quote
I agree. James, what you've outlined sounds to me like it has enough levers to mimic real-world dynamics, and none that are redundant. By my count that gives us four parameters that must be uniquely specified for each vehicle:
1. Fixed monthly cost $/month
2. Maintenance charge $/km
3. Operating cost $/km
4. Overhaul frequency /km
We'd also have two game-wide parameters
1. Overhaul cost % of capital cost
2. Something to increase overhaul or operating cost as the vehicle ages
Is that right? If some vehicles had more expensive overhauls than others then more frequent overhauls can serve as a proxy for this.

(2) and (3) would not be specified or displayed separately (there is a single per kilometre cost), but could be calculated separately in a balancing spreadsheet and combined. Overhaul cost as a function of capital cost would be specified globally as a default, but could also be specified on a per-vehicle basis. Some vehicles indeed would have more expensive and others more frequent overhauls, and some vehicles would have more expensive and more frequent overhauls (but be either otherwise good generally or fulfil a particular need at a particular time).


Quote
I'm pretty sure we do, otherwise we don't get the economic working life dynamic. Flat maintenance charge + flat price overhauls means that an overhaul returns the vehicle to new condition and at overhaul time, the decision is a simple choice between paying the cost of a replacement vehicle or paying the cost of an overhaul (the next overhaul will be due at the same time regardless). The overhaul is much cheaper so it is always the better option, leaving working life determined purely by obsolescence, not age. If an overhaul returns a vehicle to new condition then it should cost as much as a new vehicle.
It doesn't really matter whether increasing the maintenance charge per km or the overhaul cost that is used to increase maintenance cost with age, but as far as I can see (about 50cm without glasses) it is redundant to vary both. I think the maintenance charge is the better one to vary, as it is charged continuously so gives more control over game-play. As for increasing costs further once the unit is obsolete, again in principle it wouldn't matter whether this was done either way, and it shouldn't need to be done both ways. If the maintenance charge was a linear or otherwise increasing function then overhaul costs wouldn't need to increase and all that coding around obsolescence would become, well, obsolete. Even if the maintenance charge was sigmoid it could be set to level out at an uneconomically high rate so overhaul costs could still remain constant.

Hmm - I thought that the point of overhauls was to de-amortise long-term vehicle wear maintenance so as to enable per unit of distance maintenance charges to be balanced such that the vehicles have to earn enough over a considerable period of time to pay for their overhauls later on? Is the point that there is also some other mechanism that dictates a necessity to have increased basic maintenance charges throughout a vehicle's life-cycle? I am not sure that it necessarily follows that, if a vehicle is returned to an as new condition one should pay an as new price, not least because there is no need to pay for all the materials again (no overhaul will completely replace everything, after all). As to incentive to buy new vehicles - is there not enough incentive in that the new types vehicles are often better than the older ones? It is common practice particularly on the railways to cascade older vehicles to less and less significant duties until they become completely obsolete before retiring them. I don't think, for example, that the many Victorian steam locomotives still running in the 1930s (or the railway carriage built in the 1880s that ran until 1960 that I visited in the London Transport Museum on Friday, which was only replaced when it was superseded by modern electric multiple units which themselves have not yet been replaced despite their half-century vintage) cost significantly more to maintain than the newer steam locomotives running at the time, save that they were probably less efficient on coal and water because of their relatively inferior design (but then, always had been); nor do I think that the steam locomotives running in preservation now are inherently in a poorer state owing to their age or mileage than they were when running in ordinary revenue earning service. Usage patterns of actual vehicles tend to suggest that they do tend to be used until they become obsolete (albeit they are overhauled several times in the process). Certainly, this retention of older stock and cascading is something that I'd like to encourage (not least by means of players having a strong incentive to be frugal generally by correct balancing of income and expenditure), and so I am most reluctant to add any mechanism that will excessively penalise older stock and give players a strong incentive to buy newer vehicles instead of keeping older ones going. It is technically feasible to maintain most pieces of equipment in something close to as new condition given enough resources; different parts of equipment wear at different rates and not every part has to be replaced at every overhaul. There will come a time, of course, when the vehicle has had so many overhauls that its as new price has been paid or more than paid in overhaul costs, which may well come before the time when every last component is replaced (does the bracket holding the fire extinguisher in the cab really wear out with age...?). For this reason, I rather suspect that flat maintenance until obsolescence and flat overhaul charges create incentives closer to the real world than ever-increasing maintenance charges for non-obsolete vehicles that cannot be reduced by overhauls.


Way based tonnage charges

Way tiles already store statistics about the number of convoys passing this and last month, so storing statistics integers on a per way tile basis is evidently not considered excessive even in Standard. The simplest way of doing this would be to store a "tons this month" figure on each way tile, and, at the end of each month, compute the cost based on the way's "cost per ton", debit that amount from the infrastructure maintenance account, and reset the figure in each of the tiles.

Use of other players' lines

I don't think that the cost of this should be fixed by any coded mechanism. I take the view quite firmly that, in any multi-player game, the cost at which goods or services are exchanged between players should be determined by the players, not by the code. Players should be free to charge players what they like for using their ways (and say, for example, "player X can use player Y's railway in A, if player X lets player Y use player X's roads in B, C and D" without any money changing hands at all). I'd like to see a mechanism for the transfer of arbitrary amounts of money (both on a one-off and recurring basis) between players in a multi-player game in due course.

As to the public player, the idea is that this player is, effectively, the government. It should raise money by raising taxes (both on players' profits and the general population (which will reduce growth)), but it should still have to remain solvent and pay for what it does. In reality, governments often supply the roads and maintain them. Whether it charges people for using them in one way or another is a matter for whoever plays the public player.

Quote
I have a few thoughts on balancing and how to progress it, continuing on the benchmarking theme. The notion of balancing implies that there is a set of circumstances under which competing options will come out equal. We can exploit this property to generate balanced parameter sets in a semi-automatic fashion, by throwing all the fundamental performance and cost parameters into a single spreadsheet, and linking them with appropriate formulae. The demands of balancing mean that, for example, if we change the power output of a single loco for historical accuracy but don't want that to alter the balance of the game, its cost performance parameters should automatically adjust to compensate for, and effectively cancel out, the change in technical performance. This is easily handled in a spreadsheet, and adding a new vehicle to the pak can be accommodated by adding a line to the spreadsheet and matching up the new unit's parameters. We could, if necessary, include revenue assumptions so as to balance out things like speed advantages. Basically such a spreadsheet would be an extension of the comparison one I attached in a previous thread, and is something I can work on. First though, I need to get hold of the .dat file(s), which I don't know how to find/isolate. Can someone point me at them?
For balancing goods prices, it's important that a player has roughly equal prospects regardless of what industries appear, since that's outside the player's control. That gives us a benchmarking target, so we shouldn't have to flail about too much on this one either. The balance can be upset by altering the productivity of an individual factory type, or the configuration of a supply chain, so I'm seeing another spreadsheet that contains factory, supply chain and price assumptions and helps us adjust them towards benchmarks that equalise financial outcomes between supply chains.
It might take us a few iterations of spreadsheet versions, and many iterations of adjusting numbers, to complete the job, but this is the only controlled process I can think of for arriving at a balanced set of game parameters. It integrates performance and cost and allows us to progress on both fronts simultaneously. As repositories of assumptions the spreadsheets would also facilitate discussion and collaborative effort.
These tools should also be equally useful to developers of other paksets.

A balancing spreadsheet is an excellent idea, although note that the balancing spreadsheet that you have found is for Simutrans-Standard and Pak128.Britain-Standard, in which the balancing parameters (and, in many cases, the parameters of the various items of rolling stock and infrastructure) are quite different. That is also a little out of date, I think, in that much more has been added to the pakset since then. If you are looking for up-to-date .dat files for Pak128.Britain-Ex, have a look at the Github repository here.

The vehicle replacer

I'd be interested in Sdog's feedback on this tool - perhaps in another thread?

Quote from: Sdog
The idea here was not having such highly reliable equipment, but that one of the vehicles in the game is a token for a small fleet of vehicles. Which would just get replaced or fixed as they break. This should be integrated in the maintenance cost. (If you want just imagine at one of the stops they just replace the vehicle and send it back while the other one continues seemlessly and invisibly. So we can just look at an average. This also makes your japanese car problem much easier, as we don't have to look at one that can cause random costs but on the average for a large enough set. This is a really nice thing, when confronted with random events, get enough of them :-). If you want to go back into the displayed single vehicle picture again just assume it is in a universe where everything always takes the expectation value.

This, incidentally, is correct.

Quote
Just realised we have two concepts of balancing flying about here, and perhaps reason to further bifurcate this thread. One balancing concept is early vs mature game (make it easier to survive at first and more challenging to prosper later on), the other is the relative profitability of cargoes/modes/vehicles (so that choices between modes and vehicles are realistic and intuitive). These are independent concepts. I melded them somewhat at the beginning by suggesting that some currently absent real world dynamics are needed to address the former, and these would impact on specifying the latter. In an effort to clarify which is for what:

Balancers aimed at making early play less costly and mature play more costly:
1. Age-based maintenance costs
2. Fixed time-based vehicle cost (coded)
3. Variable way maintenance costs

Balancing cargoes/modes/vehicles:
Build a couple of spreadsheets to contain all the vital parameters, linked by formulae, to easily adjust the relative technical and financial performance of cargoes, modes, and vehicles. Most, perhaps all vehicle and way parameters will need to be included in these spreadsheets, so the spreadsheets will have to change to mirror consequential coding changes (e.g. maintenance cost curves).

Yes, indeed - none of the individual posts in this thread have been entirely about the second part of the topic, so I can't split this as I did on the previous occasion. Perhaps somebody could start a thread about setting up a balancing spreadsheet for Experimental?

The order of work appears to me to be as follows:

(1) identify precisely what changes are needed to the base code;
(2) implement those changes;
(3) set up a spreadsheet to give basic balancing parameters for different types of vehicles and infrastructure on the basis of the model outlined in (1) (can be done concurrently with (2) if done by a different person);
(4) balance the physics of steam locomotives (and possibly boats)*;
(5) balance industry production/consumption ratesl
(6) implement an initial run at the balance specified in (3) (can be done simultaneously with (4) and (5) if done by a different person;
(7) test the balance in game;
(8) make further adjustments to the balancing formula or its implementation;
(9) return to (7).

* I have started work on this.

Perhaps the remainder of this thread can be concerned with item (1), and the separate thread discussed can be concerned with how to get towards item (3) and we can than start to make some progress on this rather large but rather important task?

Thank you all for your help on this so far!
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: JamesI thought that the point of overhauls was to de-amortise long-term vehicle wear maintenance so as to enable per unit of distance maintenance charges to be balanced such that the vehicles have to earn enough over a considerable period of time to pay for their overhauls later on?
The overhauls per-se do not increase maintenance cost with age (unless you dispose of the vehicle prior to its first overhaul). You are right that the idea was to defer maintenance expense to help early game dynamics, but we could also achieve this with a cost curve that is lower in early life (whether linear, sigmoid, or otherwise).

Quote from: JamesIs the point that there is also some other mechanism that dictates a necessity to have increased basic maintenance charges throughout a vehicle's life-cycle?
Not necessarily increasing throughout, just higher later in life.

Quote from: JamesIt is common practice particularly on the railways to cascade older vehicles to less and less significant duties until they become completely obsolete before retiring them.
Yes, and the reason they are cascaded to lighter duties is because they cost relatively more to run and are less reliable. Their new duties are usually characterised by high tolerance of breakdowns and low mileage, which translates into poor utilisation that weighs against investing new capital. In the real world those lighter duties may also be performed by another operator (i.e. the original operator disposes of the vehicle), such as North American schoolbuses finding second lives as long-distance buses in Latin America (mileages higher in this instance but maintenance labour cheaper and capital for new vehicles harder to raise), so a player's choices will be influenced by what kinds of tasks are available in their network, e.g. do they have any "slow" lines on which to employ an old loco, or Latin-American long-distance bus routes?
I can see four real-world factors that seem to be stronger in reality than they are in the sim:
1. The player can't buy used vehicles that may cost more to run but are cheap to buy and fit-for-purpose where loadings are low
2. In the real world lighter loadings mean lower operating costs, in the sim every km is charged the same regardless of load
3. Simutrans lines aren't differentiated by reliability tolerances
4. Inflation and depreciation mean the capital value of the vehicle by that stage in its life is virtually zero
My estimation of how best to drive this kind of choice in the sim is:
1. Don't make fixed costs so high that the player can't afford to retain a poorly utilised unit. It would be legitimate to ease a proportion of the fixed costs as the vehicle depreciates.
2. Apply a maintenance cost curve that increases when vehicles age, but levels off like the sigmoid does. The more I think about the sigmoid the better I think it suits our purposes.
3. Make sure the resale value of vehicles erodes significantly so that late in their lives there is little return on selling them (I haven't checked how resale values deteriorate in the sim)
4. Degrade the performance of old units, encouraging the player to move them off the busiest lines. They would also become incapable of synchronised service with newer units.

In Melbourne they still run 80yo trams on some routes, generally routes where a breakdown won't affect the rest of the network. The tram operator keeps trying to retire them but they are historical icons and the government keeps intervening to force the operator to keep them in service. Some retired units have been sold overseas but there's now also an embargo on exporting them.

Quote from: JamesI rather suspect that flat maintenance until obsolescence and flat overhaul charges create incentives closer to the real world than ever-increasing maintenance charges for non-obsolete vehicles that cannot be reduced by overhauls.
One of the tricky things here is that by the time a vehicle gets old, the technology of new ones has improved, and I don't have a great sense of how that pans out in the sim. All the same I don't see how the balancing can work without a mechanism that limits a vehicle's economic life on a usage basis. We should think beyond rail vehicles, too, as rail vehicles have longer lives than most of the other vehicles in the sim. The typical commercial lifespan of trucks, aircraft, and bulk carriers is shorter. And come to think of it with rail vehicles, we see 50yo units in service and tend to assume that all units built 50 years ago would still be economic to run. Is that generally the case or were they just the over-engineered or underutilised ones?

The Hood

Quote from: moblet on January 09, 2011, 01:43:34 PM
Yes, and the reason they are cascaded to lighter duties is because they cost relatively more to run and are less reliable. Their new duties are usually characterised by high tolerance of breakdowns and low mileage, which translates into poor utilisation that weighs against investing new capital.

4. Degrade the performance of old units, encouraging the player to move them off the busiest lines. They would also become incapable of synchronised service with newer units.

One idea that you may wish to consider for experimental is the idea of breakdowns (as included in TTD) - they have been rejected for standard simutrans but having some kind of reliability factor that affects the rate of breakdown (and therefore operation and average journey times etc) could help.  Obviously this would become less reliable with age, but improve with overhauls.  You could also have the option to choose between different maintenance regimes (e.g. 50%, 100%, 150% of the average maintenance costs specified in the dat file but with consequences for reliability).

ӔO

I don't know if it has been mentioned already, but, generally, the life expectancy of trams and buses is about 20~25yrs.

Any company using them beyond that are either keeping them for special use only, they don't have a suitable replacement or they are just broke.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

The Hood

Buses in the UK often get used only for 7-10 years, but I think that is mainly an "image" thing - the buses themselves still work I think.

ӔO

I don't know what it's like for trucks and buses, but the well made modern japanese car engines don't have to be overhauled until at least the 300,000km mark.

engines also lose power gradually even when maintained properly, more so for neglected, hence the need for an overhaul after x mileage.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Briefly (as I currently am limited in time) on overhauls versus sigmoid curves: overhauls have the advantages that they are easier to represent to a player (what is expressed as the vehicle's maintenance cost if it varies over its lifetime?), easier to implement and do not interfere with the existing obsolescence model (on which work has already largely been done. Do the advantages of the sigmoid curves, such as they are, really outweigh all that?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

#50
I think the current implementation is fine.
It's just a bit less obvious at first, because it's more like "you're setting aside X money for maintenance" instead of "oh my, how am I going to pay for maintenance?" The so called "hidden fees".

perhaps a slight change in the maintenance cost increase after obsolete along with changes in retirement dates?

------
edit:

Also, I'm not sure where it was mentioned, but value depreciation is normally compounded and not linear like in the game. Rates depend on how valuable the vehicle is. Reliable with good reputation depreciates less than unreliable. More common depreciates more than rare, but that latter is not really applicable to trucks and buses and aimed more at cars or locomotives.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

Hopefully these charts will speak for themselves. Attached is a spreadsheet comparing the shapes of life cycle costs under different maintenance charging schemes, along with their cash flows over time so their relative impact on early and mature gameplay can be assessed. There's a chart on each page. Feel free to fiddle with parameters at the top of each page.

A word on interpreting life cycle cost curves - the lowest point on such a curve represents the optimal economic vehicle life. They typically descend quickly and only climb gradually from their minimum. Such a shape means there isn't a great penalty for keeping a vehicle a while longer than the theoretical optimum, which is handy if one doesn't have enough money to replace it, and encourages cascading to lighter duties.

And a philosophical issue with the obsolescence model: I would expect that historically each vehicle became obsolete because something better came along and demand for it decreased (except the ones made out of dodo feathers and non-scientifically-hunted whalebone). If the sim contains a representative sweep of vehicles through history, with representative relative cost performance, then that, in conjunction with the speedbonus, means the older vehicles are no longer competitive to operate and effectively imposes obsolescence anyway. An operator could not afford not to upgrade. That might be enough of a hit to make players upgrade in the game without "double-dipping" by imposing further costs on out-of-date equipment.

Quote from: The HoodBuses in the UK often get used only for 7-10 years, but I think that is mainly an "image" thing - the buses themselves still work I think.
When formal service contracts were introduced for bus operators in NSW they included an upper limit on the average age of a fleet (12 years). I wouldn't be surprised if something similar is happening there, as presumably this was copied from somewhere. Here many buses are kept just to do school runs, working only 800 hours a year, and those ones will easily last 30 years or more if not legislated into retirement.



inkelyad

Quote from: moblet on January 10, 2011, 06:13:14 AM
and encourages cascading to lighter duties.
It did not really  work if we don't include convoy mass in calculations. I believe for locomotives fuel consumption will be quite different with empty/full convoy.

neroden

Quote from: jamespetts on January 05, 2011, 01:53:52 PM
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.

We should do this, the trouble is journey times aren't actually specified in a coherent manner right now; the way waiting times are computed from internal ticks is not quite the same as the way journey times and speeds are computed and neither are documented in a sensible way....

This is the single biggest problem with Simutrans right now and I'm trying to fix it in standard....

neroden

Quote from: jamespetts on January 09, 2011, 11:43:37 AM
(1) identify precisely what changes are needed to the base code;
(2) implement those changes;
(3) set up a spreadsheet to give basic balancing parameters for different types of vehicles and infrastructure on the basis of the model outlined in (1) (can be done concurrently with (2) if done by a different person);
(4) balance the physics of steam locomotives (and possibly boats)*;
(5) balance industry production/consumption ratesl
(6) implement an initial run at the balance specified in (3) (can be done simultaneously with (4) and (5) if done by a different person;
(7) test the balance in game;
(8) make further adjustments to the balancing formula or its implementation;
(9) return to (7).

I can't disagree with this overall, but I'd state it somewhat differently.

I think the first code change which needs to be made is a saner treatment of time, distance, and speed in simutrans.  Which I'm working on, with difficulty.

If we can figure out the number of ticks in a "vehicle hour", then with a standard definition of 1 km = some number of tiles, Bernd's physics model should hold us in good stead.

The second thing which is needed is appropriate ("realistic") weight, power, tractive effort, and air/water resistance numbers (and capacities, but I think those are good) for buses, lorries, boats, and ships.  (For ships these may be somewhat different from reality for "realistic" behavior, because ships float in water and all that.) The third is realistic weights (and capacities, but I think those are good) for railway wagons and carriages.  The fourth is appropriate power, tractive effort, and air/water resistance numbers for railway locomotives.

This will give us "reasonably realistic physics".  This should probably be playable in sandbox mode.  Only after this point can we actually start on pricing, because *any change to this stuff requires a complete recomputation of pricing*.  And pricing should start with infrastructure pricing.

Now there is a problem here.  Pak128.britain has a vast, vast number of vehicles -- and even a large number of infrastructure choices.  It is unrealistic to expect them all to be "physics-balanced" in a short time, yet people would clearly like to get to the pricing balancing.

So perhaps step one should be to keep an index of vehicles, marked with whether they are "physics balanced" or not.  We should perhaps identify a "core list of vehicles" and get the physics balanced on those, an appropriate selection across the timeline, so that we can start working on pricing balances for them.
Weight limits and speed limits on infrastructure actually depend on physics balance for at least some vehicles, so once we have this "core list" of vehicles balanced I think we can nail down the behavior of the infrastructure, and then we should be able to come up with some scheme for pricing.

But, frankly, I don't think we can balance the whole pak at once -- it's too large.  I think we need to define a "core subset" of the pak to balance first. 

If we get a "core subset" balanced we should be able to spot whether we really want to add complexity to the core pricing code or not; I don't think we can tell until we do that.

jamespetts

This is getting very complicated! Let me try to deal with the salient issues at this juncture to move this forward.

Moblet's graphs and the various models for increasing maintenance costs

The spreadsheets and graphs were very interesting: a number of intriguing conclusions can be drawn as follows:

(1) the sigmoid curve is the one that starts out the shallowest and ends up the steepest;
(2) the flat rate model currently in Standard is a long way behind all the others in varying incentive by use;
(3) the obsolescence model is very similar to a combination of flat plus linear degradation (because that, in effect, is what it is); and
(4) the obsolescence model is better than the linear increase in providing differential maintenance cost at the beginning and end of a vehicle's life.

A number of issues with the calculations arise. Firstly, the obsolescence model is a linear capped model: in other words, after a certain point, the maintenance costs stop going up. Secondly, I'd very much like to see (1) a combination of the sigmoid and obsolescence; (2) a combination of overhauls and obsolescence; (3) a combination of sigmoid and overhauls; and (4) a combination of sigmoid, overhauls and obsolescence (in each case with less frequent, more expensive overhauls where applicable, and with the obsolescence capped, where applicable).

Another possible model is one that combines the linear or sigmoid maintenance increases with the overhauls model such that the maintenance charge increases until overhaul and then reverts to its previous state again. In that model, one might consider making overhauls optional or giving the user some sort of control over when they are carried out (perhaps with the default at what will usually be the optimum level).

I am reluctant to do away with obsolescence, however, as obsolescence represents something distinct from wear. Let me give an example (although I don't have the exact figures). In 1990 a large group of volunteers started building a new full sized steam locomotive from scratch: Tornado, with the aim of running it on enthusiast trains on the mainline. Their ambition was realised in 2008, and the locomotive (a brand new reproduction of a design from the 1940s, the Thompson A1 class) has run regularly on the UK mainline hauling enthusiasts' trains ever since - it once famously hauled a relief train for ordinary travellers when the electric traction equipment used by the ordinary trains was made inoperative by heavy snowfall. It is somewhat difficult to assess, because I do not have figures to hand, but I very much doubt that Tornado costs significantly less to run/maintain than more traditionally preserved steam locomotives rescued from scrapyards that had a full working life (and many thousands of miles) behind them. The reason that steam locomotives cost a very large amount to maintain now is that economic conditions have changed since the time when they were last economic to run: unskilled labour is vastly more expensive, and modern regulations make the job even more labour-intensive than once it was. Obsolescence is intended to catch these kinds of situational changes: things that make vehicles of that type more expensive to run in the years after their obsolescence than they were when they were new. It wouldn't be economic to run an 80-year-old 'bus now, for example, even if it had been sitting untouched in a garage for 79 years, not because it'd be worn out (it wouldn't be), but because it'd be obsolete. That is partly because newer, better 'buses are available, but also partly because one can't get the parts for the older types, or the expertise to maintain them, and because they don't conform to modern regulations/expectations, etc., at least not without substantial adjustment. Obsolescence is how we deal with the changing economies of time.

The obsolescence model was intended to deal both with this, and, to some extent a vehicle's natural lifecycle (as the two tend to coincide quite often), but that was before I appreciated the point that Moblet raised in relation to utilisation and profit balancing. If, therefore, we add a second effect increasing the cost of an older vehicle in some way, we might need to reduce the level of the obsolescence increase.

As to affecting performance, I am somewhat sceptical of this idea: what measure of performance would be affected? Vehicles do not generally get slower as they age, nor take longer to accelerate, nor become able to haul less weight; they can become less reliable, but we do not simulate breakdowns individually in any case (for good reason), but count unreliability as part of the maintenance cost.

Quote
One of the tricky things here is that by the time a vehicle gets old, the technology of new ones has improved, and I don't have a great sense of how that pans out in the sim. All the same I don't see how the balancing can work without a mechanism that limits a vehicle's economic life on a usage basis.

This is not simple, and interrelates to the above to some extent. In Standard, the philosophy is that the (and the only) incentive (and the only incentive necessary) for players to replace vehicles is that something better comes along. Indeed, this can be a powerful incentive in itself. One thing to consider: when a vehicle comes to the end of its economic life in reality, almost never is it scrapped and replaced with a brand new but otherwise identical vehicle: it is always replaced with something newer in design, and I do not think that this is a coincidence. If the only option was a brand new but otherwise identical vehicle, would a full overhaul not almost always be a more economical option than a new vehicle, unless the vehicles were built so cheaply so as almost to be disposable commodities (which would be the case for very few, if any, commercial vehicles; bicycles, motorcycles and very light vans only, perhaps; and, of course, horses are a rather different proposition, as they have a very different sort of "life" cycle). Is it not the case with most commercial vehicles that, obsolescence aside, a sufficiently heavy overhaul can generally restore them to something close to an as new condition for less money than actually buying a new one, and that the only reason that new vehicles are, in fact, bought is either that the improvements in the design of the new ones make it worthwhile or that the old ones are in some way obsolete that make them relatively less economic to run now than they were when new? Again, I don not have figures, so may be wrong, but this seems more consistent with how vehicle operators actually behave than other models posited so far.

QuoteWe should think beyond rail vehicles, too, as rail vehicles have longer lives than most of the other vehicles in the sim. The typical commercial lifespan of trucks, aircraft, and bulk carriers is shorter. And come to think of it with rail vehicles, we see 50yo units in service and tend to assume that all units built 50 years ago would still be economic to run. Is that generally the case or were they just the over-engineered or underutilised ones?

That's interesting - I'd have thought that ships would have had a longer lifespan than railway vehicles; do passenger ships, at least, not last more than 30 years generally? I have some doubts that the long-lived rail vehicles were uneconomically over-engineered or underutilised, however: many of the Edwardian railway carriages surviving in the 1960s had been used heavily throughout their long lives, and most were of a far flimsier construction (wooden bodied) than their replacements (which have lasted far less long, largely for reasons of obsolescence in not meeting modern safety standards and expectations of passenger amenity, rather than because they have worn out per se: many 1950s era carriages live on in preserved railways or for special excursion work, often being hauled by the steam locomotives operating on the main line for enthusiasts discussed above). The oldest trains operating in the UK are on the Isle of Wight - 1938 stock from the London Underground, which had been used very intensively indeed until the 1980s when it was withdrawn and transferred to the Isle of Wight (after receiving an overhaul and conversion of its traction equipment from 4th rail to 3rd rail), replacing London Underground stock from the 1920s that had operated on the Island since the end of steam haulage in the 1960s. Since the design of Underground trains was for decades based on the highly successful 1938 stock, it seems improbable to consider it uneconomically over-engineered; and, although duties on the Isle of Wight are comparatively light, the services on the entire island are operated by a handful of trains. Successful designs tend to last the longest, which tends to indicate that being physically worn-out is not usually the prime driver for replacement (although if a vehicle is coming up for its overhaul and the choice is to pay £X to overhaul it or £X * Y to buy a new one, the fact that the older vehicles need an overhaul is often a relevant consideration.

Quote
I don't know if it has been mentioned already, but, generally, the life expectancy of trams and buses is about 20~25yrs.

This one reason that the obsolescence defaults were set to 15 years for 'buses, 25 years for trams and 30 years for rail vehicles. Thank you for the information, however.

Physics
Quote from: neroden
It did not really  work if we don't include convoy mass in calculations. I believe for locomotives fuel consumption will be quite different with empty/full convoy.

What's that sound that I hear? The distinctive clunk of a can of worms being opened, I think! This issue goes to how we compute the various elements that go into the per kilometre running cost. If we imagine that per kilometre maintenance cost accounts for fuel plus regular wear-based maintenance, then increasing the per kilometre cost by a function of the load hauled and/or speed would increase, effectively, the charge for maintenance as well as fuel, and I am not sure that it is accurate. (If it so happens that the per kilometre maintenance costs increase in about the same way with speed/load as fuel consumption, then that is very convenient, but I rather suspect that they don't).

So, we are then faced with adding a further layer of complexity, and, importantly, a further parameter that all Experimental pakset maintainers will have to add to all powered vehicles (including the vast number of vehicles in Pak128.Britain). Because of the large cost of doing this, we need to be very, very sure that it is worth the cost; I'd be interested in thoughts on that issue (especially given that developers concentrating on this will preclude us from doing other things in the same time).

Quote from: nerodenI think the first code change which needs to be made is a saner treatment of time, distance, and speed in simutrans.  Which I'm working on, with difficulty.

If we can figure out the number of ticks in a "vehicle hour", then with a standard definition of 1 km = some number of tiles, Bernd's physics model should hold us in good stead

I think that we may be closer to that than you seem to suggest, unless I have missed something: I already calculated fairly precisely (with the help of Prissi) how Simutrans works out speed in relation to the length of a tile, and then computed the tile length, journey and waiting times all pegged to that scale: in Pak128.Britain-Ex, one tile is 250m squared (each side being 250m). The only reason that waiting times may appear to be calculate differently to journey times is that they are reduced by a factor to compensate for the fact that, in reality, people have access to timetables, and are more likely to arrive shortly before their service is scheduled to depart than they are shortly after the last one has departed. The physics model, so far as I am aware, is based on the distance scale (250m/tile in Pak128.Britain-Ex), and is certainly intended to be realistic within its parameters.

QuoteThe second thing which is needed is appropriate ("realistic") weight, power, tractive effort, and air/water resistance numbers (and capacities, but I think those are good) for buses, lorries, boats, and ships.  (For ships these may be somewhat different from reality for "realistic" behavior, because ships float in water and all that.) The third is realistic weights (and capacities, but I think those are good) for railway wagons and carriages.  The fourth is appropriate power, tractive effort, and air/water resistance numbers for railway locomotives.

I think that we're not too far off on this, as a great many (indeed, most) vehicles have been researched historically and quite accurate information obtained. The areas with outstanding issues are the power of steam locomotives, on which I am working presently, and the values for rolling/water resistance. Currently, they are set as constants. I know that BerndGabriel was keen to have these as variables, but I had considered at the time that this might be too much for pakset maintainers. I added air resistance (which is separate from rolling/water resistance in Bernd Gabriel's model) as a tunable parameter to allow streamlining to be simulated, which it is for many vehicles. I'd be interested in people's views on the importance of allowing rolling/water resistance to be tunable as a physics parameter (which would have to be able to be set in both the vehicle and the way), as well as what sensible defaults should be. I do know that I read in the last few days in an authoritative book on steam railway locomotives that the quality of bearings and number of axles of earlier railway carriages, as well as the quality of the track, made for an inaccurate performance between early steam locomotives measured in their time and more "modern" locomotives (the book was written in about 1925). Of course, this would add yet another parameter for pakset authors to have to specify for every single vehicle and waytype, and yet another parameter to enter into our balancing spreadsheets.

As to the vastness of the number of vehicles, the usual approach to deal with this is to get a good range of vehicles balanced precisely, and then interpolate/extrapolate for the rest (and further individual examples can be balanced precisely as and when is convenient; it often turns out that little or no further adjustment is necessary). O
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

inkelyad

Quote
What's that sound that I hear? The distinctive clunk of a can of worms being opened, I think! This issue goes to how we compute the various elements that go into the per kilometre running cost. If we imagine that per kilometre maintenance cost accounts for fuel plus regular wear-based maintenance, then increasing the per kilometre cost by a function of the load hauled and/or speed would increase, effectively, the charge for maintenance as well as fuel, and I am not sure that it is accurate. (If it so happens that the per kilometre maintenance costs increase in about the same way with speed/load as fuel consumption, then that is very convenient, but I rather suspect that they don't).
Uh.
$/MW*hour (depends on total energy spend to travel/vehicle destruction, will include fuel cost, depends on convoy mass etc, can be calculated with physical model)

sdog

I don't think you should worry too much about parameter load for pakset maintainers, if you set up reasonable default values.
Some things are easily obtainable, e.g. the number of axles, this could help for rolling resistance and axle loads. Other things can be guessed or rather approximated with a little research, water resistance for instance. For steam engine the driver diameter is easily obtainable (the large wheels for locos, where the coupling rods connect) could help quite a lot to determine it's dynamics.

It is important thoug, to use good units for this, the best is real life units. The worst would be just a factor what the water resistance is in comparison to the Queen Elizabeth.

If you really want realistic, instead of game-balancing, values for the costs, just drop the costs altogether. Instead calculate resource or labour demand, and specify the functions of resource costs over time. In general energy costs drop while labour costs rise. Having a physical model to maintain over centuries is much easier than doing so for an economic model. It also saves you the work of having to research two different sets of data, economic and physics.

Labour demand can be based on vehicle type, with some scale factors for things like number of axles, power or so. Efficiency can be estimated from the introduction of technological advancements like tripple expansion engines. This could help to get an approximation of the fuel consumption.

Moblet, are costs for material (steel, wood) or for spare parts significant for the overall maintenance costs?

Please also remember there has been quite a change in the way vehicles are maintained. Spare replacement units are only something relatively new, started in WW2. Before only single spare parts were bought, and often almost everything was fixed themselves. This is especially so for steam engines, where third world repair shops still produce all spare parts themselves. There are even plans (perhaps already realized) to produce smaller tank engines again in india, for export in third world countries. When labour costs are low, steam locos are the cheapest to run, since coal is so cheap.

moblet

#58
moblet's graphs and the various models for increasing maintenance costs
Quote from: jamespetts on January 11, 2011, 12:22:42 AM
a number of intriguing conclusions can be drawn as follows:
(1) the sigmoid curve is the one that starts out the shallowest and ends up the steepest;
(2) the flat rate model currently in Standard is a long way behind all the others in varying incentive by use;
(3) the obsolescence model is very similar to a combination of flat plus linear degradation (because that, in effect, is what it is); and
(4) the obsolescence model is better than the linear increase in providing differential maintenance cost at the beginning and end of a vehicle's life.
Actually, none of these "conclusions" is quite right. It's important to remember that for the obsolescence model, the relationship between the km-based age and maintenance costs depends on the date of purchase. The cashflow chart implies that km is an independent variable - for the obsolescence model, it's not.
(1) The linear curve is shallowest in very early life, the sigmoid shallowest through mid-life, and the linear steepest late in life. This is the theoretical result, and also what the curves show.
(2) Only until the first overhaul. After that it's not significantly different from flat + overhaul.
(3) In theory, yes. In practice the pre-obsolescence maintenance costs need to be artificially low to produce a comparable dynamic.
(4) No, it's the other way around. The yellow line is way below the linear and sigmoids early on. And that's with artificially low pre-obsolescence maintenance costs.
Quote from: JamesThis is getting very complicated!...I'd very much like to see (1) a combination of the sigmoid and obsolescence; (2) a combination of overhauls and obsolescence; (3) a combination of sigmoid and overhauls; and (4) a combination of sigmoid, overhauls and obsolescence
You really want to code those? I'm not interested in looking at more complex ways of sidestepping fundamental real-world dynamics. I know you're attached to the obsolescence model, as I would be, both because it's already in place and because it was assumed to completely resolve equipment life cycles. As I said at the outset of this discussion, the primary driver is the relationship between capital cost and maintenance/operating costs that increase with usage, and obsolescence is a secondary driver. There is a place for an obsolescence model in a complex sim, but only as a secondary module to the primary life cycle model. An obsolescence model cannot be reliably fudged to substitute for the absence of the primary dynamic, either in gameplay or in the generation of a balanced parameter set. At this point, rather than be gung-ho about moving this forward, I suggest sleeping on it for some weeks/months and, if anything, reflecting on the dynamics rather than worrying about how to include them. It's usually only once one is familiar with a dynamic that they can see the most efficient way to model it.
Quote from: JamesAs to affecting performance, I am somewhat sceptical of this idea: what measure of performance would be affected? Vehicles do not generally get slower as they age, nor take longer to accelerate, nor become able to haul less weight
No, but these things can serve in the sim as a proxy for the real-world limitations of older units, and drive a player to use older units in a fashion similar to a real-world operator. But I think we can regard this idea as of low priority, and one only to be dug up after we're satisfied we've captured all the big-ticket real-world dynamics.
Quote from: JamesOne thing to consider: when a vehicle comes to the end of its economic life in reality, almost never is it scrapped and replaced with a brand new but otherwise identical vehicle: it is always replaced with something newer in design, and I do not think that this is a coincidence.
This is the case today, but the further back you go in time, the slower the pace of technological change, and therefore the less likely it was that when something expired something better had come along. Horses are the ultimate example.
Quote from: JamesIs it not the case with most commercial vehicles that, obsolescence aside, a sufficiently heavy overhaul can generally restore them to something close to an as new condition for less money than actually buying a new one, and that the only reason that new vehicles are, in fact, bought is either that the improvements in the design of the new ones make it worthwhile or that the old ones are in some way obsolete that make them relatively less economic to run now than they were when new?
I suspect chassis wear is a factor in this. You can't "overhaul" a bulk carrier or aircraft with a thoroughly fatigued and/or corroded hull. Heavy rail vehicles are ideally suited to rebuilds because their chassis can be overengineered, and rebuilt upon, more cheaply than for other modes. Another big factor is the economies of mass-production - road vehicles are mass-produced, so new manufacture is relatively cheaper than rebuilding (not to mention that the nearest factory equipped to rebuild may be on the other side of the world). Rail vehicles are pretty much hand-built, and any workshop equipped for major maintenance is also equipped for rebuilding, so there are few economies in original manufacture compared to overhauling.

Physics
Quote from: JamesWhat's that sound that I hear? The distinctive clunk of a can of worms being opened, I think! This issue goes to how we compute the various elements that go into the per kilometre running cost. If we imagine that per kilometre maintenance cost accounts for fuel plus regular wear-based maintenance, then increasing the per kilometre cost by a function of the load hauled and/or speed would increase, effectively, the charge for maintenance as well as fuel, and I am not sure that it is accurate.
I rather suspect that this is the case. Would you expect wear on a truck's chassis, motor, transmission, bearings, brakes and tyres to be the same per km regardless of whether it was empty or full? Would you expect a component to be more likely to fail under full load, or half load? This is the kind of stuff that puts older units on light duties.
Quote from: JamesSo, we are then faced with adding a further layer of complexity, and, importantly, a further parameter that all Experimental pakset maintainers will have to add to all powered vehicles (including the vast number of vehicles in Pak128.Britain). Because of the large cost of doing this, we need to be very, very sure that it is worth the cost; I'd be interested in thoughts on that issue (especially given that developers concentrating on this will preclude us from doing other things in the same time).
My thoughts are that a fair amount of effort has been put into building in complexities that model secondary effects, e.g. obsolescence, comfort, while some very fundamental primary dynamics appear to have been ignored or overlooked (e.g. energy and wear). It is disturbing to me to see objections to fundamental dynamics on the basis of complexity, especially when they would not be exceptionally complex to incorporate if they were properly considered, in favour of modules that add intricacies, and potentially distortions, to a flawed (in the sense that it is incomplete) general economic model. There is a risk that Simutrans Experimental could end up feeling more like a complex and abstract toy than a simulation game.
Physics has major economic implications in the sim because it determines not only a unit's maximum revenue potential, but also the sensitivity of its economic performance to changes in its operational role, a.k.a. versatility. We can't on the one hand say we want high historical realism, and on the other dismiss physics as introducing unnecessary complexity. As to how physics is modelled, my goal would be to minimise the number of parameters necessary in the sim to produce the desired dynamics. The decision of which dynamics/parameters to include and which to omit would ideally be based on quantitative analysis of their significance, not mental models thereof, or personal preferences, or mere debate, e.g. to include differential air resistances explicitly in the sim I'd want to first be sure that it was going to have a real impact on gameplay.
********************
Quote from: sdogIf you really want realistic, instead of game-balancing, values for the costs, just drop the costs altogether.
sdog's done it again! It wouldn't be entirely stupid to draw a line between physics and economics, and forget all the economic stuff for a while and just focus on the physics representation in the sim. After all, the economic stuff can't be done properly until the physics are finalised anyway. Trying to keep both balls in the air is a recipe for confusion, and also for panic when any discussion of physics infringes on existing code or ideas for the economics.
Quote from: sdogMoblet, are costs for material (steel, wood) or for spare parts significant for the overall maintenance costs?
I won't stick my neck out on that one, as I can think of examples either way (e.g. replacing a tyre vs replacing a head gasket). I suspect this relationship has changed over time, especially as we've increasingly gone from hand-building replacement parts to buying (often mass-produced) replacement components off the shelf, and once managers adopted life cycle costing, designers paid increasing attention to ease of maintenance. Plus labour has become relatively more expensive, and raw materials relatively cheaper, over time.
Quote from: sdogPlease also remember there has been quite a change in the way vehicles are maintained. Spare replacement units are only something relatively new, started in WW2. Before only single spare parts were bought, and often almost everything was fixed themselves.
As you said.

sdog

I think i have to clarify a bit what i meant with my last post. I think it is quite futile to try to reconstruct the costs of historic equipment, for so many aspects, and doing this in any way consistently. The physical properties can be reconstructed, with some work. We could also get some costs with some assumptions. This would require building a good model, the first step thereof would be identifying what can be neglected. I expect this would be quite a difficult task.

The question here is, do we actually need or want realistic costs for the sim? Perhaps it's much better to have plausible parameters for engines, providing a weak ordering. An A4 is faster and more powerful than a Jinty. Besides that the values can be spread widely as long as they don't break the economics and some limits. Historical texts will provide some material for this weak ordering.

The physics approach should provide some intrinsic balancing, or rather a state that is consistent enough that the economy could be balanced around it. (For an accurate physical model, it would be a very nice test for the simulation if the parameters of the economic balancing would reflect reality in any way.)

The other model, with plausible but arbitrary values, requires to find the values in a consistent way. You can tune it from the beginning to be easier to balance. Care is required not to get lost in historic details, and i doubt it will lead any where to try putting the puzzle-pieces you find together to get the bigger picture.

We shouldn't forget, even if we work out a beautiful and detailed physics model and also have a robust and realistic economic model, we still have an extremely rough and very arbitrary sociological model.
The interactions of those three will be awfully complex, and i fear even in real live only roughly understood.

Just remember, we do not cover fare at all! Perhaps the most important socio-oeconomic factor relevant for the sim. Theres also hardly a way to do it at the moment, since fare has to be treated in different sets of value. How much is the money worth for a passenger, how much is it worth for a passenger to pay it. Historic example, if the fare is as expensive as a weeks wage people just walked, a healthy person can cover 500 km in a week!

The fare couples sociological aspects to the economy via revenue per pax and ridership. Through it both are coupled to physics aspects, technological advance lowered the (relative price of) fares.

The rough way to build a model could be: Find all known effects possibly influencing your system. Quantify them, if not possible estimate. Identify the irrelevant.
Reduce the complexity through approximations. Check if this structural model provides expected behaviour under given conditions. If not either refine your model or if there can be other unknown effects, model them based on their behaviour. (Build a hypothesis on the nature of those effects and find someone you can convince to design an experiment for that.)

jamespetts

Apologies all for the delay in replying to this fascinating discussion: I have spent a great deal of time of late building then setting up my lovely new computer, so have been somewhat distracted from the world of Simutrans, and am now returning slowly to the fold.

I think that, as Moblet implied recently, the best approach is to start by working out what we need to model, then thinking about how we model it. We should aim to produce a definitive list of all the "primary drivers", as Moblet terms them, that are not already simulated in Simutrans-Experimental that need to be included. All the existing "secondary drivers" (such as obsolescence) can remain, as there's no advantage in removing them (and, indeed, great disadvantage if they are indeed true drivers, whether secondary or not). We should keep the list of things that need to be included confined to those that really do need to be included so as to minimise the amount of work to be done in implementing them, but we should not leave off anything that really does need to be included, or else our exercise will be lacking in value.

From discussions so far, might I tentatively suggest the following provisional list, and invite comments on things that ought be added or removed:

Primary drivers - necessary

  • Time-based vehicle maintenance (already in the code, needs to be added to paksets only)
  • Usage/weight-based maintenance costs for ways
  • Some simulation of the effect of wear on vehicles per unit of use (either by distance or by power *distance or similar)

Primary drivers - query for further consideration of necessity

  • Power-based computation of per-kilometre running costs for vehicles
  • Credit interest rate for players' bank accounts
  • Variable rolling resistances for vehicles and ways
  • Variable brake forces for vehicles (vehicles with lower brake forces having to start braking sooner)
  • Rail speed limits depending on signal spacing (requiring the player to balance speed and capacity carefully)

Once we have a clear idea of what drivers need to be implemented, we can then discuss how they should be implemented. Any comments on the above list?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

#61
the braking forces would be an interesting and welcome addition, as it is a bit odd that a train going 200km/h will stop suddenly at the end of the platform.

I don't think variable rolling resistances for vehicles and ways are important or necessary, unless you want to remove speed limits of ways altogether. Technically, the only reason to have speed limits at all, is because the roads are not suitable for higher speeds due to safety concerns.

The spacing of signals and speed limits are also interesting, but I'm not sure how this will work. In the game, currently, a spacing above 6 will cause some accordion effects, because the faster train behind will not path find far enough ahead to realize it is stuck behind a slower train and slow down accordingly. However, having a maintenance cost on each signal might be good, because more signals allow more capacity, but would increase cost and maintenance.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

Quote from: jamespetts on January 24, 2011, 12:15:30 AMthe best approach is to start by working out what we need to model, then thinking about how we model it.
What I was driving at here was to step back a bit further and look at the complete picture, and to then assess every proposal in the context of the complete picture. As we're tinkering with a system we need to maintain a total system view at all times. Is there, among the Experimental documentation, a brief but comprehensive list of what dynamics are modelled? Not just of what's unique to Experimental, but of everything. That would be one starting point. Another process would be to start a very rough sketch of the dynamics that one might consider including if one was building a sim from scratch, e.g:

Macro-economic
Cost of capital, or interest rate
Inflation
Market cycles

Micro-economic
Capital vs operating cost trade-off
Wear on permanent way
Fixed & variable operating costs
Depreciation
Credit rating & loan arrangements

Demographic
.
Supply Chains
.
Right-of-way
.
Physics
.
etc

Then we can assess and sort these into two buckets, "include" and "don't include". Doing it this way means we are aware of what real-world dynamics we aren't including, and therefore what implications that holds for executing the included ones. We may also:
- be able to think of ways to compensate for some of the omitted dynamics
- find that some of them can be adequately captured within another dynamic and therefore don't require coding
- be able to proceed in such a manner that we include the dynamics we know we want to include, with a design that allows us to easily add any or all of the dynamics that we aren't yet sure about, should testing reveal that we need them.

As I'm sure you've discovered, some dynamics crash into each other too, for example if train braking distances are able to exceed signal spacing it creates potential problems that require effort to be put into thinking and coding to solve problems instead of enhancing the game. If we see these kinds of conflicts coming we can save ourselves having to solve problems post-haste, and our best chance of spotting these conflicts is to keep the system view in front of us at all times.
QuoteRail speed limits depending on signal spacing (requiring the player to balance speed and capacity carefully)
A first question on this: in the real world, if the next signal is red, the present signal is a caution with a reduced speed limit. Has that dynamic been entertained in Simutrans development?

sdog

QuoteWhat I was driving at here was to step back a bit further and look at the complete picture, and to then assess every proposal in the context of the complete picture. [...] Doing it this way means we are aware of what real-world dynamics we aren't including, and therefore what implications that holds for executing the included ones.
This is also in my opinion the way to go.

Quote from: james
- Variable brake forces for vehicles (vehicles with lower brake forces having to start braking sooner)
- Rail speed limits depending on signal spacing (requiring the player to balance speed and capacity carefully)
I'm not sure if it is too wise to really go into this. Signals are finnicky enough already. (Perhaps one could even get rid of some inbetween in the long run) Break force could be quite interesting, but it will interfere with signaling.

Experimental already has quite a large amount of new features. A consolidation phase would be quite good for it now. Moblets approach is quite good there. Perhaps this process should also critically review features already implemented and consider if they are required for the model, represent the reality you want to simulate and what they cost (cpu time, balancing effort, playability). Being quite skeptic there and perhaps having some hard choices could mean quite an improvement or easier development in the long run.

jamespetts

Quote from: moblet on January 24, 2011, 01:42:48 PMIs there, among the Experimental documentation, a brief but comprehensive list of what dynamics are modelled? Not just of what's unique to Experimental, but of everything. That would be one starting point.

No, there is no such list, either for Standard or Experimental. I'm not sure how one would go about compiling such a list - what exactly would count as a dynamic modelled? One couldn't just list features, as many or even most dynamics might well be emergent properties of multiple features, some of which may be very complicated, and some of which unintended (and, of those unintended, some may be desirable and some undesirable).

The approach that I have taken so far when working with Experimental is, starting from Standard, to examine, after having played Standard for quite a while, where players are incentivised to make decisions that are substantially deviant from the decisions that they would be incentivised to make were the world of Simutrans the real world, then try to find what element of the simulation of reality is missing and fill it in: that is why we have comfort and loading times, for example, as, in Standard, there is no incentive to use short-distance vehicles on short-distance routes and long-distance vehicles on long-distance routes.

Your approach so far seems to have been to ask the slightly different but equally useful question of what elements of the simulation of reality are missing such that player profitability is distorted, excessively favouring established players over new players, which seems like a good way to continue. As noted above, I am not sure how one would go about listing all dynamics modelled in that way. If you'd like to have a go, however, I'd be interested to see what you come up with.


QuoteAnother process would be to start a very rough sketch of the dynamics that one might consider including if one was building a sim from scratch, e.g:

Macro-economic
Cost of capital, or interest rate
Inflation
Market cycles

Micro-economic
Capital vs operating cost trade-off
Wear on permanent way
Fixed & variable operating costs
Depreciation
Credit rating & loan arrangements

Demographic
.
Supply Chains
.
Right-of-way
.
Physics
.
etc

Then we can assess and sort these into two buckets, "include" and "don't include". Doing it this way means we are aware of what real-world dynamics we aren't including, and therefore what implications that holds for executing the included ones. We may also:
- be able to think of ways to compensate for some of the omitted dynamics
- find that some of them can be adequately captured within another dynamic and therefore don't require coding
- be able to proceed in such a manner that we include the dynamics we know we want to include, with a design that allows us to easily add any or all of the dynamics that we aren't yet sure about, should testing reveal that we need them.

The difficulty with this approach is that it may well not take sufficient account of the very real resource management issues that we have in developing Simutrans-Experimental that make adding each substantial new feature take many months of implementation in the code, testing, bug reporting/fixing and then implementation (if applicable) into the pakset and further reporting/testing, during which time the game is relatively unstable, and fewer people incentivised to play it (meaning fewer people testing the other features, fewer people being drawn into the Simutrans-Experimental player community, thus reducing the pool of possible future developers, etc.). I wonder whether we need a balancing spreadsheet for developers! ;-)

In practical terms, we need to look at making the minimum changes necessary to acheive a functioning economic model (unless we can find a few skilled developers with lots and lots of time on their hands who are able and willing to dedicate much of it to Simutrans-Experimental and its paksets). That is why, I think, the approach has to be to ask "what dynamics is Simutrans-Experimental missing without which critical features of the economy cannot be simulated, resulting in significant distortions that render balancing impossible"? Being parsimonious with the features will allow us to build a better Experimental within a reasonable timeframe. Larger changes may be able to come later, when Experimental is more established and there are more developers able to dedicate their time to it.


QuoteAs I'm sure you've discovered, some dynamics crash into each other too, for example if train braking distances are able to exceed signal spacing it creates potential problems that require effort to be put into thinking and coding to solve problems instead of enhancing the game. If we see these kinds of conflicts coming we can save ourselves having to solve problems post-haste, and our best chance of spotting these conflicts is to keep the system view in front of us at all times.A first question on this: in the real world, if the next signal is red, the present signal is a caution with a reduced speed limit. Has that dynamic been entertained in Simutrans development?

No - there seems to be a general reluctance amongst Simutrans users to increase the complexity/depth of the simulation of railway signalling.

Quote from: sdog on January 24, 2011, 07:05:28 PM
Experimental already has quite a large amount of new features. A consolidation phase would be quite good for it now. Moblets approach is quite good there. Perhaps this process should also critically review features already implemented and consider if they are required for the model, represent the reality you want to simulate and what they cost (cpu time, balancing effort, playability). Being quite skeptic there and perhaps having some hard choices could mean quite an improvement or easier development in the long run.

I have been trying to have a consolidation phase for quite a long time! The difficulty is that significant balancing or playability issues are found in testing which then require substantial changes to the code to be made. This is why I suggest the parsimonious version of the above, asking which critical dynamics are omitted the absence of which makes good balancing impossible. We can then implement the minimum of new features necessary to enable balancing to work properly, and concentrate otherwise on increasing stability and producing pakset assets, tuning and testing.

As to removing features, we should not be too hasty to do that not least because removing a feature is as major a change as inserting it in the first place, and making major changes without a very strong reason is not really consistent with a consolidation phase. One feature, however, removal of which might be considered is the feature by which the generation of passengers is distributed over different geographical distances: that feature was initially coded (shortly) before I came up with the idea of journey time tolerances, and it might be possible for that feature (journey time tolerances) to be used (with or without adjustment in the paksets and/or code) to fulfil the originally intended function of the journey distances model, although careful consideration would be needed to ensure that nothing important is lost in the process.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

for now, of all the macro and micro economics listed, I think the one major thing that is lacking are incentives for expansion, random mission objectives that may come up from time to time.

Challenges that cities might ask your company to do, like linking up their town with other towns and meeting a minimum average speed for that line within an allotted time frame for a reward. It would then be up to the player to take up such an offer or not, as the game may ask, at random, for very high standards which might be impossible to do or cost more than the reward.

There's not much incentive for a player to expand their network, as it is now.

I think the other factors can be replicated in game with the current set of editable variables.
The only exception would be the credit rating/loan, which doesn't feel right. A loan should be an up front, lump sum, boost in money in the bank.


Oh, one other thing, whatever happened to the feature where starting money varied depending on starting year?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

#66
Quote from: jamespetts on January 26, 2011, 09:36:00 AM
No, there is no such list, either for Standard or Experimental. I'm not sure how one would go about compiling such a list - what exactly would count as a dynamic modelled? One couldn't just list features, as many or even most dynamics might well be emergent properties of multiple features, some of which may be very complicated, and some of which unintended (and, of those unintended, some may be desirable and some undesirable).
Might have to list both "dynamics" and "features" and see how to line them up. Every feature of the game should have been put there to represent, or help represent, some dynamic, or to help the player manage that dynamic.
Quote from: JamesThe approach that I have taken so far when working with Experimental is, starting from Standard, to examine, after having played Standard for quite a while, where players are incentivised to make decisions that are substantially deviant from the decisions that they would be incentivised to make were the world of Simutrans the real world, then try to find what element of the simulation of reality is missing and fill it in
I think that is a very useful exercise but is unlikely to produce a good outcome, or do so efficiently, if adopted as a development approach. It's a bit like the boy racers who bolt something on to their car to make it go faster, then bolt something else on, then bolt something else, but then their car keeps breaking because they never thought about whether each component can support the increased performance demands. Or, for another analogy closer to home, the difference between one's Simutrans city expanding in a controlled fashion, where one sets out the street grid and provides transport infrastructure (or at least the space for it), or whether the sim is allowed to bolt on streets and buildings wherever it likes without thinking about how the whole city is going to function. In the latter case some of what was built ends up having to be knocked down in order to produce an acceptably efficient city, and there is conflict between keeping what's established and having an efficient city.
Quote from: JamesYour approach so far seems to have been to ask the slightly different but equally useful question of what elements of the simulation of reality are missing such that player profitability is distorted, excessively favouring established players over new players, which seems like a good way to continue.
That is not my approach, that is just one of the balances that I think the game needs to strike. My approach, in as few words as possible, is to see the forest, and see every tree in the context of its place in the forest. Right now I feel like we're just running from tree to tree.
Quote from: JamesI am not sure how one would go about listing all dynamics modelled in that way. If you'd like to have a go, however, I'd be interested to see what you come up with.
Happy to start, but is only worth doing if a view of the forest will actually get used.
Quote from: JamesThe difficulty with this approach is that it may well not take sufficient account of the very real resource management issues that we have in developing Simutrans-Experimental that make adding each substantial new feature take many months of implementation in the code, testing, bug reporting/fixing and then implementation (if applicable) into the pakset and further reporting/testing, during which time the game is relatively unstable, and fewer people incentivised to play it (meaning fewer people testing the other features, fewer people being drawn into the Simutrans-Experimental player community, thus reducing the pool of possible future developers, etc.). I wonder whether we need a balancing spreadsheet for developers! ;-)
This is ultimately why I'm proposing this approach. Bolting on a substantial new feature just because it seems like a good idea and it's the tree in front of us, without an objective assessment of whether it is the best use of programming resources, or a clear vision of whether it is even relevant to the ultimate goal, carries a major risk of wasting effort, and wasting effort is a pretty good way to demotivate volunteers. We do indeed need a balancing, and prioritisation, process for development, and it falls under the "project co-ordination" task. If you see yourself as the co-ordinator of the Experimental project, then this is your job, and it's one of the most important tasks you have. You can delegate evaluation and design work but "seeing the trees and the forest" cannot be delegated.
Quote from: James
In practical terms, we need to look at making the minimum changes necessary to acheive a functioning economic model (unless we can find a few skilled developers with lots and lots of time on their hands who are able and willing to dedicate much of it to Simutrans-Experimental and its paksets). That is why, I think, the approach has to be to ask "what dynamics is Simutrans-Experimental missing without which critical features of the economy cannot be simulated, resulting in significant distortions that render balancing impossible"? Being parsimonious with the features will allow us to build a better Experimental within a reasonable timeframe. Larger changes may be able to come later, when Experimental is more established and there are more developers able to dedicate their time to it.
The minimum work required to reach the ultimate goal is unlikely to be found by selecting the shortest apparent route at every turn. That's how one ends up doing lots of remedial coding because some subsequent feature, or even long-intended feature, is incompatible with the design.
Quote from: James
No - there seems to be a general reluctance amongst Simutrans users to increase the complexity/depth of the simulation of railway signalling.
And fair enough too. It is one of the obstacles to mastering the basics quickly.
Quote from: James
I have been trying to have a consolidation phase for quite a long time! The difficulty is that significant balancing or playability issues are found in testing which then require substantial changes to the code to be made.
This is a natural occurrence when dynamics aren't coded faithfully and efficiently, i.e. in such a way that playability issues can be resolved at the parameter level. Solution: more thoroughly think through how something is going to work, and how it can be tweaked, when designing it; try to generate multiple viable designs and evaluate them against these criteria.
Quote from: JamesThis is why I suggest the parsimonious version of the above, asking which critical dynamics are omitted the absence of which makes good balancing impossible. We can then implement the minimum of new features necessary to enable balancing to work properly, and concentrate otherwise on increasing stability and producing pakset assets, tuning and testing.
It will be risky to do this without first establishing and then maintaining a full system view, because changes made to facilitate balancing would be quite likely to impact on many elements of the sim. Same goes for removing anything.
Quote from: AEOChallenges that cities might ask your company to do, like linking up their town with other towns and meeting a minimum average speed for that line within an allotted time frame for a reward.
Seems to me the sim is recording a lot of the right information for this kind of thing to be possible (e.g. what's connected to what, journey times, etc). The way development is currently conducted this kind of thing can't be considered until game development has stopped, because the code is a moving target so anything built upon it may become obsolete. If Experimental was designed more from the ground up, with a vision from the outset of what scenario challenges it would be able to offer, then it could possibly be developed in parallel.

Spike

#67
I'll start a list of the dynamics/features, and the ones with better knowledge of STE might expand from this:

Vehicles

Achievable top speed
Acceleration
Waiting times
Capacity
Comfort
Price
Running cost
Maintenance
Pathfinding
Speed bonus
Ecological impact (?)


Ways

Weight limits
Speed limits
Signaling
Maintenance
Electrification


Stations

Capacity
Goods/mail enabled
Waiting times
Price
Maintenance
Catchment area


Depots

Price
Maintenance


Industries

Production rate
Storage capacities
Power supply
Workers


Economy

Taxes (?)
Inflation (?)
Loans/interest rate (?)
Goods price/demand fluctuations (?)
Max. allowed time of transport for goods ?)


jamespetts

Quote from: moblet on January 27, 2011, 11:12:01 AM
Might have to list both "dynamics" and "features" and see how to line them up. Every feature of the game should have been put there to represent, or help represent, some dynamic, or to help the player manage that dynamic.

Hmm - but how do we count a feature? Is it a feature that, when a user presses the left mouse button with the inspection tool activated, a clicking sound can be heard? There are a great many features that are non-economic - features that either relate to the interface or are cosmetic (for example, the "groundobj" terrain decoration). I presume that we exclude those? That still leaves the question of where one feature ends and another begins. Take the private cars, for example: the code for whether passengers use a private car is bound up in the same code as decides where their destinations are and which route to take for the trip generally; it also generates the little private car graphics that one sees in the game, which impacts on the routing of vehicles (generating congestion for player vehicles), and impacts on the city growth algorithms by the mechanism of congestion (congestion is a function of the density of the city, the amount of road space in the city and the number of car journeys that begin or end in that city; the higher the congestion, the lower the growth rate until, at 100 and above, growth stops entirely). Is congestion a separate feature from private car ownership? Is it part of the private car model; or is it part of the city growth model? Do we have to count it twice, once when we deal with passenger routing and once when we deal with the city growth model, or do we describe the city growth model incompletely and then describe the congestion model, including its impact on city growth, elsewhere?

I'm not sure that it's easy to come up with a meaningful list. One might attempt a narrative, but it would be very, very, very long: essentially, a natural language version of all of the economic aspects of the code. If one were to simplify, one might miss crucial detail that could throw balancing off if balancing was reliant on having a precise description of the workings of Simutrans-Experimental from which to work.

Might it not be better simply to use existing sources of information (the wiki and the list of Simutrans-Experimental specific features)? This might be considerable duplication of work otherwise, and I am still not quite sure what such a list might look like or how exactly it might be used (the latter, of course, informing the former).

QuoteI think that is a very useful exercise but is unlikely to produce a good outcome, or do so efficiently, if adopted as a development approach. It's a bit like the boy racers who bolt something on to their car to make it go faster, then bolt something else on, then bolt something else, but then their car keeps breaking because they never thought about whether each component can support the increased performance demands. Or, for another analogy closer to home, the difference between one's Simutrans city expanding in a controlled fashion, where one sets out the street grid and provides transport infrastructure (or at least the space for it), or whether the sim is allowed to bolt on streets and buildings wherever it likes without thinking about how the whole city is going to function. In the latter case some of what was built ends up having to be knocked down in order to produce an acceptably efficient city, and there is conflict between keeping what's established and having an efficient city.

Interesting - you edit your cities? There's divergence of play style there, I think.

QuoteThat is not my approach, that is just one of the balances that I think the game needs to strike. My approach, in as few words as possible, is to see the forest, and see every tree in the context of its place in the forest. Right now I feel like we're just running from tree to tree.

I see. And what does that entail in practical terms? How do you see the significance of the fact that Experimental is not a stand-alone project, but is parasitic on Simutrans-Standard, its raison d'etre simply being to do whatever Simutrans-Standard does with more economic and operational depth and realism?

QuoteHappy to start, but is only worth doing if a view of the forest will actually get used.

In practical terms, how would one use a list/narrative of dynamics for balancing purposes? Is the idea that it would make it easier to see what is missing or mis-designed?

QuoteThis is ultimately why I'm proposing this approach. Bolting on a substantial new feature just because it seems like a good idea and it's the tree in front of us, without an objective assessment of whether it is the best use of programming resources, or a clear vision of whether it is even relevant to the ultimate goal, carries a major risk of wasting effort, and wasting effort is a pretty good way to demotivate volunteers. We do indeed need a balancing, and prioritisation, process for development, and it falls under the "project co-ordination" task. If you see yourself as the co-ordinator of the Experimental project, then this is your job, and it's one of the most important tasks you have. You can delegate evaluation and design work but "seeing the trees and the forest" cannot be delegated.

Do you have any suggestions as to how this process might work better than it does now? I do have a good idea in the abstract of what I want Simutrans-Experimental to be, but it is not always easy to think of all the things that need to be simulated at once. Often, I think of a new thing that needs to be simulated only after testing (by me or others), or observing or reading about real transport networks, or sometimes just at random when thinking about Simutrans, and on some occasions realise that such a feature would model an important dynamic the omission of which causes problems.

QuoteThis is a natural occurrence when dynamics aren't coded faithfully and efficiently, i.e. in such a way that playability issues can be resolved at the parameter level. Solution: more thoroughly think through how something is going to work, and how it can be tweaked, when designing it; try to generate multiple viable designs and evaluate them against these criteria.

The difficulty that I have had so far is knowing exactly what dynamics I need to be modelling in the first place; but perhaps you could assist with that? Indeed, is that in a sense what you're proposing here...?

Might I ask, Moblet, perhaps I'm being unintentionally pedantic about the listing of features, etc.: what had you imagined that an overall system view would look like? How detailed need the descriptions of the features/dynamics be, and to what extent would we need painstakingly to calculate every economically significant emergent property of other features/dynamics or sets thereof? What do you imagine us then doing with that information such as to create the most efficient approach to realising the design goal of a well-balanced Simutrans-Experimental: in other words, a well balanced version of Simutrans that does what Simutrans-Standard does, but with greater economic and operational depth and realism? I'm not quite clear at this juncture about what exactly that such a process would entail.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

#69
Extracting the relevant dynamics from a system, describing, analysing and finaly recommending a change seems to be exactly the thing Moblet is doing for a living? The nice thing is, here one could always look it up in the source code, a bit more difficult IRL :-]


Oh, i also think i have to clarify something here, since i think my texts often read quite overcritical. James i think you did in particular a brilliant start with experimental. If it's only analysed nothing ever gets done, by just implementing concepts that seemed obviously missing you get things moveing. It's also very likely those are the most lacking aspects.

moblet

Quote from: Hajo on January 27, 2011, 11:26:27 AM
I'll start a list of the dynamics/features
Great start Hajo. Can we split this post into a new topic on the documentation board? Sounds like it might be a useful exercise for familiar and unfamiliar participants alike. I suggest largely completing the exercise for Standard before starting on Experimental.
Quote from: JamesTake the private cars, for example: the code for whether passengers use a private car is bound up in the same code as decides where their destinations are and which route to take for the trip generally;
I don't know what you mean by "bound up". These are two separate computational tasks, one of which applies to other modes, so there is no reason for them to be "bound up" and a compelling case for coding them as separate modules. They are connected, but from a programming design perspective all that is required is that one module invokes the other. If they have not been designed and built as separate modules then this is an example of complexity, and increased difficulty of subsequent alteration, that would not occur in a program that was carefully designed before it was built. That is not criticise the work that's been done, especially as it's an open source, volunteer gig, just an observation of how things seem to me, and perhaps a case for documenting, consolidating, and maybe reconfiguring in places, the way the Standard engine works.
Quote from: JamesIs congestion a separate feature from private car ownership? Is it part of the private car model; or is it part of the city growth model? Do we have to count it twice, once when we deal with passenger routing and once when we deal with the city growth model, or do we describe the city growth model incompletely and then describe the congestion model, including its impact on city growth, elsewhere?
The answers to these questions should have been determined before any of it was coded. Perhaps they were, and maybe the decisions were documented somewhere.
Quote from: James
One might attempt a narrative, but it would be very, very, very long: essentially, a natural language version of all of the economic aspects of the code.
The reason this narrative has been dragging on for so long is because we don't have any such document. What I envisage is more a case of a few points against each feature/dynamic describing what assumptions are made in the sim, and what the sim is supposed to represent. If we don't have that, and the code is our only reference, then we can't evaluate the code against what it's supposed to achieve, or properly consider alternative ways of coding.
Quote from: JamesMight it not be better simply to use existing sources of information (the wiki and the list of Simutrans-Experimental specific features)?
I think Hajo answered this question by starting his list. He didn't link to anything existing.
Quote from: JamesI am still not quite sure what such a list might look like or how exactly it might be used (the latter, of course, informing the former).
Think of it as a specification rather than a list.
Quote from: JamesInteresting - you edit your cities? There's divergence of play style there, I think.
The point is not about playing styles, it's about the long-term consequences of not thinking far enough ahead.
Quote from: JamesHow do you see the significance of the fact that Experimental is not a stand-alone project, but is parasitic on Simutrans-Standard, its raison d'etre simply being to do whatever Simutrans-Standard does with more economic and operational depth and realism?
Experimental is not parasitic, it is an extension of Standard. Experimental doesn't pick bits out of Standard, it builds additional features upon Standard's foundations. To take a parasitic approach one doesn't need to understand how Standard works, just identify the bits one wants to steal. To build an extension one has to first understand the foundation upon which one is building. So I see a process like this:
1. Document and understand what Standard does, and also what it doesn't do
2. Identify everything that Standard does that is undesirable, and what it doesn't do that is desirable
3. Develop designs that integrate the desired changes into the simplest possible game, coded in the simplest possible way
4. Assess each design against criteria such as coding hours required, modularity, expandability, simplicity of calibration, etc, and select one
5. Start building, and so on
Quote from: JamesIn practical terms, how would one use a list/narrative of dynamics for balancing purposes? Is the idea that it would make it easier to see what is missing or mis-designed?
One needs to know the specification to balance, but the specification has many more uses than that, including seeing what is missing or sub-optimally designed.
Quote from: JamesI do have a good idea in the abstract of what I want Simutrans-Experimental to be, but it is not always easy to think of all the things that need to be simulated at once.
Can you articulate that vision? Because I can't see what it is, and am concerned that it may contain fatal contradictions that will only otherwise become apparent after investing hundreds of hours into development trying to make work what cannot work (an open-ended process if one never realises that it can't work). I think a couple of steps have been skipped, including developing those abstract ideas into practical ones before rushing into coding Experimental. No, it is not easy to visualise everything at once, although it does become easier with practice. If all of those things are not documented in one place then (1) you will have great difficulty entertaining all of them at once and (2) no one else will be able to contribute.
Quote from: JamesThe difficulty that I have had so far is knowing exactly what dynamics I need to be modelling in the first place; but perhaps you could assist with that? Indeed, is that in a sense what you're proposing here...?
How can one possibly build a simulation model without first deciding what dynamics need to be modelled? Even if the model was sound one wouldn't know what it represented or how to interact with it. I can help, but only in a culture of developing understanding before trying to build the finished product.
Quote from: Jameswhat had you imagined that an overall system view would look like? How detailed need the descriptions of the features/dynamics be, and to what extent would we need painstakingly to calculate every economically significant emergent property of other features/dynamics or sets thereof? What do you imagine us then doing with that information such as to create the most efficient approach to realising the design goal of a well-balanced Simutrans-Experimental: in other words, a well balanced version of Simutrans that does what Simutrans-Standard does, but with greater economic and operational depth and realism? I'm not quite clear at this juncture about what exactly that such a process would entail.
I think we need to follow the steps I listed above.
As for evaluating what dynamics to include, it usually only takes a few minutes to evaluate the kind of difference a feature could make, and it's a good filter - if someone keeps insisting that an insignificant dynamic must be included, it shouldn't be difficult to produce a few calculations to shut them up and help them set their mind on something more significant. The evaluation process is what tells us which trees are big, and which ones are small. That is a picture that develops in one's mind over time, but the nature of a collaborative distributed effort means it also needs to be documented so we don't have to keep repeating our conclusions. To revisit some Simutrans history, this post lists things that "will never happen" because they were deemed insignificant, too difficult etc, but it doesn't present the assumptions/calculations that were used to reach the conclusions. Others have since revisited them and now some of these things are happening. We need to "prove" that something does or doesn't add anything to the game, or quantify the difference it will make so we can reach a sensible and defensible decision on whether or not to include it. Sounds like work but it takes out all the stress and confusion, and stops all the "why didn't you include x?" traffic, so in my experience it ends up feeling like less work.
Quote from: sdogExtracting the relevant dynamics from a system, describing, analysing and finaly recommending a change seems to be exactly the thing Moblet is doing for a living?
Good guess sdog! I have a degree in applied mathematics and used to analyse and model supply chains and expansion options for a living, especially mine-rail-port systems. Lost my health a few years back and had to quit work. Health is slowly improving - not long ago I couldn't have kept up with this discussion.
Quote from: sdogi think my texts often read quite overcritical
In the ones I've seen that is very rarely the case, and you seem to be aware of when translation difficulties could cause misunderstanding. You engage with the issues on a technical level, not a personal one, and you get straight to the heart of them, which is really valuable.
Quote from: sdogJames i think you did in particular a brilliant start with experimental. If it's only analysed nothing ever gets done, by just implementing concepts that seemed obviously missing you get things moveing.
I'll second this.

jamespetts

Quote from: sdog on January 28, 2011, 03:39:55 AM
Extracting the relevant dynamics from a system, describing, analysing and finaly recommending a change seems to be exactly the thing Moblet is doing for a living? The nice thing is, here one could always look it up in the source code, a bit more difficult IRL :-]

Oh to be able to debug reality...
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Spike

Quote from: moblet on January 28, 2011, 09:16:22 AM
Great start Hajo. Can we split this post into a new topic on the documentation board? Sounds like it might be a useful exercise for familiar and unfamiliar participants alike.

I've reposted the list over here:
http://forum.simutrans.com/index.php?topic=6736.msg64966#msg64966

ӔO

currently, I don't really think there is any feature that needs to be removed from experimental
http://forum.simutrans.com/index.php?topic=1959.0
there are enough features to give differentiation and specialization to various vehicles. It's all a matter of tweaking the settings.

In the previous version, there were not enough passengers generated.
In the current version, there are too many passengers generated.

We'll probably have to bounce around the settings like that for a few versions, until an ideal balance is struck.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Spike

I know it's very time consuming, but I think it's important that the developer(s) also play the game to get an impression what works well and what doesn't. Nowadays I see many pak set developers depend on spreadsheets and formulas, but at some point the proper tuning can only be done from experience by playing.

jamespetts

Quote from: moblet on January 28, 2011, 09:16:22 AM
I don't know what you mean by "bound up". These are two separate computational tasks, one of which applies to other modes, so there is no reason for them to be "bound up" and a compelling case for coding them as separate modules. They are connected, but from a programming design perspective all that is required is that one module invokes the other. If they have not been designed and built as separate modules then this is an example of complexity, and increased difficulty of subsequent alteration, that would not occur in a program that was carefully designed before it was built. That is not criticise the work that's been done, especially as it's an open source, volunteer gig, just an observation of how things seem to me, and perhaps a case for documenting, consolidating, and maybe reconfiguring in places, the way the Standard engine works.

The code in question looks like this:


/* this creates passengers and mail for everything is is therefore one of the CPU hogs of the machine
* think trice, before applying optimisation here ...
*/
void stadt_t::step_passagiere()
{
//@author: jamespetts
// Passenger routing and generation metrics.
const uint32 local_passengers_min_distance = welt->get_einstellungen()->get_local_passengers_min_distance();
const uint32 local_passengers_max_distance = welt->get_einstellungen()->get_local_passengers_max_distance();
const uint32 midrange_passengers_min_distance = welt->get_einstellungen()->get_midrange_passengers_min_distance();
const uint32 midrange_passengers_max_distance = welt->get_einstellungen()->get_midrange_passengers_max_distance();
const uint32 longdistance_passengers_min_distance = welt->get_einstellungen()->get_longdistance_passengers_min_distance();
const uint32 longdistance_passengers_max_distance = welt->get_einstellungen()->get_longdistance_passengers_max_distance();

const uint16 min_local_tolerance = welt->get_einstellungen()->get_min_local_tolerance();
const uint16 max_local_tolerance = max(0, welt->get_einstellungen()->get_max_local_tolerance() - min_local_tolerance);
const uint16 min_midrange_tolerance = welt->get_einstellungen()->get_min_midrange_tolerance();
const uint16 max_midrange_tolerance = max( 0, welt->get_einstellungen()->get_max_midrange_tolerance() - min_midrange_tolerance);
const uint16 min_longdistance_tolerance = welt->get_einstellungen()->get_min_longdistance_tolerance();
const uint16 max_longdistance_tolerance = max(0, welt->get_einstellungen()->get_max_longdistance_tolerance() - min_longdistance_tolerance);

const uint8 passenger_packet_size = welt->get_einstellungen()->get_passenger_routing_packet_size();
const uint8 passenger_routing_local_chance = welt->get_einstellungen()->get_passenger_routing_local_chance();
const uint8 passenger_routing_midrange_chance = welt->get_einstellungen()->get_passenger_routing_midrange_chance();

// DBG_MESSAGE("stadt_t::step_passagiere()", "%s step_passagiere called (%d,%d - %d,%d)\n", name, li, ob, re, un);
// long t0 = get_current_time_millis();

// post oder pax erzeugen ?
// "post or generate pax"
const ware_besch_t* wtyp;
if (simrand(400) < 300)
{
wtyp = warenbauer_t::passagiere;
}
else
{
wtyp = warenbauer_t::post;
}
const int history_type = (wtyp == warenbauer_t::passagiere) ? HIST_PAS_TRANSPORTED : HIST_MAIL_TRANSPORTED;

// restart at first buiulding?
if (step_count >= buildings.get_count())
{
step_count = 0;
}
if(buildings.get_count()==0)
{
return;
}
const gebaeude_t* gb = buildings[step_count];

// prissi: since now backtravels occur, we damp the numbers a little
const int num_pax =
(wtyp == warenbauer_t::passagiere) ?
(gb->get_tile()->get_besch()->get_level()      + 6) >> 2 :
max(1,(gb->get_tile()->get_besch()->get_post_level() + 5) >> 4);


// Hajo: track number of generated passengers.
city_history_year[0][history_type+1] += num_pax;
city_history_month[0][history_type+1] += num_pax;

// create pedestrians in the near area?
if (welt->get_einstellungen()->get_random_pedestrians() && wtyp == warenbauer_t::passagiere)
{
haltestelle_t::erzeuge_fussgaenger(welt, gb->get_pos(), num_pax);
}

// suitable start search
const koord k = gb->get_pos().get_2d();
const planquadrat_t* plan = welt->lookup(k);
const halthandle_t* halt_list = plan->get_haltlist();

minivec_tpl<halthandle_t> start_halts(plan->get_haltlist_count());
for (int h = plan->get_haltlist_count() - 1; h >= 0; h--)
{
halthandle_t halt = halt_list[h];
if (halt->is_enabled(wtyp)  &&  !halt->is_overcrowded(wtyp->get_catg_index()))
{
start_halts.append(halt);
}
}

INT_CHECK( "simcity 2282" );

// Check whether this batch of passengers has access to a private car each.
// Check run in batches to save computational effort.
const sint16 private_car_percent = wtyp == warenbauer_t::passagiere ? get_private_car_ownership(welt->get_timeline_year_month()) : 0;
// Only passengers have private cars
const bool has_private_car = private_car_percent > 0 ? simrand(100) <= (uint16)private_car_percent : false;

// Record the most useful set of information about why passengers cannot reach their chosen destination:
//  Too slow > overcrowded > no route. Tiebreaker: higher destination preference.
koord best_bad_destination;
uint8 best_bad_start_halt;
bool too_slow_already_set;

//Only continue if there are suitable start halts nearby, or the passengers have their own car.
if(start_halts.get_count() > 0 || has_private_car)
{
//Add 1 because the simuconf.tab setting is for maximum *alternative* destinations, whereas we need maximum *actual* desintations
// const uint8 max_destinations = has_private_car ? 1 : (welt->get_einstellungen()->get_max_alternative_destinations() < 16 ? welt->get_einstellungen()->get_max_alternative_destinations() : 15) + 1;
// Passengers with a private car will not tolerate second best destinations,
// and will use their private car to get to their first choice destination
// regardless of whether they might go to other destinations by public transport.

// Now that private cars also have a journey time tolerance and check whether the roads are connected, passengers *might*
// not be able to get to their destination by private car either, so the above is redundant.
const uint8 max_destinations = (welt->get_einstellungen()->get_max_alternative_destinations() < 16 ? welt->get_einstellungen()->get_max_alternative_destinations() : 15) + 1;

// Find passenger destination
for (int pax_routed = 0; pax_routed < num_pax; pax_routed += passenger_packet_size)
{

/* number of passengers that want to travel
* Hajo: for efficiency we try to route not every
* single pax, but packets. If possible, we do 7 passengers at a time
* the last packet might have less then 7 pax
* Number now not fixed at 7, but set in simuconf.tab (@author: jamespetts)*/

int pax_left_to_do = min(passenger_packet_size, num_pax - pax_routed);

// search target for the passenger
pax_zieltyp will_return;

const uint8 destination_count = simrand(max_destinations) + 1;

// Split passengers: between local, midrange and long-distance
// according to the percentages set in simuconf.tab.
// Note: a random town will be found if there are no towns within range.
const uint8 passenger_routing_choice = simrand(100);
const journey_distance_type range =
passenger_routing_choice <= passenger_routing_local_chance ?
local :
passenger_routing_choice <= (passenger_routing_local_chance + passenger_routing_midrange_chance) ?
midrange : longdistance;
const uint16 tolerance =
wtyp != warenbauer_t::passagiere ?
0 :
range == local ?
simrand(max_local_tolerance) + min_local_tolerance :
range == midrange ?
simrand(max_midrange_tolerance) + min_midrange_tolerance :
simrand(max_longdistance_tolerance) + min_longdistance_tolerance;
destination destinations[16];
for(int destinations_assigned = 0; destinations_assigned <= destination_count; destinations_assigned ++)
{
if(range == local)
{
//Local - a designated proportion will automatically go to destinations within the town.
if((float)passenger_routing_choice <= adjusted_passenger_routing_local_chance)
{
// Will always be a destination in the current town.
destinations[destinations_assigned] = finde_passagier_ziel(&will_return, 0, local_passengers_max_distance, k);
}
else
{
destinations[destinations_assigned] = finde_passagier_ziel(&will_return, local_passengers_min_distance, local_passengers_max_distance, k);
}
}
else if(range == midrange)
{
//Medium
destinations[destinations_assigned] = finde_passagier_ziel(&will_return, midrange_passengers_min_distance, midrange_passengers_max_distance, k);
}
else
//else if(range == longdistance)
{
//Long distance
destinations[destinations_assigned] = finde_passagier_ziel(&will_return, longdistance_passengers_min_distance, longdistance_passengers_max_distance, k);  //"Ziel" = "target" (Google)
}
}

INT_CHECK( "simcity 2371" );

uint8 current_destination = 0;

route_status route_good = no_route;

const uint16 max_walking_distance = welt->get_einstellungen()->get_max_walking_distance();
uint16 car_minutes = 65535;

best_bad_destination = destinations[0].location;
best_bad_start_halt = 0;
too_slow_already_set = false;

while(route_good != good && route_good != private_car_only && current_destination < destination_count)
{
// Dario: Check if there's a stop near destination
const planquadrat_t* dest_plan = welt->lookup(destinations[current_destination].location);
const halthandle_t* dest_list = dest_plan->get_haltlist();

// Knightly : we can avoid duplicated efforts by building destination halt list here at the same time
minivec_tpl<halthandle_t> destination_list(dest_plan->get_haltlist_count());

halthandle_t start_halt;

// Check whether the destination is within walking distance first.
// @author: jamespetts, December 2009
if(accurate_distance(destinations[current_destination].location, k) <= max_walking_distance)
{
// Passengers will always walk if they are close enough.
route_good = can_walk;
}

if(route_good != can_walk)
{
for (int h = dest_plan->get_haltlist_count() - 1; h >= 0; h--)
{
halthandle_t halt = dest_list[h];
if (halt->is_enabled(wtyp))
{
destination_list.append(halt);
ITERATE(start_halts, i)
{
if(halt == start_halts[i])
{
route_good = can_walk;
start_halt = start_halts[i];
// Mail does not walk, but people delivering it do.
break;
}
}
}
}
}

// check, if they can walk there?

if (route_good == can_walk)
{
break;
}

// ok, they are not in walking distance
// Check whether public transport can be used.
ware_t pax(wtyp); //Journey start information needs to be added later.
pax.set_zielpos(destinations[current_destination].location);
pax.menge = (wtyp == warenbauer_t::passagiere ? pax_left_to_do : 1 );
//"Menge" = volume (Google)

// now, finally search a route; this consumes most of the time

uint16 best_journey_time = 65535;
uint8 best_start_halt = 0;

ITERATE(start_halts,i)
{
halthandle_t current_halt = start_halts[i];

uint16 current_journey_time = current_halt->find_route(&destination_list, pax, best_journey_time);
if(current_journey_time < best_journey_time)
{
best_journey_time = current_journey_time;
best_start_halt = i;
}
if(pax.get_ziel().is_bound())
{
route_good = good;
}
}

// Check first whether the best route is outside
// the passengers' tolerance.

if(route_good == good && tolerance > 0 && best_journey_time > tolerance)
{
route_good = too_slow;

if(!too_slow_already_set)
{
best_bad_destination = destinations[current_destination].location;
best_bad_start_halt = best_start_halt;
too_slow_already_set = true;
}
}
else
{
// All passengers will use the quickest route.
if(start_halts.get_count() > 0)
{
start_halt = start_halts[best_start_halt];
}
}

INT_CHECK("simcity.cc 2882");

if(has_private_car)
{
const uint32 straight_line_distance = accurate_distance(k, destinations[current_destination].location);
uint16 time_per_tile = 65535;
switch(destinations[current_destination].type)
{
case 1:
//Town
time_per_tile = check_road_connexion_to(destinations[current_destination].object.town);
break;
case FACTORY_PAX:
time_per_tile = check_road_connexion_to(destinations[current_destination].object.industry);
break;
case TOURIST_PAX:
time_per_tile = check_road_connexion_to(destinations[current_destination].object.attraction);
break;
default:
//Some error - this should not be reached.
dbg->error("simcity.cc", "Incorrect destination type detected");
};

if(time_per_tile < 65535)
{
// *Tenths* of minutes used here.
car_minutes =  time_per_tile * straight_line_distance;
}
else
{
car_minutes = 65535;
}
}

if(car_minutes <= tolerance)
{
if(route_good != good)
{
// The passengers can get to their destination by car but not by public transport.
// Therefore, they will certainly use their car.
route_good = private_car_only;
}

else
{
// The passengers can get to their destination both by car and public transport.
// Choose which they prefer.

// Now, decide whether passengers would prefer to use their private cars,
// even though they can travel by public transport.
const uint32 distance = accurate_distance(destinations[current_destination].location, k);

//Weighted random.
uint8 private_car_chance = simrand(100);
if(private_car_chance >= 1)
{
// The basic preference for using a private car if available.
sint16 car_preference = welt->get_einstellungen()->get_base_car_preference_percent();

//First, adjust for distance. For very long-distance journies, cars are less popular.

if(distance > (midrange_passengers_max_distance * 3))
{
if(distance >= longdistance_passengers_max_distance)
{
car_preference /= 10;
}
else
{
const float proportion = ((float)distance - (float)(midrange_passengers_max_distance * 3.0F)) / (float)longdistance_passengers_max_distance;
car_preference /= (10 * proportion);
}
}

// Secondly, congestion. Drivers will turn to public transport if the origin or destination towns are congested.

// This percentage of drivers will prefer to use the car however congested that it is.
const sint16 always_prefer_car_percent = welt->get_einstellungen()->get_always_prefer_car_percent();

//Average congestion of origin and destination towns, and, at the same time, reduce factor.
uint8 congestion_total;
if(destinations[current_destination].type == 1 && destinations[current_destination].object.town != NULL)
{
congestion_total = (city_history_month[0][HIST_CONGESTION] + destinations[current_destination].object.town->get_congestion()) / 4;
}
else
{
congestion_total = (city_history_month[0][HIST_CONGESTION] / 1.33);
}
car_preference = ((car_preference - congestion_total) > always_prefer_car_percent) ? car_preference - congestion_total : always_prefer_car_percent;

// Thirdly adjust for service quality of the public transport.
// Compare best journey speed on public transport with the
// likely private car journey time.

INT_CHECK( "simcity 3004" );

const float proportion = ((float)best_journey_time / (float)car_minutes) * car_minutes > best_journey_time ? 1.25F : 0.75F;
car_preference *= proportion;

// If identical, no adjustment.

//Fourthly, the number of unhappy passengers at the start station compared with the number of happy passengers.
float unhappy_factor = start_halt->get_unhappy_proportion(0);

if(unhappy_factor > 0.8F)
{
private_car_chance /= unhappy_factor;
}

//Finally, determine whether the private car is used.
if(private_car_chance <= car_preference)
{
// Private cars chosen by preference even though public transport is possible.
route_good = private_car_only;
}
}
}
}

if(route_good == can_walk)
{
// so we have happy passengers

// Passengers who can walk to their destination may be happy about it,
// but they are not happy *because* the player has made them happy.
// Therefore, they should not show on the station's happy graph.
// @author: jamespetts, December 2009

//start_halt->add_pax_happy(pax_left_to_do);

merke_passagier_ziel(destinations[0].location, COL_DARK_YELLOW);
if (welt->get_einstellungen()->get_random_pedestrians() && wtyp == warenbauer_t::passagiere)
{
haltestelle_t::erzeuge_fussgaenger(welt, start_halt->get_basis_pos3d(), pax_left_to_do);
}

// They should show that they have been transported, however, since
// these figures are used for city growth calculations.
city_history_year[0][history_type] += pax_left_to_do;
city_history_month[0][history_type] += pax_left_to_do;
}

else if(route_good == good)
{
// Passengers can and will use public transport.
pax.arrival_time = welt->get_zeit_ms();
pax.set_origin(start_halt);
start_halt->starte_mit_route(pax);
merke_passagier_ziel(destinations[current_destination].location, COL_YELLOW);
}

else if(route_good == private_car_only)
{
// Passengers have either chosen to use their car or have no other choice.
stadt_t* const destination_town = destinations[current_destination].type == 1 ? destinations[current_destination].object.town : NULL;
set_private_car_trip(num_pax, destination_town);
merke_passagier_ziel(destinations[current_destination].location, COL_TURQUOISE);
#ifdef DESTINATION_CITYCARS
erzeuge_verkehrsteilnehmer(k, step_count, destinations[current_destination].location);
}
#endif

// send them also back
// (Calculate a return journey)
if(will_return != no_return && route_good == good || route_good == private_car_only)
{
// this comes most of the times for free and balances also the amounts!
halthandle_t ret_halt = pax.get_ziel();
bool return_in_private_car = private_car_only || !ret_halt.is_bound();

if(!return_in_private_car)
{
// we just have to ensure, the ware can be delivered at this station
bool found = false;
for (uint i = 0; i < plan->get_haltlist_count(); i++)
{
halthandle_t test_halt = halt_list[i];

if(test_halt->is_enabled(wtyp) && (start_halt == test_halt || test_halt->get_connexions(wtyp->get_catg_index())->access(start_halt) != NULL))
{
found = true;
start_halt = test_halt;
break;
}
}

// now try to add them to the target halt
if(!ret_halt->is_overcrowded(wtyp->get_catg_index()))
{
// prissi: not overcrowded and can recieve => add them
if(found)
{
ware_t return_pax(wtyp, ret_halt);
if(  will_return != town_return  &&  wtyp==warenbauer_t::post  )
{
// attractions/factory generate more mail than they recieve
return_pax.menge = pax_left_to_do * 3;
}
else
{
// use normal amount for return pas/mail
return_pax.menge = pax_left_to_do;
}
return_pax.set_zielpos(k);
return_pax.set_ziel(start_halt);
if(ret_halt->find_route(return_pax) != 65535)
{
return_pax.arrival_time = welt->get_zeit_ms();
ret_halt->starte_mit_route(return_pax);
merke_passagier_ziel(destinations[current_destination].location, COL_YELLOW);
//ret_halt->add_pax_happy(pax_left_to_do);
// Experimental 7.2 and onwards does this when passengers reach their destination
}
}
else
{
// no route back
if(car_minutes < 65535)
{
// This assumes that the journey time in both directions is identical: but
// this may not be so if there are one-way routes.
return_in_private_car = true;
}
else
{
ret_halt->add_pax_no_route(pax_left_to_do);
merke_passagier_ziel(destinations[current_destination].location, COL_DARK_ORANGE);
}
}
}
else
{
// Return halt crowded. Either return by car or mark unhappy.
if(car_minutes < 65535)
{
return_in_private_car = true;
}
else
{
ret_halt->add_pax_unhappy(pax_left_to_do);
merke_passagier_ziel(destinations[current_destination].location, COL_RED);
}
}
}

if(return_in_private_car)
{
if(car_minutes < 65535)
{
// Do not check tolerance, as they must come back!
stadt_t* const destination_town = destinations[0].type == 1 ? destinations[0].object.town : NULL;
set_private_car_trip(num_pax, destination_town);
merke_passagier_ziel(destinations[current_destination].location, COL_TURQUOISE);
#ifdef DESTINATION_CITYCARS
//citycars with destination
erzeuge_verkehrsteilnehmer(k, step_count, destinations[0].location);
#endif
}
else
{
if(ret_halt.is_bound())
{
ret_halt->add_pax_no_route(pax_left_to_do);
}
merke_passagier_ziel(destinations[current_destination].location, COL_DARK_ORANGE);
}
}
} // Returning passengers

INT_CHECK( "simcity 3128" );
current_destination ++;
} // While loop (route_good)

if((route_good != good && route_good != private_car_only) && start_halts.get_count() > 0)
{
// Passengers/mail cannot reach their destination at all, either by public transport or private car,
// *but* there are some stops in their locality. Record their inability to get where they are going
// at those local stops accordingly.
halthandle_t start_halt = start_halts[best_bad_start_halt]; //If there is no route, it does not matter where passengers express their unhappiness.
if(!has_private_car || car_minutes > tolerance)
{
// If the passengers are able to use a private car, then they should not record as "no route"
if(too_slow_already_set)
{
if(start_halt.is_bound())
{
start_halt->add_pax_too_slow(pax_left_to_do);
}
merke_passagier_ziel(best_bad_destination, COL_LIGHT_PURPLE);
}
else
{
if(start_halt.is_bound())
{
start_halt->add_pax_no_route(pax_left_to_do);
}
merke_passagier_ziel(destinations[0].location, COL_DARK_ORANGE);
}
}
}

} // For loop (passenger/mail packets)

} // If statement (are some start halts, or passengers have private car)

else
{
// The unhappy passengers will be added to all crowded stops
// however, there might be no stop too
// NOTE: Because of the conditional statement in the original loop,
// reaching this code means that passengers must not be able to use
// a private car for this journey.

// all passengers without suitable start:
// fake one ride to get a proper display of destinations (although there may be more) ...
pax_zieltyp will_return;
//const koord ziel = finde_passagier_ziel(&will_return);
destination destination_now = finde_passagier_ziel(&will_return);

// First, check whether the passengers can *walk*. Just because
// they do not have a start halt does not mean that they cannot
// walk to their destination!
const double tile_distance = accurate_distance(k, destination_now.location);
if(tile_distance < welt->get_einstellungen()->get_max_walking_distance())
{
// Passengers will walk to their destination if it is within the specified range.
// (Default: 1.5km)
merke_passagier_ziel(destination_now.location, COL_DARK_YELLOW);
city_history_year[0][history_type] += num_pax;
city_history_month[0][history_type] += num_pax;
}
else
{
// If the passengers cannot walk, they will be unhappy.

bool crowded_halts = false;
for(  uint h=0;  h<plan->get_haltlist_count(); h++  )
{
halthandle_t halt = halt_list[h];
if (halt->is_enabled(wtyp))
{
halt->add_pax_unhappy(num_pax);
crowded_halts = true;
}
}

// Only show as being overcrowded if there are, in fact, potentially suitable but overcrowded stops.
if(crowded_halts)
{
merke_passagier_ziel(destination_now.location, COL_RED);
}

else
{
merke_passagier_ziel(destination_now.location, COL_DARK_ORANGE);
}
// we do not show no route for destination stop!
}
}

// long t1 = get_current_time_millis();
// DBG_MESSAGE("stadt_t::step_passagiere()", "Zeit f�r Passagierstep: %ld ms\n", (long)(t1 - t0));
}


A very rough overview of how it works is as follows:

* Cities generate passengers from particular buildings. The numbers depend on the density of the buildings and the passenger factor set in simuconf.tab. The numbers generated are logged appropriately.
* The passengers are either given or not given access to a private car, using a weighted random system, the weightings being based on the percentage of passengers with access to a private car at that point in time (set by using an external file, privatecar.tab).
* Passengers check whether there are any places where they can embark on transport ('bus stops, railway stations, etc.) within their radius.
* The passengers are assigned a destination building using a weighted random system based on the type of building (city building, industry, tourist attraction) and geographical distance from the origin (short-range, mid-range, long-distance*).
* Passengers are assigned a journey time tolerance level.
* Passengers check whether they can get to their destination, either by walking (if it is very close), taking the player's transport or taking their private car.
* If passengers can walk, they do so.
* If the passengers can take their private car (if they have one) but not any other means, they do so if the journey time does not exceed their tolerance.
* If passengers can use player transport but no other means, they calculate the quickest journey on player transport, and use that if the journey time does not exceed their tolerance.
* If passengers can use either private car or player transport, they evaluate which to use based on factors such as the relative speed of the journeys, the congestion in the origin and destination cities (the most important factor) and a fixed car preference value set in simuconf.tab. There is a certain percentage of passengers who will always take their private cars if they possibly can - this percentage is also set in simuconf.tab. They then take the appropriate mode, if the journey time does not exceed their tolerance.
* Once the passengers know which route that they are taking, their journey is logged in the appropriate ways. If a private car is used, an appropriate car graphic is generated, and traffic (and therefore congestion) numbers are adjusted accordingly in the origin and (if applicable) destination cities.
* If the passengers cannot reach their destination by any means, this too is logged (differentially depending on whether there is no route, or there is a route that exceeds their tolerance).

The above process also works for mail, except that mail cannot either walk or take a private car. There is also a mechanism to generate returning passengers, which, for the sake of parsimony, I have omitted from the rough description above. This is what I mean by "bound up", and it does not seem obvious that one could or should have a separate module for the private car journeys here.

* I am considering removing this element, as it might be that the journey time tolerances feature can be made, more realistically, to have the desired effect of this in any event.

QuoteThe answers to these questions should have been determined before any of it was coded. Perhaps they were, and maybe the decisions were documented somewhere.

Ahh, I never really saw the need to have a conceptual separation of features into discrete units (as, after all, reality is not so compartmentalised). The approach was always simply to simulate, in so far as relevant and practicable, the various dynamics of reality and their interaction with one another.

QuoteThe reason this narrative has been dragging on for so long is because we don't have any such document. What I envisage is more a case of a few points against each feature/dynamic describing what assumptions are made in the sim, and what the sim is supposed to represent. If we don't have that, and the code is our only reference, then we can't evaluate the code against what it's supposed to achieve, or properly consider alternative ways of coding.

So that I have an idea of where we're heading with this, can you give me an example/extract, perhaps based on the features described above relating to the passenger generation code?

QuoteThe point is not about playing styles, it's about the long-term consequences of not thinking far enough ahead.

Ahh, that was more a casual aside than anything related to the main discussion!

QuoteExperimental is not parasitic, it is an extension of Standard. Experimental doesn't pick bits out of Standard, it builds additional features upon Standard's foundations. To take a parasitic approach one doesn't need to understand how Standard works, just identify the bits one wants to steal. To build an extension one has to first understand the foundation upon which one is building. So I see a process like this:
1. Document and understand what Standard does, and also what it doesn't do
2. Identify everything that Standard does that is undesirable, and what it doesn't do that is desirable
3. Develop designs that integrate the desired changes into the simplest possible game, coded in the simplest possible way
4. Assess each design against criteria such as coding hours required, modularity, expandability, simplicity of calibration, etc, and select one
5. Start building, and so on

This looks like the approach that one might adopt if one were starting Experimental to-morrow. Presumably, what we need to do now is to document and understand what Experimental does and doesn't do and evaluate then what of that is undesirable or missing?

QuoteCan you articulate that vision? Because I can't see what it is, and am concerned that it may contain fatal contradictions that will only otherwise become apparent after investing hundreds of hours into development trying to make work what cannot work (an open-ended process if one never realises that it can't work). I think a couple of steps have been skipped, including developing those abstract ideas into practical ones before rushing into coding Experimental. No, it is not easy to visualise everything at once, although it does become easier with practice. If all of those things are not documented in one place then (1) you will have great difficulty entertaining all of them at once and (2) no one else will be able to contribute.

The vision that I have for Experimental might be considered rather abstract, but it is this: given the basic elements and design assumptions of Simutrans (the simulation of operating a transport company by owning and running vehicles and ways, etc.), develop a version of it that will mean that the decisions that are made in the game by players have as similar effects as possible/practical on the things simulated by the game as in reality, such that a player playing such as to take game-optimal decisions will make the same decisions (in so far as possible) as, within the constraints of what is actually modelled by Simutrans, would have been similarly optimal decisions in reality, with as similar a set of consequences (within the constraints of what is actually modelled by Simutrans) as possible, such that, given realistic starting parameters (the giving of which is also a design goal of Experimental in so far as that is not possible in Standard), the development of transport networks in Simutrans by players making game-optimal decisions will follow as closely as possible the actual historical development of transport networks as they were actually developed, or might have been developed were it not for outside factors (wars, nationalisations, etc.) that are not inherent to the economics of transportation but were historically accidental, whilst still maintaining a game that is engaging and fun to play (at least for those who can tolerate a relatively high degree of complexity), and further (and relatedly) to mean that players making decisions in the game can make them on the basis of an abstract or heuristic understanding of real-world transportation, without having to engage in Simutrans-specific number crunching to calculate the optimal choice. At the same time, certain ancillary or secondary features that are not directed at that primary goal, but improve the user experience of the game (such as the vehicle replacer, or perhaps more cosmetic features such as the mooted livery variation system) are also desirable to be added along the way so long as they do not interfere with the primary goal. I like the idea that players (and, indeed, developers!) can learn about why things are as they are in transport terms by playing the game and seeing the various economic elements interact (which is one reason that I am particularly keen on using historical figures where possible).

QuoteHow can one possibly build a simulation model without first deciding what dynamics need to be modelled? Even if the model was sound one wouldn't know what it represented or how to interact with it. I can help, but only in a culture of developing understanding before trying to build the finished product.I think we need to follow the steps I listed above.

Ahh, I think that I was not as clear as I might have been - I thought that I did have a good understanding of what needed to be modelled until you pointed out the various missing things that rendered good balancing impossible; I had also periodically realised that important dynamics of which I had not hitherto thought had not been modelled. The problem was more that I don't know what the game is missing in terms of dynamics that I don't know or don't remember exist: it is the epistemological problem of not knowing the full extent of one's ignorance.

QuoteAs for evaluating what dynamics to include, it usually only takes a few minutes to evaluate the kind of difference a feature could make, and it's a good filter - if someone keeps insisting that an insignificant dynamic must be included, it shouldn't be difficult to produce a few calculations to shut them up and help them set their mind on something more significant. The evaluation process is what tells us which trees are big, and which ones are small. That is a picture that develops in one's mind over time, but the nature of a collaborative distributed effort means it also needs to be documented so we don't have to keep repeating our conclusions. To revisit some Simutrans history, this post lists things that "will never happen" because they were deemed insignificant, too difficult etc, but it doesn't present the assumptions/calculations that were used to reach the conclusions. Others have since revisited them and now some of these things are happening. We need to "prove" that something does or doesn't add anything to the game, or quantify the difference it will make so we can reach a sensible and defensible decision on whether or not to include it. Sounds like work but it takes out all the stress and confusion, and stops all the "why didn't you include x?" traffic, so in my experience it ends up feeling like less work.

There may be much to be said for this approach, in that case, although I am still a tad unclear on what the list/specification might look like and how detailed that it should be: the example requested above would be much appreciated in that respect.

QuoteI have a degree in applied mathematics and used to analyse and model supply chains and expansion options for a living, especially mine-rail-port systems. Lost my health a few years back and had to quit work. Health is slowly improving - not long ago I couldn't have kept up with this discussion.

I hope, in that case, that our discussions are contributing to, and not detracting from, your health!

Quote from: AEO
In the previous version, there were not enough passengers generated.
In the current version, there are too many passengers generated.

This is a pakset thing, not an Experimental thing, but the point applies, of course, to the pakset development.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: Hajo on January 28, 2011, 11:23:16 AM
I know it's very time consuming, but I think it's important that the developer(s) also play the game to get an impression what works well and what doesn't. Nowadays I see many pak set developers depend on spreadsheets and formulas, but at some point the proper tuning can only be done from experience by playing.
That's how I ended up on these boards! I was playing and realised that the costs were inconsistent and that some modes were profitable while others made losses at comparable utilisations. I thought, "I know how to specify these, using return on capital as a benchmark" and started looking into how I could balance the costs, only to discover that neither Standard nor Experimental is designed to support a trade-off between capital and operating costs. Using spreadsheets and formulas to at least generate a reasonable starting set of parameter values is by far the most practical and efficient approach, but I can see why it might not work. The dynamics assumed in the spreadsheets and formulas must match the dynamics used in the sim, and also the sim may not support all the dynamics required for balancing to work (I'm still getting my head around this).

I still play the game but now, I just give myself lots of money at the start and pay no attention to financial performance.
Quote from: JamesThe code in question looks like this:
OK
1. Let's start with Standard, not Experimental. Maybe pick something that hasn't been altered. In any case I will start drilling down from the overview of Standard into detail in particular areas.
2. This is a complex example and therefore a bad place to start. For demonstration purposes pick something that's as simple and self-contained as possible.
3. The sequence of logic you've documented is substantially different from the sequence of logic in the code. They need to match perfectly. As a result it's hard to make sense of. Before reading the code, I read your description and started writing a flow chart based on how I would code it, but quickly found the description didn't match the sequence of the code, and promptly stopped. When I started reading the code I wondered why "does the passenger have access to a car?" is being asked before the trip is even generated. The first action on my flow chart is "generate trip", the second is "can the player walk?" I then saw that on this question alone the code appears to, avoidably:
a. test for whether passengers who will walk have access to a car
b. test middle and long range trips for the possibility that the player will walk
...and that's as far I've got. I'm not going to engage with all the details of this particular piece of code at this point, as understanding and documenting Standard is my first priority. I would also insist on some quantitative assessment of the value of the dynamics in this piece of code before worrying about the code itself.
Quote from: JamesAhh, I never really saw the need to have a conceptual separation of features into discrete units (as, after all, reality is not so compartmentalised). The approach was always simply to simulate, in so far as relevant and practicable, the various dynamics of reality and their interaction with one another.
Reality is a bit of a mess. It's OK if a player's game simulates reality in that way, but the development and coding of Simutrans needs to be anything but. There's a good reason why expert programmers are considered to be out of touch with the real world - their output is nowhere near as messy.
Quote from: JamesThis looks like the approach that one might adopt if one were starting Experimental to-morrow. Presumably, what we need to do now is to document and understand what Experimental does and doesn't do and evaluate then what of that is undesirable or missing?
This is the approach that's ultimately unavoidable. We can start using it now, or after you've burned out. I'd prefer the former, since you're highly productive!
Quote from: JamesThe vision that I have for Experimental...
That was incredibly convoluted. A vision has to be communicable in one line to be effective. Would it be fair to paraphrase it as wanting "a transport network game that behaves as much like the real world as possible, without any unnecessary complexity"?
Quote from: JamesI hope, in that case, that our discussions are contributing to, and not detracting from, your health!
So far, so good. Have had enough practice at pacing myself. I don't claim to accomplish much else on a day where I write a couple of posts here, but a couple of posts here is better than nothing. It's good to exercise the brain on this stuff and see how much I remember, in an environment where a mistake doesn't cost millions of dollars.

jamespetts

Quote from: MobletOK
1. Let's start with Standard, not Experimental. Maybe pick something that hasn't been altered. In any case I will start drilling down from the overview of Standard into detail in particular areas.
2. This is a complex example and therefore a bad place to start. For demonstration purposes pick something that's as simple and self-contained as possible.
3. The sequence of logic you've documented is substantially different from the sequence of logic in the code. They need to match perfectly. As a result it's hard to make sense of. Before reading the code, I read your description and started writing a flow chart based on how I would code it, but quickly found the description didn't match the sequence of the code, and promptly stopped. When I started reading the code I wondered why "does the passenger have access to a car?" is being asked before the trip is even generated. The first action on my flow chart is "generate trip", the second is "can the player walk?" I then saw that on this question alone the code appears to, avoidably:
a. test for whether passengers who will walk have access to a car
b. test middle and long range trips for the possibility that the player will walk
...and that's as far I've got. I'm not going to engage with all the details of this particular piece of code at this point, as understanding and documenting Standard is my first priority.

Ahh, the reason that I chose this example was just to explain why and how passenger generation and private car generation are bound up with each other, as you  had suggested that it might not be good for them to be so bound. Do I understand you to mean, however, that we need to have a precise natural language description (and possibly flowchart) of all the economically significant parts of the code before we can balance? That is likely to be a very, very large amount of work!

Quote
I would also insist on some quantitative assessment of the value of the dynamics in this piece of code before worrying about the code itself.

I am not sure what you mean here; what would such a quantitative assessment entail?

(As an aside, I'm not sure that the following two things really are avoidable:

Quote
a. test for whether passengers who will walk have access to a car
b. test middle and long range trips for the possibility that the player will walk.

As to (a), the code iterates over multiple destinations to implement the alternative destinations feature: it might be that a packet of passengers can walk to their second choice destination, but not the first choice, and could only get to their first choice destination by car. Since the code is the same whatever iteration is current (the use of the for loop), we can't separate the cases.

On (b), we can't be sure that the user won't have specified a minimum distance for either the long-range or middle-range that is less than or equal to the walking distance, as there is considerable flexibility in how pakset maintainers can use the distances feature: they can set all the distance ranges to be the same but vary the journey time tolerances for each type, for example, or set the minimum numbers all the same, but change the maximum numbers. Since these specifications are not unambiguously perverse, the code has to be able to accommodate those possibilities.)

Quote
Reality is a bit of a mess. It's OK if a player's game simulates reality in that way, but the development and coding of Simutrans needs to be anything but. There's a good reason why expert programmers are considered to be out of touch with the real world - their output is nowhere near as messy.

Hmm, interesting. I have always followed the principle that a simulation will work most reliably and accurately, and be the easiest to code, debug and balance if the algorithmic representation of the reality simulated is as similar to that reality in its mechanism as is practicable: the fewer the divergences from the way that things work in reality, the fewer the chances for mistaken assumptions or oversimplifications to create distortions or just plain bugs, and the greater the chance that an emergent property that is also a property of reality that the developer would never have thought consciously to design will manifest.

Quote
That was incredibly convoluted. A vision has to be communicable in one line to be effective. Would it be fair to paraphrase it as wanting "a transport network game that behaves as much like the real world as possible, without any unnecessary complexity"?

Ahh, forgive me: I think that that is my profession manifesting itself just as your splendid graphs are examples of yours; I do hate to miss out the details, and wasn't sure of how precise that you wanted it. Your summary is, in so far as can be expected of a two clause summary of a lengthy paragraph, indeed approximately a correct description of what I am trying to do, although perhaps with the addition of "whilst still being fun" at the end, too, although I accept that what is fun for some is a chore for others (hence the divergence between Standard and Experimental in the first instance).

In any event, as you will have noticed, I have found and replied to the post about documenting the dynamics of Standard to which this discussion relates. Is that the sort of list that you had imagined as sufficing for the purpose of knowing what is included and left out so that we can commence the work of deducing what needs to be included that is not currently included that is of primary importance for balancing?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: jamespetts on January 31, 2011, 11:41:48 PM
Do I understand you to mean, however, that we need to have a precise natural language description (and possibly flowchart) of all the economically significant parts of the code before we can balance? That is likely to be a very, very large amount of work!
We need to have thought through how the code interacts with the pakset, then design the logic of code, then write the code and document the principles on which paksets should be parameterised. In an open source volunteer project the intended logic of the code should not reside exclusively inside one person's head, unless of course it's OK if all the work is lost if that person moves on.
Quote from: jamespettsI am not sure what you mean here; what would such a quantitative assessment entail?
Articulating, and then quantifying, exactly what difference this enhancement would make to the game. If its influence turns out to be very minor in practice then it would not be worth the complexity and effort. In this particular instance I would have the sim output some log files to quantify generated trips and work from those, probably using a spreadsheet to estimate how the numbers would be different under an alternative trip generation algorithm. Without logs one ends up doing too much guessing, and has no data.
Quote from: jamespetts
I have always followed the principle that a simulation will work most reliably and accurately, and be the easiest to code, debug and balance if the algorithmic representation of the reality simulated is as similar to that reality in its mechanism as is practicable: the fewer the divergences from the way that things work in reality, the fewer the chances for mistaken assumptions or oversimplifications to create distortions or just plain bugs, and the greater the chance that an emergent property that is also a property of reality that the developer would never have thought consciously to design will manifest.
A simulation is a model. A model is a simplified representation of a phenomenon or phenomena. In order to tell us anything about the real world, or in this case mimic the real world, the model itself has to be internally coherent and as dynamically faithful as possible. All models are built on assumptions, and those assumptions are critical to the form and operation of the model, as well as the conclusions that can be drawn from its use. In practice assumptions get negotiated in the model building process, as assumptions are typically traded against complexity (e.g. assume all destinations are equally likely or have a tiered destination probability). Assumptions must be documented and never forgotten, and are crucial to pakset balancing. The art in modelling is, as Einstein reputedly said, "make things as simple as possible, but no simpler". The best models are built by first understanding the dynamics of the target, identifying and modelling the ones that are indispensible, and confining the rest to the list of assumptions.
As for the easiest way to build, debug and test, it is this: Select one of the dynamics believed to be indispensible and build the simplest possible algorithm that might possibly be adequate, erring on the side of simplicity. Test it. If it's dynamically adequate, add the next dynamic and repeat. If it needs more complexity, add one unit of complexity and retest, and so on. Never ever go from zero to a highly complex algorithm, or add more than one dynamic at a time to a model (unless they are tried and true components that one thoroughly understands), because this is inefficient and often impossible to debug and calibrate. By following this process one arrives at the minimally complex adequate model with minimal wasted effort, and, if there's no deadline, no stress.
Quote from: James
In any event, as you will have noticed, I have found and replied to the post about documenting the dynamics of Standard to which this discussion relates. Is that the sort of list that you had imagined as sufficing for the purpose of knowing what is included and left out so that we can commence the work of deducing what needs to be included that is not currently included that is of primary importance for balancing?
It's a vital piece of the documentation picture, what I would call a basic overview of the sim's assumptions. The first step towards instructing a pakset builder in how to balance.

jamespetts

#79
The issues of feature significance and documentation I have dealt with in the other thread; one thing to which I should perhaps respond here, however, is this:

Quote
The best models are built by first understanding the dynamics of the target, identifying and modelling the ones that are indispensible, and confining the rest to the list of assumptions.

I don't think that this is entirely correct, since one might very well acquire an understanding of the dynamics of the target (at least, in so far as those dynamics consist of emergent properties) precisely by building and running the model.

On the list of dynamics, what I was really getting at is whether the level of detail of the description of the dynamics in the list is adequate for our purposes, as they are general headings more than anything else. If that will suffice, then the exercise may be easier than I had imagined. Do we need to do more work on listing the existing dynamics? I think that I have already put down all or at least nearly all of the dynamics not modelled by either Standard or Experimental of which I can think. It can, however, be difficult at times to work out what exactly all of the modelled dynamics are.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: jamespetts on February 02, 2011, 10:07:04 PM
I don't think that this is entirely correct, since one might very well acquire an understanding of the dynamics of the target (at least, in so far as those dynamics consist of emergent properties) precisely by building and running the model.
Just to clarify what I meant, I was trying to say that one would evaluate all the dynamics thought to be significant, by using analysis and modelling. Having established which dynamics are fundamental and which are peripheral, only include the fundamental ones in the final model. The peripheral dynamics get replaced by "assumptions", meaning a statement of what is assumed in the model, e.g. "flat $/km revenue regardless of distance". A model's list of assumptions are just as important as the model itself, especially for pakset developers.
Quote from: James
On the list of dynamics, what I was really getting at is whether the level of detail of the description of the dynamics in the list is adequate for our purposes, as they are general headings more than anything else.
Different levels of detail are required for different purposes. Major purposes are:
1. Discussion & comparison of coding logic and options
2. Instructions to programmers
3. Writing player help files and user manual
4. What pakset developers need to know
5. Leaving enough of a paper trail such that if any key person moves on, others can pick up from where they left off
I'm not trying to write all of them right now, my immediate goal is #1. But ideally we'd have all five.

jamespetts

Quote
1. Discussion & comparison of coding logic and options
2. Instructions to programmers
3. Writing player help files and user manual
4. What pakset developers need to know
5. Leaving enough of a paper trail such that if any key person moves on, others can pick up from where they left off
I'm not trying to write all of them right now, my immediate goal is #1. But ideally we'd have all five.

No. 1 is important because we need to know what is missing in order accurately to simulate the dynamics necessary to make balancing possible? How best to start, do you think?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: jamespetts on February 05, 2011, 02:26:29 AM
How best to start, do you think?
I proposed a first course of action in the other thread but it passed unnoticed.

jamespetts

Quote from: moblet on February 06, 2011, 10:35:19 AM
I proposed a first course of action in the other thread but it passed unnoticed.

Did that first step not include the suggestion that the starting point for making the necessary changes to Experimental be, not Experimental itself, but Standard? If so, I refer to my response on that thread to that suggestion.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.