News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Overhauls and renewals

Started by Spenk009, November 09, 2014, 06:00:09 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sarlock

Quotealthough I am not convinced by the idea of having a 10-20 year moratorium on new companies: this is unrealistic and arbitrary, and could lead to perverse incentives in the game whereby certain routes, for example, are profitable only if run by a new company

It's not uncommon for new companies to get a tax break when starting out, especially where the added service(s) would be of economic benefit to the area served.

Taxes would not make a profitable line unprofitable - it only serves to make them less profitable.  A line with marginal profitability would have little to no taxation while a line that is unprofitable would be untaxed completely.

I echo some of DrSuperGood's thoughts, especially on the multiplayer front.  Making new lines and connecting new industries/cities is fun.  Routine maintenance is generally tedious and boring.

I am concerned that we are overcomplicating the economic model by adding things that can be just as effectively simulated with the existing systems in place.
Current projects: Pak128 Trees, blender graphics

Vladki

There was a short discussion in another thread about headquarters for pak128, about making them something more than voluntary money sink...

I think that the bigger companies have bigger overhead - more employees need more bosses and managers and they need higher salaries more benefits etc etc. This could be simulates by forcing companies to upgrade headquarters or to upgrade them automaticaly and incease the overhead costs automaticaly.

The main question is what should indicate how big the company is. Number of lines? Convoys? Stations? Length of tracks? Cash? Income? Cargo delivered ton*km/month?

Sent using recycled electrons.


DrSuperGood

QuoteI think that the bigger companies have bigger overhead - more employees need more bosses and managers and they need higher salaries more benefits etc etc. This could be simulates by forcing companies to upgrade headquarters or to upgrade them automaticaly and incease the overhead costs automaticaly.
Employees are directly proportional to company size. However the issue is that they are already factored in the maintenance and running cost of convoys and structures.

Although pay does increase for managers in larger companies, once can assume that you own 100% of your company and are the only manger getting paid anything special.

That said, you could force headquarter size based on profit per month. Without a suitably sized headquarter for your profit you incur a percentage profit penalty due to "inefficiency" which may get worse as the amount of profit rises (possibly to >100% causing you to never be able to make money). Eventually you reach a point where upgrading headquarters becomes a cost saving as the reduction in inefficiency (possibly to 0%) is worth the extra cost. Efficiency as a whole could be modelled with not only headquarters but the need for offices if you are really big and the headquarter cannot cope alone. It could also be open ended where the last headquarter upgrade gives you 0% inefficiency no mater how much profit you make.

zook2

Perhaps it would be best to keep it as simple as possible by having your CFO pay out a certain percentage of profits as dividends each quarter, or each year. Early on, investors understand that your company's goal is to grow and that you cannot pay much. Also, net losses equal no dividends that quarter. Later on, your industry behemoth is expected to take care of many, many rich widows and orphans. Say good-bye to 50% of your earnings. And the board, representing the shareholders, takes the weight of the decision off your shoulders, setting the payout rate automatically and without asking the CEO's (your) opinion.

Sarlock

I foresee this as the best solution to the issue, and the easiest to implement and understand.  A dividend rate that takes into account the past 5 years' earnings and sets a rate accordingly.  If the current year runs negative, then the dividend is suspended, to preserve cash.  This encourages the player to not accumulate cash and instead employ it, unless earnings are so healthy that there is no alternative but to let them accumulate and be paid out in aggressive dividends.

Combined with a public player directed taxation system, this would largely address the issue and act as a brake on large company excess cash accumulation.  And, as a bonus, it is entirely realistic and completely missing from the game currently.
Current projects: Pak128 Trees, blender graphics

zook2

Perhaps dividends shouldn't be dependent on earnings alone, but on changes in company net value. Otherwise, I'd spend my excess cash on a fleet of steamships and keep them in the depot, either for use at a later time or simply as a money sink to keep the cash in the company.

Sarlock

Adding the fixed maintenance cost for convoys would fix that.  I believe this is already in place, just needs to be added to the pakset.
Current projects: Pak128 Trees, blender graphics

DrSuperGood

Dividends could be based on the a certain type of profit (before construction/new vehicles but after maintenance/overhaul/running cost). This way you cannot exploit it by tying up profit in assets.

However I still think throwing it all out in tax and office overhead would be more fair.

