News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Towards a balancing spreadsheet for vehicles

Started by moblet, January 09, 2011, 12:28:56 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

moblet

Here's a simple and merely conceptual first draft. No real numbers in it, just some of the basic calculations; things like the speedbonus and a charge for infrastructure costs aren't in there yet. Wanted to get this out for review of the concept and also because it might help inform current discussion on game features.

Proposed methodology is to have the spreadsheet accept each unit's parameters, along with operating assumptions such as average speed and load factor, and compute its "lifecycle profit factor". The lifecycle profit factor is the lifetime revenue divided by the lifecycle cost of the unit. I propose this as the fundamental unit of comparison between units, benchmark value = 1. My little brain currently thinks that this produces a valid comparison between vehicles that may have very different technical and cost performance. Basically the task is to set the numbers for each unit to hit the benchmark, or whatever value we want that unit to have. High-speed vehicles can have their assumed average speed set higher; with this done they can be benchmarked to 1 and their cost structure will make them less economic for low-speed service. I'd expect benchmarking could be at least semi-automated by use of macros or VB coding and Excel's Goal Seek function, if not by some algorithm of our own design.

The vehicle's lifespan is a user-defined assumption in this draft, but a nagging voice is telling me that it is really an output of the other numbers in the spreadsheet, depending on the shape of the maintenance cost curve (and the still-in-progress discussion on handling maintenance costs with age). Either way the lifespan is a pivotal number, and my current belief is that balancing is impossible if vehicles don't have one.

I've not included overhauls in this draft. Overhauls would add to the complexity of the balancing task and probably not add any benefits in terms of levers, as I think we have enough levers there as it is. They are simple enough to add to the spreadsheet, though.

ӔO

for the trains, which can run quite an extensive variation in consists, power balance should be looked at too.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Thank you for that - that is most interesting. I notice that the revenue per kilometre is fixed, whereas, in Simutrans-Experimental, the revenue per kilometre can vary greatly (i.e., by orders of magnitude) depending on the average speed of the line and, for passenger vehicles, also the comfort of the vehicle. The computations for both are really rather complicated: the relevance of average speed to revenue takes into account the following:

(1) the "speed bonus" rating of the particular type of goods;
(2) a speed bonus speed level, set in speedbonus.tab, which varies with the year; and
(3) the length of the journey (the longer the journey, the greater the importance of speed).

The importance of comfort varies depending on the following factors:

(1) the length of the journey relative to a minimum tolerable comfort level set for that length of journey using parameters specified in simuconf.tab;
(2) the defined values for a discomfort penalty or luxury bonus for falling below or exceeding the tolerable values respectively (the discomfort penalty is usually about twice as much as the luxury bonus); and
(3) whether, and if so, the extent to which, a vehicle is overcrowded (all standing passengers have a maximum comfort of 10).

As to overhauls - I thought that those were important? That is a matter for the other thread, I suppose, but I'd be interested in your views on the latest discussions there.

You also refer to "scrap value". That is not at present how Simutrans works with respect to resale value, although I'd like to change that in the future. Currently, all vehicles have a linearly-depreciated age-based resale value, being identical to their purchase cost in the month after purchase. What I'd rather have is the ability for players to be able to trade secondhand vehicles amongst each other, and, in default of that, obtain only a scrap value for them, defined as a certain (low) percentage of their purchase price (perhaps 5% or so). However, the present state of affairs ought be borne in mind for the present.

One other complexity relates to capacity. This is all very well for 'buses, boats and aircraft, but falls apart with trains where there are often separate locomotives and carriages, which can be mixed and matched. One has to look at locomotives as having a haulage capacity (based on the weight of carriages available when they are new, I suppose: carriages get heavier throughout the game); but then carriages themselves need balancing. I wonder how one would incorporate that into a spreadsheet like this? (The same applies for horse-drawn 'buses, of course).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

Quote from: jamespetts on January 09, 2011, 12:55:57 PM
One other complexity relates to capacity. This is all very well for 'buses, boats and aircraft, but falls apart with trains where there are often separate locomotives and carriages, which can be mixed and matched. One has to look at locomotives as having a haulage capacity (based on the weight of carriages available when they are new, I suppose: carriages get heavier throughout the game); but then carriages themselves need balancing. I wonder how one would incorporate that into a spreadsheet like this? (The same applies for horse-drawn 'buses, of course).

I would start off with a list of carriages available and their parameters. Sets can be rounded up into one entity and use a default % increase or decrease for certain configurations. Like a dining would be 5% more in cost and 15% more in maintenance over the stock configuration.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Ahh, yes, I forgot to mention the relevance of catering and TPO vehicles, which furhter complicate revenue calculation. They should be more expensive to buy and run, but increase a whole train's revenue (to a greater extent for longer journeys).

The complexity is, of course, that, for any given carriage type, different locomotives can haul different numbers of them at different speeds (and not just in a linear relationship to each other: some locomotives are good at hauling a large number at a low or moderate speed; some are good at hauling a small number at a high speed; some are good at hauling a large number at high speed; and some can only haul a few at low speed; and everything in between).

Then, we have multiple units which can either have fixed formations or have different numbers of non-powered vehicles to powered vehicles depending on the user's chosen configuration.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

The Hood

Just a practical suggestion: I've found in the balancing I've done in Standard the spreadsheet method isn't infallible.  I'd recommend getting things approximately right with a spreadsheet and then testing them and seeing if they work in their intended way in game.  Also, given how journey times affect loadings etc in experimental, I'd also get the power/speed balanced as well as possible first, and only then try to do the speed.

ӔO

I think multiple units are easier, since they're very restricted in possible configurations and possible speeds, the unfortunate part is, they're only available later in the game.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

Quote from: Jamesthe revenue per kilometre is fixed, whereas, in Simutrans-Experimental, the revenue per kilometre can vary greatly
Yes, I know enough to know that the revenue side is complicated so I left it for another day. The first question is whether the "lifetime profit factor" is the right measure to use as a benchmark, before getting too carried away. No one's shot that down so far, although sdog is yet to chime in...

Of course the trains have to be special 8). What's in my head at the moment is that passenger vs goods as a whole ought to be balanced so that a loco equally suited to either will do equally well hauling either. And we of course have to look at balancing within passenger service and to take into account ancillary carriages, pretty confident we can navigate that, AEO's idea of corralling them into sets might come in handy. Not sure where the comfort model fits into all this yet, I have to get my head around it, and the speedbonus, first. My feeling is that the comfort model won't make too big a mess, it just influences which configuration might be optimal behind a given loco.

I'm not sure all of the differences in loco capability are going to be very difficult to incorporate, since it sounds like they come down to assumptions of capacity and speed. Yes, locos have differential performance, but we handle that by benchmarking the loco on what it does best, since that's what we expect a skilled player to buy it for. We might do a bit of adjustment in the area of versatility, e.g. if a loco is really only fit for one kind of work there is a higher risk in purchasing it relative to a more versatile unit, so its profit factor should be relatively higher in exchange for that risk. Multiple units won't be hard - we select their optimal configuration, or, if we can't separate them, any one will do.

Quote from: The HoodI've found in the balancing I've done in Standard the spreadsheet method isn't infallible
There are so many assumptions underpinning the balancing process that it would be a miracle it we got it right on the first iteration. I think this constitutes a good process for developing the first iteration, and also for converting the feedback from each set into a better subsequent set. We need to have the right levers in the spreadsheet so we can make any kind of adjustment we need to. Just on that point, can Simutrans write a log of journey speeds, loadings, cost, and revenue? Getting actual data out of the sim would help us punch accurate numbers into the balancing process, and to identify where our assumptions were barmy.

Quote from: Jamesall vehicles have a linearly-depreciated age-based resale value
Ha! I just asked this question in the other thread. Real-world depreciation is a percentage of remaining value, so the value decreases at a decreasing rate. By scrap value I just mean depreciated value at the end of the nominated life. We don't have to use that terminology in the sim; I wouldn't change it.

Quote from: Jamescarriages get heavier throughout the game
Something that helps weigh into replacement decisions, but since carriages should outlast locos it may not matter all that much.


jamespetts

Quote from: moblet on January 09, 2011, 02:45:06 PM
Yes, I know enough to know that the revenue side is complicated so I left it for another day. The first question is whether the "lifetime profit factor" is the right measure to use as a benchmark, before getting too carried away. No one's shot that down so far, although sdog is yet to chime in...

I suppose that the question is this - in real life, are the lifetime profit factors of all (successful) vehicles of a certain type identical, or at least within a narrow range? If so, then that may be the way to go. If not, then, given that we're trying to simulate reality, we'll be failing if we adopt this model. My starting point would be to make the simulation as close to real life as possible in significant respects, then put in numbers as close to real-world numbers as possible and see what happens. Don't we want the outcome to be something that we learn from running the simulation on real data, rather than something that we stipulate from the beginning? Of course, if we then need to adjust the values after testing to make the game playable, that's another matter.

QuoteOf course the trains have to be special 8). What's in my head at the moment is that passenger vs goods as a whole ought to be balanced so that a loco equally suited to either will do equally well hauling either. And we of course have to look at balancing within passenger service and to take into account ancillary carriages, pretty confident we can navigate that, AEO's idea of corralling them into sets might come in handy. Not sure where the comfort model fits into all this yet, I have to get my head around it, and the speedbonus, first. My feeling is that the comfort model won't make too big a mess, it just influences which configuration might be optimal behind a given loco.

Further complexities are introduced as there are different types of goods traffic: a locomotive good for hauling vast amounts of coal may be less than useful for hauling a fast fish train, and so on. As to comfort (and also to be considered: loading times), that is intended to be able to differentiate between suburban, semi-fast and long-distance travel (and various gradations in between in some cases), so different configurations will be differently profitable depending on the sort of journey for which they are used: train A might be highly profitable on an express, but lose money on a suburban stopping service, whereas train B might be ideally suited to a local stopping service, but be hopeless (and unprofitable) on an express. Running costs, loading times and comfort all have a part to play in this equation (running costs in that local trains will generally have lower revenue but be able to use slower, less powerful and less comfortable vehicles).

QuoteI'm not sure all of the differences in loco capability are going to be very difficult to incorporate, since it sounds like they come down to assumptions of capacity and speed. Yes, locos have differential performance, but we handle that by benchmarking the loco on what it does best, since that's what we expect a skilled player to buy it for. We might do a bit of adjustment in the area of versatility, e.g. if a loco is really only fit for one kind of work there is a higher risk in purchasing it relative to a more
versatile unit, so its profit factor should be relatively higher in exchange for that risk. Multiple units won't be hard - we select their optimal configuration, or, if we can't separate them, any one will do.

We also have to bear in mind that newer (and often heavier) rolling stock will be introduced after a locomotive is introduced, although I suppose, as in real life, that is not accounted for when building the locomotive.

QuoteThere are so many assumptions underpinning the balancing process that it would be a miracle it we got it right on the first iteration. I think this constitutes a good process for developing the first iteration, and also for converting the feedback from each set into a better subsequent set. We need to have the right levers in the spreadsheet so we can make any kind of adjustment we need to. Just on that point, can Simutrans write a log of journey speeds, loadings, cost, and revenue? Getting actual data out of the sim would help us punch accurate numbers into the balancing process, and to identify where our assumptions were barmy.

I don't think that it can output a log, but the line statistics in the line management window are useful.

QuoteHa! I just asked this question in the other thread. Real-world depreciation is a percentage of remaining value, so the value decreases at a decreasing rate. By scrap value I just mean depreciated value at the end of the nominated life. We don't have to use that terminology in the sim; I wouldn't change it.
Something that helps weigh into replacement decisions, but since carriages should outlast locos it may not matter all that much.

Given that I hope eventually to change this to an internal market for secondhand vehicles and scrap value, there is no need to tinker with this now.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

QuoteNo one's shot that down so far, although sdog is yet to chime in...
well, you know german brainstorming? link

i'll avoid to look into the spreadsheets now, i have to distract myself a bit less. It is not good that i already accumulated quite a backlog in the first week of the year.

moblet

#10
Quote from: jamespetts on January 09, 2011, 03:13:36 PM
I suppose that the question is this - in real life, are the lifetime profit factors of all (successful) vehicles of a certain type identical, or at least within a narrow range?
Probably. They must have been profitable, and even if they weren't, from a playability perspective we have to make sure that every vehicle is profitable if operated sensibly, but at the same time that no vehicle wallops all the others of its era in terms of cost performance. Hold that thought. In the real world different owners operated under different local economic and operating conditions so I wouldn't try to simulate actual profitability.
Quote from: JamesIf not, then, given that we're trying to simulate reality, we'll be failing if we adopt this model.
"This model" is not a single set of answers, it is a process for generating consciously constructed, and playable, parameter sets. We will almost certainly fail if we don't have any such process. This is an effort to bring some order and efficiency to what is a very large and intricate task, on a "first crawl, then walk, then run" basis.
Quote from: JamesMy starting point would be to make the simulation as close to real life as possible in significant respects, then put in numbers as close to real-world numbers as possible and see what happens. Don't we want the outcome to be something that we learn from running the simulation on real data, rather than something that we stipulate from the beginning? Of course, if we then need to adjust the values after testing to make the game playable, that's another matter.
I don't hear anyone else saying that the ultimate goal is that every number in the sim matches the real world. I believe what people want is a sim that behaves like the real world. Simutrans is a simple model of the real world; to get that model to mimic the real world in the ways we'd like, we have to understand what it does and doesn't capture, what assumptions underpin it, and adapt its inputs accordingly. I believe the goal is to have the sim respond to player decisions in manner similar to how the real world would, and the way to achieve that is not to fixate on real-world numbers, but to identify the real-world dynamics that warrant capture and find the most realistic and efficient way to mimic them. This then drives the data gathering requirements.
Quote from: JamesFurther complexities are introduced as there are different types of goods traffic: a locomotive good for hauling vast amounts of coal may be less than useful for hauling a fast fish train, and so on.
What I've already said still applies - we benchmark a loco on the assumption that it will be used for what it does best, e.g. we assume the slow loco hauls something non-perishable, and compare that with the profitability of the faster loco hauling something perishable. If they can't be balanced sensibly then we would have to revisit the goods pricing.
Quote from: Jamestrain A might be highly profitable on an express, but lose money on a suburban stopping service, whereas train B might be ideally suited to a local stopping service, but be hopeless (and unprofitable) on an express. Running costs, loading times and comfort all have a part to play in this equation (running costs in that local trains will generally have lower revenue but be able to use slower, less powerful and less comfortable vehicles).
Again, I thought we'd already covered this with the idea of benchmarking a vehicle on what it does best. If something isn't technically capable of earning large revenues then it will have to be cheaper to own and run, while if something is capable of earning large revenues it must cost more so it is only worth buying if those revenues will be realised. This benchmarking process can tell us what those cost differences should be, but can only do so after, as a couple of people have observed, the technical performance of the vehicles has been specified. If the cost disparities required to balance the profitabilities of disparate vehicles seem too large, or too small, compared with what they were in reality, or more importantly what makes for good gameplay, then the revenue model(s) can be adjusted to alter the relative profit outcomes in the desired manner.

EDIT/AFTERTHOUGHT: In accordance with a basic modelling principle of starting off simply and adding complexity, I suggest that we stop confusing ourselves by trying to start with the most complex balancing task, i.e. trains, and focus on mastering the concept and practice of balancing with the simpler modes. Once we have them in our pocket the rail task won't seem so daunting.

moblet

Quote from: sdog on January 10, 2011, 07:06:30 AM
i'll avoid to look into the spreadsheets now, i have to distract myself a bit less.
No problem. Your incisive (German?) analysis is worth waiting for.

neroden

#12
Quote from: moblet on January 09, 2011, 12:28:56 PM
Here's a simple and merely conceptual first draft.
I haven't looked at yours, but please look at the spreadsheet I created for this purpose, which is actually in SVN if I remember correctly.

I went to some effort to work out the infrastructure cost model and the number of vehicles using the infrastructure, which is crucial for getting a good sense of the actual revenue and costs (infrastructure cost matters!).

I agree that we should do "single-unit" vehicles before trains.  I suggest doing ships/boats first, as their infrastructure cost model is simplest, then buses (with a more complicated set of infrastructure choices).

I would like to emphasize again that there is no point in balancing prices until carrying capacity, vehicle weight, power, and tractive effort have been set, and these are supposed to be set "realistically" for pak128.britain.  

Carrying capacity should come first, and I think carrying capacities are close to correct.

However, tractive effort has not been set yet for the majority of buses and lorries, so I feel that we have a long way to go before we're really ready to balance prices.

EDIT: If you're going to work on balancing, I suggest working on infrastructure maintenance costs first.  I am really unsure how to balance them properly, but every good way of balancing vehicle prices depends on balancing infrastructure maintenance first.  :-P

I know bridge prices need to be scaled to the scale because elevated track prices are, that would be a start...

jamespetts

Quote from: moblet on January 10, 2011, 11:14:38 AM
Probably. They must have been profitable, and even if they weren't, from a playability perspective we have to make sure that every vehicle is profitable if operated sensibly, but at the same time that no vehicle wallops all the others of its era in terms of cost performance. Hold that thought. In the real world different owners operated under different local economic and operating conditions so I wouldn't try to simulate actual profitability.

In many cases the profitabilities would have been comparable; two transport companies in the same country in the same era would all have more or less comparable profit, would they not? Further, different sorts of vehicles may well have been differently profitable by orders of magnitude; local 'buses, for example, may never give anything like the return on investment as airliners (even taking into account capital depreciation), but they are necessary in order to get the passengers to and from the airport and enable the aircraft to carry enough passengers in order to be profitable. That a vehicle is profitable does not tell us how profitable that it is: a set of different profitable vehicles, each potentially the best in any given situation (including budgetary constraints) at a given point in time might be orders of magnitude different in profitability. Some types of transportation might well be orders of magnitude different in profitability to others, but that does not make the less profitable ones not worth pursuing, not least because either they are necessary for linking to the more profitable types to make them work, or because, in a competitive environment, all the opportunities for the more profitable type of transport have been taken away, so the only remaining opportunities are for transportation types with lower profitability.

If a player joins a multiplayer game, for example, 50 or 100 years after it's started, and all that's realistically left for that player to do is add some local 'bus networks to outlying areas not served by other players, then that operation may (even taking into account capital depreciation) be orders of magnitude less profitable than the existing players' rail/air/boat routes, or bus/tram routes in more densely populated areas; but, as long as it is at least a little profitable, it will be worthwhile the johnny-come-lately player performing that type of transportation, and there might well be vehicles that are optimally suited to just that task  and little else (minibuses, for example). If we balanced the minibus so that its profitability was, taking into account capital depreciation, identical to that of an airliner, there would be some significant distortion. Availability of the market is as important a choice for businesses making decisions about where to invest as profit margin, if not more so.

