Topic: How to get started on balancing properly

[inkelyad]

Replacer timetabling

Not timetabling. User should be able tell "replace here" at stations near depot.

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]

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.

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

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?

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.

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?

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

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

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.

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.

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

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

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]

Worn out vehicles

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

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

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?

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

after 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:

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

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.

[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

[moblet]

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

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?

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

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

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

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.

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?

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.

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;
( 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!

[moblet]

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?

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

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?

Not necessarily increasing throughout, just higher later in life.

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.

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.

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.

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]

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.

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

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

[ӔO]

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.

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

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.

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]

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]

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]

(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;
( 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.

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.

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?

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.

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

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

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

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.

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.

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

[inkelyad]

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]

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

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.

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

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

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.

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.

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.

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?

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

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.

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.

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

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

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

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

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.

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?

[ӔO]

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.

[moblet]

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

Rail 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]

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. [...] 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.

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

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.

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.

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.

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.

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

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.

[Ӕ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?

[moblet]

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.

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

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.

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.

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.

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.

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

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!

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.

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.

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.

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.

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.

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.

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.

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]

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]

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

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.

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

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.

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?

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

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.

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.

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.

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.

[sdog]

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.