Or maybe people could be given the choice of different sorts of company? I mean if they are state run then then their profits are taken 100% by the public service provider but every month they are given a budget based on their haulage performance (especially for passenger/mail, cargo less so). The main advantage of this sort of company is that making money is less important compared with haulage percentage as the public service provider can even take up some of the bill if you are providing good service.

A public traded company has to pay dividends from its profit. It also has issue buying assets as a result (less capital to spend) but has a new option to "rent" assets instead. Rented assets have a large monthly cost (the rent) but can easily be replaced or changed out for a small fee (representing the abrupt termination of a rent contact). The main advantage of these companies is their cheap way to upgrade convoys and their large starting capital allowing for huge initial growth. This sort of company should probably get bonus for hauling freight and mail while a slight penalty for hauling passengers (comfort maybe? such companies usually skrimp and save where possible which affects comfort).

A private company could keep all the profit however operate at a cost penalty (so making money is harder) representing fewer business connections and worse deals. Some lines which are profitable with the other two company types are not profitable with this as a result. It also has less starting capital but can buy convoys. It also gets a bonus when it comes to convoy maintenance being cheaper (since you own your convoys, you make sure that they are well maintained so they last longer).

Adding 3 distinct company play styles could be a great direction for the game. They might be differently defined than above but with each having distinct advantages and disadvantages would encourage people to specialize on certain areas rather than being a jack of all trades. Someone going a state run company would probably start off with building up a passenger network and every month or so adding new routes to it. A public traded company might want to start by rapidly expanding to several industries with a shipping network or freight network. Where as a private company might be for people who only want to play with a small company such as an island or maybe specialize on certain aspects such as only going timber products.

zook2

I'm dreaming about designing a large scenario where the player is in charge of the Transsiberian Railway in the late 1940's and has to deliver a certain amount of steel to Irkutsk every year or risk getting shot in the neck. After all, that's how a large SimEx game feels to me after a while. You need to set yourself goals when money is no object. (By the way, is there an overview somewhere of what you can do with scenarios?)

But while I absolutely agree that your idea for different company types would greatly enhance the game, it sounds like a balancing nightmare to get this right. It's probably a looong way off.

DrSuperGood

QuoteBut while I absolutely agree that your idea for different company types would greatly enhance the game, it sounds like a balancing nightmare to get this right. It's probably a looong way off.
Everything is a long way off if nobody does anything. For example JIT2 in standard used to be nothing more than people stating possible improvements while now it might eventually be incorporated into standard main.

The issue is there is far too little testing and far too little resource available. Ultimately what needs to be done is to try out all the ideas mentioned and then evaluate which is most fun. Even if one fails, you can revise it and improve. That is the development cycle at work, something lacking a bit recently due to lack of resources.

jamespetts

Quote from: DrSuperGood on November 21, 2014, 10:01:18 PM
The issue is there is far too little testing and far too little resource available. Ultimately what needs to be done is to try out all the ideas mentioned and then evaluate which is most fun. Even if one fails, you can revise it and improve. That is the development cycle at work, something lacking a bit recently due to lack of resources.

This indeed is the critical issue. Simutrans (both Standard and Experimental) is fantastically complex and there are very few people working on it. I am the only person working regularly on Experimental, although others have provided enormous amounts of assistance intermittently. I work full time and am entirely self-taught in programming (and do not have a software engineering background). This means that things are extremely slow, even not taking into account my current house move which makes it very difficult for me to concentrate on other large projects such as Simutrans (I should have more time to start catching up once I actually move in, but it is a slow process).

There needs to be a clear roadmap with design decisions taken before implementation decisions. In this case, the design decisions for overhauls, etc., were taken as long ago as 2011. The livery system is currently incomplete, and was always designed with overhauls in mind back when it was first introduced in 2011. Routinely changing course on something already decided would mean that no progress at all would be made, rather than merely very slow progress.

Overhauls and renewals will not by themselves balance the game, but they are one of many measures that are intended to do so. They will not require players to become involved in mere routine maintenance: just the very major overhauls that are a significant capital expense. Even these will be automated, intervention only being necessary if the player is short of money or is planning an upgrade in the future. The renewal system of ways will in some cases reduce the need for player intervention to replace obsolete ways.

Renewals and overhauls are intended to introduce new and interesting dynamics and things for players to consider without requiring the player to undertake tedious, repetitive work. Having assets that deteriorate with use will make a real difference to strategic decision-making in many aspects of the game, of which I have given a few examples above.