So, indeed, we should balance things that, in the right conditions, no types of vehicles, infrastructure or cargo are, in their own time, impossible to use profitably, but it would be somewhat arbitrary to equalise the profitability of all types of vehicles, as they may well not have been equal in reality, and, in so far as they are not equal in reality, a simulator purporting to simulate that reality should not portray them as equal. That being so, however, it is not necessarily the case that an algorithm that will tell us what would balance things equally is useless. It might be a helpful calibration tool (not least to compare with the profitability of the real thing), and a means to check whether things are indeed profitable within a sensible margin; but the aim of the exercise should be to balance things so that they are as close to reality as possible whilst still being playable. A spreadsheet of the sort that you are devising may, therefore, very well be useful, as long as it is designed such as to ensure that all vehicles are somewhere between (and not including) unprofitable and excessively profitable, rather than aiming to equalise the profits entirely. Where within that range that the vehicles fall should resemble real life as much as possible.

Quote"This model" is not a single set of answers, it is a process for generating consciously constructed, and playable, parameter sets. We will almost certainly fail if we don't have any such process. This is an effort to bring some order and efficiency to what is a very large and intricate task, on a "first crawl, then walk, then run" basis. I don't hear anyone else saying that the ultimate goal is that every number in the sim matches the real world. I believe what people want is a sim that behaves like the real world. Simutrans is a simple model of the real world; to get that model to mimic the real world in the ways we'd like, we have to understand what it does and doesn't capture, what assumptions underpin it, and adapt its inputs accordingly. I believe the goal is to have the sim respond to player decisions in manner similar to how the real world would, and the way to achieve that is not to fixate on real-world numbers, but to identify the real-world dynamics that warrant capture and find the most realistic and efficient way to mimic them. This then drives the data gathering requirements.

Yes, indeed - although I take the view that, when in doubt, one should always err on the side of reality, not least because reality is already balanced for us! If we have a specific reason to fudge the real numbers in a particular way because we know that using the real numbers will result in a particular inaccuracy in gameplay incentives (and, yes, I do agree that the ultimate goal is to make the incentives rather than the numbers themselves realistic), then we can then decide how and how far to depart from reality. So the next issue, then, is this: where are the economic drivers in Simutrans distinctly different from those in reality? And, in each such case, is it better fixed by changing the figures or changing the programme itself? I know that we are discussing a number of potential coding changes in the other thread for just this reason.

QuoteWhat I've already said still applies - we benchmark a loco on the assumption that it will be used for what it does best, e.g. we assume the slow loco hauls something non-perishable, and compare that with the profitability of the faster loco hauling something perishable. If they can't be balanced sensibly then we would have to revisit the goods pricing.

This seems sensible - vehicles were, after all, bought and built with particular purposes in mind.

QuoteAgain, I thought we'd already covered this with the idea of benchmarking a vehicle on what it does best. If something isn't technically capable of earning large revenues then it will have to be cheaper to own and run, while if something is capable of earning large revenues it must cost more so it is only worth buying if those revenues will be realised. This benchmarking process can tell us what those cost differences should be, but can only do so after, as a couple of people have observed, the technical performance of the vehicles has been specified. If the cost disparities required to balance the profitabilities of disparate vehicles seem too large, or too small, compared with what they were in reality, or more importantly what makes for good gameplay, then the revenue model(s) can be adjusted to alter the relative profit outcomes in the desired manner.

This is interesting: I started off thinking about replying, "but what if it wasn't like that in reality?", but then realised that it almost invariably is - that things capable of earning greatly higher revenues do, indeed, cost much more than those that aren't. Of course, this isn't always a simple model: a 'bus in a densely populated town might earn vastly more than the very same 'bus in a small village, such that the smaller 'bus built just for small village use will not be less expensive in proportion to its reduced profitability; but, within bounds of very broad approximation, it does generally hold that higher revenues can be earned from more expensive vehicles, no doubt at least in part as a result of price competition (if the competition can do it much more cheaply, then they can undercut and still maintain a good profit margin; so part of the reason for the ability to generate a high revenue in the first place is the high cost that that revenue must offset for that form of transport). This would suggest that profitability levels within a fairly broad (but defined) band are indeed what one would expect in reality.

QuoteEDIT/AFTERTHOUGHT: In accordance with a basic modelling principle of starting off simply and adding complexity, I suggest that we stop confusing ourselves by trying to start with the most complex balancing task, i.e. trains, and focus on mastering the concept and practice of balancing with the simpler modes. Once we have them in our pocket the rail task won't seem so daunting.

This could work, although the note of caution that I'd sound in relation to that is that we must know in advance that our model will scale in complexity well: it is possible for any given model to work very well on the simpler tasks, but to fail completely on the more complex ones, so we have to consider the complexities (at least in the abstract) before we finalise the design for our model such as to ensure that it will, indeed, account for those complexities.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: nerodenI haven't looked at yours, but please look at the spreadsheet I created for this purpose, which is actually in SVN if I remember correctly.
Thanks neroden. It's a bit similar to the one of The Hood's I saw. What I'm proposing is a bit different; it uses some of the same data, but the unit of benchmarking is very different, being based on lifetime economic performance. My spreadsheet won't take long to understand, certainly faster than me trying to explain it. There is a fatal problem for it at present, as it relies on the idea that a unit has economic lifespan, something that does not currently exist in Simutrans, as maintenance costs do not increase with age.
Quote from: nerodenI would like to emphasize again that there is no point in balancing prices until carrying capacity, vehicle weight, power, and tractive effort have been set
I would like to second that, and add that I cannot see how to balance prices if units do not have a economic lifespan.
Quote from: nerodenIf you're going to work on balancing, I suggest working on infrastructure maintenance costs first.  I am really unsure how to balance them properly, but every good way of balancing vehicle prices depends on balancing infrastructure maintenance first.
I just discovered that myself! I guess the first question is how to simulate the degradation of infrastructure, i.e. fixed and variable costs, and replacement. There are currently no usage-based infrastructure costs, which unbalances early vs mature gameplay (makes it harder to make a profit when you start out), and also doesn't capture the reality that trains wear out rails but boats don't wear out water. If vehicles inflicted wear on their infrastructure that would be simple to include in balancing. One simplistic idea I have is to consider that each mode is, by nature, differentially infrastructure-intensive, and apply an infrastructure capital charge that is the same for each unit of a given mode. So we would benchmark a tram as if its purchase price included a portion of the infrastructure it required. The outcome of this is that the tram would be made cheaper than a bus to buy and own as an individual unit per passenger-km, to compensate for the fact that the player has to pay for more infrastructure to run the tram. The infrastructure loading would be set at a level that assumed a certain level of infrastructure utilisation; the player would not realise the benchmark return on the infrastructure investment if they did not achieve this utilisation (the lower cost of the trams would not offset the infrastructure cost unless a minimum number of trams were bought and used).
I haven't reached a conclusion as to whether infrastructure also needs a finite life for balancing to work.

