Started by moblet, January 09, 2011, 12:28:56 PM
0 Members and 1 Guest are viewing this topic.
Quote from: jamespetts on January 09, 2011, 12:55:57 PMOne 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).
Quote from: Jamesthe revenue per kilometre is fixed, whereas, in Simutrans-Experimental, the revenue per kilometre can vary greatly
Quote from: The HoodI've found in the balancing I've done in Standard the spreadsheet method isn't infallible
Quote from: Jamesall vehicles have a linearly-depreciated age-based resale value
Quote from: Jamescarriages get heavier throughout the game
Quote from: moblet on January 09, 2011, 02:45:06 PMYes, 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...
QuoteOf course the trains have to be special . 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.
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.
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.
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.
QuoteNo one's shot that down so far, although sdog is yet to chime in...
Quote from: jamespetts on January 09, 2011, 03:13:36 PMI 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?
Quote from: JamesIf not, then, given that we're trying to simulate reality, we'll be failing if we adopt this model.
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.
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.
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).
Quote from: sdog on January 10, 2011, 07:06:30 AMi'll avoid to look into the spreadsheets now, i have to distract myself a bit less.
Quote from: moblet on January 09, 2011, 12:28:56 PMHere's a simple and merely conceptual first draft.
Quote from: moblet on January 10, 2011, 11:14:38 AMProbably. 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"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.
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.
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.
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.
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.
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
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.
Quote from: JamesIn 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?
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.
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.
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.
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.
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
Quote from: Jamesbut it would be somewhat arbitrary to equalise the profitability of all types of vehicles,
Quote from: Jamesas they may well not have been equal in reality,
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
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
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
Quote from: Jamesrather than aiming to equalise the profits entirely.
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?
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.
Quote from: Jamesthings capable of earning greatly higher revenues do, indeed, cost much more than those that aren't.
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
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.
Quote from: mobletI haven't reached a conclusion as to whether infrastructure also needs a finite life for balancing to work.
Quote from: JamesI haven't been ignoring this discussion
Quote from: sdog on January 18, 2011, 05:01:38 AMLeasing 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?
Quote from: sdogFor instance in pak128 depreciation slowly drives one bancrupt.
Quote from: sdog on January 18, 2011, 11:27:10 PMat the beginning it's not unusual to build for about 350k of the 400k one has, and buy vehicles for some 5M.
Quote from: AEO on January 19, 2011, 10:30:39 PMWith the current speed bonus and goods settings
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.
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.
Quote from: jamespetts on January 24, 2011, 12:48:14 AMFourthly, 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.
Quote from: moblet on January 11, 2011, 06:38:55 AMThere 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).
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.
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.
Quote from: JamesSixthly, there may have been some confusion as to the meaning of comparable profitabilities
Quote from: JamesSeventlhy, 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.
Quote from: MobletSince 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.
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.
Quote from: jamespetts on January 28, 2011, 01:29:10 AMI 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: jamespetts on January 28, 2011, 01:29:10 AMI 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.
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.
Quote from: jamespetts on January 28, 2011, 01:29:10 AMLet me give two historical examples and see whether your model would produce the same results.
Quote from: JamesWould the ROI equalisation model not demand that trolleybuses cost more somewhere to compensate for their advantages?
Quote from: MobletFrom 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).
QuoteAs 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
QuoteThe 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.
QuoteSteam 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.
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.
Quote from: AEOsome 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.
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;
Quote from: sdog on February 01, 2011, 05:42:27 AMYou 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.
Quote from: jamespetts on January 31, 2011, 11:18:55 PMThe 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?
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?
Quote from: JamesI assume that all the various steam graphs are on top of each other in the straight line in the middle?
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.
Quote from: JamesPresumably, there are cases on the margins where one doesn't make a loss by electrifying, but also just makes less profit?
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.).
Quote from: JamesYes, indeed! The next question is how we go about doing that starting from where we are now...
QuoteOur goal is make sure the way these strategies pan out is economically realistic.
QuoteI 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.
QuoteAs 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?
Quote from: neroden on January 10, 2011, 09:42:04 PMEDIT: 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. :-PI know bridge prices need to be scaled to the scale because elevated track prices are, that would be a start...
Quote from: jamespetts on February 02, 2011, 08:36:17 PMStandard is too simplified for my tastes
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?
Quote from: JamesWhilst 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.
Quote from: JamesWould the purpose of the exercise that you are suggesting be to identify more such issues (and, ultimately, solutions for them)?
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.
Quote from: JamesThe view that I take is that, if it adds something positive to the game, there is no reason to remove it.
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
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.
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.
Quote from: JamesTo continue with the example of private cars
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.
QuoteWhere 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.
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.
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.
QuoteThe 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.
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.
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.
Quote from: jamespetts on February 05, 2011, 02:22:52 AMmy 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.
Quote from: moblet on February 06, 2011, 10:33:19 AMThis being the case, I think it's probably best that I cease distracting you and let you get on with it.
QuoteBy 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?
Quotefixing 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
Quote from: sdog on February 07, 2011, 12:29:12 AMThe 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.
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.
Quotethis 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.
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!
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.
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.
QuoteQuoteNow 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.
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.
Quote from: sdog on February 07, 2011, 01:32:09 AMFollowing 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.)
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.
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.
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!
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.
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.
Quote from: jamespetts on February 07, 2011, 02:19:28 AMI 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? ...
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.
QuoteSecondly, 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:
Quotethe 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,
QuoteIt 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.
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.
QuoteJust as adding code gives the opportunity for errors to arise, equally so does removing code.
QuoteThis only makes me more confused about what exactly the "first principles" approach entails and what the justification for taking it is in this instance.
QuoteAs 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.
QuoteActually, 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?
Quote from: sdogi'm used to the thought all my work will be in vain.
Quote from: sdogThe key is to evaluate the features already implemented with an open mindset.
Quote from: sdogAt the moment noone really knows what happens in simutrans.
Quote from: sdogMy guess, everyone else is just too lost or intimidated by the task. There will be massive testing required too.
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.
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. ...
QuoteIt 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.
Quote from: sdog on February 08, 2011, 04:40:50 AMAt 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.
Quote from: sdog on February 08, 2011, 04:40:50 AMIt 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 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?
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.
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.
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.
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).
Quote from: sdog on February 08, 2011, 04:04:25 PMNow, 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.
Quote from: sdog on February 06, 2011, 08:17:29 PMHere 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.