I should very much like if there were more resources in programming available to us, and anyone who would like to contribute is encouraged to do so.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

jamespetts

Returning to this issue again, I am in the process of designing a model for a wear based way renewal system, which I am planning to code in the coming weeks. I will describe this in some technical detail as that has been the focus of the discussion so far.

Each way tile will have an unsigned 32 bit integer value representing its condition. New ways will have a condition value of the maximum value of a 32-bit unsigned integer. When a way reaches 0, it will become unusable. These values will be reported to the player as percentages. When a way tile reaches 15% (or some alternative figure set in simuconf.tab), it will be automatically renewed (if the player has the money and has not disabled this), or otherwise will be treated as being in a degenerate state and will have a speed restriction imposed upon it of 60% of the normal speed limit, or some other figure as may be specified in simuconf.tab.

Each vehicle will report a value of "Standard Axles". That value will either be specified directly in the .dat file or to be calculated from the axle load in default thereof using a power specified in simuconf.tab per waytype (default: 4 for road, 1 for rail, 0 for water; rail has a linear relationship and water experiences no wear). This is based on research into the "forth power law" said to apply to roads, where an increase in axle load of X results in an increase in wear of X^4. There is no equivalent for rail, it seems, but some sources indicate a linear relationship or a lower degree of a progressive relationship (which can be represented with a power of 1 or 2).

Each convoy, when it changes its assemblage, will calculate a global convoy SA value. Each waytype will specify a number of standard axle passes before condition reaches zero (the SA capacity).

Each convoy passing over the way will deduct an appropriate number from the condition value based on the proportion of its SA rating to the way's SA capacity.

This system should allow SA values to be set in the vehicles' .dat files or left to be deduced by the program based on axle load, allowing basic vehicles to have their SA values calculated automatically, while vehicles with more complex requirements (such as steam locomotives with varying hammer blow) to have the values set manually.

There are some good data for calibrating this for roads: see:
http://www.pavementinteractive.org/2014/06/02/pavement-design-whats-my-structural-number/
http://www.pavementinteractive.org/article/equivalent-single-axle-load/
http://www.pavementinteractive.org/wsdot-esal-application/
http://www.kent.gov.uk/__data/assets/pdf_file/0012/13035/Making-it-Happen-Road-pavement-design-guide-July-2000.pdf

Road strengths are measured in "msa" in the UK, "msa" standing for "million standard axles". They are designed for a lifespan of 20-40 years (20 years being more common now). A "standard axle" is one of 8.0t, so a 16t lorry with 2 axles (such as the Leyland DAF 65 in Pak128.Britain) would exert a wear of 2 SAs. For other axle loads, the SA value is calculated by the fourth power law. Modern roads, of thin stone mastic asphalt, introduced in around the mid 1990s, and which is about 25% more hard wearing than traditional hot rolled asphalt, have msa values ranging from 0.5 for light roads to 30 or even 50 for the most heavily used roads. This means that, in their 20 year lifespan, the roads will take 500,000 - 20,000,000 standard axle passes before needing replacement.

For Simutrans-Experimental, some conversion is needed because of the timescale. At Pak128.Britan-Ex standards, 3.75 months = 1 day. However, this is a day without a night. Assuming 16 active hours in a day, this is closer to 2.5. 2.5 * 365 = 912.5 months per year, or 76 months per month. Real world msa values must therefore be divided by 76 to get to the equivalent in Pak128.Britain-Ex.

One must then account for the bits per month and meters per tile for which these things must be adjusted. Months are about 2x as long as they would be at default settings. The configuration files must therefore divide msa value by 152 (76 * 2) to get the number of standard axle passes for Simutrans-Experimental. That would produce:

Very heavy road, 50msa: 328,947 (50,000,000 / 152) SA
Heavy road, 30msa: 197,368 (30,000,000 / 152) SA
Medium heavy road, 20msa: 131,579 (20,000,000 / 152) SA
Medium road, 10msa: 65,789 (10,000,000 / 152) SA
Medium light road, 5msa: 32,894 (5,000,000 / 152) SA
Light road, 2msa: 13,158 (2,000,000 / 152) SA
Very light road, 0.5msa: 3,289 (500,000 / 152) SA

The Leyland DAF65 in the game has an 8t axle load, and 2 axles. This vehicle is therefore 2x SA per pass.