Quote from: James
In many cases the profitabilities would have been comparable; two transport companies in the same country in the same era would all have more or less comparable profit, would they not?
Why? If you are making a killing tramming people around London, and I am barely profitable hauling coal through the Midlands, what's going to cause us to have comparable profitabilities? Our equipment and markets are neither comparable nor transferrable, so why should we automatically achieve the same outcome? One might as well compare a steel mill and a pharmaceutical company.
Alternatively, we could both be hauling coal in different parts of the country, using identical equipment, but be getting paid a different price/km. If one of us therefore makes a lower profit than the other, is that the equipment's fault?
Quote from: Jameslocal 'buses, for example, may never give anything like the return on investment as airliners (even taking into account capital depreciation), but they are necessary in order to get the passengers to and from the airport and enable the aircraft to carry enough passengers in order to be profitable.
If we balanced a mode of transport on the assumption that it is only viable if cross-subsidised, how much fun would that be? If no bus could be profitable of its own accord, no matter what its loading? Each unit will require a certain utilisation to operate profitably. An operator could choose to assign it to a task with lower utilisation as part of a bigger network picture, but if a bus cannot make a profit under any circumstances, it is a lemon.
Quote from: JamesSome types of transportation might well be orders of magnitude different in profitability to others, but that does not make the less profitable ones not worth pursuing, not least because either they are necessary for linking to the more profitable types to make them work, or because, in a competitive environment, all the opportunities for the more profitable type of transport have been taken away, so the only remaining opportunities are for transportation types with lower profitability.
Yes. This is in contradiction to your opening argument about all transport companies having comparable profitabilities. Choosing to provide a transport service or not is a binary decision, and in a perfect world will be done wherever there is profit to be made, and regardless of the magnitude of the profit available.
Quote from: JamesIf we balanced the minibus so that its profitability was, taking into account capital depreciation, identical to that of an airliner, there would be some significant distortion.
In dollar terms yes. As a ratio of profit earned to capital cost, no. Return on capital is the actual leveller in the real world, that causes money to be shifted from one industry or operation to another. If the airliner had much higher return on capital, more investors would pile into the airline business, and none into the minibus business, until the airline market was sufficiently saturated that return on capital fell to the minibus level. The number of planes would increase until utilisation fell to the point that one got the same return on a dollar invested in the minibus business as they did on one invested in the airline business. This is the theory. In practice the market is never perfectly balanced because of uncertainty, time delay, imperfect information, and various forms of variability.
Quote from: JamesAvailability of the market is as important a choice for businesses making decisions about where to invest as profit margin, if not more so.
How could one estimate a profit margin without first estimating the market?
Quote from: JamesSo, indeed, we should balance things that, in the right conditions, no types of vehicles, infrastructure or cargo are, in their own time, impossible to use profitably
Yes
Quote from: Jamesbut it would be somewhat arbitrary to equalise the profitability of all types of vehicles,
No
Quote from: Jamesas they may well not have been equal in reality,
Because reality was heavily determined by local operating and economic conditions
Quote from: JamesIt might be a helpful calibration tool (not least to compare with the profitability of the real thing), and a means to check whether things are indeed profitable within a sensible margin
Yes
Quote from: Jamesthe aim of the exercise should be to balance things so that they are as close to reality as possible whilst still being playable
Hence the need for a tool that allows us to massage numbers as easily as possible
Quote from: JamesA spreadsheet of the sort that you are devising may, therefore, very well be useful, as long as it is designed such as to ensure that all vehicles are somewhere between (and not including) unprofitable and excessively profitable
This is exactly what I'm aiming to present in an easily digestable format, and to support easy calibration of units that we want to move away from the benchmark.
Quote from: Jamesrather than aiming to equalise the profits entirely.
Profits in the game should be an outcome of seeding and player choices, a bit like the real world. Proscribing profits in the determination of the vehicle parameters means it doesn't matter what the player does, the outcome is predetermined.
Quote from: JamesYes, indeed - although I take the view that, when in doubt, one should always err on the side of reality, not least because reality is already balanced for us! If we have a specific reason to fudge the real numbers in a particular way because we know that using the real numbers will result in a particular inaccuracy in gameplay incentives (and, yes, I do agree that the ultimate goal is to make the incentives rather than the numbers themselves realistic), then we can then decide how and how far to depart from reality. So the next issue, then, is this: where are the economic drivers in Simutrans distinctly different from those in reality?
Reality is not static, it is in a constant state of flux, shifting away from, and back towards, equilibrium, sometimes in small steps (Patricia buys some shares), sometimes in large ones (Global Financial Crisis). The Simutrans world is, by contrast, extremely static. One can't choose a moment in history and claim that everything was in balance at that moment, therefore it's difficult to pluck numbers from history and expect them to represent a balanced set of game parameters.
A non-exhaustive list of real-world drivers that aren't represented in Simutrans, but which are consequential for transport operators:
- Inflation
- Economic cycles
- Stock and capital markets
- Exchange rates
- War and pestilence
- Government regulation, taxation, or other interference
- Variations in energy costs
- Variations in the cost and availability of labour
- Geographical variation in the value of transport due to local economic conditions
- Significant variations in terrain
- Wear on vehicles and infrastructure
- Equipment failure
- Cost of land
- Variability in industrial output, both short-term (e.g. mining stops due to rain, production increases for Christmas) and long-term (e.g. I built a railway to this factory but it's now closed down)
- Range of cargoes
- Complexity of supply chains
- Demographic variations and trends
- The fact that most of the above, along with the actual performance of anything untried, are uncertain within the typical investment horizon. Not only that, the level of uncertainty of each has changed through history.
I'm not suggesting that all, or even most of these, get modelled in Simutrans, but I will say that when you look at real-world outcomes, especially ones like profitability that are derived from a myriad of factors, you would have to account for all of them to know that you were comparing apples with apples.
Quote from: JamesAnd, in each such case, is it better fixed by changing the figures or changing the programme itself? I know that we are discussing a number of potential coding changes in the other thread for just this reason.
Worthy of consideration, but initially not in reference to the existing sim, and certainly not on the basis of "well, we've already coded this other thing". To come up with a good simulator, it is necessary to first decide what a good simulator should model. Once that is clear then go back to the Simutrans engine and see how it can meet that specification.
Quote from: Jamesthings capable of earning greatly higher revenues do, indeed, cost much more than those that aren't.
Even if they don't cost more to produce. Because they are worth more to the buyer a premium can be charged for their superior performance. A rational buyer will pay up to what the unit is worth relative to the alternatives.
Quote from: JamesOf course, this isn't always a simple model: a 'bus in a densely populated town might earn vastly more than the very same 'bus in a small village, such that the smaller 'bus built just for small village use will not be less expensive in proportion to its reduced profitability
If the small village cannot achieve the same utilisation as the city, even with a downsized vehicle, then it should generate lower profitability than its city cousin. But that is a function of the environment, not the vehicle. Take the bus to the city and utilise it more fully and its profit should increase. If the vehicle's pricing is distorted away from realistic operating parameters because it was historically used in a particularly profitable or unprofitable environment it will cause distortions in player choices in other environments. Price a minibus to be admirably profitable at low utilisation and it will be outrageously profitable at high utilisation, and suddenly it will become the most profitable bus to use even in the big city. If the minibus is priced so that it is a better economic choice for the village than a double-decker, then the player will automatically choose it over the double-decker. There's no need to try to pre-empt how the player will use the vehicle, the price and the market will take care of that.
Quote from: JamesThis could work, although the note of caution that I'd sound in relation to that is that we must know in advance that our model will scale in complexity well: it is possible for any given model to work very well on the simpler tasks, but to fail completely on the more complex ones, so we have to consider the complexities (at least in the abstract) before we finalise the design for our model such as to ensure that it will, indeed, account for those complexities.
She'll be right, mate. The trains will require more computations, probably an additional model, but the numbers will be reducible to the inputs for the balancing spreadsheet.

ӔO

seeing as the game does store odometer data, could it be possible to increase maintenance after the vehicle hits a certain mileage?

the cost could increase either through two dat values or the game could just assign an average fixed value. The increase should be exponential.
For example after each 50000km, a 5% increase in maintenance cost compounded: 105% @ 50000km -> 110.25% @ 100000km -> 115.7625% @ 150000km.

or the math behind it: (1.05^(n/50000))

but I don't know how much memory this will eat.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

Quote from: mobletI haven't reached a conclusion as to whether infrastructure also needs a finite life for balancing to work.
I have now, and I think it does need a finite life.

Here is a simple real-world example of the market taking care of the purchasing decision, and of different equipment buyers making different choices according to their operational needs and philosophies. It's slide presentation by loco manufacturer EMD, look at slides 36 to 41. Operators can choose between AC & DC traction in their diesel-electrics, with AC performing better under most conditions but costing more. The brief summary of each operator's purchasing choices shows how different buyers will make different choices when confronted with the same options (presumably each locomotive's price is much the same for each operator, although I don't know their respective credit ratings). The cost of each option is constant between operators, but the value of each option differs between operators because of differences in their haulage tasks, operating environments, and infrastructure. In the sim, different parts of the map will offer different haulage tasks and constraints, and once a player has built some infrastructure this will influence subsequent choices, just like in the real world, so those elements of realism are already in place. Beyond that, I think only the following need to be balanced:
- The revenue model should reward each haulage task roughly equally if the player has fulfilled them equally. E.g. distributing from a steel mill should offer the same profit potential as distributing from a pharmaceutical plant. The sim already has the capability to differentiate those tasks by quantity, price per quantity, and perishability, which is all that's required. Differential tonnage vs speed requirements for different cargoes guarantees that for different tasks, a player will calculate the value of the same equipment differently. Balancing the parameters means setting the relative quantities and perishabilities, and then making some assumptions about achievable average speeds to arrive at benchmark prices per quantity for each commodity. Simple enough to do in a spreadsheet. I think this allows the relationship of price to distance to be the same for all commodities.
- Equipment & infrastructure costs should be such that if the player calculates the value of different items differently for different tasks, this will cause them to make different equipment choices accordingly. This demands tuning the relationship between increased performance and increased costs. This could be done by, for example, comparing vehicles by their performance of a "standard" haulage task, or by their return on capital when assigned to the task for which they are best suited. This spreadsheet applies the latter method.


jamespetts

I haven't been ignoring this discussion, but have been somewhat preoccupied with work and building a new computer (which, when finished, should make compiling Simutrans and other things considerably faster), but I shall respond in due course when I get a chance. Thank you all for your input so far!
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: JamesI haven't been ignoring this discussion
You can ignore it all you want!

Another possibility that just popped into my head would be to rent everything instead of buying it. The rental charge could be included in the monthly fixed cost. There could be nominal entry and exit fees for each rental agreement to discourage frequent swapping. Methinks balancing would be a bit simpler under this arrangement, certainly there would be fewer parameters involved. Buying feels nicer from a gameplay perspective but isn't necessarily realistic, especially for vehicles, which are typically leased rather than bought outright. The biggest advantage of renting over buying is cashflow - you pay for the vehicle as you earn revenue from it, not all up front before it's made as much as a penny - which is worth considering as another lever to balance early vs mature gameplay.

sdog

Leasing is not a bad idea, this could also be done purely on the pak-set level making it viable for standard too. Or would it require the monthly cost, instead of 1/km based costs?

Huge ships waiting two months to load would be economical than, but aren't not necessarily now. For instance in pak128 depreciation slowly drives one bancrupt. This is not an issue in experimental though.

moblet

Quote from: sdog on January 18, 2011, 05:01:38 AM
Leasing is not a bad idea, this could also be done purely on the pak-set level making it viable for standard too. Or would it require the monthly cost, instead of 1/km based costs?
Without the fixed cost the player could acquire excess vehicles without penalty, so the fixed cost would have to be there to force the player to be efficient with their acquisitions. And the variable costs are indispensible to force the player to be efficient with their operations, so I don't see it working too well without both.
Quote from: sdogFor instance in pak128 depreciation slowly drives one bancrupt.
How does that happen? Is depreciation a cash charge or something? (I've not played 128 as I'm not yet ready to tackle the combination of complex supply chains and my lack of knowledge of German at the same time.)

sdog

in standard bankruptcy is caused by the net wealth being below zero after a month change. The worth of the vehicle is counted as the players assets. Buying a vehicle doesn't really cost any thing in standard, as this will reduce cash, but increase the assets, the net wealth stays the same. So for a typical game at the beginning it's not unusual to build for about 350k of the 400k one has, and buy vehicles for some 5M.

Since the value of the vehicles depreciate at a constant rate (a few percent p.a.), one is forced to earn enough to compensate depreciation, so one is forced have more monthyl net income than depreciation. (In the example some 50k to 100k) The actual cash doesn't matter at all in standard, the only thing to monitor is net wealth.

moblet

Thanks for that explanation.
Quote from: sdog on January 18, 2011, 11:27:10 PM
at the beginning it's not unusual to build for about 350k of the 400k one has, and buy vehicles for some 5M.
I would prefer that at the beginning I could only afford to take one opportunity, and would have to operate that profitably before earning - literally - the ability to take the next one.

ӔO

#23
With the current speed bonus and goods settings, it's not very hard to make a profit on express passenger lines, even if they cost $60/km in maintenance per train. This holds true for 1930 and onward, although you really only see $60/km maintenance with the APT and TGV.


I also found this page on horse drawn carriage ability, if they are to be used as a base line for calibrating capacity of vehicles.
http://www.antiquecoach-carriage.com/faq.html
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

moblet

Quote from: AEO on January 19, 2011, 10:30:39 PM
With the current speed bonus and goods settings
Just thinking about the speedbonus concept, would it not be more realistic for the speedbonus to be independent of mode? In other words, for trip revenue to be a function of actual average speed, in a straight line from origin to destination, regardless of the mode (or combinations thereof) used. This would would increase the challenge to the player to build and service the most direct routes possible, using the most efficient modes, for the greatest number of passengers, especially as the passengers' expectations could not be influenced by what modes the player chose to provide (except in "Soviet-era" mode, perhaps ;)). It would also be simpler in concept and, by eliminating the vehicle speedbonus, reduce the number of vehicle parameters to be juggled. The speed expectation would change with time just as the current speedbonus does. It would however require some sort of algorithm to compensate for geographical barriers (e.g. bodies of water).

Quote from: AEOI also found this page on horse drawn carriage ability, if they are to be used as a base line for calibrating capacity of vehicles.
Wow, I never thought about how much weight a horse could pull, but I was surprised to see a factor of six. Then again, have seen photos of horses pulling massive and clearly well-laden carts. I expect it would get very nasty very quickly if the vehicle's brakes failed on a descent. The first road over the Blue Mountains west of Sydney (1815) had a long descent on a 1 in 4 grade; to provide braking it was routine practice to drag a log behind the carriage/wagon. Needless to say this section of road was by-passed as soon as an alternative route could be developed.

ӔO

#25
I thought about, and did try using a stricter speed bonus setting, by raising the average speed needed for the bonus to be paid and found that it cuts off anywhere from 5 to 20% of income.

Then I read this part:
Quote8.2 - Use recorded car journey time to compare against players' transport's travelling times rather than speed bonus rating for road transport when passengers decide whether to take their car or players' transport.
which must mean that passenger speed bonus is calculated differently. The one thing I don't understand, is the payout of the speed bonus. I hope james can elaborate more on if the percentage value plays any role, other than wait times.

That and you also have to factor in the fact that freight trains are slower, but they too have speed bonuses on perishable items, like food.



As a starting point, I think, with the current way the speed bonus is implemented, we can take a look at the power/weight ratio of the locomotive, and where it falls in line in relation to top speed when introduced.

If the locomotive, when introduced, is on the higher end of the speed limits or is the fastest, then maintenance should cost at least 2x power/weight. If in the middle range of speed, 1.5x power/weight. If in the lower range of speed, 1x power/weight. Or as many divisions as needed, I think about 5 to 7 would do. Express locomotives are able to sustain more than 60.00c/km of maintenance.

I think there also needs to be some exponential decay slope for reducing cost mid to late game, because the power to weight ratio growth appears to be exponential as well. Actually, the multiplier should also probably be an exponential function, but this linear one works well enough.

Taking a few examples

GWR Star 4-6-0
currently 15.18c/km maint. with top speed of 130km/h, and is one of the fastest when introduced.
1600kW/75t = 21.33kW/t
base line maint. = 21.33 * 2 = 42.66c/km

GWR 3150 2-6-2T
currently it has 5.94c/km maintenance with top speed of 105km/h when introduced, but somewhere around the middle. Multipurpose locomotive.

1375kW/78t = 18.33kW/t
base line maint. = 18.33 * 1.5 = 27.50c/km


GWR 2800 2-8-0
Currently, it has 8.58c/km maint., with top speed of 90km/h when introduced, and puts it near the bottom. It is an express use freight locomotive.

1900kW/75t = 25.33kW/t
base line maint. = 25.33c/km

even at 33.69c maint, the GWR star is quite lucrative. It doesn't need to be a double header to pull this length, but was done to raise the cost.


Concerning horses and other biological vehicles:
The current horse drawn carriage settings are a bit unrealistic, with a single horse producing 10kW, but that can't be helped, because the smallest weight allowed in simutrans is 1t, which is also why the mail bicycle weighs 1t. In real life a mail bike would be no more than 120kg with the rider and mail. A horse in real life would produce about 750W, and an average human on a bike would produce less than half of that, about 250W.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

A few brief observations on some of the main issues raised here for the time being (the other thread is the priority for the time being).

Firstly, it might be worthwhile considering this discussion in conjunction with this discussion in relation to industry, as the two are connected to some extent (especially in relation to goods revenues).

Secondly, to clarify an issue raised by AEO:

Quote8.2 - Use recorded car journey time to compare against players' transport's travelling times rather than speed bonus rating for road transport when passengers decide whether to take their car or players' transport.

does not mean that the calculation of the revenue has changed at all; rather, that, when deciding whether or not to use private cars, the game will now compute the approximate time that it would take to travel from the origin to the destination by private car using a model of the route distance and car speed (based on the road speeds and the maximum speed of the current city cars), rather than the previous method, which had involved using the speed bonus speed to calculate a far more approximate journey time. This does not affect the calculation of the speed bonus for passengers or any other cargo.

Thirdly, Moblet's idea of speed-bonus being independent of mode is more or less implemented in Pak128.Britain-Ex by the simple expedient of having the speed bonus figures set identically for each different mode (other than water). This requires no change in the code. Water is set differently, as water use in latter times usually indicates the existence of the sort of geographical barrier to which Moblet refers (and in earlier times, the water speed bonus is much closer to the land speed bonus). It would, however, be horribly difficult for the game to try to detect in each specific case whether there is some sort of obstacle, and, if so, how much of an obstacle that it would be and how that should affect the speed bonus. Indeed, it would be easier than that simply to replace the entire speed bonus system with a competitive system, such that the price depends on how fast that a player transports goods from any given A to any given B compared with all other available modes of transporting those same goods between that same A and that same B, although that would itself be very difficult, as it would require a whole new mechanism of goods/passengers having different price tolerances as well as different time tolerances, and adding the possibility of price competition would increase exponentially the complexity as players see it and the potential for monotonous micromanagement. I think, therefore, that for the time being, the present approach is to be preferred.

Fourthly, I am not quite sure what Moblet means by infrastructure having a limited life - can you elaborate, Moblet? Certainly, there are bridges tunnels, cuttings, embankments and stations out there well over a hundred years old in regular and intensive use, not likely to be replaced any time soon.

Fifthly, one issue in relation to the use of purchase price to equalise the relative economic performance of vehicles is this: although that model might make sense where the ultimate user of the vehicle has to buy it from a third party manufacturer, in olden times, many vehicles were either built to order or built by the operators themselves (most major railway companies had their own works, for example, although they also subcontracted frequently), and so the purchase cost was not subject to market sensitivity as to its ultimate value. It would seem arbitrary to ignore this significant driver, which might have made a substantial difference to the fortunes of many a transport operator. Not only that, but the cost of vehicles are often set when they are new and before their real success in service has been determined, so even then, the true market value of new vehicles is very unlikely to be reflected in their actual purchase costs.

Sixthly, there may have been some confusion as to the meaning of comparable profitabilities: I understood the idea to refer to it being meaningful to compare one level of profitability to the other such that the different levels of profitability make sense given the different circumstances in the same ultimate context - in other words, I had understood the word "comparable" literally. I think that Moblet may have used the word in its more informal sense to mean "similar", which is not the way in which I had intended the term. Ultimately, I had intended to state no more than that, if there was a substantial difference in profitability, it would have been due to factors that are simulated or ought to be able to be simulated in Simutrans (other than relatively arbitrary factors that we probably don't want to simulate, such as management administrative competence, trade union bargaining power, etc.).

Seventlhy, on cross-subsidisation, the suggestion was not that certain modes of transport could only be profitable at all when cross-subsidised, but rather the potential for one mode of transport positively to affect the profitability of another must be taken into account in circumstances where the two are likely often to be used in conjunction with each other, or distortions are likely. For example, before the second half of the 20th century, many railway branch lines were, of themselves, barely profitable or even unprofitable, but railways kept them going because they fed the far more profitable main lines. These economics of interconnexion are, to use Moblet's phrase, "primary drivers" in the economics of transport and must be simulated in order for the player's incentives in the game adequately to match real-world economic incentives, and for the transport networks produced by a competent player to be sufficiently similar to those produced by competent managers of transport companies in reality.

In any event, this should have stimulated discussion sufficiently for now. I should be interested in responses to these thoughts; thank you to all participants so far for their careful analysis of these important issues.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: jamespetts on January 24, 2011, 12:48:14 AM
Fourthly, I am not quite sure what Moblet means by infrastructure having a limited life - can you elaborate, Moblet? Certainly, there are bridges tunnels, cuttings, embankments and stations out there well over a hundred years old in regular and intensive use, not likely to be replaced any time soon.
This arose from my trying to think through balancing vehicle costs, in this case between modes. You mentioned in relation to the rail revenue model's impact on balancing that sometimes it's necessary to work through the whole process to check that it will work before coding anything - I want to raise a red flag here and say that I think we need to work out how we're going to balance vehicle and infrastructure costs before doing any more work on coding revenues and costs. Otherwise we may end up with a sim in which it's impossible for us to balance costs effectively. From above
Quote from: moblet on January 11, 2011, 06:38:55 AM
There are currently no usage-based infrastructure costs, which unbalances early vs mature gameplay (makes it harder to make a profit when you start out), and also doesn't capture the reality that trains wear out rails but boats don't wear out water. If vehicles inflicted wear on their infrastructure that would be simple to include in balancing. One simplistic idea I have is to consider that each mode is, by nature, differentially infrastructure-intensive, and apply an infrastructure capital charge that is the same for each unit of a given mode. So we would benchmark a tram as if its purchase price included a portion of the infrastructure it required. The outcome of this is that the tram would be made cheaper than a bus to buy and own as an individual unit per passenger-km, to compensate for the fact that the player has to pay for more infrastructure to run the tram. The infrastructure loading would be set at a level that assumed a certain level of infrastructure utilisation; the player would not realise the benchmark return on the infrastructure investment if they did not achieve this utilisation (the lower cost of the trams would not offset the infrastructure cost unless a minimum number of trams were bought and used).
I don't know how much sense this makes without a spreadsheet to demonstrate it - if it needs better articulation, say so - but it's the only method I have thought of so far for balancing costs between modes.
Since the relative infrastructure costs are significant in this equation, one has to pin down what the infrastructure costs actually are. This is not possible if infrastructure never ages, since, say, the cost per passenger, or cost per tram km, or whatever measure of usage you care to employ, of a tramline built in 1920 and operated until 2050 will be a lot lower than one built in 2010 and equivalently operated to 2050. In reality that 1920 tramline will need to have its foundations broken up and relaid a couple of times in its life, and presumably its catenary system would need replacing too. If everything has a life, or some reliable mechanism for charging the player for its age, we can then calculate benchmark infrastructure costs for fulfilling a given transport task, and thus calculate a logical balance between modes. If it doesn't, I don't have any answers yet.
Quote from: JamesFifthly, one issue in relation to the use of purchase price to equalise the relative economic performance of vehicles is this: although that model might make sense where the ultimate user of the vehicle has to buy it from a third party manufacturer, in olden times, many vehicles were either built to order or built by the operators themselves (most major railway companies had their own works, for example, although they also subcontracted frequently), and so the purchase cost was not subject to market sensitivity as to its ultimate value. It would seem arbitrary to ignore this significant driver, which might have made a substantial difference to the fortunes of many a transport operator.
The decision of whether or not to purchase, in a commercial organisation that has capital available, is foremost driven by return on capital. The unit could be made by Santa's elves, it doesn't matter, the question investors ask is "what will be the return on my capital?". Don't fixate on how the vehicle is produced or acquired, especially as nothing was genuinely mass-produced before the 20th century. I mentioned before that transport costs have fallen over time - one of the drivers of that has been mass-production of transport equipment, which has reduced capital cost per unit of work, which means revenue per unit of work can fall and return on capital remains constant. You won't get good return on capital buying and operating an 1870's steam engine today, and that has to be the case in the sim. In their day, though, the 1870's steam loco and the 2010 diesel should, under equivalent operating conditions, generate similar return on capital. Return on capital is the simplest, most realistic, and most reliable benchmark that I can see. To deviate from that risks arbitrariness.
Quote from: JamesNot only that, but the cost of vehicles are often set when they are new and before their real success in service has been determined, so even then, the true market value of new vehicles is very unlikely to be reflected in their actual purchase costs.
I thought we covered this before. Simutrans doesn't model uncertainty, so we can't do anything about this. If a vehicle generated a different return on capital to expected, because it didn't perform as expected, we can't mimic that in the sim because that unit will be out of balance and be excessively attractive or unattractive to use. In practice, if it became apparent early in a vehicle's life that it was performing better or worse than expected, demand for that vehicle would increase or decrease, and thus its price would be expected to increase or decrease. In theory the price would rise or fall to the point where the vehicle's return on capital was equivalent to its competitors', its performance advantages/disadvantages fully counterbalanced by its higher/lower price. I'm sure you've found in your explorations of history that certain vehicles performed poorly and the manufacturer had to drop the price to maintain sales, or in extreme cases couldn't give them away.
Quote from: JamesSixthly, there may have been some confusion as to the meaning of comparable profitabilities
Forget profitability, think return on capital.
Quote from: James
Seventlhy, on cross-subsidisation, the suggestion was not that certain modes of transport could only be profitable at all when cross-subsidised, but rather the potential for one mode of transport positively to affect the profitability of another must be taken into account in circumstances where the two are likely often to be used in conjunction with each other, or distortions are likely. For example, before the second half of the 20th century, many railway branch lines were, of themselves, barely profitable or even unprofitable, but railways kept them going because they fed the far more profitable main lines. These economics of interconnexion are, to use Moblet's phrase, "primary drivers" in the economics of transport and must be simulated in order for the player's incentives in the game adequately to match real-world economic incentives, and for the transport networks produced by a competent player to be sufficiently similar to those produced by competent managers of transport companies in reality.
I don't see why it's necessary to worry about this. If a representative selection of vehicles is provided at sensible relative costs, that includes units suitable for branch line use, and the geographical arrangement suits branch line operations, then players will build branch lines, and they will do exactly this. This is a natural economic outcome, not something we have to contrive or manage. It already happens in Simutrans as it is, and nothing we're talking about doing is going to erode that. Note that branch line stock is characterised by lower utilisation (and/or revenue km over time due to lower speeds) than mainline stock; that's why it loses money, not because the stock is inherently unprofitable. If you put the branchline stock on mainline operations it would make more money, although in practice different stock might be used because its characteristics make it even more profitable than the branchline stock would be.

ӔO

#28
for lorries and buses, their capacity and power will need to be reworked a bit to fit inside the legal limits for realism purposes.

I've searched, and have found the legal limits for UK/EU trucks.
http://www.roadtransport.com/RoadLegal/11947/weights-dimensions-plating.html
I think the max speeds of the trucks and buses do follow the limits, but here it is for reference.
http://www.roadtransport.com/RoadLegal/11954/speed-limits-overtaking.html

My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

I have split the lengthy discussion about how fast that postman can pedal their bicycles here so that we can concentrate on general balancing discussion here.

Quote from: Moblet
Since the relative infrastructure costs are significant in this equation, one has to pin down what the infrastructure costs actually are. This is not possible if infrastructure never ages, since, say, the cost per passenger, or cost per tram km, or whatever measure of usage you care to employ, of a tramline built in 1920 and operated until 2050 will be a lot lower than one built in 2010 and equivalently operated to 2050. In reality that 1920 tramline will need to have its foundations broken up and relaid a couple of times in its life, and presumably its catenary system would need replacing too. If everything has a life, or some reliable mechanism for charging the player for its age, we can then calculate benchmark infrastructure costs for fulfilling a given transport task, and thus calculate a logical balance between modes. If it doesn't, I don't have any answers yet.

I think that I understand the point: infrastructure, generally, like vehicles needs to be renewed regularly? In other words - its upkeep cost is not static over time, but increases with age? I think that that can probably be simulated, but it's harder than for vehicles. We can't force players to re-lay the tracks every few years, and it's important to avoid players having to micromanage the renewal schedules for each tile (and there's no way of defining sets of tiles without more coding work than I am able to undertake in a reasonable timescale), but I suspect that there may well be a way around this with sufficient abstraction. In any event, implementation can be considered once we have determined that it is a good idea to implement this dynamic in the first place.

One point of some significant note, however, is that, whilst tracks, roads, catenary, etc., are regularly renewed, bridges and tunnels, generally, aren't (although they are maintained, of course). Just as it is unrealistic to have roads last forever, so too it is unrealistic to have to replace one's tunnels every so many years (incidentally, how does one account for special infrastructure such as bridges and tunnels when balancing?), so we must account for that aspect of things, too.

QuoteThe decision of whether or not to purchase, in a commercial organisation that has capital available, is foremost driven by return on capital. The unit could be made by Santa's elves, it doesn't matter, the question investors ask is "what will be the return on my capital?". Don't fixate on how the vehicle is produced or acquired, especially as nothing was genuinely mass-produced before the 20th century. I mentioned before that transport costs have fallen over time - one of the drivers of that has been mass-production of transport equipment, which has reduced capital cost per unit of work, which means revenue per unit of work can fall and return on capital remains constant. You won't get good return on capital buying and operating an 1870's steam engine today, and that has to be the case in the sim. In their day, though, the 1870's steam loco and the 2010 diesel should, under equivalent operating conditions, generate similar return on capital. Return on capital is the simplest, most realistic, and most reliable benchmark that I can see. To deviate from that risks arbitrariness.

I'm no economics expert, so forgive me whilst I attempt to get to grips with how your suggested ROI equalisation would actually impact the economy of the game being played. Let me give two historical examples and see whether your model would produce the same results. The first is the development of the trolleybus. In London (and many other UK cities) in the 1930s, trolleybuses rapidly replaced trams: they were, from the transport operator's point of view, in no way inferior to trams (they were no more expensive to buy and run), they had the same passenger carrying capacity, they were considered more comfortable by many passengers (although opinions do vary), and, crucially, they did not require rails, which were expensive to purchase and maintain. In effect, they had the same economics as trams except without the capital and maintenance cost of rails. As a result, they were very popular with transport operators and replaced trams very quickly in many places. Before the 1930s, trolleybuses were simply not made: people had not thought of the idea, so trams were the best available option Would the ROI equalisation model not demand that trolleybuses cost more somewhere to compensate for their advantages? And, if it did so demand, would that not produce a result significantly at variance with reality because the driving force behind the conversion to trolleybuses was precisely that they were, in their time, no worse than trams in some areas and better in others with few, if any, significant disadvantages (including in monetary terms)?

The second example is electrification of suburban railways. Before the early 20th century, this technology was not available. During the first half of the 20th century or so, different railway companies adopted different strategies towards such electrification, but the most notable adopter was the Southern Railway, which extensively electrified its suburban then main line networks from its creation in 1923 until the outbreak of war. The Southern was the smallest of the "big four" post grouping companies and was, when it was formed, not wealthy. Indeed, many of its electric trains were simply rebuilt steam-hauled carriages by reason of budgetary necessity. As a consequence of its electrification, the Southern became considerably more profitable by the later part of the 1930s, and was able then to afford more easily to build more new and better vehicles. Its overall profitability had substantially increased as a result of the economies achieved by electrification, in ways which would not have been possible if it had stuck with steam. Other railway companies that made larger profits on longer distance routes did stick with steam on their suburban routes to a far greater extent, and were still in many cases (especially that of the LMS) more profitable overall than the Southern (one might speculate that they would have been more profitable still had they electrified their busier routes (electrification only being economical in areas of relatively high utilisation)). Would this dynamic be modelled in your system, or would equalisation of ROI require that steam and electric profitability be more evenly balanced (or alternatively, that the electric units/infrastructure be so much more expensive to buy as to consume any additional profit that they generate)?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

#30
Quote from: jamespetts on January 28, 2011, 01:29:10 AM
I have split the lengthy discussion about how fast that postman can pedal their bicycles here so that we can concentrate on general balancing discussion here.
Sorry, we got a bit carried away there...
Quote from: jamespetts on January 28, 2011, 01:29:10 AM
I think that I understand the point: infrastructure, generally, like vehicles needs to be renewed regularly? In other words - its upkeep cost is not static over time, but increases with age? I think that that can probably be simulated, but it's harder than for vehicles. We can't force players to re-lay the tracks every few years, and it's important to avoid players having to micromanage the renewal schedules for each tile (and there's no way of defining sets of tiles without more coding work than I am able to undertake in a reasonable timescale), but I suspect that there may well be a way around this with sufficient abstraction. In any event, implementation can be considered once we have determined that it is a good idea to implement this dynamic in the first place.
Fundamentally we need a reliable means of equalising the combination of infrastructure and operating costs. That is the statement of the problem. There are at least two approaches to this, of which ageing infrastructure is one; I will start a topic on fundamental approaches to balancing in the near future to articulate these and see what other options can be generated.
Quote from: jamespetts on January 28, 2011, 01:29:10 AMOne point of some significant note, however, is that, whilst tracks, roads, catenary, etc., are regularly renewed, bridges and tunnels, generally, aren't (although they are maintained, of course). Just as it is unrealistic to have roads last forever, so too it is unrealistic to have to replace one's tunnels every so many years (incidentally, how does one account for special infrastructure such as bridges and tunnels when balancing?), so we must account for that aspect of things, too.
This is no big deal if the dynamics of the code, and the parameter set, allows for differences in lifetimes and construction and maintenance costs. It's one of the trees that has to be kept in sight during the design process.
Quote from: jamespetts on January 28, 2011, 01:29:10 AM
Let me give two historical examples and see whether your model would produce the same results.
From the two examples you've selected, I think you grasp the concepts and trade-offs in ROI, but are perhaps struggling to see how easily they can (and almost currently do) play out in the sim. If one has a faithful model of the dynamics of ROI, then every outcome can be explained in terms of captial vs operating costs, just as you have done here. Capital and operating costs are parameters, and therefore every decision the player makes gets steered by the actual values of the capital vs operating costs. These actual values are something the developers can choose (and, of course, knowledgeable players can manipulate). So let's look at your examples:

Trams vs trolleybuses

Firstly, there were possibly technological improvements that enabled the trolleybus, most likely in adapting and squeezing the mechanicals of a tram into the more constrained chassis area and axle-loadings of a bus.
Quote from: JamesWould the ROI equalisation model not demand that trolleybuses cost more somewhere to compensate for their advantages?
We need to separate some concepts here. What you call "the ROI equalisation model" is not a model, it is a step towards a realistic set of capital vs operating costs. I have proposed a spreadsheet model that can perform ROI comparisons of different vehicles and modes. This spreadsheet does not demand anything, and we can put whatever numbers into it that we wish in order to get the relative ROI that we want.

How I am proposing we use the concept of "ROI equalisation" is not to simply equalise everything's ROI and stop there. If we did that then yes, trolleybuses would have to cost more to compensate for the tram tracks they don't need. Since that isn't the case, we would then adjust the trolleybuses' capital cost downwards, and/or the trams' capital cost upwards, to bring it more into line with reality. Using a model such as the one I've proposed, we would be able to decide and state by what percentage the trolleybuses' ROI should outperform the trams', which gives us a really efficient means of calibrating it for optimal gameplay. It will be much eaiser to use an equalised ROI as the starting point for adjusting the relative economic performance of modes and vehicles, than it would be to use zero. The absolute numbers in the sim matter far less than their relative values.

Remember too that even though trolleybuses were, from that point on, the chosen and presumably the best option, trams were still an option, and the economics of trams were presumably unchanged. Operators didn't think, "oh, trolleybuses are here, forget trams", they would have done their sums and concluded, independently, that the buses were more economic. It was also still the case that the higher the utlisation of the tram line, the more economic trams would be, and the more economically competitive trams would be compared to buses, even if they were always the poorer option. With ROI represented in the sim, and the parameters set correctly, these dynamics will be there.

Rail electrification

Firstly, the divergent strategies of the different companies would have been the result of different assumptions, and presumably different operating conditions, such as:
- Expected future costs of fuel and labour
- Expected future technologies and their dates of availability
- Borrowing costs
- Current and expected utilisation
- In-house knowledge & skills
- Relative performance of steam & electric traction for their particular transport tasks
- Community/operator impact of emissions

As you've observed, higher utilisation spreads the infrastructure costs and makes higher-infrastructure, lower operating cost options more attractive. The attached spreadsheet demonstrates this. One can always find a set of assumptions at which either steam or electric is uneconomic, and there is typically a threshold level of utilisation at which the higher capital cost becomes worth it, so it comes down to what one's assumptions and operating conditions are. If the sim is scaled correctly and the relative costs are about right, then the player's trade-offs will look similar to the real world's.

When it comes to analysing history, we must remember that we aren't faced with the uncertainties that these operators had when they made decisions on electric vs steam, and that the outcomes they experienced were a product of how things actually panned out. For example, if fuel and labour costs had been lower than they actually were, steam would have been relatively cheaper to run. If someone had invented some amazing battery that could fit in a locomotive and run it for a day, the catenary infrastructure would have become obsolete overnight. Presumably also if diesel engine technology had progressed much faster, or nuclear powered locomotives had emerged (sounds silly now, but I'm sure in 1950 some would have seen them as inevitable). Another issue is that these companies weren't in direct competition for traffic, since they ran to different places, so geographical changes in demand also impacted their utilisation and revenue opportunities. One thing's for sure - if electrification would have been the most economic choice for all of them, and they had known that when making their decisions, they all would have chosen it.

In applying this to Simutrans, the same trade-off needs to be presented to the player - will this line see enough traffic to justify the capital investment in electrification? The player needs to be confronted with parameters that produce a nice trade-off curve, so that if the player electrifies and the line is poorly utilised the player loses money, but if it is highly utilised they make more money than they would have with steam. Note the risk profile here - if you electrify and don't utilise you make a loss, whereas if you don't electrify and highly utilise you don't make a loss, you simply make less profit. Bottom line there is no matter where the trade-off lies, the rational decision is not to electrify unless you're absolutely sure you're going to utilise it adequately for quite a long time. Steam was still a competitive technology, so Southern would still have made a profit using it, and who knows, maybe they would have made more profit had they done so. Electrification is an obvious point of differentiation, but it wasn't the only contributor to the difference in profitability, and without data of their accounts and operations one couldn't say for certain whether electrification increased or decreased their profitability.

To equalise ROI in the sim, hopefully that spreadsheet has demonstrated that the ROI outcome depends critically on cost and utilisation assumptions. In the sim this will mean that a player's actual ROI will depend, just like the real world, on utilisation. The point where the steam vs electric ROI's meet is the only point where the ROI outcomes will be equal. At lower utilisation steam has a higher ROI than electric, and at higher utilisation, electric has the higher ROI. We need to find a set of numbers that produces a realistic threshold value, which we can do consciously, and if the sim has ROI or some proxy built into it, the player's outcome will follow the curve.

ӔO

#31
some of the main reasons to use electric over steam.
- better acceleration (good for short station intervals)
- climbing ability (no need to use a banking engine)
- extensive use inside tunnel
- easy to maintain system (not very far from cities or towns)
- cleaner to immediate vicinity.


I think it's easier to compare diesel to steam, than electric to steam.
Electrics were still an emerging technology in the golden days of steam, and they just weren't as fast.
Eventually, the technology caught up, which is why companies started expanding their electrical network.

My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Apologies for the slow reply - has been a busy week!

Quote from: Moblet
From the two examples you've selected, I think you grasp the concepts and trade-offs in ROI, but are perhaps struggling to see how easily they can (and almost currently do) play out in the sim. If one has a faithful model of the dynamics of ROI, then every outcome can be explained in terms of captial vs operating costs, just as you have done here. Capital and operating costs are parameters, and therefore every decision the player makes gets steered by the actual values of the capital vs operating costs. These actual values are something the developers can choose (and, of course, knowledgeable players can manipulate).

Aha! I may have been misunderstanding a little what was suggested: this all makes more sense now. The ROI equalisation/comparison process that you suggest is not, after all, opposed to an historical model of transportation economics in which the ROI is not necessarily equal (and is unequal in a number of specific, important respects, as in the examples), but is a process of ultimate calibration that can work in harmony with it? That being the case, there seems to be everything to recommend your method in principle, and the only remaining discussion being as to the details of its implementation. I still think that there is much value in historical research as to prices where possible: the results of that research can easily be used in conjunction with the ROI model to tell us how to equalise the ROI when we equalise it, and when to deviate from it when we need to deviate, whilst the ROI mathematics can keep such deviation within playable limits. Indeed, we can use the ROI model, can we not, to model incentives that we knew were present historically fairly accurately even if we don't have the figures? Have I understood this correctly now?

Quote
As you've observed, higher utilisation spreads the infrastructure costs and makes higher-infrastructure, lower operating cost options more attractive. The attached spreadsheet demonstrates this. One can always find a set of assumptions at which either steam or electric is uneconomic, and there is typically a threshold level of utilisation at which the higher capital cost becomes worth it, so it comes down to what one's assumptions and operating conditions are. If the sim is scaled correctly and the relative costs are about right, then the player's trade-offs will look similar to the real world's

The spreadsheet was most interesting (I assume that all the various steam graphs are on top of each other in the straight line in the middle?). I have wanted for a long time to be able to model accurately the utilisation incentives with electrification to incentivise players to make economically sensible decisions. One thing that is really very interesting about electrification are the economics at the margin: it's easy to work out that an ultra-intensive inner-suburban line should be electrified and that a long distance line to a tiny town in the sticks should not be electrified, but on the margins, where electrification will yield a greater profit, but only very slightly greater and a long way in the future, how different player strategies will play out (which may depend on capital availability, of course) is very interesting.

Quote
The player needs to be confronted with parameters that produce a nice trade-off curve, so that if the player electrifies and the line is poorly utilised the player loses money, but if it is highly utilised they make more money than they would have with steam. Note the risk profile here - if you electrify and don't utilise you make a loss, whereas if you don't electrify and highly utilise you don't make a loss, you simply make less profit.

Presumably, there are cases on the margins where one doesn't make a loss by electrifying, but also just makes less profit? I always think that it is very interesting to see consistent differences over time between players and how they handle the marginal cases, which would be especially interesting to see emerge over a long-term network game (e.g., player A tends against capital investment in cases of doubt, whereas player B tends in favour of capital investment in cases of doubt, consequently player B's network has electrification in places that player A's network wouldn't have them, etc.).

Quote
Steam was still a competitive technology, so Southern would still have made a profit using it, and who knows, maybe they would have made more profit had they done so. Electrification is an obvious point of differentiation, but it wasn't the only contributor to the difference in profitability, and without data of their accounts and operations one couldn't say for certain whether electrification increased or decreased their profitability.

The books that I have read expressly attribute the improved profitability to the electrification, and I hope that I am reasonable in assuming that their authors, learned in the subject of railway history as they are, did not make the elementary mistake of inferring causation from mere correlation.

QuoteWe need to find a set of numbers that produces a realistic threshold value, which we can do consciously, and if the sim has ROI or some proxy built into it, the player's outcome will follow the curve.

Yes, indeed! The next question is how we go about doing that starting from where we are now...

Quote from: AEO
some of the main reasons to use electric over steam.
- better acceleration (good for short station intervals)
- climbing ability (no need to use a banking engine)
- extensive use inside tunnel
- easy to maintain system (not very far from cities or towns)
- cleaner to immediate vicinity.

I do try to model some of these in Experimental - the different acceleration performance is implemented, as is climbing ability (although currently hills do not have enough of an effect on fast-moving trains, something that I am hoping to resolve in a future version); it is difficult to simulate a disincentive to make extensive use of steam in tunnels as there is no precise boundary between acceptable and unacceptable levels of usage, particularly as unacceptable levels of usage were tolerated until alternatives were found; the ease of maintenance in some areas rather than others is an interesting idea that I had not hitherto considered (but might be hard to simulate), and the local environmental impact (of which the tunnels issue is, in reality, a part) strikes me as rather a nebulous a thing to attempt to draw out into a workable algorithm in a transport game.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

QuoteIt is difficult to simulate a disincentive to make extensive use of steam in tunnels as there is no precise boundary between acceptable and unacceptable levels of usage, particularly as unacceptable levels of usage were tolerated until alternatives were found;
You already have the tool, way restrictions. Introducing a non-steam tunnel (eg. subway tunnel) with lower maintenance costs but a way restriction not to allow steam (and diesel) to use it.

jamespetts

Quote from: sdog on February 01, 2011, 05:42:27 AM
You already have the tool, way restrictions. Introducing a non-steam tunnel (eg. subway tunnel) with lower maintenance costs but a way restriction not to allow steam (and diesel) to use it.