This would equate to the following:

50msa = 164,473 lifetime passes
30msa = 98,684 lifetime passes
20msa = 65,789 lifetime passes
10msa = 32,894 lifetime passes
5msa = 16,447 lifetime passes
2msa = 6,579 lifetime passes
0.5msa = 1,644 lifetime passes

For a 20 year life, this equates to:

50msa = 685 passes/month or 107 passes/hour
30msa = 411 passes/month or 64 passes/hour
20msa = 274 passes/month or 43 passes/hour
10msa = 137 passes/month or 21 passes/hour
5msa = 68 passes/month or 10 passes/hour
2msa = 27 passes/month or 4 passes/hour
0.5msa = 6.85 passes/month 1.07 passes/hour

This suggests that we do need some new road types (light/medium/heavy hot rolled asphalt, light/medium/heavy stone mastic asphalt, perhaps; or at least medium/heavy of each, leaving the lightest roads to the "tarmac" type currently in the game), which could be produced by varying the tone of the images in the GIMP without producing new images (using the traditional idiom of lighter colours equating to better ways, which has been applied successfully for rail).

I should be interested in any feedback from users (especially those who use a lot of road transport in the modern era) of whether anywhere near the wear scenarios described above for the medium and higher strength roads are likely to be encountered in actual use, and whether we need to calibrate the SA passes rather lower as a result to give a realistic lifespan.

Calibrating this for rail is harder as there is less information. This old book suggests that wear based costs are about half of the total cost of rail maintenance, the remaining cost effectively being fixed, albeit that was for conditions in the first decade of the 20th century. I suspect that the ratio for roads will be more weighted in favour of wear based costs (75%, perhaps?), although I have not found any data on this. Any such data would be most welcome.

This paper suggests that there might be some power law in effect for rail wear, but the current research is said to be inconclusive, and it refers to other sources that indicate a linear relationship. If anyone has any useful information in this respect, that, too, would be most welcome. I might have to back-calculate from the axle load limit for rail to work out what would be an unreasonably short lifetime to calculate the SA tolerance (e.g., if rail type X has an axle load limit of 12t, infer that this is so because, at its SA rating, it would deteriorate with only Y passes at > 12t, Y being so small as to make it highly undesirable/unsafe to use the railway with such rapid deterioration); any thoughts on a sensible formula would be most welcome.

Edit: Incidentally, this is the thread in which Moblet suggested the ideas that are the basis of this work. The most relevant part is the following:

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

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

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

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

Follow Simutrans-Extended on Facebook.

jamespetts

I should note that I have now implemented the way related parts of this on the way-improvements branch.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

jamespetts

#48
I have found some good information about the effect of the hammer blow of steam locomotives on the pressure that they exert upon the track from p. 70 of this source (which was also cited in the "snippet of relative pricing information" thread in text only form). Although the source is primarily American, the physics should remain unchanged between there and here, save to note that the Americans tended only to use two cylinder locomotives and thus did not benefit from the reduced hammer blow of three or four cylinder locomotives.

The weights given in the below table, that I approximately reproduce from the original, are in pounds.

Type (wheel configuration)Weight on axle (main driver)Weight on axle (front or back drivers)Excess pressure due to hammer blow (one side only; main driver)Excess pressure due to hammer blow (one side only; front or back drivers)
4-4-255,00052,00012,0009,000
4-6-260,00056,00010,0007,000
4-6-055,00052,00011,00010,000
2-6-054,00053,00015,00011,000
2-8-054,00050,00014,0009,000

Edit: Pages 71-72 have some further interesting information on this topic, which is perhaps a better summary than the table above. The "dynamic augment" (U. S. terminology for hammer blow) force to be added to the static force of the wheels upon the rails is, apparently, 26% of the static force when the static force is over 25,000lb, and 75% on the main drivers, 60% on the front and back drivers and 26% on the trailing wheels for passenger locomotives and 66% on the main drivers, 45% on the front and back drivers and 26% on the trailing wheels for freight locomotives. Again, this is referring to American locomotives which were invariably of 2 outside cylinders, which was the type to have the highest hammer blow/dynamic augment.

Edit 2: Page 2 of the same book records,

QuoteAccording to Mr. R. Price Williams the average life of an iron rail, on the most heavily worked portions of the railways in the United Kingdom in the year 1878, may roundly be taken at 17 1/2 millions of tons.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.