Ahh, that can work up to a point, and that is exactly what I was planning to do for the deep level "tube" lines that require much smaller trains (all of which will be electric), but won't work for the equivalent of sub-surface lines, which actually were worked by steam until the late 19th century (indeed, Pak128.Britain includes a steam locomotive (the Metropolitan "E" class) that was designed specifically for use on the Metropolitan Railway, part of the London Underground.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: jamespetts on January 31, 2011, 11:18:55 PM
The ROI equalisation/comparison process that you suggest is not, after all, opposed to an historical model of transportation economics in which the ROI is not necessarily equal (and is unequal in a number of specific, important respects, as in the examples), but is a process of ultimate calibration that can work in harmony with it?
It is a historical model of transportation economics.
Quote from: JamesI still think that there is much value in historical research as to prices where possible: the results of that research can easily be used in conjunction with the ROI model to tell us how to equalise the ROI when we equalise it, and when to deviate from it when we need to deviate, whilst the ROI mathematics can keep such deviation within playable limits. Indeed, we can use the ROI model, can we not, to model incentives that we knew were present historically fairly accurately even if we don't have the figures? Have I understood this correctly now?
Yes.
Quote from: James
I assume that all the various steam graphs are on top of each other in the straight line in the middle?
Yes, the steam numbers are all the same so they lie on top of each other. I put them in so that you could compare against different steam costs if you so wished.
Quote from: JamesI have wanted for a long time to be able to model accurately the utilisation incentives with electrification to incentivise players to make economically sensible decisions.
And Simutrans is already halfway towards capturing this. The major missing links are cost of capital (can be done with the interest rate), fixed-vs-variable cost dynamics, and somehow representing the impacts of ageing.
Quote from: JamesPresumably, there are cases on the margins where one doesn't make a loss by electrifying, but also just makes less profit?
Yes, but there is more downside risk in electrifying. Southern needed to make more profit in exchange for that higher risk, and they did.
Quote from: JamesI always think that it is very interesting to see consistent differences over time between players and how they handle the marginal cases, which would be especially interesting to see emerge over a long-term network game (e.g., player A tends against capital investment in cases of doubt, whereas player B tends in favour of capital investment in cases of doubt, consequently player B's network has electrification in places that player A's network wouldn't have them, etc.).
Our goal is make sure the way these strategies pan out is economically realistic.
Quote from: James
Yes, indeed! The next question is how we go about doing that starting from where we are now...
This is where we have so far exhibited a clash of styles. As I said previously my approach is to do two things; identify what dynamics and functionality we really want in the sim, and go back to the Standard engine and compare its capabilities with that list. I did some analysis and asked some questions on the speedbonus and trip profitability the other day, from which emerged some very significant insights:
- Standard was never designed to support timeline dynamics (i.e. playing through history).
- Standard's economic engine was never designed for modular, independent pakset development. Standard's economic assumptions and dynamics are highly simplistic, and do not support the pakBritain philosophy of using historical equipment and numbers.
- Standard is designed to drive replacement decisions by having a pakset offering very limited choices, and introducing new vehicles at intervals with superior performance that effectively compel the player to upgrade. This keeps code and paksets simple, but it is not a true economic model, and it does not support the pakBritain philosophy of offering a wide range of vehicles and having the player select what will maximise profitability on the task at hand.
- Because the assumptions, calculations, and principles for developing paksets have not been documented explicitly, those pakset developers not familiar with the code are flying blind and tying themselves in knots trying to balance their sets. (If paksets are meant to be modular add-ons then the game dynamics need to be articulated in words so that pakset developers can easily learn what they need to learn. They should not be asked to compile the source code in their heads.)
I would not try to address any of the above by simply whacking more complexity on top of the Standard engine. I would first work out what dynamics were essential to the gameplay and pakset development goals, and simple ways to model them, and then compare that with what's in Standard. From there it would be a case of switching off or removing what isn't needed, and adding what is needed. I would describe the Experimental development process thus far as one of building highly complex modules of specific dynamics of unquantified significance, and while it's not a process I believe in, or can contribute to, I recognise that it has a fair bit of momentum, and I don't wish to fragment the community. The nature of an open source project is that what people will coalesce around, will happen. If people continue to coalesce around the current approach then it will continue. If there is coalescence around the idea of stepping back and designing a project version of Standard, whether that's the "Experimental version" or not, from first principles, then it will happen. As you, James, are the driving force behind Experimental, and this is a volunteer gig and a labour of love, it probably comes down to your personal priorities and what's going to be most rewarding for you. Have you identified what rewards you are seeking from your involvement in Experimental, and what would give you the most satisfaction?

jamespetts

QuoteOur goal is make sure the way these strategies pan out is economically realistic.

Yes, indeed - an admirable starting point, I think.

As to the longer part of the post, the discussion of the origins of Standard are very interesting: I was not aware of the early historical setup. Certainly, Standard is too simplified for my tastes (and was evidently even more so in the early days); that is not, of course, to criticise Hajo, not only because tastes in preferable levels of complexity vary, but also because starting a project from scratch to run on the sorts of computers available in the early 1990s requires a greater degree of simplification for practical purposes than dealing with an already established project with numerous contributors designed to run on modern day computers. Nonetheless, the outcomes of making particular sorts of decisions in Standard are sufficiently divergent from reality to mar for me the enjoyment of playing it. That is what I have aimed to rectify with Experimental.

I take the point on documentation: pakset developers and maintainers do indeed need access to a natural language description of features sufficient for them to balance the paksets effectively. The approach that I have taken so far to documentation in Simutrans-Experimental is to document the additional features of Simutrans-Experimental myself, and leave the documentation of features shared with Standard to the existing documentation systems (see here for the Wiki). For the in-game help files, I have modified a great many of them to present a user-friendly, integrated description of Simutrans-Experimental as it stands, but that is aimed at users, not pakset developers. I have done it that way because development resources are not adequate to re-document Standard features in a Simutrans-Experimental specific documentation set. Given those limited development resources and the way in which we have handled Simutrans-Experimental documentation so far, what are your thoughts about the most efficient way to proceed to acheive a level of documentation that is adequate for the purpose of pakset developers, if possible, without duplicating work already done either in this thread or by the documenters of Standard?

Quote
I would not try to address any of the above by simply whacking more complexity on top of the Standard engine. I would first work out what dynamics were essential to the gameplay and pakset development goals, and simple ways to model them, and then compare that with what's in Standard. From there it would be a case of switching off or removing what isn't needed, and adding what is needed. I would describe the Experimental development process thus far as one of building highly complex modules of specific dynamics of unquantified significance, and while it's not a process I believe in, or can contribute to, I recognise that it has a fair bit of momentum, and I don't wish to fragment the community.

Whilst it is often tempting to say, when asked how to reach a particular destination, "I wouldn't start from here", it is from here that we are, in fact, starting, and the destination, in broad terms, is, I hope, uncontroversial. You have already helpfully identified some simulation dynamics missing in both Standard and Experimental whose absence prevents the effective balancing of any pakset in ways such as to make the game challenging but playable over the long term. Those, obviously, need to be addressed: to that extent we are agreed (I do not know what the position of the Standard developers are on that issue). Would the purpose of the exercise that you are suggesting be to identify more such issues (and, ultimately, solutions for them)? Certainly, if there are any other balance-critical issues of that nature, they, too, need to be identified and addressed: Simutrans-Experimental will never really succeed if there are unresolved balance critical issues such as those that you have identified.

Does what you are proposing have any aims beyond identifying balance critical issues and the means to address them? Given that we are where we are, and that the issue at hand is the best route from our current location to our destination, not from some location in which we had found ourselves some time in the past to that same destination, you will, I hope, understand my questioning whether it is necessary to conduct the hypothetical exercise of asking what features we might have added if we were starting with Experimental to-morrow, especially if such an exercise is not a necessary step in removing balance critical issues (a number of which you appear to have identified without undertaking such an exercise), and especially given the resource implications of such a process. (Forgive me, incidentally, if I have unintentionally characterised what I understand you to be suggesting incorrectly).

We certainly can - and should - ask, as you suggest, what dynamics are essential to gameplay and pakset development goals and how best to model them. We have started that process already, and most helpfully, and I hope that we can continue that process. Where I think that we disagree is in the next part of what you suggest, being, if I understand you correctly, to remove any feature which is not essential to pakset balancing.

That a feature is not so critical that it will be difficult or impossible to balance the game effectively without it does not, in my view, make it undesirable that it should be simulated. The view that I take is that, if it adds something positive to the game, there is no reason to remove it. Removing a feature that is already present is as significant a change as adding a new feature, and the presumption should in each case be in favour of the status quo, which presumption is displaced by some good reason to believe that the changed state of affairs (taking into account the cost of making the change) will be a better state of affairs than the current state of affairs. There is nothing in that approach, as far as I can discern, that is in any way incompatible with finding a good and efficient route to the destination that I think that we both share of producing a version of Simutrans that accurately models economic incentives whilst remaining fun to play.

There is also the issue of how to quantify significance. I have no formal training in economics, and so my method of quantifying significance of a dynamic is to look at real transport networks and discern why significant things are as they are: if there are certain dynamics that have a significant impact in reality, then simulating them, if done properly, ought have a more or less equally significant impact in the simulation. I have not had the tools or resources to conduct a numerical analysis of the impact of particular features on the game (indeed, I do not think that this has been done for Standard features, either), but have done the best that I can with the tools that I do have available: historical research and knowledge of what factors were actually significant. I have then chosen what can be modelled effectively without creating excess complexity for the player, code developer or pakset developer or undue computational load such as to impact game performance, and tried to model those dynamics in a way that simulates as closely how the things work in reality as I am able.

To continue with the example of private cars: it is notorious that the ascent of the automobile has significantly changed the fortunes of short and medium distance passenger transportation, and particularly railways. The 1950s-1980s saw a precipitous decline in passenger numbers on Britain's railways, which only began to recover from the late 1980s onwards as a result of a combination of population growth, and, more importantly, the impact of congestion on the relative desirability of travelling by car. I wanted Simutrans to be able to capture this reality and for players to have to contend with the competition from private cars in as realistic way as possible. I wanted players to be in a position to choose whether to take the Beeching approach to the problem (that is, close a great many railway lines), or whether some other alternative would produce a better result. I wanted players to be in the position of having to reduce capacity in the middle 20th century, only to have to increase it again in the late 20th and early 21st century as congestion in towns and cities became an increasing problem. All of these issues are highly significant to real-world transport planning. If they turn out not to be significant in the game, that is not an indication that the feature should be abandoned; rather, that it has not been done properly and should be fixed. Whilst, however, I have not conducted any formal testing of the sort that I think that you mean, I have looked into this feature somewhat extensively, both at the micro level with a debugger looking at individual packets of passengers choosing whether to use a private car or not, and the macro, by seeing in a developed game the numbers of passengers using public transport steadily falling at the appropriate times in history and the levels of traffic concomitantly increasing despite a gradual increase in the total number of passengers generated.

In other instances, I have added features on the basis of providing a realistic incentive to choose different types of vehicles from the range of historically accurate vehicles available in Pak128.Britain: the reversing feature (combined with the weight limit feature) to provide a balance of incentives between tank and tender locomotives, for instance, the catering feature to make it meaningful to provide catering vehicles, and so forth. The significance of these features must be seen in light of that purpose. I find that it detracts enormously from the enjoyment of the game when I know that using a particular type of vehicle in the game will have no benefit, whereas, in reality, it would have a significant benefit. That sort of significance is just as good a reason to have a feature as the significance of balance criticality.

Quote
As you, James, are the driving force behind Experimental, and this is a volunteer gig and a labour of love, it probably comes down to your personal priorities and what's going to be most rewarding for you. Have you identified what rewards you are seeking from your involvement in Experimental, and what would give you the most satisfaction?

What would give me the most satisfaction is the continued development of Experimental and Pak128.Britain-Ex to a point where delightfully intricate historically plausible transport networks emerge from players simply making decisions that are economically sound in game terms, without consciously trying to give the appearance of historical plausibility, in which there is a thriving playing and developing community (ideally involving additional paksets at least some of which have similar goals) and lengthy persistent multi-player games where players variously compete and co-operate with each other, all the while producing realistic and realistically characterful transport networks that change gradually over time in much the same way as real transport networks so change. This, of course, would require Simutrans-Experimental to simulate the necessary economic ingredients to balance properly, which is, in my view, a necessary but not sufficient condition of achieving that goal, a goal which, I hope, is not mine alone.
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

Quote from: neroden on January 10, 2011, 09:42:04 PM
EDIT: If you're going to work on balancing, I suggest working on infrastructure maintenance costs first.  I am really unsure how to balance them properly, but every good way of balancing vehicle prices depends on balancing infrastructure maintenance first.  :-P

I know bridge prices need to be scaled to the scale because elevated track prices are, that would be a start...


I have now done this in my latest commit to the 9.x 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.

moblet

Quote from: jamespetts on February 02, 2011, 08:36:17 PM
Standard is too simplified for my tastes
It is for mine too, but some semantics are in order here. Say, for example, "Standard's economic model is not realistic enough", not "Standard is too simple" or anything that might convince you that Experimental can only exceed Standard by being more complicated, and/or that it will exceed Standard performance in exact measure to the extent by which it exceeds Standard's complexity. I would try to get everything we want from Experimental with no greater complexity than Standard - probably not possible, but that's my goal.
Quote from: JamesGiven those limited development resources and the way in which we have handled Simutrans-Experimental documentation so far, what are your thoughts about the most efficient way to proceed to acheive a level of documentation that is adequate for the purpose of pakset developers, if possible, without duplicating work already done either in this thread or by the documenters of Standard?
I have no magic bullets on this one - must confess that documentation's never been one of my strong points - but firstly I want to make sure we document our decision making as we work through the design. I would say though that before any new feature is coded, or any code is revised, a plain language version should be worked up and circulated on this forum for discussion. Once finalised it forms the instructions for whoever's coding, part of the technical documentation, and raw material for writing help files and manuals for players and pakset builders.
Quote from: James
Whilst it is often tempting to say, when asked how to reach a particular destination, "I wouldn't start from here", it is from here that we are, in fact, starting, and the destination, in broad terms, is, I hope, uncontroversial.
Where I would always have chosen to start from, for the purposes of examining Standard's missing dynamics, is Standard. Standard is still here, so that's where I propose we start from.
Quote from: JamesWould the purpose of the exercise that you are suggesting be to identify more such issues (and, ultimately, solutions for them)?
We have to make sure we don't overlook anything, and also that we remember to document everything we include or exclude. Step one for me is to list the dynamics of Standard, highlight the ones we've thought about changing with the reasons why, and put that to the community to see what the collective thought process comes up with. This is different to asking the wide-open question of "what do you want in Experimental?" and should focus thinking on the dynamics and throw up anything we've missed. I would be very uncomfortable proceeding on the basis of only what I've thought of.
Quote from: JamesWhere I think that we disagree is in the next part of what you suggest, being, if I understand you correctly, to remove any feature which is not essential to pakset balancing.
I didn't mean specifically pakset balancing, and I forgot to articulate all the steps in my thinking. Where I'm coming from is the need to make the sim as computationally light as possible. The real world doesn't have to be computationally efficient, but Simutrans needs to be. So in considering how to model each dynamic, the computational cost of each option has to be considered. One reason for developing multiple options to choose from. We could probably safely assume that an 80/20 rule applies here - one can get 80% of the dynamical accuracy with 20% of the computational workload, and end up consuming four fifths of the computational load trying to perfect the last 20%. The same would apply to the parameter count. I'm hoping we can get ourselves a great sim without having to cross that 80% line too much.
Quote from: JamesThe view that I take is that, if it adds something positive to the game, there is no reason to remove it.
I see that as a cost/benefit equation. The costs are computational effort and complexity confronting the player. There is otherwise no limit to what could add something positive to the game.
Quote from: JamesRemoving a feature that is already present is as significant a change as adding a new feature, and the presumption should in each case be in favour of the status quo
I would more or less agree with this with respect to Standard, for some of the complexities added to Experimental I'd want to do some analysis on their significance before agreeing that they are worth the extra parameters and computations.
Quote from: JamesThere is also the issue of how to quantify significance. I have no formal training in economics, and so my method of quantifying significance of a dynamic is to look at real transport networks and discern why significant things are as they are: if there are certain dynamics that have a significant impact in reality, then simulating them, if done properly, ought have a more or less equally significant impact in the simulation.
Just remember that sometimes the decisions that created what we see were influenced by uncertainties that were present at the time, so it's not always a black and white thing, and also that we aren't likely to be able to model every last real world dynamic. Without these factors a rational player, playing a dynamically faithful Simutrans, might build a world that isn't exactly what we see in reality, but that this isn't a bad thing.
Quote from: JamesI have not had the tools or resources to conduct a numerical analysis of the impact of particular features on the game (indeed, I do not think that this has been done for Standard features, either), but have done the best that I can with the tools that I do have available: historical research and knowledge of what factors were actually significant. I have then chosen what can be modelled effectively without creating excess complexity for the player, code developer or pakset developer or undue computational load such as to impact game performance, and tried to model those dynamics in a way that simulates as closely how the things work in reality as I am able.
The process that doesn't appear to me to have been happening is analysing the behaviour of Simutrans itself as it plays out a dynamic. That's what I propose we start doing now. Turfit just provided an example of the kind of thing I believe we should be doing first: setting up simple, controlled experiments in the sim to observe what happens. So how about we select a topical dynamic, such as electrification vs steam, and contrive an experiment in Standard to see how this choice plays out over time? By comparing Standard's behaviour to our understanding of reality, and to our vision of Experimental, we can best determine how to build from Standard.
Quote from: James
To continue with the example of private cars
To model the competition between trains and cars, I would first lay out some of the modelling options, which range from simple ones like artificially adjusting car demand to match historical figures, to developing a full-on car transport demand model based on costs and congestion. There's no doubt what happened historically was significant, but there's equally no guarantee that a player will make the decisions that set this reality up. E.g., the player might never have provided extensive passenger service in the first place. There's a lot to think through in terms of modelling possibilities.
Quote from: JamesIn other instances, I have added features on the basis of providing a realistic incentive to choose different types of vehicles from the range of historically accurate vehicles available in Pak128.Britain: the reversing feature (combined with the weight limit feature) to provide a balance of incentives between tank and tender locomotives, for instance, the catering feature to make it meaningful to provide catering vehicles, and so forth. The significance of these features must be seen in light of that purpose. I find that it detracts enormously from the enjoyment of the game when I know that using a particular type of vehicle in the game will have no benefit, whereas, in reality, it would have a significant benefit. That sort of significance is just as good a reason to have a feature as the significance of balance criticality.
The impact of reversing can be modelled explicitly, or it can be rolled into the combination of capital/operating/ownership costs. I would have started out with the latter approach, because it's simpler, and seen how that panned out before adding more code and parameters. That also means that I would have laid foundations like the modelling of costs long before thinking about issues like reversing times. I'm going to be ignoring intricacies and nice-to-haves until the really basic dynamical stuff is bedded in. Not only that, I think it will be more informative, and more conducive to obtaining an efficient final sim, to test the basic dynamical stuff without these intricacies, which is one of the reasons I suggest we begin our testing work with Standard.

jamespetts

Quote
Where I would always have chosen to start from, for the purposes of examining Standard's missing dynamics, is Standard. Standard is still here, so that's where I propose we start from.

This is not my starting point, as I am the maintainer of the Experimental project. My starting point is the Experimental project as it stands currently, and I do not understand why it should be otherwise. Taking Standard as the starting point is only a logical choice if you are suggesting changes to Standard (which changes, if implemented in Standard, are likely to find themselves in Experimental unless there is a clash between existing Experimental and new Standard features and the existing Experimental features work better, but the historical precedent is that, most often, when a new Standard feature clashes with an existing Experimental feature, the new Standard feature has taken precedence).

I do not know how the Standard developers view your suggestions for, for example, limited vehicle/infrastructure lifetime, and so forth, and therefore whether your suggestions are likely to be implemented there. What I do know is that the reason that Experimental exists at all is because the Standard developers did not want to include features that I consider important, such as calculating revenue based on actual average speeds rather than the theoretical maximum speed of the slowest vehicle in the convoy, and having passengers/goods choose which route to take according to which route will take them to their destination more quickly rather than any route with the fewest number of transfers (and, more latterly, also fewest intermediate stops). I would assume that you would also consider those features important: I cannot imagine that they are any less important than limited vehicle lifetime, etc., for proper balancing.

QuoteI didn't mean specifically pakset balancing, and I forgot to articulate all the steps in my thinking. Where I'm coming from is the need to make the sim as computationally light as possible. The real world doesn't have to be computationally efficient, but Simutrans needs to be. So in considering how to model each dynamic, the computational cost of each option has to be considered. One reason for developing multiple options to choose from. We could probably safely assume that an 80/20 rule applies here - one can get 80% of the dynamical accuracy with 20% of the computational workload, and end up consuming four fifths of the computational load trying to perfect the last 20%. The same would apply to the parameter count. I'm hoping we can get ourselves a great sim without having to cross that 80% line too much.

As to computational load, the view that I take on this topic is that, although, for any given feature set, it is always better to have the most efficient possible code, but when evaluating whether to have a feature at all as against the issue of computational load, computational load is no reason not to include any feature unless its inclusion makes the overall performance unacceptable to the user. Evaluating this is greatly complicated by the multiplicity of hardware available. Until very recently, I did all of my development on a seven-year-old Pentium 4 computer with 2Gb of RAM and Windows XP, and worked on the basis that, if it performed adequately on that computer without compiler optimisations enabled, then performance is not an issue. I have a much faster computer now, so that is slightly harder to gauge, but have not added any significant features since I have upgraded, so that has not yet been an issue.

Only one feature recently has given rise to significant computational load issues, and that is the feature of private cars checking whether they can find a route to their destination, which is problematic on large, well-populated maps. The problem is caused by the fact that the information as to whether the cars can reach their destinations is not saved, and that the routes are recalculated frequently. Fixing that issue is currently a priority, which fix will involve saving the routing data between sessions and recalculating routes for each city annually rather than monthly, spread evenly accross the year.

It should be remembered that many features that have great economic significance have only a very small effect on load, almost certainly not enough to impact on performance in a noticeable way: changes to how revenue is calculated, for example, has very little effect on computational load, as the algorithm for calculating revenue is called relatively infrequently. Reversing, catering, way constraints, weight limits and comfort are all features in Experimental with significant economic impact but insignificant computational load impact.

One of the themes of the development of Experimental has been the ability to take advantage of the more powerful computer systems available in modern times that were not available at the time that Simutrans was first developed (circa 1997), and to do things which would not have been practicable in that era. That allows a more sophisticated simulation whilst maintaining acceptable performance levels.

QuoteJust remember that sometimes the decisions that created what we see were influenced by uncertainties that were present at the time, so it's not always a black and white thing, and also that we aren't likely to be able to model every last real world dynamic. Without these factors a rational player, playing a dynamically faithful Simutrans, might build a world that isn't exactly what we see in reality, but that this isn't a bad thing.

I don't think that this contradicts the point that I made about significance in the game being derived from significance in reality, although I am not sure whether it was intended so to contradict. It is true that some features of reality are sufficiently dependant on lack of future knowledge, which knowledge cannot sensibly be denied to the player, such as to make their inclusion futile: that is why Pak128.Britain does not include broad gauge, for example, even though it was highly significant in railway history, as it is highly unlikely that Brunel would have chosen it had he known that the GWR would lose the "gauge wars" of the late 19th century. However, I do not think that there is any reason to suppose that that applies to any of the features that have been included, such as loading time, reversing times, comfort, catering, weight limits, way constraints, private cars, etc..

Quote
The process that doesn't appear to me to have been happening is analysing the behaviour of Simutrans itself as it plays out a dynamic. That's what I propose we start doing now. Turfit just provided an example of the kind of thing I believe we should be doing first: setting up simple, controlled experiments in the sim to observe what happens. So how about we select a topical dynamic, such as electrification vs steam, and contrive an experiment in Standard to see how this choice plays out over time? By comparing Standard's behaviour to our understanding of reality, and to our vision of Experimental, we can best determine how to build from Standard.

I have often undertaken such experimental analysis for the purpose of balancing, and have used it recently in relation to the balancing of steam locomotive physics (setting up a controlled test track on which I could run various steam locomotives with various loads, and then tinker with the parameters until the in-game performance matched as closely as possible historically researched real-world performances). There is merit indeed in this approach. However, as stated above, my starting point is not Standard, but Experimental as it currently stands, and I do not understand why it should be otherwise. I am not building from Standard, but refining Experimental.

QuoteThe impact of reversing can be modelled explicitly, or it can be rolled into the combination of capital/operating/ownership costs. I would have started out with the latter approach, because it's simpler, and seen how that panned out before adding more code and parameters.

I'm not sure that it is simpler to roll it into costs, because rolling it into costs requires calculating precisely what the cost of these various things ought to be (taking into account the effect of the greater turnaround time on other trains operating on the same line, which impact is itself dependant on the layout of the line, the frequency of the service, etc.), and I cannot for a moment imagine that that is a simple exercise. Indeed, I would not really know how to begin doing it that way, so, if anything, the existing approach is simpler: the simulation works out the cost balance itself rather than relying on constructing a statistical model external to the simulator which must then be checked for accuracy against the simulation itself.

Quotebut firstly I want to make sure we document our decision making as we work through the design. I would say though that before any new feature is coded, or any code is revised, a plain language version should be worked up and circulated on this forum for discussion. Once finalised it forms the instructions for whoever's coding, part of the technical documentation, and raw material for writing help files and manuals for players and pakset builders.

I had tried this in the past, but it had proven somewhat ineffective, as people often struggled to understand the intricacies of the code when presented to them in full detail, so I found that it worked better to give a more generalised overview (just as professional software developers do). Perhaps there might be some advantage to having a wiki somewhere with this information on it so that pakset maintainers can access it for balancing purposes? I would assume that only features relevant to balancing (and not, for example, things such as the new map generation tools or the vehicle replacer) would need to be listed?

As an aside, we seem to have drifted from the original scope of this topic, which was to discuss how to set out a balancing spreadsheet for vehicles, to the discussion of whether the "starting point" should be Standard or Experimental (and hypothetical questions about how features might have been developed had we been starting afresh), which, as explained above, I do not fully understand. I am not quite sure how we have managed to drift in this way, especially as I think that we are now agreed on the importance of using ROI as a base measure from which to start the balancing exercise. I thought that the other topic was intended to address the features that we need to add in order to balance correctly, and this topic was intended to discuss the actual mechanics of balancing itself?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

moblet

Quote from: jamespetts on February 05, 2011, 02:22:52 AM
my starting point is not Standard, but Experimental as it currently stands, and I do not understand why it should be otherwise. I am not building from Standard, but refining Experimental.
This being the case, I think it's probably best that I cease distracting you and let you get on with it.

jamespetts

Quote from: moblet on February 06, 2011, 10:33:19 AM
This being the case, I think it's probably best that I cease distracting you and let you get on with it.

By this do you mean that you are only interested in helping with the balancing if I ignore all the hundreds of hours already put into Experimental and start again from scratch, or something with similar effect? Since there has never been an adequate (or, indeed, really any) explanation as to why that should be done, it should hardly come as a surprise that that that is not something that I am willing to countenance. It simply does not make sense that, if we are looking at making changes to Experimental, the starting point should be anything other than Experimental.

Given that the discourse started with a discussion of specific additions that needed to be made in order to make balancing work properly, which was extremely helpful, I do not understand why the position has now become one in which that discussion cannot continue in the same helpful manner without going back to square one on the entire project for reasons unexplained.

It should go without saying that, had I found your contributions to be no more than a distraction, I should not have responded to them in the first place.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

Risking to causing more confusion by trying an interpretation, i shall do it nontheless.

Quote
By this do you mean that you are only interested in helping with the balancing if I ignore all the hundreds of hours already put into Experimental and start again from scratch, or something with similar effect?
No, it does not mean this has to be ignored. It means starting the analysis based on standard, identifying what standard actually models. (Remember we know quite well what your changes to that model are, but we know not much on what it is based on) Find the assumptions and approximations in that model. Continuing from there it can be identified what is needed to improve the model of standard.

Now the new features and changes already implemented in experimental can be evaluated in regard to those needs.

Here is a continuum of routes between major extremes possible: Standard team is willing to implement the identified needs, if fitting solutions from experimental can be adopted or newly coded with experimentals very valuable experience. Experimental continues as a testbed for new ideas and things not likely to be implemented in standard.

The other extreme would be standard stays more conservative. Experimental features are reevaluated and kept, improved or rejected for a newer experimental (perhaps rename it to 'enhanced'). New dynamics not coded already are implemented.

The reality would be somewhere in-between those extreem solutions.

As an example from what i see it's quite likely that standard implements weight limits, you might to drop your solution and implement the standard one. prissi et al will likely have a look on what you did in experimental and use elements. Perhaps speed boni get droped in standard altogether, or replaced by something else. In that case it would be sensible to do the same in experimental. etc.

To conclude, starting the development of the model at simutrans does not mean the implementation has to be discarded.

jamespetts

What I have trouble understanding is what the issue is with the view that I take that removing an existing feature of Experimental should require just as good a reason as adding a new feature, on which matter I must be firm. As discussed elsewhere, I am keen for Experimental to have what somebody described as a "consolidation phase" where few new features are added and the focus is on refining the existing feature set and producing a well-balanced pakset to go with it, but this is not possible whilst there are still outstanding issues that prevent effective balancing (and other significant problems that affect playability: I have been working on code this week-end which will greatly improve responsiveness in larger games in which private car routes are enabled: testing my code, I was able to load a version of your  "162" game saved with my the latest code from the 9.x branch and have it responsive instantly after loading; I will release a 9.3 when the next stable Standard is released incorporating this feature).

To conclude: fixing bugs and major playability/balance issues ought to be done now, but any major upheaval beyond that strikes me as an unwarranted waste of developer resources that could better be spent elsewhere. Se here for a discussion on the set of changes that I am planning for version 10.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

The key is to evaluate the features already implemented with an open mindset. This means when analysing simutrans model and developing the requirements it must be completely ignored what is in experimental already. (This has the side effect that this is quite useful for standard itself.)

After the need is defined the components of experimental can be evaluated in regard to this. You can compare it with the dissadvantages they bring and the effort to implement. Those things implemented are already in an advantaged position for this, as the cost of implementation or adaption should be quite low.

It is however not a good idea starting this process with the aim not to drop anything unless completely avoidable. In systems theory a fundamental theorem is that adding something, removeing something and doing nothing at all have same chance of improvement. (expectation value for improvement would be zero) In other words: not droping some code that makes your program worse is as bad as not implementing something that is known to improve it.

Now in simutrans-experimental it is not essentially important that the model (and it's implementation) produces reliable results. When evaluating components additional complexity can be weighted less when evaluating the costs.


Also please bear in mind that in software development you don't loose anything if you discard code altogether, regardless if and how you replace it. It served it's function and is the basis on which you do your improvement. In my area it is even very likely that a model is refined with very much effort tested and then disregarded all together, if it's impact on results is not significant. An increase in complexity has much more costs than the manpower, viz computation time, sources of errors and it is contrary to the aim to have the simples model possible to model the physics. This is perhaps more extreme in ab initio or first principles approaches employed in fundamental research.

In moblets field this might be the case too. It's not difficult to say "just drop something" if one is prepared for this to happen for years of own work.

Quote
fixing bugs and major playability/balance issues ought to be done now, but any major upheaval beyond that strikes me as an unwarranted waste of developer resources that could better be spent elsewhere. Se here for a discussion on the set of changes that I am planning for version 10
this sounds as if you would call the project finished after version 10? I think this discussion has a scope far beyond version 10. What the process moblet wants to start provides is a long term scope beyond a few versions. (and perhaps beyond experimental) So far such a long term scope has not been communicated by you, and it would speak very much for you if you don't even have any solid picture there.
Bug fixing and playability issues are always day to day work.

Some of the changes you linked to are quite severe, perhaps you want to postpone then until some analysis. It would be quite dissapointing if the chance to get a solid foundation for experimental would be missed. I'm not sure how much devotion would be for the analysis and model generation, but with current levels this should be quite rapid and if really lucky there could be first visible results in a year or so already!

jamespetts

Quote from: sdog on February 07, 2011, 12:29:12 AM
The key is to evaluate the features already implemented with an open mindset. This means when analysing simutrans model and developing the requirements it must be completely ignored what is in experimental already. (This has the side effect that this is quite useful for standard itself.)

After the need is defined the components of experimental can be evaluated in regard to this. You can compare it with the dissadvantages they bring and the effort to implement. Those things implemented are already in an advantaged position for this, as the cost of implementation or adaption should be quite low.

It is however not a good idea starting this process with the aim not to drop anything unless completely avoidable. In systems theory a fundamental theorem is that adding something, removeing something and doing nothing at all have same chance of improvement. (expectation value for improvement would be zero) In other words: not droping some code that makes your program worse is as bad as not implementing something that is known to improve it.

I don't see how the chain of reasoning follows there: why must what is in Experimental be ignored whilst what is in Standard is not ignored? I do not see any reason for distinction between the two for these purposes.

Further, if, all other things being equal, adding a feature, removing a feature, and leaving things as they are are all equally likely to be good, bad or indifferent, then my position - that as good a reason is needed to remove a feature as to add a feature - is an entirely logical consequence, is it not? Since maintaining the status quo has the advantage of being free of cost, which advantage adding and removing features do not have, maintaining the status quo should be the default position. Any variation from that default position needs a good reason. There is no reason to suppose that one sort of variation (removing a feature) needs any less of a reason than any other.

QuoteNow in simutrans-experimental it is not essentially important that the model (and it's implementation) produces reliable results. When evaluating components additional complexity can be weighted less when evaluating the costs.

I'm not sure what you mean by this, I'm afraid.

Quote
this sounds as if you would call the project finished after version 10? I think this discussion has a scope far beyond version 10. What the process moblet wants to start provides is a long term scope beyond a few versions. (and perhaps beyond experimental) So far such a long term scope has not been communicated by you, and it would speak very much for you if you don't even have any solid picture there.
Bug fixing and playability issues are always day to day work.

I certainly don't intend there never to be another major release of Experimental after version 10! The idea is simply to spend some time consolidating and getting a good playable foundation: there are many other things that could be added in the long term.

QuoteSome of the changes you linked to are quite severe, perhaps you want to postpone then until some analysis. It would be quite dissapointing if the chance to get a solid foundation for experimental would be missed. I'm not sure how much devotion would be for the analysis and model generation, but with current levels this should be quite rapid and if really lucky there could be first visible results in a year or so already!

The purpose of the thread to which I linked was to instigate just that sort of discussion and analysis. It seems clear from the discussion of the ROI model that those economic features are necessary if Simutrans is to balance properly, so they should be implemented as soon as is practicable to enable the creation of a solid and playable version of Experimental together with a well-balanced pakset to be expedited.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

QuoteI don't see how the chain of reasoning follows there: why must what is in Experimental be ignored whilst what is in Standard is not ignored? I do not see any reason for distinction between the two for these purposes.
Following a first principles approach in all consequence would mean to start from nothing. Starting the analysis at standard and evaluating it's model in the light of the requirements of a first principles model is just a practical decission.

It has two major advantages not to start at experimental. First is we know much more about the difference of standard and experimental than we know of standard. To actually understand experimental we would have to understand quite a lot of standard first. Secondly standard is slightly less complex, this helps quite a bit. Thirdly, it will be difficult to get help from some of the core devs of standard to help for an experimental only project. Remember this can be very fruitful for standard too, at least it would provide it with a documentation. At best it would redefine standard and experimental (There was hardly any transfer from experimental to standard so far, main reason was that experimental could not show that it's additions would improve standard.)


QuoteFurther, if, all other things being equal, adding a feature, removing a feature, and leaving things as they are are all equally likely to be good, bad or indifferent, then my position - that as good a reason is needed to remove a feature as to add a feature - is an entirely logical consequence, is it not? Since maintaining the status quo has the advantage of being free of cost, which advantage adding and removing features do not have, maintaining the status quo should be the default position. Any variation from that default position needs a good reason. There is no reason to suppose that one sort of variation (removing a feature) needs any less of a reason than any other.
This is in general quite correct. You just have to be careful from what 'inertial' system you view at the problem. If you view it from standard and evaluate if adding an experimental feature or from experimental and evaluate if it should be removed the outcome should be the same. Implementation costs are practically the same, patching it in or out does not matter. What matters is if the feature has a reason to stay in the simulation, is the benefit of it larger than it's costs.

As mentioned before which system is used as status quo does not matter at all for that. Pragmatic decissions can lead you here.

Quote
Quote
Now in simutrans-experimental it is not essentially important that the model (and it's implementation) produces reliable results. When evaluating components additional complexity can be weighted less when evaluating the costs.

I'm not sure what you mean by this, I'm afraid.
And that is not surprising as it is missing quite a bit of context i only mentioned later. In models in research it is most important that the model is reliably accurate. Any additional line of code could cause errors, any increased complexity of the model can cause inaccurate behaviour. The simpler the program is, the more it can be trusted. This is perhaps the whole core of first principle approaches.

As an example if you want to test classical mechanics against planetary motion of outer planets in our solar system, anything above Hamilton mechanics you put into the model will make it less worth for that purpose.  Simutrans is a game, so this can be quite relaxed. If we think reversing trains are a splendidly fun in the game, while it does not really improve the economic model it would have to go if we would do a first principles simulation of the economy of transport companies. It can (and imho should) stay in a very accurate simulation game however!

I want to say, if we find a feature does not really contribute to the model, we don't have to cancel it if it is not detrimental, the increased complexity can be excluded from the evaluation to some degree. (it still increases maintenance effort)

QuoteIt seems clear from the discussion of the ROI model that those economic features are necessary if Simutrans is to balance properly, so they should be implemented as soon as is practicable to enable the creation of a solid and playable version of Experimental together with a well-balanced pakset to be expedited.
I think this shouldn't be a short time change. Perhaps here you should be clear how the overal economic model should look like. It is nothing pressing afterall, pak britain works well enough for the moment, it is as balanced as pak 128 at least. ROI etc might be a goal for a longer time frame.

It's quite a bit out of place for me to make suggestions on what to do, but i will do so none the less, with great reluctance. Concentration on ironing out network issues, and perhaps a joint integration of the new weight limits might be a lot of work for the immediate future already, without opening this new can of worms prematurely. The industry re-linking seems to be also important.

jamespetts

#47
Quote from: sdog on February 07, 2011, 01:32:09 AM
Following a first principles approach in all consequence would mean to start from nothing. Starting the analysis at standard and evaluating it's model in the light of the requirements of a first principles model is just a practical decission.

It has two major advantages not to start at experimental. First is we know much more about the difference of standard and experimental than we know of standard. To actually understand experimental we would have to understand quite a lot of standard first. Secondly standard is slightly less complex, this helps quite a bit. Thirdly, it will be difficult to get help from some of the core devs of standard to help for an experimental only project. Remember this can be very fruitful for standard too, at least it would provide it with a documentation. At best it would redefine standard and experimental (There was hardly any transfer from experimental to standard so far, main reason was that experimental could not show that it's additions would improve standard.)

I don't agree with this analysis: firstly, the question is, what exactly is the nature of the project on which we are seeking to embark? From what I understood from Moblet's initial posts, it was an analysis of what things needed changing in order to allow Simutrans-Experimental to be well-balanced. Much of that analysis has already been done, identifying the lack of use-related maintenance cost increases and lack of a credit interest rate as significant factors preventing effective balancing between the early/late game, although how much (if any) of that analysis remains is unclear. I have not seen a justification for a more wide-ranging project, nor a clear description of what such a project would entail; in one earlier post, for example, Moblet had implied that such a project might entail the removal of features on the ground of performance alone, even if performance as it currently stands is not unacceptable. I do not consider such work necessary.

Secondly, I do not think that the reasons given are sufficient justifications for taking a starting point of anything other than where we are now in the Experimental project. Indeed, I do not fully understand some of the justifications that you give: you write that the Standard developers might not be interested in helping an Experimental only project, which further begs the question posed above about what exactly this project that is being suggested entails. A documentation project was suggested, and there may be some sense in starting with Standard there (although, again, taking into account all the existing documentation in existence for Standard and building from that rather than throwing it out and starting again), but the same does not apply to making changes to Simutrans itself: the fundamental point is that it is very different in practice to ask if one should remove an existing feature than to ask if one should add a new feature for the reasons that I gave in my previous post, and none of those reasons are displaced to any extent by the fact that Standard is simpler or that we know more about the differences between Standard and Experimental than we do about Standard itself. I don't see how those two things can address the economics of feature changing that I raised in my previous post.

It seems to be simple common sense to say that removing an existing feature requires as much justification as adding a new one. I don't see the justification for any project that entails doing anything other than that.

QuoteThis is in general quite correct. You just have to be careful from what 'inertial' system you view at the problem. If you view it from standard and evaluate if adding an experimental feature or from experimental and evaluate if it should be removed the outcome should be the same. Implementation costs are practically the same, patching it in or out does not matter. What matters is if the feature has a reason to stay in the simulation, is the benefit of it larger than it's costs.

Asking what features to add to Standard only makes sense if one is, in fact, adding features to Standard; not removing features from Experimental is not identical to adding features to Standard, and cannot be treated as equivalent. I, as the maintainer of Experimental, have to work with the code base that I have, that is Experimental. My starting point is, naturally, the Experimental code base. The Standard developers are starting from Standard. The issue of what features from Experimental should be implemented in Standard is very different to the issue of what features, if any, should be removed from Experimental, or what features added to it.

QuoteIn models in research it is most important that the model is reliably accurate. Any additional line of code could cause errors, any increased complexity of the model can cause inaccurate behaviour. The simpler the program is, the more it can be trusted. This is perhaps the whole core of first principle approaches.

Just as adding code gives the opportunity for errors to arise, equally so does removing code.  

QuoteAs an example if you want to test classical mechanics against planetary motion of outer planets in our solar system, anything above Hamilton mechanics you put into the model will make it less worth for that purpose.  Simutrans is a game, so this can be quite relaxed. If we think reversing trains are a splendidly fun in the game, while it does not really improve the economic model it would have to go if we would do a first principles simulation of the economy of transport companies. It can (and imho should) stay in a very accurate simulation game however!

This only makes me more confused about what exactly the "first principles" approach entails and what the justification for taking it is in this instance.

QuoteI think this shouldn't be a short time change. Perhaps here you should be clear how the overal economic model should look like. It is nothing pressing afterall, pak britain works well enough for the moment, it is as balanced as pak 128 at least. ROI etc might be a goal for a longer time frame.

As to the overall economic model - I was quite happy with it as it was until Moblet pointed out that, without certain further specific aspects modelled, it would not work. As a result of that discussion, my vision of the model, in general terms, has been modified to be as it is now plus the things that Moblet mentioned necessary to model in order to permit the paksets to balance properly. The idea of Experimental was only ever to make incremental changes to Standard by adding a few specific features: this discussion has so far done no more than alert me to several other specific features that need to be added.

QuoteIt's quite a bit out of place for me to make suggestions on what to do, but i will do so none the less, with great reluctance. Concentration on ironing out network issues, and perhaps a joint integration of the new weight limits might be a lot of work for the immediate future already, without opening this new can of worms prematurely. The industry re-linking seems to be also important.

Actually, it's very helpful to get an insight into users' opinions of these matters. As you may know, ironing out the network issues is a very difficult task indeed, and I am hampered by having no experience of network programming and nobody else who is available to assist on that at present, apart from general advice given very helpfully by the Standard developers. I hadn't seen much discussion on the various Experimental networking threads, so assumed that that was not the greatest priority at present; but perhaps people interested in networking have simply remained silent?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

Perhaps, i should have asked a long time ago, what your professional or scientific background is. (i've been very curious but thought it might be too intrusive in your real life. If you want to, you could perhaps give me a rough hint via pm?) You might also want to split this from the topic, i post it here though, as it is a direct response.

It seems there is a more fundamental missunderstanding, we're not really talking the same language here. First principles and ab initio are two very important concepts for models in science. The sneaky thing is, both can have slightly different meanings in various disciplines. Slight but very serious consequences.

What they have in common is not using parameters. (in praxis this sometimes means just avoidance, here some of those different meanings are hidden)

In ab initio a set of fundamental theorems is the starting point. In general it is not possible to just calculate something from this. Here i'll take the Schrödinger equation as an example.

The Schrödinger equation is a very simple equation that (we persume) completely describes non relativistic quantum mechanics! But there's a caveat: It can not be solved directly -- except for anything but the most simple problems. One of those problems is calculating the spectral lines of Hydrogen. They can be meassured with extreme accuracy, perhaps you remember Lyman alpha lines from undergrad chemistry or even astronomy. Now we know that the Schroedinger equation is correct up to extreme accuracy (at some point one has to go to more involved theories*).

For more complex systems like Helium a model must be developed. Now you could do a numerical simulation with a couple of parameters, and you could fit them in a way to reproduce the physical properties of He. However you gain hardly anything from this, at best a prediction where you should look for the next line if you know some others. Ab inition you build your model on the Schroedinger equation again, by introducing some well founded assumptions and approximations you can get to a model from which you can calculate the He spectral lines.

This also applies for more complex atoms, and molecules. We need some advanced numerical methods too. Those approximations are well known and have a name. The approximations introduced for the simpler systems might be required for all more complex systems too. An example is Bohr's approximations that we can treat the nucleus and the electrons independently. It is very important to know what approximations were used.

In quantum chemistry those approximations go so far that they calculate the energy ground state of macro-molecules with hundreds of atoms ab initio. (The equivalent of falculating the Lyman alpha line for hyrdogen.) At this level of complexity the approach from a parameter based model, which is ridiculous for Helium, starts to make sense. Often enough there is no sufficient ab initio model, but simulations based on empirical results deliver. As a general trend ab initio is found more often in fundamental research while the other approach is very frequent in applied research. There are of course hybrids also. You might know the physical law for a system but don't know the material dependent constants in it. Here empirical parameters might be used. As an example for this equations describing the behaviour of semi conductor lasers spring to my mind. For different semiconductors and dopings other parameters have to be chosen.

In general the model itself requires a multitude more work and ingenuity than the implementation in code. Typically only the description of the model is published. The code is often either considered insignificant or sometimes also extremely involved but either open sourced or kept secret to have an advantage.

The first principles approach has a number of advantages. Foremost is testing theory. If we can test the Schroedinger equation for Hydrogen directly it shows it is correct for Hydrogen. If a first principles model of it also works for Helium and Lithium we show it is likely valid for all light atoms. First principle models for a multitude of problems in atomic and solid state physics shows it is valid for the whole field. (It's still not a proof!)

A good ab initio model might even show some behaviour not seen in experiments yet, but that is found after knowing where to look. You often hear that theory predicted something that was found/or not at LHC/Hubble telescope/anywhere else. All high energy physics and cosomology works more or less works like that. Just to much noise or data to find anything unless you know very exactly what to look for.

Another advantage is, and this is much more useful here, the lack of parameters makes it easy to apply an ab initio model if it is good. You don't have to make a large number of empirical tests to find parameters and test them. It suffices to have a lot of empirical data to test if the model is correct.

Now the biggest power lies here looking at an ab initio model that accurately models a real life system, and does so with the least possible complexity, we understand the real life system! We see what really is important, and what is completely unimportant. For example having an ab initio model of vast masses of people moving, we can see they behave exactly like sand grains flowing down. We find that it is important to have wide openings, and put an obstacle two meters before this opening to prevent clogging. As individual decissions are not important we see it doesn't matter to have detailed signs, we need just something to get them into one direction (equals gravity for grains). One can also see they do not behave like water, which does not clog in front of openings, sand does so therefor the obstacle to speed things up. This model is of course not a pure first principles model, humans are no sand grains, while grain size and friction are material constants for grain, they are likely free parameters for humans. If we get such parameters for english or chinese, we could also model other occasions where masses of people move with the same parameters! E.g model what happens if a dense crowd of people suddenly starts to spread into a large open area.

For simutrans a real first principles approach does not seem possible to me. However, building a model with first principles as an ideal in mind might be a good idea. This is opposed to just use a parameter based model that is tweaked to give some acceptable results. Following a philosophy close to first principles could avoid tweaking at all.

We would build the model as good as we can, and then we look first at direct economic data, optimize the model. If the time dependent factors are also included, at one point we should be able to reproduce some of the historical results you researched so far from the sim. Important here, doing so without tweaking it to get those results or planing the sim to arrive there.


*Here's something extremely thrilling comming up from LHC soon, precission spectroscopy of anti-hydrogen (anti matter version of hydrogen atoms). Some extremely small differences are predicted, breaking the symmetry between matter and anti-matter (CP violation). This would explain the biggest mystery of the big bang, if matter and anti-matter formed condensed from energy, why was there more matter than anti-matter. We know the last part for the simple fact that we are.

sdog

#49
now answering directly to james previous message
Quote from: jamespetts on February 07, 2011, 02:19:28 AM
I don't agree with this analysis: firstly, the question is, what exactly is the nature of the project on which we are seeking to embark? ...
Analysing the problem and building a model for a transport simulation. For practical reasons it should be deviated from first principles and started by analysing a working implementation in simutrans.

When the model in simutrans is understood, the step to simutrans experimental is very small. You know already what has changed, you documented it in part, and it is much less.


Quotefor example, Moblet had implied that such a project might entail the removal of features on the ground of performance alone, even if performance as it currently stands is not unacceptable. I do not consider such work necessary.
I really can't see your problem here. Of course should a feature be removed if it's benefit does not outweigh it's cost. Performance is definitely a cost. I also do not think moblet came to any conclusion what weights to give to any factor, including performance. If it is decided that performance has a relatively low weight a feature that gets removed because of this must have been next to useless. Denying the possiblility to remove a feature of the game at all makes the whole process pointless.

Quote
Secondly, I do not think that the reasons given are sufficient justifications for taking a starting point of anything other than where we are now in the Experimental project. Indeed, I do not fully understand some of the justifications that you give: you write that the Standard developers might not be interested in helping an Experimental only project, which further begs the question posed above about what exactly this project that is being suggested entails.
A documentation project was suggested, and there may be some sense in starting with Standard there (although, again, taking into account all the existing documentation in existence for Standard and building from that rather than throwing it out and starting again), but the same does not apply to making changes to Simutrans itself:
Documentation is a side effect of finding of developing a model. At the moment noone really knows what happens in simutrans. Some people, like prissi or Hajo have a very good understanding. But even those two do not have the full picture i think.

Quote
the fundamental point is that it is very different in practice to ask if one should remove an existing feature than to ask if one should add a new feature for the reasons that I gave in my previous post,
At best at a practical point of view. It is also not a very important issue at the moment. Also i hope i don't hurt you by suggesting this, you invested quite a lot of work. Now some people who did nothing at all come and question everything. As said before, i'm used to the thought all my work will be in vain. (This happened with one year of work for my first thesis) Try not to be attached too much to code, and don't forget at the end it is not automatic, but still your decission to keep or reject code. Afterall you would be certain it is detrimental before you would drop anything.

Quote
It seems to be simple common sense to say that removing an existing feature requires as much justification as adding a new one. I don't see the justification for any project that entails doing anything other than that.
Exactly that is the reason why it should not matter at all if you build your model based on standard or experimental. If you have feature A that has to be included in standard to make it a perfect simulation, this means also it has to be kept in experimental to make it a perfect simulation. The other way round if feature B must not be included in standard to make it a perfect simulation, it should be removed from experimental too. As if it was beneficial we would have to include it in standard. This is of course a hypothetical case, you see i used perfect simulation. In praxi you can relax the argument. Feature C doesn't really bring anything, but it doesn't really hurt either, so keep it if it's already there, but it's perhaps not worth to do anything to get it.

QuoteAsking what features to add to Standard only makes sense if one is, in fact, adding features to Standard; not removing features from Experimental is not identical to adding features to Standard, and cannot be treated as equivalent. I, as the maintainer of Experimental, have to work with the code base that I have, that is Experimental. My starting point is, naturally, the Experimental code base. The Standard developers are starting from Standard. The issue of what features from Experimental should be implemented in Standard is very different to the issue of what features, if any, should be removed from Experimental, or what features added to it.
Implementation or code base does not matter for the model. The model provides you with an end point you would like to reach, if we get there from first principles, from standard, or experimental does not matter at all. Starting from standard or experimental only makes it easier to identify what specifically is needed and what real restrictions are there.

If standard has the set of components S, experimental has E and an the desired model M. A comparison of S and M would show that the major dynamics  A,B,C are required. A comparison of S and E shows that E has the additional dynamics B,C,D. It would require A to be implemented and D which is not necessary to be tested if it is detrimental.

Now if you start from experimental, you find by comparing E and M that it would need A to be implemented and that D is superfluous. To improve standard to the state of the model, comparing S and E and the requirements from comparing M and E shows that S would require the sets B and C implemented from experimental and A needs to be newly coded.

Quote
Just as adding code gives the opportunity for errors to arise, equally so does removing code. 
at point of implementation, but if that code was superfluous for the model, not for the simulation and not for long term maintenance.
Quote
This only makes me more confused about what exactly the "first principles" approach entails and what the justification for taking it is in this instance.
see my very long previous message

Quote
As to the overall economic model - I was quite happy with it as it was until Moblet pointed out that, without certain further specific aspects modelled, it would not work. As a result of that discussion, my vision of the model, in general terms, has been modified to be as it is now plus the things that Moblet mentioned necessary to model in order to permit the paksets to balance properly. The idea of Experimental was only ever to make incremental changes to Standard by adding a few specific features: this discussion has so far done no more than alert me to several other specific features that need to be added.
in what moblet suggested above, the main work lies not necessarily in coding those features, but in finding out what is needed. Moblet showed us very impressively that a) we don't know what the sim is doing and b) the anticipated economic model is extremely ambitious. (in particular as it should hold over three centuries, with very different environment) If he manages to build a working model, and doing it rigorously, he would have material for more than one paper or a master thesis in economy.

Quote
Actually, it's very helpful to get an insight into users' opinions of these matters. As you may know, ironing out the network issues is a very difficult task indeed, and I am hampered by having no experience of network programming and nobody else who is available to assist on that at present, apart from general advice given very helpfully by the Standard developers. I hadn't seen much discussion on the various Experimental networking threads, so assumed that that was not the greatest priority at present; but perhaps people interested in networking have simply remained silent?
My guess, everyone else is just too lost or intimidated by the task. There will be massive testing required too. I avoid it like the pest, as  i still remember what a personal fiasko it was when i tried to test the network code on timothy's server just for a few moments.

moblet

Thanks for chiming in and articulating these things, sdog. And yes, I think you understand perfectly where I'm coming from!
Quote from: sdogi'm used to the thought all my work will be in vain.
One has to adopt this mindset when undertaking any research, investigation, or modelling. Edison put the most positive spin on it when trying to identify a substance that would work as a light bulb filament. After testing over 1,000 materials without success, he didn't say he'd failed to reach his goal, he said he'd successfully proven that all of those substances were unsuitable for use as light bulb filament. I'd estimate that about a third of the effort I've expended in my professional career never achieved anything as far as its intended purpose was concerned. Some of it, however, improved my skills or dynamical understanding, but perhaps most importantly the experiences of "acceptance" and "rejection" taught me how to identify why some efforts were spectacularly successful, while others were doomed from the outset. I would get excited about stuff I was doing, as I'm sure sdog did too, but I never dared to become emotionally attached to its ultimate implementation.
Quote from: sdogThe key is to evaluate the features already implemented with an open mindset.
I can't stress this enough. In this line of work it's impossible to get good results without an open mindset, and trying to work alongside someone who is attached to particular components is a red flag for me. I'm not going to commit effort to something that my experience tells me is bound to come unstuck.
Quote from: sdogAt the moment noone really knows what happens in simutrans.
Laughed when I read this, but it's true, and it's the first reason why I've been proposing using Standard as the initial reference. By this I have always meant first studying Standard, not necessarily using Standard as the first modelling iteration or for evaluation of proposed Experimental features. My gut feeling is that in practice we would, after a period of developing understanding, ultimately find ourselves working from a simplified version of Experimental, say with its introduced non-linearities switched off. Note also that some of what's already coded in Experimental can give us the opportunity to directly compare two options (e.g. of passenger trip choice algorithms), should we want to do this.
Quote from: sdogMy guess, everyone else is just too lost or intimidated by the task. There will be massive testing required too.
I think that's one reason. It certainly looks daunting until one realises that it can be broken up into little independent pieces, and each piece can be distributed to any willing player to do a test run and send the data back. It's also low-stress work, and the thinking bit can be fun.
Another reason may be that, as sdog has tried to explain, the planning and development of Experimental has not followed the route familiar to most modellers/programmers/scientists, so some may be unsure of when, where, and how to contribute their ideas.

jamespetts

To answer SDog's initial question: I am a barrister by profession, and, although interested in the natural sciences, have no formal scientific or mathematical training beyond secondary school. I was not aware that either "first principles" or "ab initio" were being used here as terms of art: "ab initio" does have a particular meaning in law, where it is used to refer to putting people back in the same position as they were before the happening of a particular event (such as entering into a contract). Literally translated from Latin, I think that it means something like "from the start". Is this what you intend here?

Do I understand you correctly that, in very brief summary, ab initio in the scientific sense refers to modelling by extrapolating from assumptions, and the "first principles" approach (is this the same as the "parameter" approach?) involves starting without assumptions and letting the model replicate the thing being simulated itself? If this is so, it is interesting to note that transport simulators (that is, professional grade, non-game transport simulators used for real-world transport planning) come in both flavours, and both, apparently, have their own strengths and weaknesses (the assumptions system being quicker and simpler, but only useful in so far as the assumptions are sufficiently complete and accurate, which itself is not always easy to measure accurately). In this context, the terms that I have heard used are "bottom up" for what I think that you call the first principles approach, and "top down" for what I think that you call the ab initio approach.

Turning to the more practical issues, the project on which we are engaged cannot, realistically, be to ask what we would do if we were starting from scratch, but rather to ask what we should do given where we are now. If we were starting from scratch, for example, I'd do away with direct specification of prices all together and instead model prices based on relative fuel/labour/raw materials costs and some sort of model for relative inflation between the various types of cost. We cannot engage in the somewhat indulgent exercise of asking what would an ideal model of a transport network look like without keeping a firm eye on questions of implementation at every step, as there is no point in designing an ideal model if the resources to implement it within a sane timescale are lacking. There is no point in undertaking an exercise of designing a model from the ground up in isolation from the reality that that model has to be implemented, and that it has to be implemented in the existing Simutrans-Experimental code.

For those reasons, I do not think that the task in which we can practically be engaged can be described as,

"Analysing the problem and building a model for a transport simulation. For practical reasons it should be deviated from first principles and started by analysing a working implementation in simutrans."

The nature of the task is not building a model for a transport simulation, it is refining and improving an existing transport simulation which already has its own (albeit imperfect) model, which model will need careful consideration in the process of the refining and improving process.

In any event, nothing written so far seems to be any reason at all to depart from what seems to me to be an obviously correct approach that removing a feature requires the same degree of justification as adding a feature. That it does not matter for the purposes of (re-)designing the theoretical model that underpins Simutrans-Experimental whether one asks whether any given feature that is already in Experimental ought be added to Standard or removed from Experimental does not mean that it does not matter at all, as it certainly matters at the implementation stage. All other things being equal, leaving things as they are is the only sensible default.

Quote from: SdogIf standard has the set of components S, experimental has E and an the desired model M. A comparison of S and M would show that the major dynamics  A,B,C are required. A comparison of S and E shows that E has the additional dynamics B,C,D. It would require A to be implemented and D which is not necessary to be tested if it is detrimental.

Now if you start from experimental, you find by comparing E and M that it would need A to be implemented and that D is superfluous. To improve standard to the state of the model, comparing S and E and the requirements from comparing M and E shows that S would require the sets B and C implemented from experimental and A needs to be newly coded.

In the above example, I see no reason to take steps to remove D unless there is some good and specific reason to suppose that Simutrans-Experimental with D is a worse game than Simutrans-Experimental without D. From what I understand from what is being proposed, D would in that example be removed, which is why I disagree with what is proposed.

It is not, incidentally, any irrational reticence to remove features simply because I have expended effort on them: I am more than happy to remove things on which I have expended effort when there is a good reason to do so (such as the original implementation of the Simutrans-Experimental routing algorithm, which was replaced entirely by Knightly by an algorithm that was superior in every way to that which it replaced). What I do not think, however, is necessary is removing (or, indeed, making changes to) features when there is no good reason to do so. There is nothing wrong with evaluating existing features with an open mindset, providing that an open mindset means a willingness to change features where a good reason is shown so to change, not a willingness to change features whether or not a good reason is shown.

I do not see why it is necessary in order properly to document Simutrans (Standard and Experimental) and to improve the economic modelling in Experimental (or both) that any features be removed where there is not shown a good reason for removing them, or why my willingness or otherwise to remove features where there is no good reason shown for their removal should be determinative of whether others are interested in working on such a project. Perhaps I have misunderstood what is being suggested, and nobody is really suggesting that at all - if so, my apologies (accompanied by a humble request for what was really meant to be re-explained). If, however, I have not misunderstood what is being suggested, I remain perplexed at the position. Given that we are all fond of Simutrans and all want to see the quality and realism of the economic simulation in the game improving, it makes no sense to be interested in being involved in a project to improve that quality and realism only if and in so far as I am willing to remove existing features even where no specific reason is shown in favour of their removal. (It should be noted as an aside that many features can be extensively tuned, in many cases to the point of being effectively disabled entirely, using simuconf.tab parameters).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

It seems i was not very clear about ab initio and first principles, i want to correct this here and provide another example to show the difference to other models, using parameters. First principles and ab initio are used roughly synonymously. (there are some distinctions in quantum chemistry, this might be the case in other fields too)

The starting point for ab initio are, in physics, physical laws, so they are the first principles, in the meaning the most fundamental ones. Assumptions have to be made to reduce the problem to something that can be treated. For example to calculate earths orbit we neglect the rest of the universe. The assumptions define the boundary conditions and approximations to be made.

Typically ab initio or first principle methods require much more complicated calculations than parameter based models. The gain is much higher flexibility. Eg. you can get a lot of empirical data and find parameters or better coefficients to estimate the wear of a road with your pocket calculator. It would perhaps be a ponylomial (i'm guessing here, best ask banksie) a m^4 + b m^3 + c m^2 + d m + e. The real effort is in getting the coefficients. An approach closer to first principles would perhaps model energy deposition, shear and tensions into the road. Typically you have to solve systems of differential equations. This is much more effort but it might provide results for other materials or other effects. (and will perhaps be used to get the coefficients.)

QuoteIn the above example, I see no reason to take steps to remove D unless there is some good and specific reason to suppose that Simutrans-Experimental with D is a worse game than Simutrans-Experimental without D. From what I understand from what is being proposed, D would in that example be removed, which is why I disagree with what is proposed. ...

In the example D would be removed, but not without reason. And if i understood you correctly, you would remove D too, if there is a reason. The reason would be it has more disadvantages to keep D than the benefit it brings. Let me have a very direct example, and i want to point out this is only a hypothetical example:

Let us assume moblet finds the speed bonus system causes very strong distortions to the economy, greatly unbalancing the income. He finds that a system by giving trains that leave at odd hours of the day twice the money and apply black magick to trains leaving at even hours is exactly what happens in the real world and can be implemented. In that case i think you would have no objections to drop the speed bonus system?

Now modify this a little bit. The speed bonus is still fubar in this example, completely skewed results. But moblet finds that no such system at all will provide exactly the correct results. Do you think the speed bonus must be kept?

I took the speed bonus for this example not only as it might very well have a detrimental influence on balance, but also because it was coded in experimental by trying to improve a system from standard that seemd completely absurd. Providing speed boni to vehicles just because they have a higher speed.

Now we learned this was as false assumption by almost anyone around, they did it only to have an incentive in pakHajo or pak64 to use more modern vehicles or rather to compensate for the higher running costs of those. In other words it was a solution specifically taylored to a problem in a pak set. It was named a bit missleadingly and after a while other pak set creators thought it is some system to give a bonuse for fast deliveries!

This should also illustrate that we don't know anything about simutrans. In fact it is even worse, we believe things about simutrans. This might very well be wrong.

Here i understand prissis reservations towards experimental much better now. My guess is he does not have the ambition to model reality, he's quite happy with a good game that behaves plausibly or should i say believably.

If you want to put a simutrans that should simulate economy and transportation realisticaly on this. And you also have the ambition it should reflect historical developments and work stable over more than two centuries, you might be trying to build a bridge from Dover to Calais on a sand-castle as foundation.

At this point i would like to say that i do not suggest using an ab inito or first principles approach or anything near it. I don't suggest against it either. It can be extremely large gains, it could work not at all, in any case it will be extremely much and difficult work i think.
I'm not sure if moblet would pull it and be willing to do so. The good thing is, if done properly at any time it is broken off, there would be a documentation on simutrans as side effect.

Oh, and of course i would very much like to see such a project, very exciting!

I think you're at a point where you have to decide in what direction you want simutrans to move.

- A technology testbed for things to be included in standard?
- A framework to run pak britain
- A realistic simulation (with a high risk of failure)

Instead of moblets approach you might decide to tweak experimental to get some degree of balance. You might add some additional refinements to the economy, but to get some balance it is not completely unlikely you have to resort to some 'cheating'. Eg introduce artificial money sinks.

Quote
It should be noted as an aside that many features can be extensively tuned, in many cases to the point of being effectively disabled entirely, using simuconf.tab parameters.
This is very good for testing. It is, however, extremely bad coding practice to leave code that is turned off in the code. There are at least two major reasons, first you gain nothing. After a couple of revisions it will not work anymore without major rewrite. The second reason is those parts have the nasty habit of being considered to be still active (wrong assumptions), they might get turned on unknowingly (wrong model), they hinder refactoring of code or maintenance. It is a very clear rule. If it is not needed, delete it! If you happen to need it in two years, you can always get it from your backups or git repo.

moblet

Quote from: sdog on February 08, 2011, 04:40:50 AM
At this point i would like to say that i do not suggest using an ab inito or first principles approach or anything near it. I don't suggest against it either. It can be extremely large gains, it could work not at all, in any case it will be extremely much and difficult work i think.
I'm not sure if moblet would pull it and be willing to do so.
When I used the words "first principles" I was thinking in terms of us deciding, before anything else, what fundamental economic and physical principles were important to us. Having done that, then dive into understanding what Standard actually does, all the while with a vision of the "ultimate" Simutrans in the backs of our minds.
I'm quite happy to pull this initially. Once the process starts it will become apparent that it's not impossible, and is relatively uncomplicated, and others should have no problem grasping what to do and pulling it forwards themselves. From the beginning we'd need at least a group of three intellectually engaged with it, preferably many more. There would need to be some degree of organisation and succession planning though because of the uncertainties of my health, which is not predictable in the short to medium term, so it would be a case of aiming to make me as dispensable as possible as early as possible.

jamespetts

Quote from: sdog on February 08, 2011, 04:40:50 AM
It seems i was not very clear about ab initio and first principles, i want to correct this here and provide another example to show the difference to other models, using parameters. First principles and ab initio are used roughly synonymously. (there are some distinctions in quantum chemistry, this might be the case in other fields too)

The starting point for ab initio are, in physics, physical laws, so they are the first principles, in the meaning the most fundamental ones. Assumptions have to be made to reduce the problem to something that can be treated. For example to calculate earths orbit we neglect the rest of the universe. The assumptions define the boundary conditions and approximations to be made.

Typically ab initio or first principle methods require much more complicated calculations than parameter based models. The gain is much higher flexibility. Eg. you can get a lot of empirical data and find parameters or better coefficients to estimate the wear of a road with your pocket calculator. It would perhaps be a ponylomial (i'm guessing here, best ask banksie) a m^4 + b m^3 + c m^2 + d m + e. The real effort is in getting the coefficients. An approach closer to first principles would perhaps model energy deposition, shear and tensions into the road. Typically you have to solve systems of differential equations. This is much more effort but it might provide results for other materials or other effects. (and will perhaps be used to get the coefficients.)

Ahh, I think that I see - so both "first principles" and ab initio are "top down" approaches, whereas the parameter model is a "bottom up" approach? I'm not sure that I understand the distinction at this stage between ab initio and "first principles", but perhaps I don't have to understand that for these purposes. The real issue, as you write, is finding the appropriate coefficients: if there are known specific and tested models for particular things that we want to model, then using those sort of formulae may well be sensible; but if these things are unknown, then a "bottom up" approach is probably preferable. One example where there seem to be known formulae is in relation to road surface wear (as discussed by banksie_82), so it would seem sensible to use those formulae in that field.

QuoteIn the example D would be removed, but not without reason. And if i understood you correctly, you would remove D too, if there is a reason. The reason would be it has more disadvantages to keep D than the benefit it brings. Let me have a very direct example, and i want to point out this is only a hypothetical example:

Let us assume moblet finds the speed bonus system causes very strong distortions to the economy, greatly unbalancing the income. He finds that a system by giving trains that leave at odd hours of the day twice the money and apply black magick to trains leaving at even hours is exactly what happens in the real world and can be implemented. In that case i think you would have no objections to drop the speed bonus system?

Now modify this a little bit. The speed bonus is still fubar in this example, completely skewed results. But moblet finds that no such system at all will provide exactly the correct results. Do you think the speed bonus must be kept?

In your example, the speed bonus would not be removed because of a presumption that features whose benefit in terms of the economic model cannot clearly shown be removed; it would be removed because there was a reason specific to that feature (viz. that it caused significant economic distortions) to remove it. Of course, it should only be removed if there is an alternative (including the system of having flat income despite the journey speeds: i.e., having no speed bonus at all) that causes fewer distortions.

In reality, the price for a journey does vary significantly depending on travel speeds (particularly in relation to alternative travel available on that route, although this element would be difficult to model in Simutrans without introducing an affordability model, which I'd prefer to avoid to prevent players from having to, or having an incentive to and being unable to, micromanage prices), so our simulation would be lacking an important element of reality (a price incentive to reduce journey times) if it did not model what is modelled by the speed bonus in some way or another.

The approach that I take, as mentioned before, in deciding what things to include in the economic model are to discover what is, in fact, economically important in reality and model those. If, in the model, those things turn out not to be significant, then it does not mean that they should be removed, but rather that they are not modelled properly, as, if they were modelled properly, they would have the same significant effect as they have in reality (Moblet's point about the uncertainties of reality can only apply to a few economic effects, as not many significant such factors are dependant on such uncertain contingencies, and it should be easy to identify from a knowledge of reality which ones are and which ones are not so dependant).

QuoteI took the speed bonus for this example not only as it might very well have a detrimental influence on balance, but also because it was coded in experimental by trying to improve a system from standard that seemd completely absurd. Providing speed boni to vehicles just because they have a higher speed.

Now we learned this was as false assumption by almost anyone around, they did it only to have an incentive in pakHajo or pak64 to use more modern vehicles or rather to compensate for the higher running costs of those. In other words it was a solution specifically taylored to a problem in a pak set. It was named a bit missleadingly and after a while other pak set creators thought it is some system to give a bonuse for fast deliveries!

This should also illustrate that we don't know anything about simutrans. In fact it is even worse, we believe things about simutrans. This might very well be wrong.

Here i understand prissis reservations towards experimental much better now. My guess is he does not have the ambition to model reality, he's quite happy with a good game that behaves plausibly or should i say believably.

Ahh - and that is where the objectives of Standard and Experimental diverge! It is the reason that we have two separate branches of Simutrans in the first place.

QuoteIf you want to put a simutrans that should simulate economy and transportation realisticaly on this. And you also have the ambition it should reflect historical developments and work stable over more than two centuries, you might be trying to build a bridge from Dover to Calais on a sand-castle as foundation.

At this point i would like to say that i do not suggest using an ab inito or first principles approach or anything near it. I don't suggest against it either. It can be extremely large gains, it could work not at all, in any case it will be extremely much and difficult work i think.
I'm not sure if moblet would pull it and be willing to do so. The good thing is, if done properly at any time it is broken off, there would be a documentation on simutrans as side effect.

Oh, and of course i would very much like to see such a project, very exciting!

I think you're at a point where you have to decide in what direction you want simutrans to move.

- A technology testbed for things to be included in standard?
- A framework to run pak britain
- A realistic simulation (with a high risk of failure)

Instead of moblets approach you might decide to tweak experimental to get some degree of balance. You might add some additional refinements to the economy, but to get some balance it is not completely unlikely you have to resort to some 'cheating'. Eg introduce artificial money sinks.

I'd like it to be a realistic but fun simulation game - I think that my aim for Experimental I described quite precisely in an earlier post on this (or perhaps the other) thread; the aim is not the same as it would be for professional/commercial non-game software used for modelling transport networks, which is why I use the phrase "simulation game" rather than "simulation"; it must be realistic enough that, within the parameters of what is explicit to the user, a user's decision about how to manage the network will be more or less similarly sensible in the game as it would be in reality (so that, for example, using high-speed express trains on local routes would not be a sensible decision, as it often is in Standard). I'd also like it to be able to engage with the delightful intricacies of various historical features of real transport networks without forcing the player to micromanage: see the discussion of the liveries feature, for example. I particularly like the idea that, when looking at a well established and long developed game, the history of that network in the game should be readily apparent.

QuoteThis is very good for testing. It is, however, extremely bad coding practice to leave code that is turned off in the code. There are at least two major reasons, first you gain nothing. After a couple of revisions it will not work anymore without major rewrite. The second reason is those parts have the nasty habit of being considered to be still active (wrong assumptions), they might get turned on unknowingly (wrong model), they hinder refactoring of code or maintenance. It is a very clear rule. If it is not needed, delete it! If you happen to need it in two years, you can always get it from your backups or git repo.

If things are disabled at the pakset level, then they are not entirely turned off, as other pakset developers might want to use the features. There is at least one other Simutrans-Experimental pakset currently in development (Pak.German-Exp), and the developers of that pakset might want to take different decisions than the developers of Pak128.Britain-Ex about which features are used.

One thing that might be able to go for this reason, however, are the remnants of the original routing system that I had written before Knightly coded the centralised pathfinding system; these were retained in case Knightly's system did not work with the network mode. Ironically, it turned out that the distributed pathfinding system did not work in network mode, and Knightly has now modified his centralised system such that it does work in network mode.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

sdog

QuoteIn your example, the speed bonus would not be removed because of a presumption that features whose benefit in terms of the economic model cannot clearly shown be removed; it would be removed because there was a reason specific to that feature (viz. that it caused significant economic distortions) to remove it. [...] If, in the model, those things turn out not to be significant, then it does not mean that they should be removed, but rather that they are not modelled properly, as, if they were modelled properly, they would have the same significant effect as they have in reality (Moblet's point about the uncertainties of reality can only apply to a few economic effects, as not many significant such factors are dependant on such uncertain contingencies, and it should be easy to identify from a knowledge of reality which ones are and which ones are not so dependant).
Why should something stay if it turns out not to have any effect? Either we find that an effect is needed, but it fails to model it. In that case it can be removed and something new should be coded. Or it has no effect and no effect is required. There is no reason to keep this subsystem, it can be removed, not urgently. But it would be a waste of time to keep it in other versions if it does nothing at all.

Now, here i diverge quite a bit from moblet, i think. If it has no economic effect, it might very well stay if it has not detrimental economic effect but a game play benefit, or models some other aspects of a transport simulation. Reversing trains might be a good example for this. Colourful pak sets instead of plain symbols are another.

moblet

Quote from: sdog on February 08, 2011, 04:04:25 PM
Now, here i diverge quite a bit from moblet, i think. If it has no economic effect, it might very well stay if it has not detrimental economic effect but a game play benefit, or models some other aspects of a transport simulation. Reversing trains might be a good example for this. Colourful pak sets instead of plain symbols are another.
No serious diversion. From a project management perspective I can't help thinking that there are unlimited additions that would offer gameplay benefits, so I see a need for a cost-conscious process for selecting the "best" ones, otherwise everything can be included. Simutrans isn't only about economics, it's got to remain a cute transport simulation too  :)

jamespetts

It seems that the issue on whether to remove features is a rather marginal one in the grand scheme of things, especially as it is vanishingly improbable that any given feature will have literally no effect at all on the game, whether economic, cosmetic or otherwise. My point is simply that, in cases of doubt, the default position should be to preserve the status quo. The highly improbable finding that a given feature certainly has literally no impact whatsoever on any aspect of the game whatsoever is not a case of doubt.

Hopefully having moved passed that issue, perhaps we can return to the more pressing issues of the structure of the proposed project and who is to do what? It would be very good to make some serious progress in this regard, as having a well-balanced game would substantially improve the enjoyment that can be derived from it by all.
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.

neroden

Quote from: sdog on February 06, 2011, 08:17:29 PM
Here is a continuum of routes between major extremes possible: Standard team is willing to implement the identified needs, if fitting solutions from experimental can be adopted or newly coded with experimentals very valuable experience.
The standard team has explicitly refused to implement the single most important change in experimental -- the switch to revenue based on average or actual speeds rather than theoretical top speeds.  This is relatively simple to implement in at least three different ways (ahem), and is absolutely necessary in order to provide any semblance of realism (the "TGV-on-sand-track" bug), but so far they have simply refused to consider it.

As long as that is the case, I do not think there is any point in considering standard as the baseline for balancing -- it cannot be balanced while being plausible because of the bug which they are unwilling to fix.  If the willingness to fix this changes, we can reconsider.

Just to point out my view here.